Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAL0YbF02603 for ietf-xml-mime-bks; Tue, 20 Nov 2001 16:34:37 -0800 (PST) Received: from mail.asahi-net.or.jp (mail.asahi-net.or.jp [202.224.39.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAL0Ya802594 for ; Tue, 20 Nov 2001 16:34:36 -0800 (PST) Received: from localhost (j082008.ppp.asahi-net.or.jp [61.213.82.8]) by mail.asahi-net.or.jp (Postfix) with ESMTP id A50A5A400; Wed, 21 Nov 2001 09:34:27 +0900 (JST) Date: Wed, 21 Nov 2001 09:38:05 +0900 (JST) Message-Id: <20011121.093805.34921812.murata@hokkaido.email.ne.jp> To: ian.graham@utoronto.ca, igraham@ic-unix.ic.utoronto.ca Cc: ned+xml-mime@mrochek.com, davidc@nag.co.uk, ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: Re: [xml-dev] Registration status From: MURATA Makoto In-Reply-To: References: <01KAUAR4BJ86001D5Q@mauve.mrochek.com> X-Mailer: Mew version 2.1rc1 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Ian Graham Subject: Re: [xml-dev] Registration status Date: Sun, 18 Nov 2001 18:26:30 -0500 (EST) > I think (ii) is the $1000 question. A $500 question might be: "Did the > authors of RFC 3023 consider the RFC 2912 mechanism for providing internal > data about XML typed data?" (RFC 2912 isn't mentioned in 3023). Yes, we were aware of RFC 2912. We thus did not try to solve problems addressed by it. I am happy to mention it in the next RFC for XML media types. Cheers, Makoto Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJ0o5U28972 for ietf-xml-mime-bks; Sun, 18 Nov 2001 16:50:05 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJ0o4828968 for ; Sun, 18 Nov 2001 16:50:04 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KAT0W0QXQO001H9E@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Sun, 18 Nov 2001 16:49:55 -0800 (PST) Date: Sun, 18 Nov 2001 16:46:36 -0800 (PST) From: ned+xml-mime@mrochek.com Subject: Re: [xml-dev] Registration status In-reply-to: "Your message dated Sun, 18 Nov 2001 18:26:30 -0500 (EST)" To: Ian Graham Cc: ned+xml-mime@mrochek.com, MURATA Makoto , ian.graham@utoronto.ca, davidc@nag.co.uk, ietf-xml-mime@imc.org, xml-dev@lists.xml.org Message-id: <01KAUUDFAJMQ001H9E@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01KAUAR4BJ86001D5Q@mauve.mrochek.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > i is a solved problem. ii remains to be seen. Thus far I've seen little use > > made of this facility. > I think (ii) is the $1000 question. A $500 question might be: "Did the > authors of RFC 3023 consider the RFC 2912 mechanism for providing internal > data about XML typed data?" (RFC 2912 isn't mentioned in 3023). While I suppose that feature lists could be used as a dispatch mechanism, it isn't intended to be one, and in no way obviates the need for propoer MIME types so dispatching can be done effectively. > I can imagine many possible reasons (e.g., easy adaptation for current > MIME dispatchers), but would like to know which one the authors found most > compelling. You'd have to ask them. At the time I was certainly aware of the mechanism, but I didn't suggest it for the simple reason that I believe it to be completely inappropriate in the context of what RFC 3023 seeks to do. That doesn't mean it couldn't be a useful adjunct to RFC 3023, of course. Ned Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJ0iRh28826 for ietf-xml-mime-bks; Sun, 18 Nov 2001 16:44:27 -0800 (PST) Received: from ic-unix.ic.utoronto.ca (ic-unix.ic.utoronto.ca [142.150.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJ0iF828817 for ; Sun, 18 Nov 2001 16:44:15 -0800 (PST) Received: from localhost (igraham@localhost) by ic-unix.ic.utoronto.ca (8.9.3+Sun/8.9.1) with ESMTP id TAA16278; Sun, 18 Nov 2001 19:35:35 -0500 (EST) Date: Sun, 18 Nov 2001 19:35:35 -0500 (EST) From: Ian Graham Reply-To: Ian Graham To: Ian Graham cc: ned+xml-mime@mrochek.com, MURATA Makoto , davidc@nag.co.uk, ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: Re: [xml-dev] Registration status (corr.) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 18 Nov 2001, Ian Graham wrote: ... > I think (ii) is the $1000 question. A $500 question might be: "Did the > authors of RFC 3023 consider the RFC 2912 mechanism for providing internal > data about XML typed data?" (RFC 2912 isn't mentioned in 3023). > > I can imagine many possible reasons (e.g., easy adaptation for current > MIME dispatchers), but would like to know which one the authors found most > compelling. > By which I meant to say "I can imagine many possible reasons for the model presented in RFC 3023 (...." Ian Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAINYer27097 for ietf-xml-mime-bks; Sun, 18 Nov 2001 15:34:40 -0800 (PST) Received: from ic-unix.ic.utoronto.ca (ic-unix.ic.utoronto.ca [142.150.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAINYT827089 for ; Sun, 18 Nov 2001 15:34:29 -0800 (PST) Received: from localhost (igraham@localhost) by ic-unix.ic.utoronto.ca (8.9.3+Sun/8.9.1) with ESMTP id SAA13910; Sun, 18 Nov 2001 18:26:30 -0500 (EST) Date: Sun, 18 Nov 2001 18:26:30 -0500 (EST) From: Ian Graham Reply-To: Ian Graham To: ned+xml-mime@mrochek.com cc: MURATA Makoto , ian.graham@utoronto.ca, davidc@nag.co.uk, ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: Re: [xml-dev] Registration status In-Reply-To: <01KAUAR4BJ86001D5Q@mauve.mrochek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 18 Nov 2001 ned+xml-mime@mrochek.com wrote: > > > My thinking is that, if an application is XML aware, it can take take > > advantage of namespace identifiers to obtain more detailed 'subtype' data > > than a content-type header can provide. The rationale for expanding this > > outside of the content-type header is that the header is too limited to > > express much detail about the payload content -- and, as you quite rightly > > note, the parameter extension mechanism is largely ignored. > > Defining additional header fields for this purpose is NOT the answer. > There's already a very complete, extensible system for indicating media > features in MIME. See RFC 2912 for details. Thank you for this -- the mechanism described in 2912 (with syntax detailed in RFC 2566) seems to allow for all that I (and I believe others) have suggested, and much more. > Defining the necessary tags for namespace identifiers and so on would seem > to me to be reasonably straightforward. Yes. > > The background questions, however, are these -- i) how can you reveal more > > about the type of a MIME part, and ii) how useful would that information > > really be. > > i is a solved problem. ii remains to be seen. Thus far I've seen little use > made of this facility. I think (ii) is the $1000 question. A $500 question might be: "Did the authors of RFC 3023 consider the RFC 2912 mechanism for providing internal data about XML typed data?" (RFC 2912 isn't mentioned in 3023). I can imagine many possible reasons (e.g., easy adaptation for current MIME dispatchers), but would like to know which one the authors found most compelling. I'd also am curious to know if others see the contet-features: header as an appropriate mechanisms for providing additional 'internal' data about XML message parts. Best wishes -- Ian Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAIFSIR00840 for ietf-xml-mime-bks; Sun, 18 Nov 2001 07:28:18 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAIFSH800836 for ; Sun, 18 Nov 2001 07:28:17 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KAUA2RVH9C001D5Q@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Sun, 18 Nov 2001 07:28:18 -0800 (PST) Date: Sun, 18 Nov 2001 07:24:45 -0800 (PST) From: ned+xml-mime@mrochek.com Subject: Re: [xml-dev] Registration status In-reply-to: "Your message dated Fri, 16 Nov 2001 19:00:09 -0500 (EST)" To: Ian Graham Cc: MURATA Makoto , ian.graham@utoronto.ca, davidc@nag.co.uk, ietf-xml-mime@imc.org, xml-dev@lists.xml.org Message-id: <01KAUAR4BJ86001D5Q@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20011117.020107.127170929.murata@hokkaido.email.ne.jp> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > My thinking is that, if an application is XML aware, it can take take > advantage of namespace identifiers to obtain more detailed 'subtype' data > than a content-type header can provide. The rationale for expanding this > outside of the content-type header is that the header is too limited to > express much detail about the payload content -- and, as you quite rightly > note, the parameter extension mechanism is largely ignored. Defining additional header fields for this purpose is NOT the answer. There's already a very complete, extensible system for indicating media features in MIME. See RFC 2912 for details. Defining the necessary tags for namespace identifiers and so on would seem to me to be reasonably straightforward. > The background questions, however, are these -- i) how can you reveal more > about the type of a MIME part, and ii) how useful would that information > really be. i is a solved problem. ii remains to be seen. Thus far I've seen little use made of this facility. Ned Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAH08Mp03938 for ietf-xml-mime-bks; Fri, 16 Nov 2001 16:08:22 -0800 (PST) Received: from ic-unix.ic.utoronto.ca (ic-unix.ic.utoronto.ca [142.150.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH08B803921 for ; Fri, 16 Nov 2001 16:08:12 -0800 (PST) Received: from localhost (igraham@localhost) by ic-unix.ic.utoronto.ca (8.9.3+Sun/8.9.1) with ESMTP id TAA16802; Fri, 16 Nov 2001 19:00:09 -0500 (EST) Date: Fri, 16 Nov 2001 19:00:09 -0500 (EST) From: Ian Graham Reply-To: Ian Graham To: MURATA Makoto cc: ian.graham@utoronto.ca, davidc@nag.co.uk, ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: Re: [xml-dev] Registration status In-Reply-To: <20011117.020107.127170929.murata@hokkaido.email.ne.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 17 Nov 2001, MURATA Makoto wrote: > From: Ian Graham > Subject: Re: [xml-dev] Registration status > Date: Thu, 15 Nov 2001 18:49:00 -0500 (EST) > > > Any thoughts? > > It is not clear to me how your proposal solves problems > described in Appendix A (especially, A.5) of RFC 3023. > > > A.5 Why not use a MIME parameter to specify that a media type uses XML > > syntax? > > > > For example, one could use "Content-Type: application/iotp; > > alternate-type=text/xml" or "Content-Type: application/iotp; > > syntax=xml". > > > > Section 5 of [RFC2045] says that "Parameters are modifiers of the > > media subtype, and as such do not fundamentally affect the nature of > > the content". However, all XML-based media types are by their nature > > always XML. Parameters, as they have been defined in the MIME > > architecture, are never invariant across all instantiations of a > > media type. > > > > More practically, very few if any MIME dispatchers and other MIME > > agents support dispatching off of a parameter. While MIME agents on > > the receiving side will need to be updated in either case to support > > (or fall back to) generic XML processing, it has been suggested that > > it is easier to implement this functionality when acting off of the > > media type rather than a parameter. More important, sending agents > > require no update to properly tag an image as "image/svg+xml", but > > few if any sending agents currently support always tagging certain > > content types with a parameter. My thinking is that, if an application is XML aware, it can take take advantage of namespace identifiers to obtain more detailed 'subtype' data than a content-type header can provide. The rationale for expanding this outside of the content-type header is that the header is too limited to express much detail about the payload content -- and, as you quite rightly note, the parameter extension mechanism is largely ignored. Another issue would be multiply-typed data -- for example, an SVG document containing MathML and XHTML. If an app is keying on the SVG content type, then it may simply refuse to let me do anything with it, even if the app can ignore the SVG but still display the rest. However, I should note that a namespace identification mechanism can't handle backward-compatibility, nor can it handle things like */dtd+xml, so I would see a role for both. The background questions, however, are these -- i) how can you reveal more about the type of a MIME part, and ii) how useful would that information really be. I think some on these lists are struggling with these questions. Best wishes -- Ian Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAG9dBL07921 for ietf-xml-mime-bks; Fri, 16 Nov 2001 01:39:11 -0800 (PST) Received: from mail17.messagelabs.com (mail17.messagelabs.com [62.231.131.67]) by above.proper.com (8.11.6/8.11.3) with SMTP id fAG9dA807915 for ; Fri, 16 Nov 2001 01:39:10 -0800 (PST) X-VirusChecked: Checked Received: (qmail 12949 invoked from network); 16 Nov 2001 09:38:42 -0000 Received: from unknown (HELO nag.co.uk) (62.231.145.242) by server-7.tower-17.messagelabs.com with SMTP; 16 Nov 2001 09:38:42 -0000 Received: from penguin.nag.co.uk (IDENT:root@penguin.nag.co.uk [192.156.217.14]) by nag.co.uk (8.9.3/8.9.3) with ESMTP id JAA01785; Fri, 16 Nov 2001 09:38:46 GMT Date: Fri, 16 Nov 2001 09:38:44 GMT Message-Id: <200111160938.JAA07671@penguin.nag.co.uk> Received: by penguin.nag.co.uk (8.9.3) id JAA07671; Fri, 16 Nov 2001 09:38:44 GMT From: David Carlisle To: ian.graham@utoronto.ca CC: ietf-xml-mime@imc.org, xml-dev@lists.xml.org In-reply-to: (message from Ian Graham on Thu, 15 Nov 2001 18:49:00 -0500 (EST)) Subject: Re: [xml-dev] Registration status References: Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Any thoughts? sounds reasonable to me, although I vaguely remember some previous discussion as to why having separate xxx+xml types was thought preferable to having extra information layered over the xml type. David _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAFNusX04263 for ietf-xml-mime-bks; Thu, 15 Nov 2001 15:56:54 -0800 (PST) Received: from ic-unix.ic.utoronto.ca (ic-unix.ic.utoronto.ca [142.150.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFNuq804258 for ; Thu, 15 Nov 2001 15:56:52 -0800 (PST) Received: from localhost (igraham@localhost) by ic-unix.ic.utoronto.ca (8.9.3+Sun/8.9.1) with ESMTP id SAA01611; Thu, 15 Nov 2001 18:49:00 -0500 (EST) Date: Thu, 15 Nov 2001 18:49:00 -0500 (EST) From: Ian Graham Reply-To: Ian Graham To: David Carlisle cc: ietf-xml-mime@imc.org, xml-dev@lists.xml.org Subject: Re: [xml-dev] Registration status In-Reply-To: <200110290944.JAA11486@penguin.nag.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 29 Oct 2001, David Carlisle wrote: Sorry for delay (been off line ...) > > having to upgrade that installed base is exactly the problem with > the xxx+xml proposals. If XML is served as text or application/xml .... > > But if your mail agent comes across an xxx+xml document and it doesn't > know this type, basically it's stumped. It won't even (currently) by > default do the "obvious" thing of dropping the xxx+ and trying the more > general xml mime type. > > you say > > > This of course, is all IMHO, as RFC 3023 explicitly supports you > > serving all XML as application/xml if you really want to. But as A.15 > > mentions, there are no apparent downsides from using custom types and > > several advantages. > .... > > Incidentally it seems to be widely held belief that text/xml was a > mistake and that xml ought almost always be in application/xml. I don't > really hold that view. For decades TeX users have sent tex markup as > plain text emails and been more or less happy. I don't see > (document-oriented) XML as significantly different. If someone sends me > some email with some mathematics in, and I'm sat at a machine without a > mathml renderer, I'd much rather just see the mathml markup inline > (which can be read, in small doses, honestly:-) than just be offered a > file/save option on the grounds that the lovingly constructed > mathematics is just unreadable application specific data. I've been thinking about this one a bit more, and perhaps a useful alternative would be to expand upon the XML 'type' information with extra XML-specific headers ... something like: Content-type: text/mathml xml-primary-namespace: http://www.whatever.org/namespace xml-secondary-namespace: http://some.other.org/namespace xml-secondary-namespace: http://and.another.org/namespace Older MIME-aware applications would just use content-type, and ignore the rest, while newer 'XML-aware' applications could use the namepace headers to more finely 'type' the message content, and process it appropriately. Any thoughts? Ian