Received: by above.proper.com (8.11.6/8.11.3) id g0U4hTa12182 for ietf-xml-mime-bks; Tue, 29 Jan 2002 20:43:29 -0800 (PST) Received: from virginia.yamato.ibm.co.jp (virginia.yamato.ibm.co.jp [203.141.89.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0U4hN312177 for ; Tue, 29 Jan 2002 20:43:23 -0800 (PST) Received: from ns.trl.ibm.com (ns.trl.ibm.com [9.116.48.18]) by virginia.yamato.ibm.co.jp (8.11.6/3.7W/GW3.3) with ESMTP id g0U4hE107902; Wed, 30 Jan 2002 13:43:20 +0900 Received: from localhost by ns.trl.ibm.com (AIX4.3/8.9.3/TRL4.5SRV) id NAA19414; Wed, 30 Jan 2002 13:43:14 +0900 Date: Wed, 30 Jan 2002 13:38:38 +0900 (JST) Message-Id: <20020130.133838.78214563.mmurata@trl.ibm.com> To: ian.graham@utoronto.ca, igraham@ic-unix.ic.utoronto.ca Cc: simonstl@simonstl.com, ietf-xml-mime@imc.org Subject: Re: Internet-Draft: Media Feature - xmlns From: MURATA Makoto In-Reply-To: References: <1011891879.5317.347.camel@localhost.localdomain> X-Mailer: Mew version 2.1 on Emacs 20.4 / 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: Internet-Draft: Media Feature - xmlns Date: Thu, 24 Jan 2002 23:45:29 -0500 (EST) > > > On 24 Jan 2002, Simon St.Laurent wrote: > > > > > On Wed, 2002-01-23 at 22:14, Ian Graham wrote: > > > My only suggestion, for what it's worth, would be to allow for the > > > declaration (and please don't overinterpret that word ;-) ) of the 'root' > > > namespace for a document. That seems a reasonable distinction to make, > > > although you'd then have to define how such a statement interacts with > > > content-type declarations such as application/xml+mathml (would that, in > > > some twisted way, imply a default 'root'-level namespace, and if so, > > > how?). > > > > Personally, I believe that the root namespace is not a definitive guide > > to the contents of the document. The XSLT case is prominent, but there > ... > > Well, in practice there is only one namespace distinction you can make -- > between the 'root' namespace and all others. Specifying both classes thus > provides, _all_ the namespace information you can provide in the absence > of the complete document instance. It seemed to me silly to avoid > providing this information when it's so easy to (notationally) do so. I do not think that importance of a "root" namespace is that obvious. Some people (including me) would like to allow an XML document to have a sequence of "root" elements rather than a single root element. Such XML will be much more appropriate for log files. I even heard that one widely-used XML parser already has a hidden option to allow such XML documents. If such an extension becomes part of XML, a document may have more than one top-level namespace. Cheers, Makoto Received: by above.proper.com (8.11.6/8.11.3) id g0P50b618263 for ietf-xml-mime-bks; Thu, 24 Jan 2002 21:00:37 -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 g0P50Z318258 for ; Thu, 24 Jan 2002 21:00:36 -0800 (PST) Received: from localhost (igraham@localhost) by ic-unix.ic.utoronto.ca (8.9.3+Sun/8.9.1) with ESMTP id XAA10413; Thu, 24 Jan 2002 23:51:27 -0500 (EST) Date: Thu, 24 Jan 2002 23:51:27 -0500 (EST) From: Ian Graham Reply-To: Ian Graham To: Mark Baker cc: "Simon St.Laurent" , Ian Graham , ietf-xml-mime@imc.org Subject: Re: Internet-Draft: Media Feature - xmlns In-Reply-To: <200201241714.MAA22189@markbaker.ca> 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 Thu, 24 Jan 2002, Mark Baker wrote: > > Personally, I believe that the root namespace is not a definitive guide > > to the contents of the document. > > I agree. It *can* be used as an indicator of the first processor to > be handed the document (after the one dispatched from the media type), > but it need not as we've seen. > > FWIW, my new media type will require that content expects that it will > be processed in this manner. But */xml and */*+xml don't have any > such requirement. IN retrospect I realize that XML content-types really just define a 'most important' namespace, in the sense that they reference the first layer of 'xml-aware' software that should handle the resource. Following on this model, I find that Simon's draft makes more sense (to me) if I think of it as defining the 'relative importance' of different namespaces in the data, particularly when 'q' values are used to define quality parameters. Looking at it this way make the content-features header a more natural extension on information provided by the content-type. So, in a sense, this takes the set of namespaces in a document (root + all others) and maps them into a different set that weights the different namespaces in an application-specific manner.... Ian Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0P4sbY18015 for ietf-xml-mime-bks; Thu, 24 Jan 2002 20:54:37 -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 g0P4sZ318011 for ; Thu, 24 Jan 2002 20:54:36 -0800 (PST) Received: from localhost (igraham@localhost) by ic-unix.ic.utoronto.ca (8.9.3+Sun/8.9.1) with ESMTP id XAA10260; Thu, 24 Jan 2002 23:45:30 -0500 (EST) Date: Thu, 24 Jan 2002 23:45:29 -0500 (EST) From: Ian Graham Reply-To: Ian Graham To: "Simon St.Laurent" cc: Ian Graham , ietf-xml-mime@imc.org Subject: Re: Internet-Draft: Media Feature - xmlns In-Reply-To: <1011891879.5317.347.camel@localhost.localdomain> 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 24 Jan 2002, Simon St.Laurent wrote: > > On Wed, 2002-01-23 at 22:14, Ian Graham wrote: > > My only suggestion, for what it's worth, would be to allow for the > > declaration (and please don't overinterpret that word ;-) ) of the 'root' > > namespace for a document. That seems a reasonable distinction to make, > > although you'd then have to define how such a statement interacts with > > content-type declarations such as application/xml+mathml (would that, in > > some twisted way, imply a default 'root'-level namespace, and if so, > > how?). > > Personally, I believe that the root namespace is not a definitive guide > to the contents of the document. The XSLT case is prominent, but there ... Well, in practice there is only one namespace distinction you can make -- between the 'root' namespace and all others. Specifying both classes thus provides, _all_ the namespace information you can provide in the absence of the complete document instance. It seemed to me silly to avoid providing this information when it's so easy to (notationally) do so. Ian Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0OHCl128846 for ietf-xml-mime-bks; Thu, 24 Jan 2002 09:12:47 -0800 (PST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OHCj328842 for ; Thu, 24 Jan 2002 09:12:45 -0800 (PST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id MAA22189; Thu, 24 Jan 2002 12:14:24 -0500 Message-Id: <200201241714.MAA22189@markbaker.ca> Subject: Re: Internet-Draft: Media Feature - xmlns To: simonstl@simonstl.com (Simon St.Laurent) Date: Thu, 24 Jan 2002 12:14:24 -0500 (EST) Cc: ian.graham@utoronto.ca (Ian Graham), ietf-xml-mime@imc.org In-Reply-To: <1011891879.5317.347.camel@localhost.localdomain> from "Simon St.Laurent" at Jan 24, 2002 12:04:38 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] 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: > Personally, I believe that the root namespace is not a definitive guide > to the contents of the document. I agree. It *can* be used as an indicator of the first processor to be handed the document (after the one dispatched from the media type), but it need not as we've seen. FWIW, my new media type will require that content expects that it will be processed in this manner. But */xml and */*+xml don't have any such requirement. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com Received: by above.proper.com (8.11.6/8.11.3) id g0OG2wU24479 for ietf-xml-mime-bks; Thu, 24 Jan 2002 08:02:58 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OG2u324473 for ; Thu, 24 Jan 2002 08:02:57 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0OG0KT30129; Thu, 24 Jan 2002 11:00:21 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: Internet-Draft: Media Feature - xmlns From: "Simon St.Laurent" To: Ian Graham Cc: ietf-xml-mime@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 12:04:38 -0500 Message-Id: <1011891879.5317.347.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2002-01-23 at 22:14, Ian Graham wrote: > My only suggestion, for what it's worth, would be to allow for the > declaration (and please don't overinterpret that word ;-) ) of the 'root' > namespace for a document. That seems a reasonable distinction to make, > although you'd then have to define how such a statement interacts with > content-type declarations such as application/xml+mathml (would that, in > some twisted way, imply a default 'root'-level namespace, and if so, > how?). Personally, I believe that the root namespace is not a definitive guide to the contents of the document. The XSLT case is prominent, but there are other cases where the root namespace has a tenuous connection or no connection to the content's processing. Other mechanisms for establishing the MIME Media Type seem to be more effective in these cases, especially for the XSLT case. On the other hand, I wouldn't heartily oppose a registration of "rootxmlns" or somesuch. I suspect it rates a separate registration document, however, as the issues it raises are both more substantive than (potential conflict with Media Type) and different from the issues raised by a simple list of namespace URIs. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0OFnc823669 for ietf-xml-mime-bks; Thu, 24 Jan 2002 07:49:38 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OFnb323663 for ; Thu, 24 Jan 2002 07:49:37 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0OFnZT29614 for ; Thu, 24 Jan 2002 10:49:35 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: new release of Registration of xmlns Media Feature Tag From: "Simon St.Laurent" To: ietf-xml-mime@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 24 Jan 2002 11:53:52 -0500 Message-Id: <1011891233.5317.336.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IETF has just published a new draft of "Registration of xmlns Media Feature Tag". http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-01.txt This new version fixes a number of typos, notably missing colons in the examples. It also adds a section on "Relation to MIME Media Types". I'm also maintaining both an archive of these drafts and the currently open (unsubmitted) draft at: http://simonstl.com/ietf/ Current modifications include making it explicit that order doesn't matter in use of the xmlns feature, and adding support for "no default namespace" (xmlns=""). Comments and suggestions are welcome. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0O6big24874 for ietf-xml-mime-bks; Wed, 23 Jan 2002 22:37:44 -0800 (PST) Received: from virginia.yamato.ibm.co.jp (virginia.yamato.ibm.co.jp [203.141.89.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0O6bg324870 for ; Wed, 23 Jan 2002 22:37:42 -0800 (PST) Received: from ns.trl.ibm.com (ns.trl.ibm.com [9.116.48.18]) by virginia.yamato.ibm.co.jp (8.11.6/3.7W/GW3.3) with ESMTP id g0O6bd128010; Thu, 24 Jan 2002 15:37:39 +0900 Received: from localhost by ns.trl.ibm.com (AIX4.3/8.9.3/TRL4.5SRV) id PAA18326; Thu, 24 Jan 2002 15:37:39 +0900 Date: Thu, 24 Jan 2002 15:33:09 +0900 (JST) Message-Id: <20020124.153309.01369827.mmurata@trl.ibm.com> To: ian.graham@utoronto.ca, igraham@ic-unix.ic.utoronto.ca Cc: simonstl@simonstl.com, ietf-xml-mime@imc.org Subject: Re: Internet-Draft: Media Feature - xmlns From: MURATA Makoto In-Reply-To: References: <1011655788.1480.58.camel@localhost.localdomain> X-Mailer: Mew version 2.1 on Emacs 20.4 / 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: > My only suggestion, for what it's worth, would be to allow for the > declaration (and please don't overinterpret that word ;-) ) of the 'root' > namespace for a document. That seems a reasonable distinction to make, I am not convinced. In the case of XSLT, the root of an XSLT stylesheet do not always belong to the XSLT namespace. Why is the top-level namespace so important? >although you'd then have to define how such a statement interacts with >content-type declarations such as application/xml+mathml (would that, in >some twisted way, imply a default 'root'-level namespace, and if so, >how?). I think that this is a good reason NOT to introduce special handling of the top-level namespace. Cheers, Makoto Received: by above.proper.com (8.11.6/8.11.3) id g0O3NY820402 for ietf-xml-mime-bks; Wed, 23 Jan 2002 19:23:34 -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 g0O3NW320393 for ; Wed, 23 Jan 2002 19:23:32 -0800 (PST) Received: from localhost (igraham@localhost) by ic-unix.ic.utoronto.ca (8.9.3+Sun/8.9.1) with ESMTP id WAA23422; Wed, 23 Jan 2002 22:14:26 -0500 (EST) Date: Wed, 23 Jan 2002 22:14:26 -0500 (EST) From: Ian Graham Reply-To: Ian Graham To: "Simon St.Laurent" cc: ietf-xml-mime@imc.org Subject: Re: Internet-Draft: Media Feature - xmlns In-Reply-To: <1011655788.1480.58.camel@localhost.localdomain> 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: My only suggestion, for what it's worth, would be to allow for the declaration (and please don't overinterpret that word ;-) ) of the 'root' namespace for a document. That seems a reasonable distinction to make, although you'd then have to define how such a statement interacts with content-type declarations such as application/xml+mathml (would that, in some twisted way, imply a default 'root'-level namespace, and if so, how?). Ian (who is very loopy after a long day at work cut off from the surrealistic world of xml-dev) On 21 Jan 2002, Simon St.Laurent wrote: > > I'm happy to announce the availability of an Internet-Draft, > Registration of xmlns Media Feature Tag, which: > --------------------- > registers a media feature tag 'xmlns', per RFC 2506, > intended for use in a Content-features header to indicate > the XML namespaces used in an XML document. This information > augments MIME content-type information, providing a finer granularity > of content description for XML documents. > --------------------- > http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-00.txt > > This is different work from the XML Media Types work done in RFC 3023, > but this list seems the most appropriate place to discuss it. > > -- > Simon St.Laurent > Ring around the content, a pocket full of brackets > Errors, errors, all fall down! > http://simonstl.com > > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LMPYj19668 for ietf-xml-mime-bks; Mon, 21 Jan 2002 14:25:34 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LMPW319664 for ; Mon, 21 Jan 2002 14:25:32 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0LMPTE16580 for ; Mon, 21 Jan 2002 17:25:29 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Internet-Draft: Media Feature - xmlns From: "Simon St.Laurent" To: ietf-xml-mime@imc.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 21 Jan 2002 18:29:47 -0500 Message-Id: <1011655788.1480.58.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm happy to announce the availability of an Internet-Draft, Registration of xmlns Media Feature Tag, which: --------------------- registers a media feature tag 'xmlns', per RFC 2506, intended for use in a Content-features header to indicate the XML namespaces used in an XML document. This information augments MIME content-type information, providing a finer granularity of content description for XML documents. --------------------- http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-00.txt This is different work from the XML Media Types work done in RFC 3023, but this list seems the most appropriate place to discuss it. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: by above.proper.com (8.11.6/8.11.3) id g0KMPwp02499 for ietf-xml-mime-bks; Sun, 20 Jan 2002 14:25:58 -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 g0KMPt302495 for ; Sun, 20 Jan 2002 14:25:55 -0800 (PST) Received: from localhost (igraham@localhost) by ic-unix.ic.utoronto.ca (8.9.3+Sun/8.9.1) with ESMTP id RAA02081; Sun, 20 Jan 2002 17:16:44 -0500 (EST) Date: Sun, 20 Jan 2002 17:16:43 -0500 (EST) From: Ian Graham Reply-To: Ian Graham To: Graham Klyne cc: Ian Graham , ietf-xml-mime@imc.org Subject: Re: Media types In-Reply-To: <5.1.0.14.2.20020118112649.03c61870@joy.songbird.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 Fri, 18 Jan 2002, Graham Klyne wrote: > > At 08:51 PM 1/17/02 -0500, Ian Graham wrote: > >MIME really doesn't give you a nice way of defining multipe properties for > >a single resource, other than the media features extension described > >in RFC 2912. Using this extension (Designed for a different purpose, BTW) > >you could write something like: > > Not so very different... > > >Content-Type: text/xml; > >Content-features: > > (& (primary-namespace="uri1") > > (secondary-namespace="uri2") > > ... > > ) > > > >The question then is -- does that really give you anything particularly > >useful over text/xml+whatever? Once I started to think through some > >uses, I honestly couldn't think of a compelling advantage ... > > ... it gives fine grained content feature description with sufficient > detail to form a basis for content negotiation. The work had (some of) > its roots in recognition of the fact that the content type alone was > insufficient for effective content negotiation in HTTP. .... > (I'm not suggesting all this is relevant to the current debate, just trying > to answer the question you raise.) I do agree, but at the same time I couldn't, in the context of projects I was working on, find a use case that cried out for this approach. In many cases it seemed easier to user XML messaging to do the content negotiation, and use a 'base' XML dialect to bootstrap content negotiation, for example. Thus my 'no compelling advantage' comment. The arguement for the current approach over this (or any other) extended approach was apparently based on pragmatics: most existing MIME type handlers only pay attention to the content type, and moreover ignore any property extension added to the field (e.g., content-type: text/xml;namespace="foo") Thus, the application/xml+svg was the 'easiest' solution that would work with a minimum of fus with essentially all mime handlers. (I'm paraphrasing this argument from correspondence by Simon St. Laurent and "MURATA, Makoto" -- I accept full blame for any misrepresentations) Best -- Ian Received: by above.proper.com (8.11.6/8.11.3) id g0IBkCN17025 for ietf-xml-mime-bks; Fri, 18 Jan 2002 03:46:12 -0800 (PST) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IBkB317021 for ; Fri, 18 Jan 2002 03:46:11 -0800 (PST) Received: from GK-VAIO.NineByNine.org (dyn47-32.sftm-212-159.plus.net [212.159.32.47]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g0IJYe407211; Fri, 18 Jan 2002 11:34:40 -0800 Message-Id: <5.1.0.14.2.20020118112649.03c61870@joy.songbird.com> X-Sender: gk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Jan 2002 11:41:21 +0000 To: Ian Graham From: Graham Klyne Subject: Re: Media types Cc: ietf-xml-mime@imc.org In-Reply-To: References: <1011301539.859.61.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 08:51 PM 1/17/02 -0500, Ian Graham wrote: >MIME really doesn't give you a nice way of defining multipe properties for >a single resource, other than the media features extension described >in RFC 2912. Using this extension (Designed for a different purpose, BTW) >you could write something like: Not so very different... >Content-Type: text/xml; >Content-features: > (& (primary-namespace="uri1") > (secondary-namespace="uri2") > ... > ) > >The question then is -- does that really give you anything particularly >useful over text/xml+whatever? Once I started to think through some >uses, I honestly couldn't think of a compelling advantage ... ... it gives fine grained content feature description with sufficient detail to form a basis for content negotiation. The work had (some of) its roots in recognition of the fact that the content type alone was insufficient for effective content negotiation in HTTP. It also allows one a (limited) capability to describe dependencies between features (e.g. raw text in English and French, HTML in English only, or an image with Japanese content). (I'm not suggesting all this is relevant to the current debate, just trying to answer the question you raise.) #g -------------------------- __ /\ \ Graham Klyne / \ \ (GK@ACM.ORG) / /\ \ \ / / /\ \ \ / / /__\_\ \ / / /________\ \/___________/ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IBg6f16572 for ietf-xml-mime-bks; Fri, 18 Jan 2002 03:42:06 -0800 (PST) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IBg5316568 for ; Fri, 18 Jan 2002 03:42:05 -0800 (PST) Received: from GK-VAIO.NineByNine.org (dyn139-40.sftm-212-159.plus.net [212.159.40.139]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g0IJUZ407183; Fri, 18 Jan 2002 11:30:35 -0800 Message-Id: <5.1.0.14.2.20020118111237.03c62b80@joy.songbird.com> X-Sender: gk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 18 Jan 2002 11:23:11 +0000 To: "Simon St.Laurent" From: Graham Klyne Subject: RE: Media types Cc: ietf-xml-mime@imc.org In-Reply-To: <1011315227.865.107.camel@localhost.localdomain> References: <5.1.0.14.2.20020117232536.00a00bc0@joy.songbird.com> <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> <5.1.0.14.2.20020117232536.00a00bc0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:53 PM 1/17/02 -0500, Simon St.Laurent wrote: >On Thu, 2002-01-17 at 18:32, Graham Klyne wrote: > > Well, we now have ways to express other (non-primary) content types. > > > > E.g., per RFC 2912, RFC 2913, ... > > > > Content-Type: multipart/mixed; boundary="break" > > Content-features: > > (& (Type="text/plain") (Type="image/jpeg") (Type="audio/wav") ) > >Can we simply say (for an XHTML document also containing SVG, MathML, >SMIL, and XLink): > >Content-Type: application/xhtml+xml >Content-features: (& >(xmlns="http://www.w3.org/1999/xhtml") >(xmlns="http://www.w3.org/2000/svg") >(xmlns="http://www.w3.org/1998/Math/MathML") >(xmlns="http://www.w3.org/2001/SMIL20/") >(xmlns="http://www.w3.org/1999/xlink") >) Sure... if feature tag xmlns is registered (per RFC 2506). (Something like this is almost anticipated by CC/PP, which mentions a "schema" attribute - described in terms of schema identification rather than namespaces). >If so, then we may already be out of the brush, though my reading of RFC >2913 suggests that we would need to add xmlns to RFC 3023's existing >structure. RFC 2913 and RFC 3023 are almost orthogonal ... there's arguably a very small overlap of functionality (between RFC 2912+2913 and RFC 3023), but nothing about using RFC 2913 that I can see requires any change to RFC 3023. Note that RFC 2913 specifically excludes use of content-type parameters, so adding xmlns to RFC 3023 wouldn't change that, and would create a more significant overlap. #g -------------------------- __ /\ \ Graham Klyne / \ \ (GK@ACM.ORG) / /\ \ \ / / /\ \ \ / / /__\_\ \ / / /________\ \/___________/ Received: by above.proper.com (8.11.6/8.11.3) id g0I2GSU06371 for ietf-xml-mime-bks; Thu, 17 Jan 2002 18:16:28 -0800 (PST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I2GQ306367 for ; Thu, 17 Jan 2002 18:16:26 -0800 (PST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id VAA22084; Thu, 17 Jan 2002 21:17:45 -0500 Message-Id: <200201180217.VAA22084@markbaker.ca> Subject: Re: Media types To: fielding@ebuilt.com (Roy T. Fielding) Date: Thu, 17 Jan 2002 21:17:44 -0500 (EST) Cc: simonstl@simonstl.com (Simon St.Laurent), www-tag@w3.org, ietf-xml-mime@imc.org In-Reply-To: <20020117173349.A28787@waka.ebuilt.net> from "Roy T. Fielding" at Jan 17, 2002 05:33:49 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] 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: > Let's say you have two resources that both resolve to the same content. > GET one and the response is always sent as image/cvg+xml. > GET two and the response is always sent as application/xml. > Those are separate semantics, and thus separate resources. It doesn't > prevent the UA from taking the content and choosing to manipulate it > in different ways, but it does define the semantics from the perspective > of the person who created the two separate URI used to access those > two resources containing the same content. I understand that view. It's equivalent to sending HTML as text/plain and not expecting that it be displayed as HTML. It's a reasonable argument, primarily because the specification of */xml doesn't say what to expect, plus not all XML uses namespaces. Assuming no dispatch would at least provide some consistentcy. So let's say we define a new media type for which this dispatching behaviour is required. Then publishers describing their content with that type would expect that the first processor (other than the one for the media type) to see the content would be, in your example, an SVG processor. How's that sound? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com Received: by above.proper.com (8.11.6/8.11.3) id g0I20di05947 for ietf-xml-mime-bks; Thu, 17 Jan 2002 18:00:39 -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 g0I20b305942 for ; Thu, 17 Jan 2002 18:00:37 -0800 (PST) Received: from localhost (igraham@localhost) by ic-unix.ic.utoronto.ca (8.9.3+Sun/8.9.1) with ESMTP id UAA27328; Thu, 17 Jan 2002 20:51:31 -0500 (EST) Date: Thu, 17 Jan 2002 20:51:31 -0500 (EST) From: Ian Graham Reply-To: Ian Graham To: "Simon St.Laurent" cc: www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net Subject: Re: Media types In-Reply-To: <1011301539.859.61.camel@localhost.localdomain> 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 17 Jan 2002, Simon St.Laurent wrote: > > Sorry to come to this discussion late. (Those reading this on > ietf-xml-mime may want to visit > http://lists.w3.org/Archives/Public/www-tag/2002Jan/index.html and read > the Media Types thread.) > > On Thu, 2002-01-17 at 13:41, Mark Baker wrote: > > >[Tim Bray] > > > Hm... you're creeping in the direction of deprecating media type > > > MIME headers in the case where the resource body is XML. > > > > Not deprecating, just creating a parallel alternative. But if it's > > done well, it could become a 90+% solution. > > > > > To start > > > with, should such a discussion happen at least partly over in the > > > IETF? > > > > For sure. This won't happen without the IETF. > For me, the main points (which simon has nicely captured) for XML and MIME are:: * using URIs to reference vocabulary definitions * XML documents can reference multiple vocabulary definition * The mime mechanism can capture only one of these vocabularies (note how this dances carefully away from the word 'type' ;-) ) MIME really doesn't give you a nice way of defining multipe properties for a single resource, other than the media features extension described in RFC 2912. Using this extension (Designed for a different purpose, BTW) you could write something like: Content-Type: text/xml; Content-features: (& (primary-namespace="uri1") (secondary-namespace="uri2") ... ) The question then is -- does that really give you anything particularly useful over text/xml+whatever? Once I started to think through some uses, I honestly couldn't think of a compelling advantage ... Ian Received: by above.proper.com (8.11.6/8.11.3) id g0I1CNi05058 for ietf-xml-mime-bks; Thu, 17 Jan 2002 17:12:23 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I1CL305054 for ; Thu, 17 Jan 2002 17:12:21 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0I1Bud31009; Thu, 17 Jan 2002 20:11:56 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: Media types From: "Simon St.Laurent" To: www-tag@w3.org, ietf-xml-mime@imc.org In-Reply-To: <200201180100.UAA21097@markbaker.ca> References: <200201180100.UAA21097@markbaker.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 21:16:10 -0500 Message-Id: <1011320172.865.121.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2002-01-17 at 20:00, Mark Baker wrote: > > Therefore, it is not useful to send something as application/xml unless > > the sender specifically wishes it to be processed as generic XML. > > Fair enough. So what if we define "generic XML" to include dispatch > to processors keyed on namespace declarations? Wouldn't that make > it more semantically significant? I think I'm going to write up an initial draft using Content-features for an xmlns feature, so we should have some "semantic significance" in a MIME-specific context to discuss shortly. Hopefully I'll have it written by end of day tomorrow - this doesn't look especially tough, at least for an initial draft. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: by above.proper.com (8.11.6/8.11.3) id g0I0wl204781 for ietf-xml-mime-bks; Thu, 17 Jan 2002 16:58:47 -0800 (PST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I0wj304777 for ; Thu, 17 Jan 2002 16:58:46 -0800 (PST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id UAA21097; Thu, 17 Jan 2002 20:00:04 -0500 Message-Id: <200201180100.UAA21097@markbaker.ca> Subject: Re: Media types To: fielding@ebuilt.com (Roy T. Fielding) Date: Thu, 17 Jan 2002 20:00:04 -0500 (EST) Cc: simonstl@simonstl.com (Simon St.Laurent), www-tag@w3.org, ietf-xml-mime@imc.org In-Reply-To: <20020117160803.B20375@waka.ebuilt.net> from "Roy T. Fielding" at Jan 17, 2002 04:08:03 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] 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: > Therefore, it is not useful to send something as application/xml unless > the sender specifically wishes it to be processed as generic XML. Fair enough. So what if we define "generic XML" to include dispatch to processors keyed on namespace declarations? Wouldn't that make it more semantically significant? MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com Received: by above.proper.com (8.11.6/8.11.3) id g0I0Hc703897 for ietf-xml-mime-bks; Thu, 17 Jan 2002 16:17:38 -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 g0I0Hb303893 for ; Thu, 17 Jan 2002 16:17:37 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KD6BRLYJS0000RDW@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Thu, 17 Jan 2002 16:17:32 -0800 (PST) Date: Thu, 17 Jan 2002 16:16:30 -0800 (PST) From: ned+xml-mime@mrochek.com Subject: RE: Media types In-reply-to: "Your message dated Thu, 17 Jan 2002 19:53:46 -0500" <1011315227.865.107.camel@localhost.localdomain> To: "Simon St.Laurent" Cc: Graham Klyne , Mike Dierken , www-tag@w3.org, ietf-xml-mime@imc.org Message-id: <01KD6MQ03D2A000RDW@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> <5.1.0.14.2.20020117232536.00a00bc0@joy.songbird.com> <5.1.0.14.2.20020117232536.00a00bc0@joy.songbird.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Thu, 2002-01-17 at 18:32, Graham Klyne wrote: > > Well, we now have ways to express other (non-primary) content types. > > > > E.g., per RFC 2912, RFC 2913, ... > > > > Content-Type: multipart/mixed; boundary="break" > > Content-features: > > (& (Type="text/plain") (Type="image/jpeg") (Type="audio/wav") ) > Can we simply say (for an XHTML document also containing SVG, MathML, > SMIL, and XLink): > Content-Type: application/xhtml+xml > Content-features: (& > (xmlns="http://www.w3.org/1999/xhtml") > (xmlns="http://www.w3.org/2000/svg") > (xmlns="http://www.w3.org/1998/Math/MathML") > (xmlns="http://www.w3.org/2001/SMIL20/") > (xmlns="http://www.w3.org/1999/xlink") > ) You can if xmlns is already defined. AFAIK it isn't, but defining it should be easy. > If so, then we may already be out of the brush, though my reading of RFC > 2913 suggests that we would need to add xmlns to RFC 3023's existing > structure. Adding an additional attribute does not constitute a structural change. Ned Received: by above.proper.com (8.11.6/8.11.3) id g0I0GGQ03870 for ietf-xml-mime-bks; Thu, 17 Jan 2002 16:16:16 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I0GE303866 for ; Thu, 17 Jan 2002 16:16:14 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0I0G9d29409; Thu, 17 Jan 2002 19:16:09 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: Media types From: "Simon St.Laurent" To: "Roy T. Fielding" Cc: www-tag@w3.org, ietf-xml-mime@imc.org In-Reply-To: <20020117160803.B20375@waka.ebuilt.net> References: <1011301539.859.61.camel@localhost.localdomain> <200201172236.g0HMaFi24318@astro.cs.utk.edu> <20020117151813.A20009@waka.ebuilt.net> <1011313899.866.93.camel@localhost.localdomain> <20020117160803.B20375@waka.ebuilt.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 20:20:24 -0500 Message-Id: <1011316825.860.110.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2002-01-17 at 19:08, Roy T. Fielding wrote: > On Thu, Jan 17, 2002 at 07:31:10PM -0500, Simon St.Laurent wrote: > > On Thu, 2002-01-17 at 18:18, Roy T. Fielding wrote: > > > I think the mistake is in assigning such messages a type that implies > > > it should be handled by a generic XML processor. There is no such thing, > > > > No such thing? There are all kinds of processing gidgets and storage > > systems that work on XML generically. You might want to choose more > > precise language. > > There are all types of procesing gadgets and storage systems that work on > bytes generically. If that was a useful distinction at the message level > then there wouldn't have been any need for media types. Sure. But I hope you've noticed that XML is perhaps slightly more than bytes - and perhaps even a "useful distinction at the message level". If not, I'm not sure I really want to send my nouns to your limited set of verbs. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0I0Fkq03849 for ietf-xml-mime-bks; Thu, 17 Jan 2002 16:15:46 -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 g0I0Fj303845 for ; Thu, 17 Jan 2002 16:15:45 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KD6BRLYJS0000RDW@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Thu, 17 Jan 2002 16:15:43 -0800 (PST) Date: Thu, 17 Jan 2002 16:09:21 -0800 (PST) From: ned+xml-mime@mrochek.com Subject: Re: Media types In-reply-to: "Your message dated Thu, 17 Jan 2002 18:38:30 -0500" <200201172338.g0HNcUi24653@astro.cs.utk.edu> To: Keith Moore Cc: "Roy T. Fielding" , Keith Moore , "Simon St.Laurent" , www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net Message-id: <01KD6MNREXQW000RDW@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <20020117151813.A20009@waka.ebuilt.net> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > actually, the dispatching is not implied by the content-type - > the recipient agent is free to dispatch each content as it sees fit. > the content-type really is just labelling the data representation > used by the content. Labelling is definitely the intent, but that has always been filtered by a desire to use the label as a basis for various sorts of actions. So yes, dispatching isn't implied, but the labels are constructed to facilitate dispatching. This has had mixed results -- the primary type concept, for example, has worked well in some cases and poorly in others. Additionally, we have been reluctant to go much beyond labelling the representation of the data in the content type field. Information about whether an image is black and white or color, what Postscript features are employed, and so on belong somewhere else. We didn't address where that was in the original MIME work, but the content-features work has done this. Ned Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0I07ea03518 for ietf-xml-mime-bks; Thu, 17 Jan 2002 16:07:40 -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 g0I07c303513 for ; Thu, 17 Jan 2002 16:07:38 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KD6BRLYJS0000RDW@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-xml-mime@imc.org; Thu, 17 Jan 2002 16:07:25 -0800 (PST) Date: Thu, 17 Jan 2002 15:52:09 -0800 (PST) From: ned+xml-mime@mrochek.com Subject: RE: Media types In-reply-to: "Your message dated Thu, 17 Jan 2002 23:32:32 +0000" <5.1.0.14.2.20020117232536.00a00bc0@joy.songbird.com> To: Graham Klyne Cc: "Simon St.Laurent" , Mike Dierken , www-tag@w3.org, ietf-xml-mime@imc.org Message-id: <01KD6MDGXIY0000RDW@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> <1011313361.867.89.camel@localhost.localdomain> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > At 07:22 PM 1/17/02 -0500, Simon St.Laurent wrote: > > > > At what point does it make sense to move beyond MIME? > > > > > > > > > > Is it MIME or just the singular Content-Type that is a problem? > > > >Singular content-type. I don't think the rest of MIME (except some > >encoding issues) causes much trouble. MIME content-types are intended to be acted on. Their descriptive capabilities are secondary, and are extended and supplemented by other content fields, including content-disposition and content-features. > Well, we now have ways to express other (non-primary) content types. > E.g., per RFC 2912, RFC 2913, ... > Content-Type: multipart/mixed; boundary="break" > Content-features: > (& (Type="text/plain") (Type="image/jpeg") (Type="audio/wav") ) Exactly. This is the solution I suggest the last time this topic came up on this list. Features are extensible to include new "axes" of description, including things that come from XML. People seem to think MIME is the same now as it was in 1993. Not so. We've added a lot, including but not limited to facilities for describing content that consists of multiple formats. Ned Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HNtSq03239 for ietf-xml-mime-bks; Thu, 17 Jan 2002 15:55:28 -0800 (PST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HNtR303233 for ; Thu, 17 Jan 2002 15:55:27 -0800 (PST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id SAA20422; Thu, 17 Jan 2002 18:56:46 -0500 Message-Id: <200201172356.SAA20422@markbaker.ca> Subject: Re: Media types To: tbray@textuality.com (Tim Bray) Date: Thu, 17 Jan 2002 18:56:46 -0500 (EST) Cc: www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net In-Reply-To: <5.1.0.14.2.20020117151525.027005c0@pop.intergate.ca> from "Tim Bray" at Jan 17, 2002 03:19:24 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] 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: > At 04:11 PM 17/01/02 -0500, Mark Baker wrote: > >Almost exactly what I was thinking. My strawman media type was > >application/xmlns-dispatch+xml (not very catchy, I know). > > None of the arguments I've read here lead me to see this as > a value-add over application/xml. It seems we think that > applications should when processing XML resources dispatch > based on namespaces... except when they can't, which I guess > is the point of the worry about XSLT. Yes. If it weren't for XSLT (and that we haven't gone looking for other cases like it), I'd be suggesting we do this with */xml and maybe +xml too. What I primarily want to accomplish is documenting the rules of containment and dispatch. Which media type(s) we bind those too can be determined later. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com Received: by above.proper.com (8.11.6/8.11.3) id g0HNnd302998 for ietf-xml-mime-bks; Thu, 17 Jan 2002 15:49:39 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HNnb302990 for ; Thu, 17 Jan 2002 15:49:37 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0HNnVd28652; Thu, 17 Jan 2002 18:49:31 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: RE: Media types From: "Simon St.Laurent" To: Graham Klyne Cc: Mike Dierken , www-tag@w3.org, ietf-xml-mime@imc.org In-Reply-To: <5.1.0.14.2.20020117232536.00a00bc0@joy.songbird.com> References: <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> <5.1.0.14.2.20020117232536.00a00bc0@joy.songbird.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 19:53:46 -0500 Message-Id: <1011315227.865.107.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2002-01-17 at 18:32, Graham Klyne wrote: > Well, we now have ways to express other (non-primary) content types. > > E.g., per RFC 2912, RFC 2913, ... > > Content-Type: multipart/mixed; boundary="break" > Content-features: > (& (Type="text/plain") (Type="image/jpeg") (Type="audio/wav") ) Can we simply say (for an XHTML document also containing SVG, MathML, SMIL, and XLink): Content-Type: application/xhtml+xml Content-features: (& (xmlns="http://www.w3.org/1999/xhtml") (xmlns="http://www.w3.org/2000/svg") (xmlns="http://www.w3.org/1998/Math/MathML") (xmlns="http://www.w3.org/2001/SMIL20/") (xmlns="http://www.w3.org/1999/xlink") ) If so, then we may already be out of the brush, though my reading of RFC 2913 suggests that we would need to add xmlns to RFC 3023's existing structure. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HNcW102417 for ietf-xml-mime-bks; Thu, 17 Jan 2002 15:38:32 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HNcV302413 for ; Thu, 17 Jan 2002 15:38:31 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g0HNcUi24653; Thu, 17 Jan 2002 18:38:30 -0500 (EST) Message-Id: <200201172338.g0HNcUi24653@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Roy T. Fielding" cc: Keith Moore , "Simon St.Laurent" , www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net Subject: Re: Media types In-reply-to: Your message of "Thu, 17 Jan 2002 15:18:13 PST." <20020117151813.A20009@waka.ebuilt.net> Date: Thu, 17 Jan 2002 18:38:30 -0500 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > or that expecting the MIME content-type to convey the action that > > should be performed by a recipient, rather than a description of > > the content, is a bit of a mis-application of MIME? > > That's not always true. MIME uses the content-type to indicate what type > of handler should be selected for the message body. The same content can > be sent for different purposes by using different media types. E.g., > image/jpeg vs application/octet-stream, multipart/alternative vs > multipart/mixed, etc. actually, the dispatching is not implied by the content-type - the recipient agent is free to dispatch each content as it sees fit. the content-type really is just labelling the data representation used by the content. the same is true for application/octet-stream - this just happens to be the type name for "unknown", and the multipart/* types just happen to use MIME framing internally. it's not as if labelling a content as image/jpeg implies that the image should be displayed whereas labelling it as application/octet-stream implies that it should not be displayed (even if it often works out that way) we have content-disposition to specify presentation hints. > > the fact that XML picked a means of labelling content that is > > incompatible with MIME's content-type is hardly MIME's fault. > > I think the mistake is in assigning such messages a type that implies > it should be handled by a generic XML processor. There is no such thing, > even though it is possible to view all XML types via generic XML tools. well, I'd agree with that. > A more architecturally fitting course of action would be to create a > top-level media type of xml and then have xml/* subtypes, but for > some reason (deployed apps, I presume) the top-level namespace has been > frozen for ages. that wouldn't have been consistent with the MIME content-type labelling architecture either. whether a content uses XML as a presentation layer is orthogonal to the type of the content. after all, XML can certainly be used to represent text, images, application data, audio or video. the most "architecturally fitting course of action" (for MIME) would have been to define a separate facet for the nature of the underlying content (say content-presentation-layer to pick a hasty example) and put this in a separate header field. but people wanted to be able to dispatch on content-type alone (even though that's unrealistic), and HTTP doesn't make a clean separation between facets of the content and attributes of the bearer protocol. so we're kind of stuck. Keith Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HNXoB02201 for ietf-xml-mime-bks; Thu, 17 Jan 2002 15:33:50 -0800 (PST) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HNXo302197 for ; Thu, 17 Jan 2002 15:33:50 -0800 (PST) Received: from GK-VAIO.NineByNine.org (dyn170-32.sftm-212-159.plus.net [212.159.32.170]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g0I7MI405946; Thu, 17 Jan 2002 23:22:18 -0800 Message-Id: <5.1.0.14.2.20020117232536.00a00bc0@joy.songbird.com> X-Sender: gk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Jan 2002 23:32:32 +0000 To: "Simon St.Laurent" From: Graham Klyne Subject: RE: Media types Cc: Mike Dierken , www-tag@w3.org, ietf-xml-mime@imc.org In-Reply-To: <1011313361.867.89.camel@localhost.localdomain> References: <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:22 PM 1/17/02 -0500, Simon St.Laurent wrote: > > > At what point does it make sense to move beyond MIME? > > > > > > > Is it MIME or just the singular Content-Type that is a problem? > >Singular content-type. I don't think the rest of MIME (except some >encoding issues) causes much trouble. Well, we now have ways to express other (non-primary) content types. E.g., per RFC 2912, RFC 2913, ... Content-Type: multipart/mixed; boundary="break" Content-features: (& (Type="text/plain") (Type="image/jpeg") (Type="audio/wav") ) #g -------------------------- __ /\ \ Graham Klyne / \ \ (GK@ACM.ORG) / /\ \ \ / / /\ \ \ / / /__\_\ \ / / /________\ \/___________/ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HNRVZ01933 for ietf-xml-mime-bks; Thu, 17 Jan 2002 15:27:31 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HNRU301929 for ; Thu, 17 Jan 2002 15:27:30 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0HNROd28049; Thu, 17 Jan 2002 18:27:24 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: Media types From: "Simon St.Laurent" To: "Roy T. Fielding" Cc: www-tag@w3.org, ietf-xml-mime@imc.org In-Reply-To: <20020117151813.A20009@waka.ebuilt.net> References: <1011301539.859.61.camel@localhost.localdomain> <200201172236.g0HMaFi24318@astro.cs.utk.edu> <20020117151813.A20009@waka.ebuilt.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 19:31:10 -0500 Message-Id: <1011313899.866.93.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2002-01-17 at 18:18, Roy T. Fielding wrote: > I think the mistake is in assigning such messages a type that implies > it should be handled by a generic XML processor. There is no such thing, No such thing? There are all kinds of processing gidgets and storage systems that work on XML generically. You might want to choose more precise language. > even though it is possible to view all XML types via generic XML tools. Viewing is just one possibility. > A more architecturally fitting course of action would be to create a > top-level media type of xml and then have xml/* subtypes, but for > some reason (deployed apps, I presume) the top-level namespace has been > frozen for ages. That proposal went over like a lead ballon - see the ietf-xml-mime archives for much more detail. +xml, a 'lesser' though similar notion, wasn't exactly easy to put across either. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: by above.proper.com (8.11.6/8.11.3) id g0HNPFC01831 for ietf-xml-mime-bks; Thu, 17 Jan 2002 15:25:15 -0800 (PST) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HNPD301827 for ; Thu, 17 Jan 2002 15:25:13 -0800 (PST) Received: from rune.antarcti.ca (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id F1355102D5; Thu, 17 Jan 2002 15:25:05 -0800 (PST) Message-Id: <5.1.0.14.2.20020117151525.027005c0@pop.intergate.ca> X-Sender: tbray@pop.intergate.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Jan 2002 15:19:24 -0800 To: www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net From: Tim Bray Subject: Re: Media types In-Reply-To: <200201172112.QAA18078@markbaker.ca> References: <1011301539.859.61.camel@localhost.localdomain> 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: At 04:11 PM 17/01/02 -0500, Mark Baker wrote: >Almost exactly what I was thinking. My strawman media type was >application/xmlns-dispatch+xml (not very catchy, I know). None of the arguments I've read here lead me to see this as a value-add over application/xml. It seems we think that applications should when processing XML resources dispatch based on namespaces... except when they can't, which I guess is the point of the worry about XSLT. Before launching the quest for a new media type, I think we need a clearer explanation of the use case where this is used and application/xml or anything/anything+xml isn't appropriate, and why. -Tim Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HNL2N01649 for ietf-xml-mime-bks; Thu, 17 Jan 2002 15:21:02 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HNL0301645 for ; Thu, 17 Jan 2002 15:21:01 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g0HNKxi24571; Thu, 17 Jan 2002 18:20:59 -0500 (EST) Message-Id: <200201172320.g0HNKxi24571@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Simon St.Laurent" cc: Keith Moore , www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net Subject: Re: Media types In-reply-to: Your message of "17 Jan 2002 19:04:38 EST." <1011312307.867.81.camel@localhost.localdomain> Date: Thu, 17 Jan 2002 18:20:59 -0500 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > > It's not MIME's fault that it was designed in an era when no one > > > expected the possibility of creating such labelled content. However, > > > such content is useful, and MIME's inability to handle such things > > > definitely feels like a limitation from the perspective of people who > > > like such things. > > > > I don't see an inability of MIME to handle labelled content, I see > > XML's deliberate decision to use a means of content-labelling which > > was incompatible with MIME, while still expecting to use MIME > > framing to convey XML from one place to another. > > How would you have proposed that XML's developers create a > MIME-compliant form of content labelling? > > Or would you simply have banned the notion of mixing different > vocabularies into a single document? I'm not saying that MIME's notion of content-labelling could have satisified all of the desired goals for XML; I'm saying that there's an impedance mismatch between the purposes for which MIME was designed and the way that XML folks want to use it. You can think of that as a limitation of MIME, and in a sense that's true, but the bottom line is that MIME wasn't designed for that purpose. And had we tried to design MIME for that purpose it would have taken several more years to finish it. > > MIME does have its limitations > > Anything with only two levels is pretty well guaranteed to run into a > need for three or more. Some of us think in retrospect that two levels was one too many - the top-level has been misused more often than not. But adding more levels wouldn't have solved the "mixing vocabularies" problem. > > On the other hand, it might be worth the trouble to define a > > different transmission format for the sole purpose of shipping > > XML around. It's not as if either SMTP or HTTP is ideal for > > this purpose either. > > No, they're not very efficient. I'm not convinced however, that sending > XML over separate pipes is particularly sensible either. Nor am I convinced that the existence of HTTP obviates the need for other applications. As for "separate pipes", there is no need - the pipes that are in place already have a very flexible mechanism for multiplexing different kinds of data. It's called IP. Keith Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HNIWp01529 for ietf-xml-mime-bks; Thu, 17 Jan 2002 15:18:32 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HNIV301524 for ; Thu, 17 Jan 2002 15:18:31 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0HNIQd27788; Thu, 17 Jan 2002 18:18:26 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: RE: Media types From: "Simon St.Laurent" To: Mike Dierken Cc: www-tag@w3.org, ietf-xml-mime@imc.org In-Reply-To: <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> References: <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 19:22:12 -0500 Message-Id: <1011313361.867.89.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2002-01-17 at 18:05, Mike Dierken wrote: > > At what point does it make sense to move beyond MIME? > > > > Is it MIME or just the singular Content-Type that is a problem? Singular content-type. I don't think the rest of MIME (except some encoding issues) causes much trouble. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HN6Nc00997 for ietf-xml-mime-bks; Thu, 17 Jan 2002 15:06:23 -0800 (PST) Received: from xmlfmail.xmlfund.com (mail.xmlfund.com [63.224.51.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HN6M300991 for ; Thu, 17 Jan 2002 15:06:22 -0800 (PST) Received: by xmlfmail.xmlfund.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 15:06:15 -0800 Message-ID: <2AE31649CF989F4FB354F6D95EB0CE6E4D6761@xmlfmail.xmlfund.com> From: Mike Dierken To: www-tag@w3.org, ietf-xml-mime@imc.org Subject: RE: Media types Date: Thu, 17 Jan 2002 15:05:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Simon St.Laurent [mailto:simonstl@simonstl.com] > At what point does it make sense to move beyond MIME? > Is it MIME or just the singular Content-Type that is a problem? Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HN0vn00722 for ietf-xml-mime-bks; Thu, 17 Jan 2002 15:00:57 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HN0u300717 for ; Thu, 17 Jan 2002 15:00:56 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0HN0pd27310; Thu, 17 Jan 2002 18:00:51 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: Media types From: "Simon St.Laurent" To: Keith Moore Cc: www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net In-Reply-To: <200201172254.g0HMsOi24429@astro.cs.utk.edu> References: <200201172254.g0HMsOi24429@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 19:04:38 -0500 Message-Id: <1011312307.867.81.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2002-01-17 at 17:54, Keith Moore wrote: > > It's not MIME's fault that it was designed in an era when no one > > expected the possibility of creating such labelled content. However, > > such content is useful, and MIME's inability to handle such things > > definitely feels like a limitation from the perspective of people who > > like such things. > > I don't see an inability of MIME to handle labelled content, I see > XML's deliberate decision to use a means of content-labelling which > was incompatible with MIME, while still expecting to use MIME > framing to convey XML from one place to another. How would you have proposed that XML's developers create a MIME-compliant form of content labelling? Or would you simply have banned the notion of mixing different vocabularies into a single document? > MIME does have its limitations Anything with only two levels is pretty well guaranteed to run into a need for three or more. MIME is a legacy technology. It works well for what it did and does. That doesn't mean it'll work well going forward. (And the same may well happen to XML over a similar period of time.) > On the other hand, it might be worth the trouble to define a > different transmission format for the sole purpose of shipping > XML around. It's not as if either SMTP or HTTP is ideal for > this purpose either. No, they're not very efficient. I'm not convinced however, that sending XML over separate pipes is particularly sensible either. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HMsRg00492 for ietf-xml-mime-bks; Thu, 17 Jan 2002 14:54:27 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HMsP300487 for ; Thu, 17 Jan 2002 14:54:25 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g0HMsOi24429; Thu, 17 Jan 2002 17:54:24 -0500 (EST) Message-Id: <200201172254.g0HMsOi24429@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Simon St.Laurent" cc: Keith Moore , www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net Subject: Re: Media types In-reply-to: Your message of "17 Jan 2002 18:49:06 EST." <1011311375.867.72.camel@localhost.localdomain> Date: Thu, 17 Jan 2002 17:54:24 -0500 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > It's not MIME's fault that it was designed in an era when no one > expected the possibility of creating such labelled content. However, > such content is useful, and MIME's inability to handle such things > definitely feels like a limitation from the perspective of people who > like such things. I don't see an inability of MIME to handle labelled content, I see XML's deliberate decision to use a means of content-labelling which was incompatible with MIME, while still expecting to use MIME framing to convey XML from one place to another. > At what point does it make sense to move beyond MIME? It depends on the purpose for which MIME is being used. MIME does have its limitations, but the installed base of mail clients and servers, and web clients and servers, is so large that it would take a very compelling gain in functionality to make it worth these applications abandoning MIME for some other format - and the issues associated with transition would be considerable. ( not to mention the effort needed to support both formats for the duration that such messages would be used - probably decades.) On the other hand, it might be worth the trouble to define a different transmission format for the sole purpose of shipping XML around. It's not as if either SMTP or HTTP is ideal for this purpose either. Keith Received: by above.proper.com (8.11.6/8.11.3) id g0HMkcv00158 for ietf-xml-mime-bks; Thu, 17 Jan 2002 14:46:38 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HMkb300152 for ; Thu, 17 Jan 2002 14:46:37 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0HMkXd26889; Thu, 17 Jan 2002 17:46:33 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: Media types From: "Simon St.Laurent" To: Keith Moore Cc: www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net In-Reply-To: <200201172236.g0HMaFi24318@astro.cs.utk.edu> References: <200201172236.g0HMaFi24318@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 18:50:19 -0500 Message-Id: <1011311448.869.74.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2002-01-17 at 17:36, Keith Moore wrote: > or that expecting the MIME content-type to convey the action that > should be performed by a recipient, rather than a description of > the content, is a bit of a mis-application of MIME? Oops. Forgot this bit. Listing namespaces in a document is just describing the content. Action on such namespaces is up to the recipient. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HMjVQ00101 for ietf-xml-mime-bks; Thu, 17 Jan 2002 14:45:31 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HMjT329995 for ; Thu, 17 Jan 2002 14:45:29 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0HMjKd26861; Thu, 17 Jan 2002 17:45:20 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: Media types From: "Simon St.Laurent" To: Keith Moore Cc: www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net In-Reply-To: <200201172236.g0HMaFi24318@astro.cs.utk.edu> References: <200201172236.g0HMaFi24318@astro.cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 18:49:06 -0500 Message-Id: <1011311375.867.72.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2002-01-17 at 17:36, Keith Moore wrote: > > It would be difficult for such a thing to happen without the IETF, but > > making changes to MIME of any fundamental sort is intensely difficult. > > Despite the work I put into RFC 3023, and the very rough consensus we > > managed to achieve there, I think XML is demonstrating the limitations > > of MIME on a regular basis. > > that's a pretty bizarre statement. perhaps it's truer to say that XML > is trying to misuse MIME on a regular basis? > > or that expecting the MIME content-type to convey the action that > should be performed by a recipient, rather than a description of > the content, is a bit of a mis-application of MIME? > > the fact that XML picked a means of labelling content that is > incompatible with MIME's content-type is hardly MIME's fault. It's not MIME's fault that it was designed in an era when no one expected the possibility of creating such labelled content. However, such content is useful, and MIME's inability to handle such things definitely feels like a limitation from the perspective of people who like such things. Kind of like, say, 7-bit ASCII feels to people trying to use Unicode's upper reaches. At what point does it make sense to move beyond MIME? And is there a way to signal such "moving beyond" so that MIME applications have fair warning? -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HMaPU29630 for ietf-xml-mime-bks; Thu, 17 Jan 2002 14:36:25 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HMaO329626 for ; Thu, 17 Jan 2002 14:36:24 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g0HMaFi24318; Thu, 17 Jan 2002 17:36:16 -0500 (EST) Message-Id: <200201172236.g0HMaFi24318@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Simon St.Laurent" cc: www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net Subject: Re: Media types In-reply-to: Your message of "17 Jan 2002 16:05:09 EST." <1011301539.859.61.camel@localhost.localdomain> Date: Thu, 17 Jan 2002 17:36:15 -0500 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > It would be difficult for such a thing to happen without the IETF, but > making changes to MIME of any fundamental sort is intensely difficult. > Despite the work I put into RFC 3023, and the very rough consensus we > managed to achieve there, I think XML is demonstrating the limitations > of MIME on a regular basis. that's a pretty bizarre statement. perhaps it's truer to say that XML is trying to misuse MIME on a regular basis? or that expecting the MIME content-type to convey the action that should be performed by a recipient, rather than a description of the content, is a bit of a mis-application of MIME? the fact that XML picked a means of labelling content that is incompatible with MIME's content-type is hardly MIME's fault. Keith Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HLB2w27163 for ietf-xml-mime-bks; Thu, 17 Jan 2002 13:11:02 -0800 (PST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HLB1327157 for ; Thu, 17 Jan 2002 13:11:01 -0800 (PST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id QAA18078; Thu, 17 Jan 2002 16:12:00 -0500 Message-Id: <200201172112.QAA18078@markbaker.ca> Subject: Re: Media types To: simonstl@simonstl.com (Simon St.Laurent) Date: Thu, 17 Jan 2002 16:11:59 -0500 (EST) Cc: www-tag@w3.org, ietf-xml-mime@imc.org, mura034@attglobal.net In-Reply-To: <1011301539.859.61.camel@localhost.localdomain> from "Simon St.Laurent" at Jan 17, 2002 04:05:09 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] 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: Simon, > It would be difficult for such a thing to happen without the IETF, but > making changes to MIME of any fundamental sort is intensely difficult. > Despite the work I put into RFC 3023, and the very rough consensus we > managed to achieve there, I think XML is demonstrating the limitations > of MIME on a regular basis. Definitely. Though what I'm proposing should ruffle the feathers of any media type folk, I wouldn't think. I'm not proposing anything like "+xml", just a (possibly) new media type for XML that would be used to describe content which follows certain rules about how it expects to be handed to processors bound to namespaces. > Mark earlier proposed: > application/xml; xmlns="http://www.w3.org/1999/xhtml" I like to think that I "tossed it out for discussion". I have reservations about it myself[1]. > XLink is a great case of that, as most implementations I've encountered > focus only on simple linking, and leave off the more complex stuff for > now. XSLT provides a lot of interesting and difficult cases as well. > RDDL (http://rddl.org) may be an important ingredient in the mix. Yes, I haven't given these the attention they deserve yet. Perhaps I'll just write down what I'm thinking (an I-D is under way) and let others add to it. > > Does the above help to alleviate those concerns? I'm not suggesting we > > prevent anybody from doing what they're already comfortable with. I'm > > only suggesting we attempt to define a generic dispatch model triggered > > from a generic XML media type, which would likely be useful to lots of > > people, especially those working with multi-namespace documents. > > If that is to happen - and I think it would be a good thing - I'd much > prefer such information appears in metadata provided before an > application goes to the trouble of downloading a document. More > information sooner is - I think - always going to be the better option. > For now, that means MIME types like image/svg+xml rather than plain old > application/xml, if only because both graphics programs and XML > processors will be happier. > > Documents containing multiple namespaces are a substantial challenge to > the foundations of MIME content types. It may be that we need a new > MIME type (application/extensible+xml?) Almost exactly what I was thinking. My strawman media type was application/xmlns-dispatch+xml (not very catchy, I know). But it would really help its chance for success if we could bind this behaviour to application/xml. XSLT makes that tough, but it would be worth digging to see how common this use of XSLT is (I fear it's common). Alternately, it could be bound to "+xml", but we'd have to check to see that it's consistent with deployed processors. Also, it might be confusing to people (or just plain wrong?) if "+xml" is used to specify this behaviour, but */xml is not. I'll start with a new media type. > and a header or parameter or > plural thereof to identify namepace URIs. I'm not so sure. I expect lots of discussion about this point though. > Getting there will require a > lot of long but worthwhile discussions at the IETF. > ietf-xml-mime@imc.org is the place to start that. Let the games begin! I'll try to have my draft out shortly, but my time has been at a premium recently. Luckily it should be a short draft. > (There may also have been an Internet-Draft about this at some point, > but I don't remember where/if it went.) Hmm, I don't recall one but I could have missed it. [1] http://lists.w3.org/Archives/Public/www-tag/2002Jan/0070.html MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HK1Vs25539 for ietf-xml-mime-bks; Thu, 17 Jan 2002 12:01:31 -0800 (PST) Received: from serrano.hesketh.net (serrano.hesketh.net [66.45.6.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HK1T325534 for ; Thu, 17 Jan 2002 12:01:29 -0800 (PST) Received: from [192.168.124.14] (syr-24-24-11-230.twcny.rr.com [24.24.11.230]) by serrano.hesketh.net (8.11.6/8.11.3) with ESMTP id g0HK1Pd19872; Thu, 17 Jan 2002 15:01:25 -0500 X-Spam-Filter: check_local@serrano.hesketh.net by digitalanswers.org X-More-Information: http://spamfighter.hesketh.net Subject: Re: Media types From: "Simon St.Laurent" To: www-tag@w3.org Cc: ietf-xml-mime@imc.org, mura034@attglobal.net In-Reply-To: <200201171841.NAA16767@markbaker.ca> References: <200201171841.NAA16767@markbaker.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 Date: 17 Jan 2002 16:05:09 -0500 Message-Id: <1011301539.859.61.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry to come to this discussion late. (Those reading this on ietf-xml-mime may want to visit http://lists.w3.org/Archives/Public/www-tag/2002Jan/index.html and read the Media Types thread.) On Thu, 2002-01-17 at 13:41, Mark Baker wrote: > >[Tim Bray] > > Hm... you're creeping in the direction of deprecating media type > > MIME headers in the case where the resource body is XML. > > Not deprecating, just creating a parallel alternative. But if it's > done well, it could become a 90+% solution. > > > To start > > with, should such a discussion happen at least partly over in the > > IETF? > > For sure. This won't happen without the IETF. It would be difficult for such a thing to happen without the IETF, but making changes to MIME of any fundamental sort is intensely difficult. Despite the work I put into RFC 3023, and the very rough consensus we managed to achieve there, I think XML is demonstrating the limitations of MIME on a regular basis. I wrote briefly about this last year (http://www.xml.com/pub/a/2000/06/21/disruption/index.html), but suspect that it may be time to move past two-part MIME Content-Type identifiers entirely, and start moving toward identification approaches which are capable of supporting the diversity XML makes possible. It seems like XML is effectively using URIs for vocabulary identification, though this isn't entirely explicit in the namespaces specification. The problem with the compromise we managed to reach on ietf-xml-mime during the RFC 3023 work is that even image/svg+xml or application/soap+xml doesn't say enough to make clear decisions about the nature of a document without actually reading it. We did what we could under the historical, technical, and political circumstances to communicate as much information as possible. Mark earlier proposed: application/xml; xmlns="http://www.w3.org/1999/xhtml" It's a good idea, but only a start, given all the possibilities of that XHTML document's content. I don't believe the "root namespace" is an adequate identifier. Beyond that, I worry about lots of cases where a namespace may appear in a document, and an application needs to understand its use, but only some of its functionality is used. XLink is a great case of that, as most implementations I've encountered focus only on simple linking, and leave off the more complex stuff for now. XSLT provides a lot of interesting and difficult cases as well. RDDL (http://rddl.org) may be an important ingredient in the mix. > > Yes, I agree in principle with the notions that dispatching on > > namespaces is a good thing, and that the namespace of the root > > element of an XML document has a special status, but I'm highly > > unconvinced that serving everything that has XML syntax as > > application/xml is a good direction to take. > > Does the above help to alleviate those concerns? I'm not suggesting we > prevent anybody from doing what they're already comfortable with. I'm > only suggesting we attempt to define a generic dispatch model triggered > from a generic XML media type, which would likely be useful to lots of > people, especially those working with multi-namespace documents. If that is to happen - and I think it would be a good thing - I'd much prefer such information appears in metadata provided before an application goes to the trouble of downloading a document. More information sooner is - I think - always going to be the better option. For now, that means MIME types like image/svg+xml rather than plain old application/xml, if only because both graphics programs and XML processors will be happier. Documents containing multiple namespaces are a substantial challenge to the foundations of MIME content types. It may be that we need a new MIME type (application/extensible+xml?) and a header or parameter or plural thereof to identify namepace URIs. Getting there will require a lot of long but worthwhile discussions at the IETF. ietf-xml-mime@imc.org is the place to start that. (There may also have been an Internet-Draft about this at some point, but I don't remember where/if it went.) -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com Received: by above.proper.com (8.11.6/8.11.3) id g0GMbfk18646 for ietf-xml-mime-bks; Wed, 16 Jan 2002 14:37:41 -0800 (PST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GMbe318642 for ; Wed, 16 Jan 2002 14:37:40 -0800 (PST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id RAA08447 for ietf-xml-mime@imc.org; Wed, 16 Jan 2002 17:38:56 -0500 Message-Id: <200201162238.RAA08447@markbaker.ca> Subject: I-D ACTION:draft-baker-soap-media-reg-00.txt (fwd) To: ietf-xml-mime@imc.org Date: Wed, 16 Jan 2002 17:38:56 -0500 (EST) From: Mark Baker X-Mailer: ELM [version 2.5 PL3] 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: FYI Forwarded message: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The 'application/soap+xml' media type > Author(s) : M. Baker, M. Nottingham > Filename : draft-baker-soap-media-reg-00.txt > Pages : > Date : 15-Jan-02 > > This document defines the 'application/soap+xml' media type which can > be used to describe SOAP 1.2 messages serialized as XML. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-00.txt MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com Received: by above.proper.com (8.11.6/8.11.3) id g0BHR9C01175 for ietf-xml-mime-bks; Fri, 11 Jan 2002 09:27:09 -0800 (PST) Received: from xmlfmail.xmlfund.com (mail.xmlfund.com [63.224.51.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BHR8301170 for ; Fri, 11 Jan 2002 09:27:08 -0800 (PST) Received: by xmlfmail.xmlfund.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 09:27:05 -0800 Message-ID: <2AE31649CF989F4FB354F6D95EB0CE6E4D674A@xmlfmail.xmlfund.com> From: Mike Dierken To: "'ietf-xml-mime@imc.org'" Subject: FW: Media types Date: Fri, 11 Jan 2002 09:26:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [...re-sending...] > -----Original Message----- > From: Mark Baker [mailto:distobj@acm.org] > [...] > I agree that media types aren't suitable for multi-namespaced > documents. > That's why I'm all for making the transition from media types to > namespaces with either vanilla "application/xml", or adorned with the > root namespace. Does a namespace alone indicate the semantic meaning of an XML document? Is it 'enough' of a hint to do useful things? Or do you need the name of the root element as well? Would schema+rootElement be a better alternative? Would that sufficiently identify the 'model' of the message content? Could XML documents without schema use namespace in place of schema reference? Is there a more general idea of 'content-model' that might apply to multiple content-type representations? Example: Content-Type: application/xml Content-Model: http://www.w3.org/2001/12/soap-envelope#Envelope and Content-Type: application/x-java-serialized-object Content-Model: java:org.apache.sample.user.profile Mike Received: by above.proper.com (8.11.6/8.11.3) id g0AI2vs27004 for ietf-xml-mime-bks; Thu, 10 Jan 2002 10:02:57 -0800 (PST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0AI2t327000 for ; Thu, 10 Jan 2002 10:02:56 -0800 (PST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id NAA26887; Thu, 10 Jan 2002 13:03:43 -0500 Message-Id: <200201101803.NAA26887@markbaker.ca> Subject: Re: Media types To: david.orchard@bea.com (David Orchard) Date: Thu, 10 Jan 2002 13:03:43 -0500 (EST) Cc: www-tag@w3.org, ietf-xml-mime@imc.org In-Reply-To: <00d201c1995a$024f1c90$180ba8c0@beasys.com> from "David Orchard" at Jan 09, 2002 02:07:19 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] 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: Hi Dave, > Mark, > > The same concerns I raised in xmlp apply here. The slippery slope of > manifests appears. What about other namespaces and vocabularies? For > example, SOAP with my foo vocabulary using xml schema data types would be: > application/xml; xmlns="soapns" xmlns="foons" xmlns="datatypesns" > > or perhaps > application/xml; xmlns="soapns foons datatypens" > > This would have to duplicata all the xmlns decls in the document. > > Does this make sense? I understood the slippery slope argument around the "+xml" convention because the syntax didn't (and couldn't) preclude other "+" things. But "xmlns" would be restricted to a single URI value identifying the root namespace. Note that I'm not really sold on this myself, it just looks pretty. 8-) An issue with it is that every tool I'm familiar with that enables an app to be bound to a media type, doesn't permit me to bind different apps to different parameter values of the same type. So for example; application/xml; xmlns="http://www.w3.org/1999/xhtml" and application/xml; xmlns="http://www.w3.org/2001/12/soap-envelope" would only be allowed to be dispatched to a generic XML processor anyhow, who would then be tasked with further dispatch based on the namespace. So the parameter doesn't add a lot of value in that case beyond what would be possible with just "application/xml", except as a quicker lookup mechanism, which itself comes at the cost of the complexity of duplicating that information and handling additional error cases. I think the need for it (or not) would come mostly from the email community, which I unfortunately don't have nearly enough knowledge about. > The way I see it, media types are broken for multiple namespace'd xml > documents, especially documents that are targetted to be frameworks like > soap. The "+" syntax for media-types simply doesn't scale to these kinds of > documents. I don't know how, but we have to find someway of either > expressing a manifest, or the name of a profile that is a reference to a > manifest. At least with the use of xmlns we have some notion of versions as > well, given the namespace name would be used. I agree that media types aren't suitable for multi-namespaced documents. That's why I'm all for making the transition from media types to namespaces with either vanilla "application/xml", or adorned with the root namespace. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g09MuxN02468 for ietf-xml-mime-bks; Wed, 9 Jan 2002 14:56:59 -0800 (PST) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09Muw302464 for ; Wed, 9 Jan 2002 14:56:58 -0800 (PST) Received: from GK-VAIO.ninebynine.org (dyn194-37.sftm-212-159.plus.net [212.159.37.194]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g0A6jg418557; Wed, 9 Jan 2002 22:45:43 -0800 Message-Id: <5.1.0.14.2.20020109222835.00ab6e90@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Jan 2002 22:32:24 +0000 To: Mark Baker From: Graham Klyne Subject: Re: Media types Cc: ietf-xml-mime@imc.org In-Reply-To: <200201092155.QAA17443@markbaker.ca> References: <200201092116.QAA16938@markbaker.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:55 PM 1/9/02 -0500, Mark Baker wrote: >I raised this with the authors of RFC 3023 long ago, but they rejected >it. But I believe it remains worth considering. It seems to me to be >a nice bridge, similar to the one the XMLP WG has taken with >"relocating" SOAPAction to a parameter on the proposed SOAP media >type[1]. I think I understand why it was rejected in the discussions for RFC 3023, and I think those reasons were valid in that context. But I don't think that means the idea is completely without merit. I think there is some concern about how well Content-type parameters are handled by deployed MIME applications, but that seems less of an issue for newer Web applications. I remain agnostic. #g -- ------------------- Graham Klyne Received: by above.proper.com (8.11.6/8.11.3) id g09LsT901073 for ietf-xml-mime-bks; Wed, 9 Jan 2002 13:54:29 -0800 (PST) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09LsR301069 for ; Wed, 9 Jan 2002 13:54:28 -0800 (PST) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id QAA17443; Wed, 9 Jan 2002 16:55:19 -0500 Message-Id: <200201092155.QAA17443@markbaker.ca> Subject: Re: Media types To: www-tag@w3.org Date: Wed, 9 Jan 2002 16:55:19 -0500 (EST) Cc: ietf-xml-mime@imc.org In-Reply-To: <200201092116.QAA16938@markbaker.ca> from "Mark Baker" at Jan 09, 2002 04:16:28 PM From: Mark Baker X-Mailer: ELM [version 2.5 PL3] 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: [I should have CCd ietf-xml-mime on the initial post, but it didn't occur to me. Anyhow, that post can be found here; http://lists.w3.org/Archives/Public/www-tag/2002Jan/0063.html ] Speaking for myself now, > Q. 3; What is, or what should be, the relationship between a media type > and an XML namespace? One of the thoughts that I had quite a while ago (that I believe came from something I saw from Dan Connolly), was of being able to migrate from media types to namespaces by exposing the namespace through an optional namespace parameter on a generic XML media type, for example XHTML could be described with; application/xml; xmlns="http://www.w3.org/1999/xhtml" instead of with the custom type, application/xhtml+xml. I raised this with the authors of RFC 3023 long ago, but they rejected it. But I believe it remains worth considering. It seems to me to be a nice bridge, similar to the one the XMLP WG has taken with "relocating" SOAPAction to a parameter on the proposed SOAP media type[1]. [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0029.html MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com