Received: by ns.secondary.com (8.9.3/8.9.3) id UAA25920 for ietf-xml-mime-bks; Tue, 31 Oct 2000 20:09:14 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA25915 for ; Tue, 31 Oct 2000 20:09:12 -0800 (PST) From: ned.freed@INNOSOFT.COM Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JVZYX8TDSW00046H@mauve.mrochek.com> for ietf-xml-mime@imc.org; Tue, 31 Oct 2000 20:15:28 -0700 (PDT) Date: Tue, 31 Oct 2000 20:08:35 -0700 (PDT) Subject: RE: text/xhtml+xml vs. application/xhtml+xml In-reply-to: "Your message dated Tue, 31 Oct 2000 12:01:24 -0500" To: Gavin Thomas Nicol Cc: ietf-xml-mime@imc.org Message-id: <01JVZZX0ZI7M00046H@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01JVXYP9H7ZI00011D@mauve.mrochek.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > But the analogy is gravely flawed in any case -- text/html > > has proved to have no value whatsoever. And this goes far > > beyond the notion of "good" and "bad" use. > I think the millions of messages sent using text/html would > disprove the notion that "text/html has proved to have no value > whatsoever". Actually, the type's use proves nothing, since as I pointed out previously, it isn't necessary to use the type to get the right effect. > It seems to me that you are projecting a subjective > analysis. It's fair to say that text/html is not being used as > intended. That is not the same as saying it is of no use. And you are arguing a strawman here. I never said that sending HTML was of no use, only that the labelling of it as text/html was and is unnecessary. > Anyway, the genie *is* out of the bag. For HTML it is. Doesn't mean it is out of the bag for other types. We should learn from our mistakes. > > > because again, of (supposed) interoperability, and because they > > > didn't have any escape route. > > > > Sure they did. Application/html combined with a content-disposition > > label of "inline" offers all the benefits and has none of the > > problems. > If that is the case then why didn't the MUA's adopt this? Because it isn't what we told them to do. We told them to use text/html, so that's what they did. But we also said that the HTML had to be legible. That didn't happen. Again, I'm not blaming anybody for this. It happened, it was a mistake, or an expectation mismatch, or whatever else you want to call it. The point is now we know better, so we should not let it happen again. > > > With HTML, the genie is already out of the bottle, but with XML > > > there is a chance to get MUA's working as they should: when > > > sending textual data, use text/xml, but when sending application > > > specific data, send application/foo+xml, etc. > > > > In case it isn't obvious, I am strongly opposed to this policy. > It's obvious, but that doesn't discount it. I believe my argument discounts it quite effectively. In addition, I haven't noticed a lot of support for other quarters for your approach. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23088 for ietf-xml-mime-bks; Tue, 31 Oct 2000 10:35:44 -0800 (PST) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23084 for ; Tue, 31 Oct 2000 10:35:43 -0800 (PST) Received: from zingo (ith1-3e6.twcny.rr.com [24.24.11.230]) by hesketh.net (8.9.3/8.9.3) with SMTP id NAA30075 for ; Tue, 31 Oct 2000 13:41:57 -0500 Message-Id: <200010311841.NAA30075@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 31 Oct 2000 13:45:34 -0500 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Fwd: Protocol Action: XML Media Types to Proposed Standard 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: This list wasn't CC'd, but I thought you all might want to know. >To: IETF-Announce: ; >Cc: RFC Editor , IANA >Cc: Internet Architecture Board >From: The IESG >Subject: Protocol Action: XML Media Types to Proposed Standard >Date: Tue, 31 Oct 2000 07:38:26 -0500 > > > >The IESG has approved the Internet-Draft 'XML Media Types' > as a Proposed Standard. This has been >reviewed in the IETF but is not the product of an IETF Working Group. >The IESG contact persons are Patrik Faltstrom and Ned Freed. > > >Technical Summary > >This document is an update of RFC 2376. It standardizes five media >types -- text/xml, application/xml, text/xml-external-parsed-entity, >application/xml-external-parsed-entity, and application/xml-dtd -- >for use in exchanging network entities that are related to the >Extensible Markup Language (XML). This document also standardizes a >convention (using the suffix '+xml') for naming media types outside >of these five types when those media types represent XML entities. > >Major differences from RFC 2376 are (1) the addition of >text/xml-external-parsed-entity, >application/xml-external-parsed-entity, and application/xml-dtd, (2) >the '+xml' suffix convention (which also updates the RFC 2048 >registration process), and (3) the discussion of "utf-16le" and >"utf-16be". > >Working Group Summary > >Discussions about this memo has occurred on a number of mailing >lists, including ietf-xml-mime@imc.org and ietf-types@uninett.no. >There appears to be consensus for this update of RFC 2376. > >Protocol Quality > >Ned Freed has reviewed the specification for the IESG. > Simon St.Laurent XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books Received: by ns.secondary.com (8.9.3/8.9.3) id KAA22681 for ietf-xml-mime-bks; Tue, 31 Oct 2000 10:32:48 -0800 (PST) Received: from mail.reutershealth.com (mail.reutershealth.com [204.243.9.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22674 for ; Tue, 31 Oct 2000 10:32:46 -0800 (PST) Received: from reutershealth.com (IDENT:cowan@[192.168.3.11]) by mail.reutershealth.com (Pro-8.9.3/8.9.3) with ESMTP id NAA09277; Tue, 31 Oct 2000 13:39:48 -0500 (EST) Message-ID: <39FF11E8.C291EF31@reutershealth.com> Date: Tue, 31 Oct 2000 13:39:36 -0500 From: John Cowan Organization: Reuters Health Information X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gavin Thomas Nicol CC: ietf-xml-mime@imc.org Subject: Re: text/xhtml+xml vs. application/xhtml+xml References: 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: Gavin Thomas Nicol wrote: > > > In effect, application/xml is a proxy for x-whatever1/whatever2+xml, > > which by the rules for "x-" (don't interpret it unless you know > > what you are doing) can't be treated as XML by ignorant processors. > > Right, hence my preference for text/xml and application/foo+xml. My point was that if whatever1/whatever2+xml has not yet been registered by IANA, or should not be registered for whatever reason (only used in private interchange, e.g.), then "application/xml" serves as a proxy for it. Therefore, the existence of "application/xml" has its uses. -- There is / one art || John Cowan no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein Received: by ns.secondary.com (8.9.3/8.9.3) id KAA22528 for ietf-xml-mime-bks; Tue, 31 Oct 2000 10:31:27 -0800 (PST) Received: from mail.reutershealth.com (mail.reutershealth.com [204.243.9.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22520 for ; Tue, 31 Oct 2000 10:31:26 -0800 (PST) Received: from reutershealth.com (IDENT:cowan@[192.168.3.11]) by mail.reutershealth.com (Pro-8.9.3/8.9.3) with ESMTP id NAA09270; Tue, 31 Oct 2000 13:38:26 -0500 (EST) Message-ID: <39FF1197.8A18C167@reutershealth.com> Date: Tue, 31 Oct 2000 13:38:15 -0500 From: John Cowan Organization: Reuters Health Information X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gavin Thomas Nicol , "ietf-xml-mime@imc.org" Subject: Re: text/xhtml+xml vs. application/xhtml+xml References: 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: Gavin Thomas Nicol wrote: > If that is the case then why didn't the MUA's adopt this? Why, for the same reason that DECnet implementations used to set the Ethernet address to match the DECnet network/node number, instead of using ARP like IP does... And the same reason that Dr. Johnson's dictionary defined "pastern" as "the knee of a horse"... Ignorance, sheer ignorance. -- There is / one art || John Cowan no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13361 for ietf-xml-mime-bks; Tue, 31 Oct 2000 08:48:18 -0800 (PST) Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13356 for ; Tue, 31 Oct 2000 08:48:17 -0800 (PST) Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id LAA26309 for ; Tue, 31 Oct 2000 11:53:02 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Tue, 31 Oct 2000 12:01:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <39FDB075.27E20419@reutershealth.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > In effect, application/xml is a proxy for x-whatever1/whatever2+xml, > which by the rules for "x-" (don't interpret it unless you know > what you are doing) can't be treated as XML by ignorant processors. Right, hence my preference for text/xml and application/foo+xml. Received: by ns.secondary.com (8.9.3/8.9.3) id IAA13355 for ietf-xml-mime-bks; Tue, 31 Oct 2000 08:48:14 -0800 (PST) Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13351 for ; Tue, 31 Oct 2000 08:48:12 -0800 (PST) Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id LAA26300 for ; Tue, 31 Oct 2000 11:53:00 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Tue, 31 Oct 2000 12:01:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <01JVXYP9H7ZI00011D@mauve.mrochek.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > But the analogy is gravely flawed in any case -- text/html > has proved to have no value whatsoever. And this goes far > beyond the notion of "good" and "bad" use. I think the millions of messages sent using text/html would disprove the notion that "text/html has proved to have no value whatsoever". It seems to me that you are projecting a subjective analysis. It's fair to say that text/html is not being used as intended. That is not the same as saying it is of no use. Anyway, the genie *is* out of the bag. > > because again, of (supposed) interoperability, and because they > > didn't have any escape route. > > Sure they did. Application/html combined with a content-disposition > label of "inline" offers all the benefits and has none of the > problems. If that is the case then why didn't the MUA's adopt this? > > With HTML, the genie is already out of the bottle, but with XML > > there is a chance to get MUA's working as they should: when > > sending textual data, use text/xml, but when sending application > > specific data, send application/foo+xml, etc. > > In case it isn't obvious, I am strongly opposed to this policy. It's obvious, but that doesn't discount it. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA15841 for ietf-xml-mime-bks; Mon, 30 Oct 2000 09:24:49 -0800 (PST) Received: from mail.reutershealth.com (mail.reutershealth.com [204.243.9.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15836 for ; Mon, 30 Oct 2000 09:24:48 -0800 (PST) Received: from reutershealth.com (IDENT:cowan@[192.168.3.11]) by mail.reutershealth.com (Pro-8.9.3/8.9.3) with ESMTP id MAA01361; Mon, 30 Oct 2000 12:31:41 -0500 (EST) Message-ID: <39FDB075.27E20419@reutershealth.com> Date: Mon, 30 Oct 2000 12:31:33 -0500 From: John Cowan Organization: Reuters Health Information X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Gavin Thomas Nicol , "ietf-xml-mime@imc.org" Subject: Re: text/xhtml+xml vs. application/xhtml+xml References: 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: Gavin Thomas Nicol wrote: > Bottom line: text/xml, application/foo+xml and (to a lesser degree) > application/xml are all useful. We should provide them all and give > people clear guidelines on their use so that we can avoid the abuse > we see with text/html. In effect, application/xml is a proxy for x-whatever1/whatever2+xml, which by the rules for "x-" (don't interpret it unless you know what you are doing) can't be treated as XML by ignorant processors. -- There is / one art || John Cowan no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein Received: by ns.secondary.com (8.9.3/8.9.3) id JAA15107 for ietf-xml-mime-bks; Mon, 30 Oct 2000 09:12:31 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15102 for ; Mon, 30 Oct 2000 09:12:29 -0800 (PST) From: ned.freed@INNOSOFT.COM Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JVWYJZVHHS00011D@mauve.mrochek.com> for ietf-xml-mime@imc.org; Mon, 30 Oct 2000 09:18:36 -0700 (PDT) Date: Mon, 30 Oct 2000 09:02:39 -0700 (PDT) Subject: RE: text/xhtml+xml vs. application/xhtml+xml In-reply-to: "Your message dated Mon, 30 Oct 2000 11:34:19 -0500" To: Gavin Thomas Nicol Cc: ietf-xml-mime@imc.org Message-id: <01JVXYP9H7ZI00011D@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01JVXAP5JUA200011D@mauve.mrochek.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > It isn't a question of blame, it is a question of whether or not > > agents have been generally able to construct HTML objects that > > are legible without any formatting. In hindsight, the answer to > > this question has proved to be "no". And since text/html's > > utility was predicated on the answer being > > "yes", it was a mistake to have defined it. > I disagree with the logic here: it's like saying that the creation > of weapons is predicated on their being put to good use, but having > seen them kill people, the creation is a mistake. Actually, a fair number of people make precisely this sort of argument in regards to weapons and consider it entirely valid. But the analogy is gravely flawed in any case -- text/html has proved to have no value whatsoever. And this goes far beyond the notion of "good" and "bad" use. > At the end of the > day, it is the responsibility of the agents to label the content > correctly... you can't hold the tools creators responsible for > their misuse. Again, you're focusing on blame. Blame isn't relevant. > If the agents consistently abuse the protocols and standards, then > there is an argument that the agents needs aren't being met. Perhaps, but in such cases the right answer is to propose new mechanisms that do meet the agent's needs, not to repeat mistakes we've made in the past. > HTML > is abused because people needed the equivalent of RTF, but wanted > to piggyback on the (supposed) interoperability/business benefits > of WWW standards. > Likewise, agents consistently send data as text/html when in > reality, the content is application/x-whatever. The main reason is > because again, of (supposed) interoperability, and because they > didn't have any escape route. Sure they did. Application/html combined with a content-disposition label of "inline" offers all the benefits and has none of the problems. > With HTML, the genie is already out of the bottle, but with XML > there is a chance to get MUA's working as they should: when > sending textual data, use text/xml, but when sending application > specific data, send application/foo+xml, etc. In case it isn't obvious, I am strongly opposed to this policy. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11255 for ietf-xml-mime-bks; Mon, 30 Oct 2000 08:21:34 -0800 (PST) Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11194 for ; Mon, 30 Oct 2000 08:21:16 -0800 (PST) Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id LAA04033 for ; Mon, 30 Oct 2000 11:26:00 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Mon, 30 Oct 2000 11:34:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <01JVXB7SRF5W00011D@mauve.mrochek.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > You can construct HTML that can be read without an HTML > processor of any sort. But few if any agents that emit > text/html actually do this. Right, and you need to ask yourself why that is. > > To get back to ground zero, one must ask why one is exchanging > > XML in the first place. If is as a structured peice of text, > > then text/* is fine. > > No it isn't, because that's not what the top-level text type is > for. The intent of the text type is to label material that can > sensible be presented to people without any processing. I think there is a lot of XML content that meets those criteria. There is obviously also a *lot* that doesn't (SOAP messages etc.) > You seem to think that the top-level text type label is intended to label > structured text, but that's just not what it is for. No. I understand quite well what the intent of text/* is. I should note that *all* text is somewhat structured (even this message which will be sent text/plain). Many XML documents doi little more than make the inherent structure explicit, and for such documents, text/xml is fine. > The +xml suffix is intended to make XML detectable even when > the specific type isn't known. Right, which just gives one more level of default behaviour. At the end of the day, people are going to use XML as they see fit, and there will be *many* application specific uses of XML. Most of those applications can, and should use application/foo or application/foo+xml. In the latter case, the main benefit is that if the processor doesn't know about application/foo, it can do *something*. Bottom line: text/xml, application/foo+xml and (to a lesser degree) application/xml are all useful. We should provide them all and give people clear guidelines on their use so that we can avoid the abuse we see with text/html. Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11203 for ietf-xml-mime-bks; Mon, 30 Oct 2000 08:21:17 -0800 (PST) Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11193 for ; Mon, 30 Oct 2000 08:21:16 -0800 (PST) Received: from endymion (endymion [198.112.118.87]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id LAA04027 for ; Mon, 30 Oct 2000 11:25:56 -0500 (EST) From: "Gavin Thomas Nicol" To: Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Mon, 30 Oct 2000 11:34:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <01JVXAP5JUA200011D@mauve.mrochek.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > It isn't a question of blame, it is a question of whether or not > agents have been generally able to construct HTML objects that > are legible without any formatting. In hindsight, the answer to > this question has proved to be "no". And since text/html's > utility was predicated on the answer being > "yes", it was a mistake to have defined it. I disagree with the logic here: it's like saying that the creation of weapons is predicated on their being put to good use, but having seen them kill people, the creation is a mistake. At the end of the day, it is the responsibility of the agents to label the content correctly... you can't hold the tools creators responsible for their misuse. If the agents consistently abuse the protocols and standards, then there is an argument that the agents needs aren't being met. HTML is abused because people needed the equivalent of RTF, but wanted to piggyback on the (supposed) interoperability/business benefits of WWW standards. Likewise, agents consistently send data as text/html when in reality, the content is application/x-whatever. The main reason is because again, of (supposed) interoperability, and because they didn't have any escape route. With HTML, the genie is already out of the bottle, but with XML there is a chance to get MUA's working as they should: when sending textual data, use text/xml, but when sending application specific data, send application/foo+xml, etc. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA10832 for ietf-xml-mime-bks; Sun, 29 Oct 2000 22:00:19 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA10828 for ; Sun, 29 Oct 2000 22:00:16 -0800 (PST) From: ned.freed@INNOSOFT.COM Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JVWYJZVHHS00011D@mauve.mrochek.com> for ietf-xml-mime@imc.org; Sun, 29 Oct 2000 22:06:21 -0700 (PDT) Date: Sun, 29 Oct 2000 21:51:48 -0700 (PDT) Subject: RE: text/xhtml+xml vs. application/xhtml+xml In-reply-to: "Your message dated Tue, 24 Oct 2000 22:22:27 -0700" To: Gavin Thomas Nicol Cc: ietf-xml-mime@imc.org Message-id: <01JVXB7SRF5W00011D@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <25D0C66E6D25D311B2AC0008C7913EE00105A16B@tdmail2.teledesic.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > This is a subtle issue that very few document creators will > > understand > True, but then the argument against text/html is also rooted in > such subtlety? The subtlety doesn't lie in the intent, but in the difficulty of achieving it. You can construct HTML that can be read without an HTML processor of any sort. But few if any agents that emit text/html actually do this. Instead they emit junk that is quite difficult to read even if you're familiar with HTML, and nearly impossible if you aren't. > > It's much better to pick one MIME type for each media type then to try to > > pass on the decision to folks who won't understand or won't care about the > > subtlety. That one type, IMHO, should almost always be application/foo+xml > > not text/foo+xml. > In that case it would seem much better to define application/foo rather > than application/foo+xml No. There's a specific purpose to the +xml suffix and it should be used when it is appropriate. > XML is a complex object type (as is text in general), the question is where > that complexity best resides, and where one desires interoperability. I > would argue that text/xml (as in my example) is useful, but not sufficient > because it doesn't capture everything needed to process the content. This > is one of the problems that XML brings to the fore because it can represent > so many things, and be interpreted in so many ways (MIME is built around > the assumption that the media type canonically defines how it should be > processed). This isn't necessarily true in light of the definition of the +xml suffix. In addition, there is more to it than this. Top level types in particular are intended to tell you generally how something is or can be processed. This can assist an agent in handling material even when a specific definition isn't available. > To get back to ground zero, one must ask why one is exchanging XML in the > first place. If is as a structured peice of text, then text/* is fine. No it isn't, because that's not what the top-level text type is for. The intent of the text type is to label material that can sensible be presented to people without any processing. You seem to think that the top-level text type label is intended to label structured text, but that's just not what it is for. > More > often than not, this will *not* be the case, and so there is a good argument > for application/*. In cases where XML content is being served with additional > defined processing, the message type will probably be a multipart message, > with one part being labelled as text/xml (another might be application/xsl > or text/css). > Bottom line: XML in well-defined cases should use XML, otherwise it will > probably use a multipart message. The +xml suffix is intended to make XML detectable even when the specific type isn't known. This eliminates the need to use application/xml to insure such processing is possible. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id VAA10505 for ietf-xml-mime-bks; Sun, 29 Oct 2000 21:45:30 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA10501 for ; Sun, 29 Oct 2000 21:45:29 -0800 (PST) From: ned.freed@INNOSOFT.COM Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JVWYJZVHHS00011D@mauve.mrochek.com> for ietf-xml-mime@imc.org; Sun, 29 Oct 2000 21:51:19 -0700 (PDT) Date: Sun, 29 Oct 2000 21:47:37 -0700 (PDT) Subject: RE: text/xhtml+xml vs. application/xhtml+xml In-reply-to: "Your message dated Tue, 24 Oct 2000 20:25:22 -0700" To: Gavin Thomas Nicol Cc: ietf-xml-mime@imc.org Message-id: <01JVXAP5JUA200011D@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <01JVHM2XD46K00056I@mauve.mrochek.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > I completely agree with Keith. Text/html was a mistake. > That's like saying richtext was a mistake. If you are referring to text/richtext, then there is in fact a broad consensus that it *was* a mistake. That's why text/enriched was devised, after all. > The fact is that the MUA's are blindingly violating the > HTML specification and making it an application-specific > format. You can hardly blame text/html for that. It isn't a question of blame, it is a question of whether or not agents have been generally able to construct HTML objects that are legible without any formatting. In hindsight, the answer to this question has proved to be "no". And since text/html's utility was predicated on the answer being "yes", it was a mistake to have defined it. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22185 for ietf-xml-mime-bks; Tue, 24 Oct 2000 22:10:00 -0700 (PDT) Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22180 for ; Tue, 24 Oct 2000 22:09:58 -0700 (PDT) Received: from endymion (modem_b [199.93.212.244]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id BAA28953 for ; Wed, 25 Oct 2000 01:14:15 -0400 (EDT) From: "Gavin Thomas Nicol" To: Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Tue, 24 Oct 2000 22:22:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <25D0C66E6D25D311B2AC0008C7913EE00105A16B@tdmail2.teledesic.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > This is a subtle issue that very few document creators will > understand True, but then the argument against text/html is also rooted in such subtlety? > It's much better to pick one MIME type for each media type then to try to > pass on the decision to folks who won't understand or won't care about the > subtlety. That one type, IMHO, should almost always be application/foo+xml > not text/foo+xml. In that case it would seem much better to define application/foo rather than application/foo+xml XML is a complex object type (as is text in general), the question is where that complexity best resides, and where one desires interoperability. I would argue that text/xml (as in my example) is useful, but not sufficient because it doesn't capture everything needed to process the content. This is one of the problems that XML brings to the fore because it can represent so many things, and be interpreted in so many ways (MIME is built around the assumption that the media type canonically defines how it should be processed). To get back to ground zero, one must ask why one is exchanging XML in the first place. If is as a structured peice of text, then text/* is fine. More often than not, this will *not* be the case, and so there is a good argument for application/*. In cases where XML content is being served with additional defined processing, the message type will probably be a multipart message, with one part being labelled as text/xml (another might be application/xsl or text/css). Bottom line: XML in well-defined cases should use XML, otherwise it will probably use a multipart message. Received: by ns.secondary.com (8.9.3/8.9.3) id UAA20997 for ietf-xml-mime-bks; Tue, 24 Oct 2000 20:12:55 -0700 (PDT) Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA20993 for ; Tue, 24 Oct 2000 20:12:53 -0700 (PDT) Received: from endymion (modem_h [199.93.212.250]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id XAA27270 for ; Tue, 24 Oct 2000 23:17:10 -0400 (EDT) From: "Gavin Thomas Nicol" To: Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Tue, 24 Oct 2000 20:25:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <01JVHM2XD46K00056I@mauve.mrochek.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I completely agree with Keith. Text/html was a mistake. That's like saying richtext was a mistake. The fact is that the MUA's are blindingly violating the HTML specification and making it an application-specific format. You can hardly blame text/html for that. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA19277 for ietf-xml-mime-bks; Tue, 24 Oct 2000 18:01:44 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19273 for ; Tue, 24 Oct 2000 18:01:43 -0700 (PDT) Received: by MGATE-01 with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 18:07:31 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE00105A16B@tdmail2.teledesic.com> From: Dan Kohn To: Gavin Thomas Nicol , ietf-xml-mime@imc.org Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Tue, 24 Oct 2000 18:07:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a subtle issue that very few document creators will understand. The vast majority of XML (including, I would argue, the example below) is considered unreadable by most users. For more evidence, think of the years of complaints about "quotable-unreadable" MIME encoding, which just has a few hex substitutions and = signs. It's much better to pick one MIME type for each media type then to try to pass on the decision to folks who won't understand or won't care about the subtlety. That one type, IMHO, should almost always be application/foo+xml not text/foo+xml. - dan -- Dan Kohn -----Original Message----- From: Gavin Thomas Nicol [mailto:gtn@ebt.com] Sent: Tuesday, 2000-10-24 17:02 To: ietf-xml-mime@imc.org Subject: RE: text/xhtml+xml vs. application/xhtml+xml > I think the general consensus of the MIME community is that making HTML > a subtype of "text/" was a mistake. While it is possible to write HTML > which is readable "to some extent" as plain text, the HTML that is > generated by a typical MUA or HTML editor is so full of useless cruft > that it doesn't qualify. Perhaps a determined human being can read the > text "to some extent" but the typical human gives up. Well, these tools would be far better off using application/html in my mind (for many, even application/html is too kind). > So IMHO we should learn from this experience and make XHTML and other > XML-ish things subtypes of application/. I disagree. We should have both application/ and text/ depending on the intent. For example, I believe the following would correctly be text/xml while and SVG image would be better application/svg+xml. ---------------------------------------------------------------------
Patently Ridiculous Patents Dogbert at the patent office Dogbert at the patent office

Patently Ridiculous Patents - There has been a literal explosion of internet related patent recently. Many of these patents are trivial, but still the cost of defineding against them will have an impact on companies worldwide.

Some examples:

  • Information Architects now has a patent on dynamic composition for syndication.
  • Sunil Paul got a patent (6,052,709) for email spam filtering.
  • Shmuel Shaffer, William Beyda and Paul Bonomo, received patent 6,092,114 for filtering attachments to make the easily viewable on the target system.
  • Dan Kikinis, of Saratoga, Calif., won a patent (6,085,232) for the DataLink Systems Corporation in San Diego for a paging system embedded in a computer keyboard.
  • Sanjay Agraharam, Lee Begeja, Carroll Creswell, Ram Ramamurthy and Sandeep Sibal received patent 6,085,231 for a combined voice and e-mail system that allows subscribers to get both just by looking in their e-mail box. The system converts voice mail into e-mail. The system then converts the voice message into text or a .wav file, formats either one as an e-mail and sends it to the recipient.

Makes one wonder where it's all going to stop...

Received: by ns.secondary.com (8.9.3/8.9.3) id QAA17974 for ietf-xml-mime-bks; Tue, 24 Oct 2000 16:49:59 -0700 (PDT) Received: from tribble.eps.inso.com (phil8.ebt.com [198.112.118.8] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17970 for ; Tue, 24 Oct 2000 16:49:58 -0700 (PDT) Received: from endymion ([209.153.196.229]) by tribble.eps.inso.com (8.9.1/8.9.1) with SMTP id TAA23539 for ; Tue, 24 Oct 2000 19:54:14 -0400 (EDT) From: "Gavin Thomas Nicol" To: Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Tue, 24 Oct 2000 17:02:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200010182126.RAA19225@astro.cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I think the general consensus of the MIME community is that making HTML > a subtype of "text/" was a mistake. While it is possible to write HTML > which is readable "to some extent" as plain text, the HTML that is > generated by a typical MUA or HTML editor is so full of useless cruft > that it doesn't qualify. Perhaps a determined human being can read the > text "to some extent" but the typical human gives up. Well, these tools would be far better off using application/html in my mind (for many, even application/html is too kind). > So IMHO we should learn from this experience and make XHTML and other > XML-ish things subtypes of application/. I disagree. We should have both application/ and text/ depending on the intent. For example, I believe the following would correctly be text/xml while and SVG image would be better application/svg+xml. ---------------------------------------------------------------------
Patently Ridiculous Patents Dogbert at the patent office Dogbert at the patent office

Patently Ridiculous Patents - There has been a literal explosion of internet related patent recently. Many of these patents are trivial, but still the cost of defineding against them will have an impact on companies worldwide.

Some examples:

  • Information Architects now has a patent on dynamic composition for syndication.
  • Sunil Paul got a patent (6,052,709) for email spam filtering.
  • Shmuel Shaffer, William Beyda and Paul Bonomo, received patent 6,092,114 for filtering attachments to make the easily viewable on the target system.
  • Dan Kikinis, of Saratoga, Calif., won a patent (6,085,232) for the DataLink Systems Corporation in San Diego for a paging system embedded in a computer keyboard.
  • Sanjay Agraharam, Lee Begeja, Carroll Creswell, Ram Ramamurthy and Sandeep Sibal received patent 6,085,231 for a combined voice and e-mail system that allows subscribers to get both just by looking in their e-mail box. The system converts voice mail into e-mail. The system then converts the voice message into text or a .wav file, formats either one as an e-mail and sends it to the recipient.

Makes one wonder where it's all going to stop...

Received: by ns.secondary.com (8.9.3/8.9.3) id KAA08741 for ietf-xml-mime-bks; Tue, 24 Oct 2000 10:32:25 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08737 for ; Tue, 24 Oct 2000 10:32:24 -0700 (PDT) Received: by MGATE-01 with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 10:38:08 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE00105A155@tdmail2.teledesic.com> From: Dan Kohn To: Marshall Rose Cc: bxxpwg@invisibleworlds.com, ietf-xml-mime@imc.org Subject: RE: [BXXPwg] application/beep+xml Date: Tue, 24 Oct 2000 10:38:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm not quite sure it's correct that these issues don't arise with XML 1.0 (although I agree life will be easier if it is true). Issues regarding the BOM are rife with XML 1.0 because UTF-16 is a recommended charset, and beep supports its use. RFC 2396 defines that the semantics of a fragment identifier are a property of the data resulting from the retrieval action, so arguably RFC 2048 should be updated to have MIME registrations explicitly define those semantics. You can leave them undefined, but there is some value from supporting XPointer. XML Base is an optional enhancement for XML 1.0 that can change the interpretation of relative URLs. You can support it, explicitly not support it (by outlawing relative URL), or leave it undefined. So, again, feel free to ignore; I just wanted to make sure the issues are clear. - dan -- Dan Kohn -----Original Message----- From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] Sent: Tuesday, 2000-10-24 10:13 To: Dan Kohn Cc: bxxpwg@invisibleworlds.com; ietf-xml-mime@imc.org; mrose@dbc.mtview.ca.us Subject: Re: [BXXPwg] application/beep+xml > Marshall, my only question is whether some of the Security Considerations of > additionally apply. Since you are > prohibiting the use of external entities, you avoid most of the risks, > however there is still the possibility of someone parsing the data with a > standard XML processor. Also, you might explicitly want to mention whether > this type follows RFC 2376bis's advice on use of the BOM (section 4), > XPointer syntax (section 5), and Base URI (section 6). Or, you could just > leave these things undefined. hi. i think you're missing the point. the particular subset listed there excludes all of the things you are mentioning. they aren't in the 1.0 specification. hence the addition text you request is redundant. that's sort of the whole point. /mtr Received: by ns.secondary.com (8.9.3/8.9.3) id KAA08105 for ietf-xml-mime-bks; Tue, 24 Oct 2000 10:10:55 -0700 (PDT) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08101 for ; Tue, 24 Oct 2000 10:10:52 -0700 (PDT) Received: (from mrose@localhost) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) id e9OHDBv08525; Tue, 24 Oct 2000 10:13:11 -0700 (PDT) Date: Tue, 24 Oct 2000 10:13:11 -0700 From: Marshall Rose To: Dan Kohn Cc: bxxpwg@invisibleworlds.com, ietf-xml-mime@imc.org, mrose@dbc.mtview.ca.us Subject: Re: [BXXPwg] application/beep+xml Message-ID: <20001024101311.A8509@dbc.mtview.ca.us> References: <25D0C66E6D25D311B2AC0008C7913EE00105A154@tdmail2.teledesic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <25D0C66E6D25D311B2AC0008C7913EE00105A154@tdmail2.teledesic.com>; from dan@dankohn.com on Tue, Oct 24, 2000 at 09:58:54AM -0700 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Marshall, my only question is whether some of the Security Considerations of > additionally apply. Since you are > prohibiting the use of external entities, you avoid most of the risks, > however there is still the possibility of someone parsing the data with a > standard XML processor. Also, you might explicitly want to mention whether > this type follows RFC 2376bis's advice on use of the BOM (section 4), > XPointer syntax (section 5), and Base URI (section 6). Or, you could just > leave these things undefined. hi. i think you're missing the point. the particular subset listed there excludes all of the things you are mentioning. they aren't in the 1.0 specification. hence the addition text you request is redundant. that's sort of the whole point. /mtr Received: by ns.secondary.com (8.9.3/8.9.3) id JAA07373 for ietf-xml-mime-bks; Tue, 24 Oct 2000 09:53:19 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA07369 for ; Tue, 24 Oct 2000 09:53:18 -0700 (PDT) Received: by MGATE-01 with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 09:59:02 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE00105A154@tdmail2.teledesic.com> From: Dan Kohn To: bxxpwg@invisibleworlds.com Cc: ietf-xml-mime@imc.org Subject: RE: [BXXPwg] application/beep+xml Date: Tue, 24 Oct 2000 09:58:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Marshall, my only question is whether some of the Security Considerations of additionally apply. Since you are prohibiting the use of external entities, you avoid most of the risks, however there is still the possibility of someone parsing the data with a standard XML processor. Also, you might explicitly want to mention whether this type follows RFC 2376bis's advice on use of the BOM (section 4), XPointer syntax (section 5), and Base URI (section 6). Or, you could just leave these things undefined. Thanks. - dan -- Dan Kohn -----Original Message----- From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] Sent: Tuesday, 2000-10-24 08:21 To: bxxpwg@invisibleworlds.com Cc: mrose@dbc.mtview.ca.us Subject: [BXXPwg] application/beep+xml hi. after review, it looks like application/beep+xml is probably the better choice. unless folks believe otherwise, here is what i propose to add to the draft. please comment. thanks, /mtr ps: naturally, the examples will all change to use this media type instead of text/xml ####### 6.4 Registration: application/beep+xml MIME media type name: application MIME subtype name: beep+xml Required parameters: none Optional parameters: charset (defaults to "UTF-8"[RFC 2279]) Encoding considerations: always use binary Security considerations: none, per se; however, any BEEP profile which uses this media type must describe its relevant security considerations Interoperability considerations: n/a Published specification: This media type is a proper subset of the the XML 1.0 specification[2]. Two restrictions are made. First, no entity references other than the five predefined general entities references ("&", "<", ">", "'", and """) and numeric entity references may be present. Second, neither the "XML" declaration (e.g., ) nor the "DOCTYPE" declaration (e.g., ) may be present. (Accordingly, if another character set other than UTF-8 is desired, then the "charset" parameter must be present.) All other XML 1.0 instructions (e.g., CDATA blocks, processing instructions, and so on) are allowed. Applications which use this media type: any BEEP profile wishing to make use of this XML 1.0 subset Additional Information: none Contact for further information: c.f., the "Author's Address" section of this memo Intended usage: limited use Author/Change controller: the IESG _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg Received: by ns.secondary.com (8.9.3/8.9.3) id JAA16077 for ietf-xml-mime-bks; Mon, 23 Oct 2000 09:11:37 -0700 (PDT) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16070 for ; Mon, 23 Oct 2000 09:11:36 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.99]) by prserv.net (out1) with SMTP id <2000102316170420104ejo1ke>; Mon, 23 Oct 2000 16:17:04 +0000 To: ph@w3.org Cc: ietf-xml-mime@imc.org Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt In-Reply-To: <39F45ED5.26317158@w3.org> References: <25D0C66E6D25D311B2AC0008C7913EE00105A0F4@tdmail2.teledesic.com> <39F45ED5.26317158@w3.org> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001024011712S.muraw3c@attglobal.net> Date: Tue, 24 Oct 2000 01:17:12 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Given what you write below, it looks like this has changed recently. > Do you have a pointer to the decision record ? Do you know the RFC > number ? Do you know when it will be published ? The IESG has approved publication of the I-D as a Proposed Standard. Here is the pointer to the decision. http://www.ietf.org/iesg/iesg.2K-10-05 > 2. The IESG approved publication of XML Media Types > as a Proposed Standard. Steve to send > announcement. Cheers, IBM Tokyo Research Lab & International University of Japan, Research Institute MURATA Makoto Received: by ns.secondary.com (8.9.3/8.9.3) id JAA15870 for ietf-xml-mime-bks; Mon, 23 Oct 2000 09:03:54 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15866 for ; Mon, 23 Oct 2000 09:03:53 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP29ZB>; Mon, 23 Oct 2000 09:10:04 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE00105A101@tdmail2.teledesic.com> From: Dan Kohn To: Philipp Hoschka Cc: ietf-xml-mime@imc.org Subject: RE: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt Date: Mon, 23 Oct 2000 09:09:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA15867 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The basic processes of IETF standardization would not allow a non-backward-compatible change to RFC2376bis, so I think there is little risk and some potential gain in referencing 2376bis. The fact that it has been "in the making for some while now" is exactly why I would prefer for any insights it contains not to go to waste. It is your choice, however. As to approval (which should be announced soon), see the minutes available at: http://www.ietf.org/iesg/iesg.2K-10-05 > 2. The IESG approved publication of XML Media Types > as a Proposed Standard. Steve to send > announcement. My understanding of the RFC Editor queue is that you could reference 2376bis in your I-D with a request for them to fill in the correct RFC number, and that this should not delay your draft (which I believe also needs to go through Last Call first). - dan -- Dan Kohn -----Original Message----- From: Philipp Hoschka [mailto:ph@w3.org] Sent: Monday, 2000-10-23 08:53 To: Dan Kohn Cc: ietf-xml-mime@imc.org Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt Dan Kohn a écrit : > > I would strongly suggest an include by reference, as implementation > experience will likely cause further updates to 2376bis at some point. As > an example, you are actually quoting text from RFC 2376, not 2376bis Citing RFC2376 seems correct, given that RFC 2376 is a stable spec, wheras the current internet draft (which you refer to as 2376bis) is not, and has been in the making for quite a while now. Given what you write below, it looks like this has changed recently. Do you have a pointer to the decision record ? Do you know the RFC number ? Do you know when it will be published ? As I said, I am will consider removing the "reference by copy", once I found out if anybody actually requested reference by copy, and why. However, I disagree with your argument that an advantage of citing by reference is that it allows easier updates - the reference will be to a stable document, and if that document is replaced by a new document, that doesn't mean that the registration for application/smil changes as well. Propagating the changes would require an update of the application/smil document. ... > If people are not willing to look up a referenced RFC, than they probably > won't bother reading the MIME registration RFC in the first place. As I said, I think there is practical evidence to the contrary. > Also, as specified in Section 7.1 of , > we would recommend referring to 2376bis for "specifying magic numbers, > fragment identifiers, base URIs, and use of the BOM". If you decide not to > do so (e.g., because of non-XPointer fragment semantics), The fragment semantics of application/smil are compatible with XPointer, as far as I can tell. >it would be worth > specifying that explicitly in your registration. Received: by ns.secondary.com (8.9.3/8.9.3) id IAA15260 for ietf-xml-mime-bks; Mon, 23 Oct 2000 08:50:12 -0700 (PDT) Received: from sophia.inria.fr (root@sophia.inria.fr [138.96.32.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15255 for ; Mon, 23 Oct 2000 08:50:09 -0700 (PDT) Received: from w3.org by sophia.inria.fr (8.10.0/8.10.0) with ESMTP id e9NFtMb15661; Mon, 23 Oct 2000 17:55:24 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host w3cdhcp15.w3.org [18.29.0.245] claimed to be w3.org Message-ID: <39F45ED5.26317158@w3.org> Date: Mon, 23 Oct 2000 17:52:53 +0200 From: Philipp Hoschka X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Dan Kohn CC: ietf-xml-mime@imc.org Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt References: <25D0C66E6D25D311B2AC0008C7913EE00105A0F4@tdmail2.teledesic.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Kohn a écrit : > > I would strongly suggest an include by reference, as implementation > experience will likely cause further updates to 2376bis at some point. As > an example, you are actually quoting text from RFC 2376, not 2376bis Citing RFC2376 seems correct, given that RFC 2376 is a stable spec, wheras the current internet draft (which you refer to as 2376bis) is not, and has been in the making for quite a while now. Given what you write below, it looks like this has changed recently. Do you have a pointer to the decision record ? Do you know the RFC number ? Do you know when it will be published ? As I said, I am will consider removing the "reference by copy", once I found out if anybody actually requested reference by copy, and why. However, I disagree with your argument that an advantage of citing by reference is that it allows easier updates - the reference will be to a stable document, and if that document is replaced by a new document, that doesn't mean that the registration for application/smil changes as well. Propagating the changes would require an update of the application/smil document. ... > If people are not willing to look up a referenced RFC, than they probably > won't bother reading the MIME registration RFC in the first place. As I said, I think there is practical evidence to the contrary. > Also, as specified in Section 7.1 of , > we would recommend referring to 2376bis for "specifying magic numbers, > fragment identifiers, base URIs, and use of the BOM". If you decide not to > do so (e.g., because of non-XPointer fragment semantics), The fragment semantics of application/smil are compatible with XPointer, as far as I can tell. >it would be worth > specifying that explicitly in your registration. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA09171 for ietf-xml-mime-bks; Mon, 23 Oct 2000 07:54:14 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09166 for ; Mon, 23 Oct 2000 07:54:13 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP29SB>; Mon, 23 Oct 2000 08:00:23 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE00105A0F4@tdmail2.teledesic.com> From: Dan Kohn To: Philipp Hoschka Cc: ietf-xml-mime@imc.org Subject: RE: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt Date: Mon, 23 Oct 2000 07:59:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA09167 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I would strongly suggest an include by reference, as implementation experience will likely cause further updates to 2376bis at some point. As an example, you are actually quoting text from RFC 2376, not 2376bis (which was just approved by the IESG this week!), and that text has significantly less detail and justification. If people are not willing to look up a referenced RFC, than they probably won't bother reading the MIME registration RFC in the first place. Also, as specified in Section 7.1 of , we would recommend referring to 2376bis for "specifying magic numbers, fragment identifiers, base URIs, and use of the BOM". If you decide not to do so (e.g., because of non-XPointer fragment semantics), it would be worth specifying that explicitly in your registration. - dan -- Dan Kohn -----Original Message----- From: Philipp Hoschka [mailto:ph@w3.org] Sent: Sunday, 2000-10-22 11:26 To: Dan Kohn Cc: ietf-xml-mime@imc.org Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt Dan, thanks for the review. See replies below Dan Kohn a écrit : > > Philipp, could I suggest that you review > , which is expected to shortly replace > RFC 2376. Specifically, I would strongly recommend changing your > application to application/smil+xml, and quoting the appropriate sections of > RFC 2376bis by reference rather than by repeating the text. For smil+xml, see Murata's recount of history. I added a paragraph explaining why we chose not to use the postfix for this one. As for the sections quoted by repeating the text: The sections were included by reference in earlier versions of the draft. I seem to remember that I decided to repeat the text either because somebody explicitly suggested doing this, or because somebody got it wrong when implementing from an earlier draft. In any case, the intention is to make sure that people actually follow these rather involved rules when implementing application/smil. If this doesn't convince you, I can consider taking them out again. Before doing so, however, I would need to do some research on whether this wasn't something that was explicitly requested by somebody else. > Thanks for considering this. > > - dan > -- > Dan Kohn > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, 2000-10-17 03:47 > Subject: I-D ACTION:draft-hoschka-smil-media-type-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : The application/smil Media Type > Author(s) : P. Hoschka > Filename : draft-hoschka-smil-media-type-05.txt > Pages : 4 > Date : 16-Oct-00 > > This document specifies the Media Type for version 1 of the > Synchronized Multimedia Integration Language (SMIL 1.0). SMIL allows > integrating a set of independent multimedia objects into a > synchronized multimedia presentation. > > A RL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-05.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-hoschka-smil-media-type-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-hoschka-smil-media-type-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA08114 for ietf-xml-mime-bks; Mon, 23 Oct 2000 07:36:33 -0700 (PDT) Received: from sophia.inria.fr (root@sophia.inria.fr [138.96.32.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08110 for ; Mon, 23 Oct 2000 07:36:31 -0700 (PDT) Received: from w3.org by sophia.inria.fr (8.10.0/8.10.0) with ESMTP id e9NEfsb11442; Mon, 23 Oct 2000 16:41:55 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host w3cdhcp15.w3.org [18.29.0.245] claimed to be w3.org Message-ID: <39F33152.D789B350@w3.org> Date: Sun, 22 Oct 2000 20:26:26 +0200 From: Philipp Hoschka X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Dan Kohn CC: ietf-xml-mime@imc.org Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt References: <25D0C66E6D25D311B2AC0008C7913EE001059F6B@tdmail2.teledesic.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan, thanks for the review. See replies below Dan Kohn a écrit : > > Philipp, could I suggest that you review > , which is expected to shortly replace > RFC 2376. Specifically, I would strongly recommend changing your > application to application/smil+xml, and quoting the appropriate sections of > RFC 2376bis by reference rather than by repeating the text. For smil+xml, see Murata's recount of history. I added a paragraph explaining why we chose not to use the postfix for this one. As for the sections quoted by repeating the text: The sections were included by reference in earlier versions of the draft. I seem to remember that I decided to repeat the text either because somebody explicitly suggested doing this, or because somebody got it wrong when implementing from an earlier draft. In any case, the intention is to make sure that people actually follow these rather involved rules when implementing application/smil. If this doesn't convince you, I can consider taking them out again. Before doing so, however, I would need to do some research on whether this wasn't something that was explicitly requested by somebody else. > Thanks for considering this. > > - dan > -- > Dan Kohn > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, 2000-10-17 03:47 > Subject: I-D ACTION:draft-hoschka-smil-media-type-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : The application/smil Media Type > Author(s) : P. Hoschka > Filename : draft-hoschka-smil-media-type-05.txt > Pages : 4 > Date : 16-Oct-00 > > This document specifies the Media Type for version 1 of the > Synchronized Multimedia Integration Language (SMIL 1.0). SMIL allows > integrating a set of independent multimedia objects into a > synchronized multimedia presentation. > > A RL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-05.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-hoschka-smil-media-type-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-hoschka-smil-media-type-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. Received: by ns.secondary.com (8.9.3/8.9.3) id SAA06643 for ietf-xml-mime-bks; Sat, 21 Oct 2000 18:14:12 -0700 (PDT) Received: from sophia.inria.fr (root@sophia.inria.fr [138.96.32.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06638 for ; Sat, 21 Oct 2000 18:14:10 -0700 (PDT) Received: from w3.org by sophia.inria.fr (8.10.0/8.10.0) with ESMTP id e9M1JSu13670; Sun, 22 Oct 2000 03:19:29 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host w3cdhcp15.w3.org [18.29.0.245] claimed to be w3.org Message-ID: <39F2400D.37E6FD0B@w3.org> Date: Sun, 22 Oct 2000 03:17:01 +0200 From: Philipp Hoschka X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: muraw3c@attglobal.net CC: dan@dankohn.com, ietf-xml-mime@imc.org Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt References: <25D0C66E6D25D311B2AC0008C7913EE001059F6B@tdmail2.teledesic.com> <20001018223739T.muraw3c@attglobal.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: muraw3c@attglobal.net a écrit : ... > Phillip, could you revise the I-D as you promised? Thanks for retracing history so well ! I just sent an updated draft, which should appear soon. -Philipp Received: by ns.secondary.com (8.9.3/8.9.3) id OAA02344 for ietf-xml-mime-bks; Fri, 20 Oct 2000 14:23:18 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02340 for ; Fri, 20 Oct 2000 14:23:17 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP27NM>; Fri, 20 Oct 2000 14:28:56 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE00105A071@tdmail2.teledesic.com> From: Dan Kohn To: James Aylett , bxxpwg@lists.invisibleworlds.com Cc: ietf-xml-mime@imc.org Subject: RE: [BXXPwg] Re: application/beep+xml Date: Fri, 20 Oct 2000 14:28:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually, I would argue that the suggestion for application/beep+xml is remarkably similar to the existing MIME type message/http, defined in Section 19.1 of RFC 2616. I thought of suggesting message/beep+xml, but section 5.2.4 of RFC 2046 says that: Future subtypes of "message" intended for use with email should be restricted to "7bit" encoding. A type other than "message" should be used if restriction to "7bit" is not possible. It isn't actually clear that the second sentence's prohibition of message types for binary content is intended to apply outside of email, but application/beep+xml seems the more conservative approach. - dan -- Dan Kohn -----Original Message----- From: James Aylett [mailto:james-ietf@tartarus.org] Sent: Friday, 2000-10-20 10:16 To: bxxpwg@lists.invisibleworlds.com Subject: Re: [BXXPwg] Re: application/beep+xml On Fri, Oct 20, 2000 at 07:52:37AM -0700, Marshall Rose wrote: > 1. text/xml isn't the right tag to use for xml-based profiles > what should we use instead? > > the things being moved around in the xml-based profiles described in beep > are protocol exchanges, not documents. when a channel is started, a > negotiation process is used to determine which profile is bound to the > channel. the registration for this profile defines what the exchanges look > like. > > so, having each profile register its own mime type is at best redundant. > worse, since the whole point of using URIs to identify profiles was to get > away from a centralized registry, a mime type per profile negates this > property. > > this leaves application/xml, which is as good a choice as any, i guess... I'm probably being stupid, but the way I see it, the protocol exchanges that BEEP uses are actually reaching the limit of what MIME types can sensibly be used to classify. I think that Marshall's "these aren't documents" can be rephrased as "these aren't MIME entities". They certainly don't have the same function as MIME entities in anything else I can think of (although they can often act as transport for a contained entity). So, as far as we need some sort of MIME type indication, the opaque application/xml is probably the best solution. (I hesitate, but think it perhaps worth pointing to: draft-eastlake-cturi-00.txt gives a mapping between content types and URIs. I don't think it's even vaguely sensible to use the content type obtained by mapping the URI of the profile register here, but I thought I'd point it out in case anyone disagreed.) Cheers, James -- /--------------------------------------------------------------------------\ James Aylett www.zap.uk.eu.org james@tartarus.org www.footlights.org _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg Received: by ns.secondary.com (8.9.3/8.9.3) id NAA00415 for ietf-xml-mime-bks; Fri, 20 Oct 2000 13:09:19 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00403 for ; Fri, 20 Oct 2000 13:09:18 -0700 (PDT) Received: from rune.antarcti.ca (dyn205.dev.antarcti.ca [10.1.1.205]) by mail.dev.antarcti.ca (Postfix) with ESMTP id 5860F103DD; Fri, 20 Oct 2000 13:14:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20001020131111.01c625f0@pop.intergate.ca> X-Sender: tbray@pop.intergate.ca X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Oct 2000 13:13:39 -0700 To: "Marshall Rose" , "Dan Kohn" , From: Tim Bray Subject: Re: application/beep+xml Cc: , "Marshall Rose" In-Reply-To: <014401c03aa5$87ac3a40$8353cf3f@dbc.mtview.ca.us> References: <25D0C66E6D25D311B2AC0008C7913EE00105A04D@tdmail2.teledesic.com> 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 07:52 AM 20/10/00 -0700, Marshall Rose wrote: >this leaves application/xml, which is as good a choice as any, i guess... Also has the effect of discouraging transcoding, which sees desirable for protocol negotiations in a multilingual world (enough things can go wrong already...) -Tim Received: by ns.secondary.com (8.9.3/8.9.3) id MAA23302 for ietf-xml-mime-bks; Fri, 20 Oct 2000 12:18:00 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23298 for ; Fri, 20 Oct 2000 12:17:59 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP260G>; Fri, 20 Oct 2000 12:23:38 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE00105A06C@tdmail2.teledesic.com> From: Dan Kohn To: bxxpwg@lists.invisibleworlds.com Cc: ietf-xml-mime@imc.org Subject: RE: application/beep+xml Date: Fri, 20 Oct 2000 12:23:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Given that all beep protocol exchanges are either channel setup or beep profile exchanges, it seems like application/beep+xml could still be a good choice. Just say in the registration that the DTD used is either the one in the beep framework document or a specific beep profile as specified by the profile entity URL. I definitely agree, though, that each beep profile should not need it's own MIME type. In general, the MIME concept of taxonomy has seemed to work quite well (I realize I'm preaching to the choir here), and the subset of documents that are beep or beep profiles seems much, much smaller than the set of all XML documents. - dan -- Dan Kohn -----Original Message----- From: Marshall Rose [mailto:mrose+mtr.netnews@dbc.mtview.ca.us] Sent: Friday, 2000-10-20 07:53 To: Dan Kohn; bxxpwg@lists.invisibleworlds.com Cc: ietf-xml-mime@imc.org; Marshall Rose Subject: Re: application/beep+xml hi. i think you raise three issues: 1. text/xml isn't the right tag to use for xml-based profiles 2. rfc1982 on sequence number arithmetic should be referenced, e.g., Consult Sections 2 through 5 of [8] for a discussion of the arithmetic properties of sequence numbers. 3. the "URL:" in things like "" should be removed 2 & 3 are editorial, and probably not all that controversial. if anyone objects to making these changes, speak up. the first issue requires more discussion. i'll agree that text/xml isn't optimal for the reasons you suggest (e.g., not intended for display to humans). so, if text/xml is out, what should we use instead? the things being moved around in the xml-based profiles described in beep are protocol exchanges, not documents. when a channel is started, a negotiation process is used to determine which profile is bound to the channel. the registration for this profile defines what the exchanges look like. so, having each profile register its own mime type is at best redundant. worse, since the whole point of using URIs to identify profiles was to get away from a centralized registry, a mime type per profile negates this property. this leaves application/xml, which is as good a choice as any, i guess... /mtr Received: by ns.secondary.com (8.9.3/8.9.3) id HAA14188 for ietf-xml-mime-bks; Fri, 20 Oct 2000 07:48:24 -0700 (PDT) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14184 for ; Fri, 20 Oct 2000 07:48:22 -0700 (PDT) Received: from shaylashayla (ppp-63-207-83-131.ded.pacbell.net [63.207.83.131]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id e9KEp0M24605; Fri, 20 Oct 2000 07:51:00 -0700 (PDT) Message-ID: <014401c03aa5$87ac3a40$8353cf3f@dbc.mtview.ca.us> From: "Marshall Rose" To: "Dan Kohn" , Cc: , "Marshall Rose" References: <25D0C66E6D25D311B2AC0008C7913EE00105A04D@tdmail2.teledesic.com> Subject: Re: application/beep+xml Date: Fri, 20 Oct 2000 07:52:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: hi. i think you raise three issues: 1. text/xml isn't the right tag to use for xml-based profiles 2. rfc1982 on sequence number arithmetic should be referenced, e.g., Consult Sections 2 through 5 of [8] for a discussion of the arithmetic properties of sequence numbers. 3. the "URL:" in things like "" should be removed 2 & 3 are editorial, and probably not all that controversial. if anyone objects to making these changes, speak up. the first issue requires more discussion. i'll agree that text/xml isn't optimal for the reasons you suggest (e.g., not intended for display to humans). so, if text/xml is out, what should we use instead? the things being moved around in the xml-based profiles described in beep are protocol exchanges, not documents. when a channel is started, a negotiation process is used to determine which profile is bound to the channel. the registration for this profile defines what the exchanges look like. so, having each profile register its own mime type is at best redundant. worse, since the whole point of using URIs to identify profiles was to get away from a centralized registry, a mime type per profile negates this property. this leaves application/xml, which is as good a choice as any, i guess... /mtr Received: by ns.secondary.com (8.9.3/8.9.3) id AAA01484 for ietf-xml-mime-bks; Fri, 20 Oct 2000 00:49:26 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA01478 for ; Fri, 20 Oct 2000 00:49:21 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP25YF>; Fri, 20 Oct 2000 00:54:55 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE00105A04D@tdmail2.teledesic.com> From: Dan Kohn To: bxxpwg@lists.invisibleworlds.com Cc: ietf-xml-mime@imc.org Subject: application/beep+xml Date: Fri, 20 Oct 2000 00:54:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I finally took the time to review and , and I would like to suggest that text/xml is probably not the best MIME type to use for your BEEP channel management and profile configuration. Among other things: + In Section 2.2.2.2, you constrain what is acceptable beyond well-formed and valid XML (e.g., internal entity declarations are not allowed). + It is hard to imagine any scenario where the BEEP channel management should be presented to users, since it is explicitly designed for process to process communications. + You don't have line-ending conversion issues to deal with, since CRLF is mandated. + The fact that you recommend against a DOCTYPE declaration in Section 2.2.2.2 (even though DTDs are defined in section 7) means that if BEEP XML gets out in the wild, it will be more difficult to identify. The custom MIME type would provide that identification. I would suggest that you review (which has finished last call and will hopefully soon be approved by the IESG). I don't know if something like application/beep+xml would meet your needs, but I am at least fairly certain that application/xml would be a better choice than text/xml. Given sections 3.1.2 and 4.1.2 of the BEEP framework, it seems that you might also want to consider registering application/tls+xml and application/sasl+xml. Or alternatively, you could have the SASL and TLS DTDs referenced as external entities to the core BEEP DTD, and get by with just application/beep+xml. (Note that there is no explicit one-to-one mapping between DTDs and MIME types, although such a mapping would be especially useful when DOCTYPE declarations are discouraged.) Separately, I would suggest that in Section 2.2.1.2, you should normatively reference serial number arithmetic as defined in RFC 1982. Finally, Appendix E of RFC 2396 deprecates the use of "URL:" as in . - dan -- Dan Kohn Received: by ns.secondary.com (8.9.3/8.9.3) id JAA03789 for ietf-xml-mime-bks; Thu, 19 Oct 2000 09:26:38 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03785 for ; Thu, 19 Oct 2000 09:26:37 -0700 (PDT) Received: from fastrack.Canada.Sun.COM ([129.155.3.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03217; Thu, 19 Oct 2000 09:31:49 -0700 (PDT) Received: from canada.sun.com (seteo [129.155.190.61]) by fastrack.Canada.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA12696; Thu, 19 Oct 2000 11:24:40 -0400 (EDT) Message-ID: <39EF128F.7E2E11BB@canada.sun.com> Date: Thu, 19 Oct 2000 11:26:07 -0400 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Kohn CC: Larry Masinter , ietf-xml-mime@imc.org Subject: Re: XHTML vs HTML media types References: <25D0C66E6D25D311B2AC0008C7913EE001059FC1@tdmail2.teledesic.com> 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: Dan Kohn wrote: > > Well, I hardly see this as life-or-death, but the intro paragraph of > says: > > "XHTML is a family of current and future document types and modules that > reproduce, subset, and extend HTML 4 [HTML]. XHTML family document types are > XML based, and ultimately are designed to work in conjunction with XML-based > user agents." > > XHTML, especially 1.1+, is more than just HTML reformulated in XML. The > modularization is a fundamentally new thing (as you of course know, Larry). > Based on this, XHTML seems to describe what XHTML is better than HTML does. > The +xml in the name is first and foremost a syntactic convention to > indicate support of the XML syntax (the fact that it's also a semantic > convention as well is an extra benefit). So, I'm still for > application/xhtml+xml. Right. I think my previous email expressed the same concern. > Separately, I agree a reference to RFC 2854 is critical. And further, I > think the registration should have a detailed discussion on file extensions. > On my laptop, .html files open in IE and .xhtml in XMLSpy. It's not > immediately obvious to me that if I upload a .xhtml file to a web server, > what is the best default MIME type mapping for that file? There's not exactly a "detailed" discussion on file extensions, but it ties in closely with the discussion on recognizing XHTML documents, and the dangers of assuming that the processor will further dispatch on a namespace (my 2c contribution to draft-murata-xml). Anyhow, there's no point getting into that much further now until the WG is ready to publish it. When the draft is announced, I'll be sure to forward it here (or however that process works - I have to recheck the order of operations). MB Received: by ns.secondary.com (8.9.3/8.9.3) id HAA25590 for ietf-xml-mime-bks; Thu, 19 Oct 2000 07:30:30 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25586 for ; Thu, 19 Oct 2000 07:30:29 -0700 (PDT) Received: from fastrack.Canada.Sun.COM ([129.155.3.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29700; Thu, 19 Oct 2000 07:34:49 -0700 (PDT) Received: from canada.sun.com (seteo [129.155.190.61]) by fastrack.Canada.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA06336; Thu, 19 Oct 2000 10:32:15 -0400 (EDT) Message-ID: <39EF0645.D181EDEB@canada.sun.com> Date: Thu, 19 Oct 2000 10:33:41 -0400 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ned.freed@INNOSOFT.COM CC: Keith Moore , Dan Kohn , ietf-xml-mime@imc.org Subject: Re: text/xhtml+xml vs. application/xhtml+xml References: <39EDF1B8.FF4EEED4@canada.sun.com> <01JVHM2XD46K00056I@mauve.mrochek.com> 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: Thanks Ned and Keith, for your comments. I wasn't aware of this perception. I'll take this back to the WG ASAP. MB ned.freed@innosoft.com wrote: > > > > While this doesn't go into as much depth as draft-murata-xml does, the > > > HTML WG believes, despite the DOCTYPE/xmlns/HTML-header preamble, that > > > the bulk (i.e. body) of most XHTML documents will useful, to "some > > > extent" (per above), to casual users. > > > I think the general consensus of the MIME community is that making HTML > > a subtype of "text/" was a mistake. While it is possible to write HTML > > which is readable "to some extent" as plain text, the HTML that is > > generated by a typical MUA or HTML editor is so full of useless cruft > > that it doesn't qualify. Perhaps a determined human being can read the > > text "to some extent" but the typical human gives up. > > > So IMHO we should learn from this experience and make XHTML and other > > XML-ish things subtypes of application/. > > I completely agree with Keith. Text/html was a mistake. > > Ned Received: by ns.secondary.com (8.9.3/8.9.3) id HAA25565 for ietf-xml-mime-bks; Thu, 19 Oct 2000 07:30:04 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25561 for ; Thu, 19 Oct 2000 07:30:03 -0700 (PDT) Received: from fastrack.Canada.Sun.COM ([129.155.1.11]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01166; Thu, 19 Oct 2000 07:35:15 -0700 (PDT) Received: from canada.sun.com (seteo [129.155.190.61]) by fastrack.Canada.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA06499; Thu, 19 Oct 2000 10:35:13 -0400 (EDT) Message-ID: <39EF06F8.6F16EDBF@canada.sun.com> Date: Thu, 19 Oct 2000 10:36:40 -0400 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Larry Masinter CC: ietf-xml-mime@imc.org Subject: Re: XHTML vs HTML media types References: 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 Larry, Larry Masinter wrote: > > RFC 2854 describes the applicability of 'text/html'; I would like to > ask that any document that talks about the any other MIME type that > might be used at least refer to it. Just to be clear, this new type would not be used for any existing content (unless by some freak accident, somebody authored a conformant XHTML document). So in what context are you recommending that I reference 2854? > I actually think that the double 'x' in 'xhtml+xml' is redundant, > and that 'application/html+xml' might be more appropriate. "XHTML" is a brand we're trying to build, so we felt it important that it be included in the subtype string. Also, "html+xml" might lead one to believe that the described content is semantically equivalent to HTML. That isn't the case (e.g. the name attribute doesn't have id semantics in XHTML, as mentioned in my previous email). We did have this discussion, and reached concensus on "xhtml+xml". Thanks for your comments. MB Received: by ns.secondary.com (8.9.3/8.9.3) id CAA16600 for ietf-xml-mime-bks; Thu, 19 Oct 2000 02:39:54 -0700 (PDT) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA16586 for ; Thu, 19 Oct 2000 02:39:47 -0700 (PDT) Received: from enoshima (dhcp-100-207.mag.keio.ac.jp [133.27.195.207]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id SAA06753; Thu, 19 Oct 2000 18:44:21 +0900 (JST) Message-Id: <4.2.0.58.J.20001019094835.03b257b0@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 19 Oct 2000 09:49:04 +0900 To: Keith Moore , Mark Baker From: "Martin J. Duerst" Subject: Re: text/xhtml+xml vs. application/xhtml+xml Cc: Dan Kohn , ietf-xml-mime@imc.org In-Reply-To: <200010182126.RAA19225@astro.cs.utk.edu> References: 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 00/10/18 17:26 -0400, Keith Moore wrote: >So IMHO we should learn from this experience and make XHTML and other >XML-ish things subtypes of application/. Or of course image/ for things such as SVG. Regards, Martin. Received: by ns.secondary.com (8.9.3/8.9.3) id QAA00637 for ietf-xml-mime-bks; Wed, 18 Oct 2000 16:22:04 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA00633 for ; Wed, 18 Oct 2000 16:22:03 -0700 (PDT) From: ned.freed@INNOSOFT.COM Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JVHCBYPH8000056I@mauve.mrochek.com> for ietf-xml-mime@imc.org; Wed, 18 Oct 2000 16:27:11 -0700 (PDT) Date: Wed, 18 Oct 2000 16:25:24 -0700 (PDT) Subject: RE: XHTML vs HTML media types In-reply-to: "Your message dated Wed, 18 Oct 2000 14:05:33 -0700" To: Larry Masinter Cc: Mark Baker , Dan Kohn , ietf-xml-mime@imc.org Message-id: <01JVHM6H9ENQ00056I@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 7BIT References: <39EDF440.D6B1F3B@canada.sun.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > RFC 2854 describes the applicability of 'text/html'; I would like to > ask that any document that talks about the any other MIME type that > might be used at least refer to it. > I actually think that the double 'x' in 'xhtml+xml' is redundant, > and that 'application/html+xml' might be more appropriate. Interesting notion. On the one hand, you're right that it is redundant, on the other, html+xml doesn't embed the XHTML "name" in the media type. On the whole I think I agree with you, although I do see the case for having xhtml+xml. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id QAA00579 for ietf-xml-mime-bks; Wed, 18 Oct 2000 16:19:16 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA00574 for ; Wed, 18 Oct 2000 16:19:15 -0700 (PDT) From: ned.freed@INNOSOFT.COM Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JVHCBYPH8000056I@mauve.mrochek.com> for ietf-xml-mime@imc.org; Wed, 18 Oct 2000 16:24:20 -0700 (PDT) Date: Wed, 18 Oct 2000 16:23:25 -0700 (PDT) Subject: Re: text/xhtml+xml vs. application/xhtml+xml In-reply-to: "Your message dated Wed, 18 Oct 2000 17:26:51 -0400" <200010182126.RAA19225@astro.cs.utk.edu> To: Keith Moore Cc: Mark Baker , Dan Kohn , ietf-xml-mime@imc.org Message-id: <01JVHM2XD46K00056I@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT References: <39EDF1B8.FF4EEED4@canada.sun.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > While this doesn't go into as much depth as draft-murata-xml does, the > > HTML WG believes, despite the DOCTYPE/xmlns/HTML-header preamble, that > > the bulk (i.e. body) of most XHTML documents will useful, to "some > > extent" (per above), to casual users. > I think the general consensus of the MIME community is that making HTML > a subtype of "text/" was a mistake. While it is possible to write HTML > which is readable "to some extent" as plain text, the HTML that is > generated by a typical MUA or HTML editor is so full of useless cruft > that it doesn't qualify. Perhaps a determined human being can read the > text "to some extent" but the typical human gives up. > So IMHO we should learn from this experience and make XHTML and other > XML-ish things subtypes of application/. I completely agree with Keith. Text/html was a mistake. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id PAA29570 for ietf-xml-mime-bks; Wed, 18 Oct 2000 15:21:30 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29566 for ; Wed, 18 Oct 2000 15:21:29 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP2X2A>; Wed, 18 Oct 2000 15:26:47 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE001059FC1@tdmail2.teledesic.com> From: Dan Kohn To: Larry Masinter Cc: ietf-xml-mime@imc.org, Mark Baker Subject: RE: XHTML vs HTML media types Date: Wed, 18 Oct 2000 15:26:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, I hardly see this as life-or-death, but the intro paragraph of says: "XHTML is a family of current and future document types and modules that reproduce, subset, and extend HTML 4 [HTML]. XHTML family document types are XML based, and ultimately are designed to work in conjunction with XML-based user agents." XHTML, especially 1.1+, is more than just HTML reformulated in XML. The modularization is a fundamentally new thing (as you of course know, Larry). Based on this, XHTML seems to describe what XHTML is better than HTML does. The +xml in the name is first and foremost a syntactic convention to indicate support of the XML syntax (the fact that it's also a semantic convention as well is an extra benefit). So, I'm still for application/xhtml+xml. Separately, I agree a reference to RFC 2854 is critical. And further, I think the registration should have a detailed discussion on file extensions. On my laptop, .html files open in IE and .xhtml in XMLSpy. It's not immediately obvious to me that if I upload a .xhtml file to a web server, what is the best default MIME type mapping for that file? - dan -- Dan Kohn -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Wednesday, 2000-10-18 14:06 To: Mark Baker; Dan Kohn Cc: ietf-xml-mime@imc.org Subject: RE: XHTML vs HTML media types RFC 2854 describes the applicability of 'text/html'; I would like to ask that any document that talks about the any other MIME type that might be used at least refer to it. I actually think that the double 'x' in 'xhtml+xml' is redundant, and that 'application/html+xml' might be more appropriate. Received: by ns.secondary.com (8.9.3/8.9.3) id OAA28393 for ietf-xml-mime-bks; Wed, 18 Oct 2000 14:22:46 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28383 for ; Wed, 18 Oct 2000 14:22:40 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA19225; Wed, 18 Oct 2000 17:26:51 -0400 (EDT) Message-Id: <200010182126.RAA19225@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Baker cc: Dan Kohn , ietf-xml-mime@imc.org Subject: Re: text/xhtml+xml vs. application/xhtml+xml In-reply-to: Your message of "Wed, 18 Oct 2000 14:53:44 EDT." <39EDF1B8.FF4EEED4@canada.sun.com> Date: Wed, 18 Oct 2000 17:26:51 -0400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > While this doesn't go into as much depth as draft-murata-xml does, the > HTML WG believes, despite the DOCTYPE/xmlns/HTML-header preamble, that > the bulk (i.e. body) of most XHTML documents will useful, to "some > extent" (per above), to casual users. I think the general consensus of the MIME community is that making HTML a subtype of "text/" was a mistake. While it is possible to write HTML which is readable "to some extent" as plain text, the HTML that is generated by a typical MUA or HTML editor is so full of useless cruft that it doesn't qualify. Perhaps a determined human being can read the text "to some extent" but the typical human gives up. So IMHO we should learn from this experience and make XHTML and other XML-ish things subtypes of application/. Keith Received: by ns.secondary.com (8.9.3/8.9.3) id OAA28020 for ietf-xml-mime-bks; Wed, 18 Oct 2000 14:07:06 -0700 (PDT) Received: from mpgw.attlabs.att.com (mpfg.attlabs.net [12.106.35.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28016 for ; Wed, 18 Oct 2000 14:07:05 -0700 (PDT) Received: from exchsj06.attlabs.att.com (exchsj06.attlabs.att.com [135.197.6.51]) by mpgw.attlabs.att.com (8.8.5/8.8.8) with ESMTP id OAA12245; Wed, 18 Oct 2000 14:11:38 -0700 (PDT) Received: from larry (larry.attlabs.att.com [135.197.2.65]) by exchsj06.attlabs.att.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 40RX3CW9; Wed, 18 Oct 2000 14:05:21 -0700 From: "Larry Masinter" To: "Mark Baker" , "Dan Kohn" Cc: Subject: RE: XHTML vs HTML media types Date: Wed, 18 Oct 2000 14:05:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <39EDF440.D6B1F3B@canada.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: RFC 2854 describes the applicability of 'text/html'; I would like to ask that any document that talks about the any other MIME type that might be used at least refer to it. I actually think that the double 'x' in 'xhtml+xml' is redundant, and that 'application/html+xml' might be more appropriate. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA24741 for ietf-xml-mime-bks; Wed, 18 Oct 2000 12:12:08 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24737 for ; Wed, 18 Oct 2000 12:12:02 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP2WXV>; Wed, 18 Oct 2000 12:17:07 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE001059FB9@tdmail2.teledesic.com> From: Dan Kohn To: Mark Baker , "Ned Freed (E-mail)" Cc: ietf-xml-mime@imc.org Subject: RE: text/xhtml+xml vs. application/xhtml+xml Date: Wed, 18 Oct 2000 12:16:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rather than trying to channel what the authors of RFC 2046 were thinking, it seems like we should just ask them. Specifically, Ned Freed and has been instrumental in framing the issues we discuss in , is (I believe) the IESG member presenting the draft, and also co-authored RFC 2046. Ned, my understanding is that text/html is seen in retrospect as problematic and has led to some of the user unhappiness with MIME, by presenting information to users that they are unlikely to be able to deal with. The referenced paragraph in the draft was meant to capture some of the discussion on the ietf-xml-mime@imc.org list, though I am on too slow a modem to find the references. I suspect that the distinction of application versus text comes down to whether you expect most users to be like us (who can heuristically recognize HTML, save to a file with the right file extension, and then open in a browser) versus my mother, who just gets annoyed with all of the cruft and gives up. At the end of the day, I would evaluate based on failure scenarios. I think people would rather see an attachment than the source text, and are more likely to be able to recover from the former. In principal, your suggestion of registering both text/xhtml+xml and application/xhtml+xml could enable the document author to decide based on the fallback behavior desired. However, this is unlikely to work as expected due to the widespread practice of mapping MIME types to file extensions, which provides insufficient granularity. Also, if we are having trouble evaluating the tradeoffs, it seems unlikely that most document authors would understand the subtlety. Finally, I also subscribe to section 3.2 of RFC 1958 on Architectural Principles of the Internet, which says, "If there are several ways of doing the same thing, choose one." - dan P.S. Mark, I presume you will keep the HTML WG in the loop on this discussion. -- Dan Kohn -----Original Message----- From: Mark Baker [mailto:mark.baker@canada.sun.com] Sent: Wednesday, 2000-10-18 11:41 To: Dan Kohn Cc: xml-mime-types@imc.org Subject: Re: text/xhtml+xml vs. application/xhtml+xml (HTML WG BCCd - the new w3.org spam filter makes it impractical to CC them) Hi Dan, Dan Kohn wrote: > > Mark, I would appreciate if the HTML WG could provide a little more context > on their thinking, perhaps by adding to discussion to the eventual XHTML > MIME registration. > > First, I'm not convinced that text/ is the correct top-level type. Section > 3 of says: > > If an XML document -- that is, the unprocessed, source XML document > -- is readable by casual users, text/xml is preferable to > application/xml. MIME user agents (and web user agents) that do not > have explicit support for text/xml will treat it as text/plain, for > example, by displaying the XML entity as plain text. Application/xml > is preferable when the XML MIME entity is unreadable by casual > users. Similarly, text/xml-external-parsed-entity is preferable when > an external parsed entity is readable by casual users, but > application/xml-external-parsed-entity is preferable when a plain > text display is inappropriate. > > NOTE: Users are in general not used to text containing tags such > as , and often find such tags quite disorienting or > annoying. If one is not sure, the conservative principle would > suggest using application/* instead of text/* so as not to put > information in front of users that they will quite likely not > understand. That's interesting. I guess I hadn't read that section. Are you attempting to update RFC 2046 on this subject? >From RFC 2046, Sec 4.1; "Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most nontextual data. Such formatted textual data should be represented using subtypes of "text"." While this doesn't go into as much depth as draft-murata-xml does, the HTML WG believes, despite the DOCTYPE/xmlns/HTML-header preamble, that the bulk (i.e. body) of most XHTML documents will useful, to "some extent" (per above), to casual users. > It seems like application/* is thus the safer bet. Moreover, section 2.11 > of already standardizes end-of-line handling, > so the canonicalization of line endings that text/* supports does not seem > necessary. True. That's a small point against text/* handling. But we feel that the text/plain fallback is more valuable. Something we did consider, that we didn't really come to concensus on (AFAIK) at this morning's call was the possibility of registering both application/xhtml+xml and text/xhtml+xml, and letting server admins decide which one wins (or if both are useful). Any thoughts about that? > Also, I would like to see some detailed discussion of when to use > application/xhtml+xml and when to use text/html. This seems like an upward > compatibility challenge of exceeding subtlety, and may deserve more > attention than it received in your IRC conversation. I'll follow that up in a separate message, hopefully soon. > Thanks in advance for any insight you can provide into your and the WG's > thinking. No problem. MB Received: by ns.secondary.com (8.9.3/8.9.3) id MAA24621 for ietf-xml-mime-bks; Wed, 18 Oct 2000 12:06:36 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24616 for ; Wed, 18 Oct 2000 12:06:34 -0700 (PDT) Received: from zingo (ith1-3e6.twcny.rr.com [24.24.11.230]) by hesketh.net (8.9.3/8.9.3) with SMTP id PAA00309 for ; Wed, 18 Oct 2000 15:11:46 -0400 Message-Id: <200010181911.PAA00309@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 18 Oct 2000 15:15:13 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: Re: text/xhtml+xml vs. application/xhtml+xml In-Reply-To: <39EDF1B8.FF4EEED4@canada.sun.com> References: <25D0C66E6D25D311B2AC0008C7913EE001059F7B@tdmail2.teledesic.com> 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 02:53 PM 10/18/00 -0400, Mark Baker wrote: >Something we did consider, that we didn't really come to concensus on >(AFAIK) at this morning's call was the possibility of registering both >application/xhtml+xml and text/xhtml+xml, and letting server admins >decide which one wins (or if both are useful). Any thoughts about that? I'd prefer to see JUST 'application/xhtml+xml', but could settle for having both. Transitions are never easy, it seems. Simon St.Laurent XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books Received: by ns.secondary.com (8.9.3/8.9.3) id LAA24407 for ietf-xml-mime-bks; Wed, 18 Oct 2000 11:58:09 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24403 for ; Wed, 18 Oct 2000 11:58:08 -0700 (PDT) Received: from fastrack.Canada.Sun.COM ([129.155.3.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02689; Wed, 18 Oct 2000 12:03:17 -0700 (PDT) Received: from canada.sun.com (seteo [129.155.190.61]) by fastrack.Canada.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA08689; Wed, 18 Oct 2000 15:03:12 -0400 (EDT) Message-ID: <39EDF440.D6B1F3B@canada.sun.com> Date: Wed, 18 Oct 2000 15:04:32 -0400 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Kohn CC: ietf-xml-mime@imc.org Subject: XHTML vs HTML media types References: <25D0C66E6D25D311B2AC0008C7913EE001059F7B@tdmail2.teledesic.com> 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 Dan, > Also, I would like to see some detailed discussion of when to use > application/xhtml+xml and when to use text/html. This seems like an upward > compatibility challenge of exceeding subtlety, and may deserve more > attention than it received in your IRC conversation. Yes, that IRC conversation was not the first or only conversation we've had on the matter. In a nutshell, you'd use the HTML type when you wanted your XHTML to be processed by a legacy processor. If you wanted your XHTML processed as XML (well-formedness expected, etc..), you'd send it with the XHTML type. There's some cross-over concerns here, such as the use of "name" vs. "id" attributes ("name" isn't special in XHTML, but has id semantics in HTML). But those are being addressed. Did you have any specific concerns you'd like to raise now? Thanks. MB Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA23921 for ietf-xml-mime-bks; Wed, 18 Oct 2000 11:47:22 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23917 for ; Wed, 18 Oct 2000 11:47:21 -0700 (PDT) Received: from fastrack.Canada.Sun.COM ([129.155.6.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27654; Wed, 18 Oct 2000 11:52:30 -0700 (PDT) Received: from canada.sun.com (seteo [129.155.190.61]) by fastrack.Canada.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA07227; Wed, 18 Oct 2000 14:52:27 -0400 (EDT) Message-ID: <39EDF1B8.FF4EEED4@canada.sun.com> Date: Wed, 18 Oct 2000 14:53:44 -0400 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Kohn CC: ietf-xml-mime@imc.org Subject: Re: text/xhtml+xml vs. application/xhtml+xml References: <25D0C66E6D25D311B2AC0008C7913EE001059F7B@tdmail2.teledesic.com> 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: (HTML WG BCCd - the new w3.org spam filter makes it impractical to CC them. Also, redirected to ietf-xml-mime@imc.org, as you had sent it to xml-mime-types@imc.org) Hi Dan, Dan Kohn wrote: > > Mark, I would appreciate if the HTML WG could provide a little more context > on their thinking, perhaps by adding to discussion to the eventual XHTML > MIME registration. > > First, I'm not convinced that text/ is the correct top-level type. Section > 3 of says: > > If an XML document -- that is, the unprocessed, source XML document > -- is readable by casual users, text/xml is preferable to > application/xml. MIME user agents (and web user agents) that do not > have explicit support for text/xml will treat it as text/plain, for > example, by displaying the XML entity as plain text. Application/xml > is preferable when the XML MIME entity is unreadable by casual > users. Similarly, text/xml-external-parsed-entity is preferable when > an external parsed entity is readable by casual users, but > application/xml-external-parsed-entity is preferable when a plain > text display is inappropriate. > > NOTE: Users are in general not used to text containing tags such > as , and often find such tags quite disorienting or > annoying. If one is not sure, the conservative principle would > suggest using application/* instead of text/* so as not to put > information in front of users that they will quite likely not > understand. That's interesting. I guess I hadn't read that section. Are you attempting to update RFC 2046 on this subject? >From RFC 2046, Sec 4.1; "Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most nontextual data. Such formatted textual data should be represented using subtypes of "text"." While this doesn't go into as much depth as draft-murata-xml does, the HTML WG believes, despite the DOCTYPE/xmlns/HTML-header preamble, that the bulk (i.e. body) of most XHTML documents will useful, to "some extent" (per above), to casual users. > It seems like application/* is thus the safer bet. Moreover, section 2.11 > of already standardizes end-of-line handling, > so the canonicalization of line endings that text/* supports does not seem > necessary. True. That's a small point against text/* handling. But we feel that the text/plain fallback is more valuable. Something we did consider, that we didn't really come to concensus on (AFAIK) at this morning's call was the possibility of registering both application/xhtml+xml and text/xhtml+xml, and letting server admins decide which one wins (or if both are useful). Any thoughts about that? > Also, I would like to see some detailed discussion of when to use > application/xhtml+xml and when to use text/html. This seems like an upward > compatibility challenge of exceeding subtlety, and may deserve more > attention than it received in your IRC conversation. I'll follow that up in a separate message, hopefully soon. > Thanks in advance for any insight you can provide into your and the WG's > thinking. No problem. MB Received: by ns.secondary.com (8.9.3/8.9.3) id GAA09561 for ietf-xml-mime-bks; Wed, 18 Oct 2000 06:32:32 -0700 (PDT) Received: from prserv.net (out4.prserv.net [32.97.166.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09557 for ; Wed, 18 Oct 2000 06:32:31 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.151]) by prserv.net (out4) with SMTP id <20001018133737239018a03se>; Wed, 18 Oct 2000 13:37:38 +0000 To: dan@dankohn.com Cc: ph@w3.org, ietf-xml-mime@imc.org Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt In-Reply-To: <25D0C66E6D25D311B2AC0008C7913EE001059F6B@tdmail2.teledesic.com> References: <25D0C66E6D25D311B2AC0008C7913EE001059F6B@tdmail2.teledesic.com> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001018223739T.muraw3c@attglobal.net> Date: Wed, 18 Oct 2000 22:37:39 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 43 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan and Philipp, > Philipp, could I suggest that you review > , which is expected to shortly replace > RFC 2376. Specifically, I would strongly recommend changing your > application to application/smil+xml, and quoting the appropriate sections of > RFC 2376bis by reference rather than by repeating the text. > > Thanks for considering this. > > - dan I raised this issue in January. -- http://www.imc.org/ietf-xml-mime/mail-archive/msg00315.html Philipp replied. --http://www.imc.org/ietf-xml-mime/mail-archive/msg00319.html >However, the use of "application/smil" predates the proposal of >appending "-xml" to XML-based MIME types by more than a year - I think >the first Internet draft dates from April '98. The proposal has >already been succesfully reviewed in the past on ietf-types, >but somebody dropped the ball bringing it to the IESG. Given >this history, and that there is an installed base, it seems reasonable >to stick with the current practice of using "application/smil". I requested addition of this historical reason in the I-D. -- http://www.imc.org/ietf-xml-mime/mail-archive/msg00320.html >However, in order not to make an antecedent, I would like the I-D to mention >this name convention and reasons not to follow it. Phillip oked. -- http://www.imc.org/ietf-xml-mime/mail-archive/msg00321.html Phillip, could you revise the I-D as you promised? Cheers, IBM Tokyo Research Lab & International University of Japan, Research Institute MURATA Makoto Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA16585 for ietf-xml-mime-bks; Tue, 17 Oct 2000 18:35:00 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16581 for ; Tue, 17 Oct 2000 18:34:58 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP2VH9>; Tue, 17 Oct 2000 18:40:07 -0700 Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP2VH2>; Tue, 17 Oct 2000 18:20:06 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE001059F91@tdmail2.teledesic.com> From: Dan Kohn To: Graham Klyne Cc: xml-mime-types@imc.org Subject: RE: XML MIME types draft Date: Tue, 17 Oct 2000 18:19:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Fair point, but we published the draft (and it should have now finished last call) well before the publication of RFC 2913 (regarding which, congrats). So, presuming that the IESG decides we have passed Last Call, we will need to fix in the nest iteration of the standard. Given that we have 35 references, and there are multi-month latencies built into the last call and the RFC Editor process, I'm pretty certain we could never publish without having one of our references grow out of date during the process. I expect we will be reissuing the draft before too long anyway, though, specifically when XBase and XPointer go to W3 Recommendation. We'll be sure to fix the conneg references at that time. Thanks. - dan -- Dan Kohn -----Original Message----- From: Graham Klyne [mailto:GK@Dial.pipex.com] Sent: Tuesday, 2000-10-17 15:15 To: Dan Kohn Cc: xml-mime-types@imc.org Subject: XML MIME types draft At 09:17 AM 10/17/00 -0700, you wrote: >.... Specifically, I would strongly recommend changing your >application to application/smil+xml, and quoting the appropriate sections of >RFC 2376bis by reference rather than by repeating the text. I noticed this and realized I hadn't checked this draft for some time... not since '|xml' was the preferred suffix.... In browsing through, I noticed this: >A.10 How about using a conneg tag instead (e.g., accept-features: > (syntax=xml))? > > When the conneg protocol is fully defined, this may potentially be a > reasonable thing to do. But given the limited current state of > conneg[RFC2703] development, it is not a credible replacement for a > MIME-based solution. > > Also, note that adding a content-type parameter doesn't work with > conneg either, since conneg only deals with media types, not their > parameters. This is another illustration of the limits of parameters > for MIME dispatchers. While I agree that feature expressions are probably inappropriate for the kind of thing you want to do, I disagree with the reasons. The conneg spec is complete: RFC2506, RFC 2533, RFC 2912 define the key elements here. All that is missing is a feature tag for expressing XML content, and it might be argued that (type='application/xml') could achieve that -- see RFC 2913. I would suggest text something like: >A.10 How about using a conneg tag instead (e.g., accept-features: > (syntax=xml))? > > The conneg framework is designed for use as a protocol element in > content negotiation over a broad range of media features. It's use > for simply designating XML formatted data would place an unnecessary > processing burden on systems that merely want to > invoke generic XML processing where possible. > > For full content negotiation, as opposed to opportunistic XML handling, > the +xml convention SHOULD NOT be exploited. Rather, a mechanism using > full content feature description should be employed, such as provided by > RFC 2506, RFC2533, RFC 2912, etc. #g ------------ Graham Klyne (GK@ACM.ORG) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA04235 for ietf-xml-mime-bks; Tue, 17 Oct 2000 10:48:36 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04231 for ; Tue, 17 Oct 2000 10:48:34 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP24CF>; Tue, 17 Oct 2000 10:54:02 -0700 Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP24B4>; Tue, 17 Oct 2000 10:49:38 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE001059F7B@tdmail2.teledesic.com> From: Dan Kohn To: mark.baker@Canada.Sun.COM, xml-mime-types@imc.org Subject: text/xhtml+xml vs. application/xhtml+xml Date: Tue, 17 Oct 2000 10:49:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark, I would appreciate if the HTML WG could provide a little more context on their thinking, perhaps by adding to discussion to the eventual XHTML MIME registration. First, I'm not convinced that text/ is the correct top-level type. Section 3 of says: If an XML document -- that is, the unprocessed, source XML document -- is readable by casual users, text/xml is preferable to application/xml. MIME user agents (and web user agents) that do not have explicit support for text/xml will treat it as text/plain, for example, by displaying the XML entity as plain text. Application/xml is preferable when the XML MIME entity is unreadable by casual users. Similarly, text/xml-external-parsed-entity is preferable when an external parsed entity is readable by casual users, but application/xml-external-parsed-entity is preferable when a plain text display is inappropriate. NOTE: Users are in general not used to text containing tags such as , and often find such tags quite disorienting or annoying. If one is not sure, the conservative principle would suggest using application/* instead of text/* so as not to put information in front of users that they will quite likely not understand. Using the canonical mother example, I know that my mother, who does not mind looking at , would be upset if her mailer revealed the ugly innards: Dan Kohn's Home Page ... It seems like application/* is thus the safer bet. Moreover, section 2.11 of already standardizes end-of-line handling, so the canonicalization of line endings that text/* supports does not seem necessary. Also, I would like to see some detailed discussion of when to use application/xhtml+xml and when to use text/html. This seems like an upward compatibility challenge of exceeding subtlety, and may deserve more attention than it received in your IRC conversation. Thanks in advance for any insight you can provide into your and the WG's thinking. - dan -- Dan Kohn Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01919 for ietf-xml-mime-bks; Tue, 17 Oct 2000 09:12:48 -0700 (PDT) Received: from mgate-01.teledesic.com (mgate-01.teledesic.com [216.190.22.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01914 for ; Tue, 17 Oct 2000 09:12:47 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <4GTP2TXL>; Tue, 17 Oct 2000 09:18:03 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE001059F6B@tdmail2.teledesic.com> From: Dan Kohn To: ph@w3.org Cc: ietf-xml-mime@imc.org Subject: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt Date: Tue, 17 Oct 2000 09:17:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philipp, could I suggest that you review , which is expected to shortly replace RFC 2376. Specifically, I would strongly recommend changing your application to application/smil+xml, and quoting the appropriate sections of RFC 2376bis by reference rather than by repeating the text. Thanks for considering this. - dan -- Dan Kohn -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, 2000-10-17 03:47 Subject: I-D ACTION:draft-hoschka-smil-media-type-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The application/smil Media Type Author(s) : P. Hoschka Filename : draft-hoschka-smil-media-type-05.txt Pages : 4 Date : 16-Oct-00 This document specifies the Media Type for version 1 of the Synchronized Multimedia Integration Language (SMIL 1.0). SMIL allows integrating a set of independent multimedia objects into a synchronized multimedia presentation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hoschka-smil-media-type-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hoschka-smil-media-type-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Received: by ns.secondary.com (8.9.3/8.9.3) id AAA16248 for ietf-xml-mime-bks; Sun, 15 Oct 2000 00:00:41 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA16244 for ; Sun, 15 Oct 2000 00:00:38 -0700 (PDT) Received: from localhost by gate.sinica.edu.tw (8.10.1/8.10.1) with ESMTP id e9F75No14087 for ; Sun, 15 Oct 2000 15:05:24 +0800 (CST) Date: Sun, 15 Oct 2000 15:05:23 +0800 (CST) From: Rick Jelliffe X-Sender: ricko@gate To: ietf-xml-mime@imc.org Subject: Re: Requiring charset parameter on +xml types? In-Reply-To: <20001015003522O.muraw3c@attglobal.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 15 Oct 2000 muraw3c@attglobal.net wrote: > Martin, > > > - For text/html+xml (and that would work for all types, actually), > > beef up the servers so that they can use the information in the > > file to set the charset parameter correctly. > > Matt Sergeant has already implemented a Perl module "Apache::MimeXML". > Let's encourage such implementation efforts! But not by making it a requirement. Get the implementations universally deployed first. Otherwise clients will be written expecting something that that cannot be provided: don't create interoperability problems! Rick Jelliffe Received: by ns.secondary.com (8.9.3/8.9.3) id IAA02705 for ietf-xml-mime-bks; Sat, 14 Oct 2000 08:30:36 -0700 (PDT) Received: from prserv.net (out5.prserv.net [32.97.166.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA02696 for ; Sat, 14 Oct 2000 08:30:34 -0700 (PDT) From: muraw3c@attglobal.net Received: from localhost ([210.88.161.112]) by prserv.net (out5) with SMTP id <2000101415352120504hj8gqe>; Sat, 14 Oct 2000 15:35:22 +0000 To: ietf-xml-mime@imc.org Cc: mark.baker@Canada.Sun.COM Subject: Re: Requiring charset parameter on +xml types? In-Reply-To: <4.2.0.58.J.20001014095427.03a18ca0@sh.w3.mag.keio.ac.jp> References: <39E74BE8.74E6DA9@canada.sun.com> <4.2.0.58.J.20001014095427.03a18ca0@sh.w3.mag.keio.ac.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001015003522O.muraw3c@attglobal.net> Date: Sun, 15 Oct 2000 00:35:22 +0900 (JST) X-Dispatcher: imput version 20000228(IM140) Lines: 37 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Martin, > - For text/html+xml (and that would work for all types, actually), > beef up the servers so that they can use the information in the > file to set the charset parameter correctly. Matt Sergeant has already implemented a Perl module "Apache::MimeXML". Let's encourage such implementation efforts! http://www.cpan.org/modules/by-module/Apache/Apache-MimeXML-0.08.readme > NAME > Apache::MimeXML - mod_perl mime encoding sniffer for XML files > > SYNOPSIS > Simply add this line to srm.conf or httpd.conf: > > PerlTypeHandler +Apache::MimeXML > > Alternatively add it only for certain files or directories using > the standard Apache methods. There is about a 30% slowdown for > files using this module, so you probably want to restrict it to > certain XML locations only. > > DESCRIPTION > An XML Content-Type sniffer. This module reads the encoding > attribute in the xml declaration and returns an appropriate > content-type heading. If no encoding declaration is found it > returns utf-8 or utf-16 depending on the specific encoding. Cheers, IBM Tokyo Research Lab & International University of Japan, Research Institute MURATA Makoto Received: by ns.secondary.com (8.9.3/8.9.3) id SAA10934 for ietf-xml-mime-bks; Fri, 13 Oct 2000 18:30:16 -0700 (PDT) Received: from sh.w3.mag.keio.ac.jp (sh.w3.mag.keio.ac.jp [133.27.194.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA10930 for ; Fri, 13 Oct 2000 18:30:14 -0700 (PDT) Received: from enoshima (ppp2ppp41.sfc.keio.ac.jp [133.27.12.246]) by sh.w3.mag.keio.ac.jp (8.9.3/3.7W) with ESMTP id KAA13721; Sat, 14 Oct 2000 10:34:49 +0900 (JST) Message-Id: <4.2.0.58.J.20001014095427.03a18ca0@sh.w3.mag.keio.ac.jp> X-Sender: duerst@sh.w3.mag.keio.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Sat, 14 Oct 2000 10:11:29 +0900 To: Mark Baker , ietf-xml-mime@imc.org From: "Martin J. Duerst" Subject: Re: Requiring charset parameter on +xml types? In-Reply-To: <39E74BE8.74E6DA9@canada.sun.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: Hello Mark, As far as I understand, for text/...+xml, the charset parameter is very close to being required (by using the general MIME default of us-ascii, which overrides any internal information). For application/...+xml (or others such as image/...+xml), the internal information is relevant if there is no charset parameter. To solve the problems, the following things should help: - Help to make system administrators, webmasters, and so on, aware of the fact that they have to allow settings and have to make them. - Maybe to define a type application/html+xml for use by those people who want to just ship files around. - For text/html+xml (and that would work for all types, actually), beef up the servers so that they can use the information in the file to set the charset parameter correctly. [Sorry to be a bit lengthy here, but I just almost got excited about this idea.] This would work about as follows: - Server detects that content type of outgoing stuff is +xml. - Server verifies that there is no setting for the charset parameter in the configuration. - Server peeks into the data to check for a BOM and/or for an encoding declaration. - Server sets charset parameter. Please note the following: - If this feature is introduced into a server without any configuration options, the only potentially undesirable effect is to label files that were intended to go out as defaulted to us-ascii as utf-8 explicitly. But this is in no way a problem, because every us-ascii file is a utf-8 file (this means no wrong labels), and because the chance that a receiving XML processor understands utf-8 are higher than for us-ascii (utf-8 is required, us-ascii is not). - Such a feature has been the idea behind Greetings, > >At the HTML WG f2f yesterday, it was proposed that we should require the >use of the charset parameter on the XHTML media type. This came up in >the discussion over whether the media type should use application/ or >text/. > >Would requiring this parameter help solve the problem of those broken >web servers that I've heard about that mislabel non-US-ASCII encoded >text/* content as US-ASCII? > >Are the any other issues/pros/cons we should be aware of for requiring >this parameter? > >Thanks. > >BTW, for W3C members that are interested (i.e. it's not required reading >to grok this message - mustUnderstand = 0 :-), the IRC log of the >conversation is available at; > >http://lists.w3.org/Archives/Member/w3c-html-wg/2000OctDec/0104.html > >MB Received: by ns.secondary.com (8.9.3/8.9.3) id LAA02773 for ietf-xml-mime-bks; Fri, 13 Oct 2000 11:04:41 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.4.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02769 for ; Fri, 13 Oct 2000 11:04:39 -0700 (PDT) Received: from localhost by gate.sinica.edu.tw (8.10.1/8.10.1) with ESMTP id e9DI8oi15015; Sat, 14 Oct 2000 02:08:50 +0800 (CST) Date: Sat, 14 Oct 2000 02:08:49 +0800 (CST) From: Rick Jelliffe X-Sender: ricko@gate To: Mark Baker cc: ietf-xml-mime@imc.org Subject: Re: Requiring charset parameter on +xml types? In-Reply-To: <39E74BE8.74E6DA9@canada.sun.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, 13 Oct 2000, Mark Baker wrote: > Would requiring this parameter help solve the problem of those broken > web servers that I've heard about that mislabel non-US-ASCII encoded > text/* content as US-ASCII? No. Servers would just be setup to provide some default and system administrators would not change it, or just use something convenient. It can only work if there is also a mechanism transfering encoding information from the generator of the entity to the HTTP system. This is nice for program-generated data, but for data that has to sit on a file system or be edoted by hand it is unworkable. Rick Jelliffe Academia Sinica Computing Center Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02310 for ietf-xml-mime-bks; Fri, 13 Oct 2000 10:47:04 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02306 for ; Fri, 13 Oct 2000 10:47:03 -0700 (PDT) Received: from fastrack.Canada.Sun.COM ([129.155.1.11]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17848 for ; Fri, 13 Oct 2000 10:51:46 -0700 (PDT) Received: from canada.sun.com (seteo [129.155.190.61]) by fastrack.Canada.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA17176 for ; Fri, 13 Oct 2000 13:51:43 -0400 (EDT) Message-ID: <39E74BE8.74E6DA9@canada.sun.com> Date: Fri, 13 Oct 2000 13:52:40 -0400 From: Mark Baker Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-xml-mime@imc.org Subject: Requiring charset parameter on +xml types? 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: Greetings, At the HTML WG f2f yesterday, it was proposed that we should require the use of the charset parameter on the XHTML media type. This came up in the discussion over whether the media type should use application/ or text/. Would requiring this parameter help solve the problem of those broken web servers that I've heard about that mislabel non-US-ASCII encoded text/* content as US-ASCII? Are the any other issues/pros/cons we should be aware of for requiring this parameter? Thanks. BTW, for W3C members that are interested (i.e. it's not required reading to grok this message - mustUnderstand = 0 :-), the IRC log of the conversation is available at; http://lists.w3.org/Archives/Member/w3c-html-wg/2000OctDec/0104.html MB Received: by ns.secondary.com (8.9.3/8.9.3) id MAA22952 for ietf-xml-mime-bks; Mon, 2 Oct 2000 12:49:37 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22948 for ; Mon, 2 Oct 2000 12:49:35 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24740; Mon, 2 Oct 2000 12:53:23 -0700 (PDT) Received: from suneast.East.Sun.COM (suneast.East.Sun.COM [129.148.9.3]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA21497; Mon, 2 Oct 2000 15:53:22 -0400 (EDT) Received: from abnaki.East.Sun.COM (abnaki [129.148.171.26]) by suneast.East.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA29879; Mon, 2 Oct 2000 15:53:20 -0400 (EDT) Received: from flame-pc.east.sun.com by abnaki.East.Sun.COM (SMI-8.6/SMI-SVR4) id PAA16028; Mon, 2 Oct 2000 15:53:22 -0400 Message-Id: <4.3.2.7.2.20001002155136.00c6a360@abnaki.east.sun.com> X-Sender: elm@abnaki.east.sun.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Oct 2000 15:52:42 -0400 To: Philipp Hoschka From: "Eve L. Maler" Subject: Re: MIME-XML technology? Cc: "Simon St.Laurent" , ietf-xml-mime@imc.org In-Reply-To: <39D8D27A.99DAD84E@w3.org> References: <3.0.32.20001002101451.02196478@pophost.arbortext.com> <200010021818.OAA32151@hesketh.net> 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:22 PM 10/2/00 +0200, Philipp Hoschka wrote: >They're referring to multipart-MIME - that's what ebXML is using to >assemble different documents (of any format) into one message. > >The ebXML TRP spec is online, btw - check out the ebXML website >(locatable via google search). > >This discussion is probably more appropriate for the xml-dist-app >list. Just to round things off, the relevant spec is at: http://www.ebxml.org/specdrafts/ebXML_Messaging_Service_Specification_v0-21.pdf Eve -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Center eve.maler @ east.sun.com Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20970 for ietf-xml-mime-bks; Mon, 2 Oct 2000 11:24:12 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20966 for ; Mon, 2 Oct 2000 11:24:09 -0700 (PDT) Received: from thinkpadssl (ith1-3e6.twcny.rr.com [24.24.11.230]) by hesketh.net (8.9.3/8.9.3) with SMTP id OAA00320; Mon, 2 Oct 2000 14:27:55 -0400 Message-Id: <200010021827.OAA00320@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: ietf-xml-mime@imc.org X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 02 Oct 2000 14:31:10 -0400 To: Philipp Hoschka From: "Simon St.Laurent" Subject: Re: MIME-XML technology? Cc: ietf-xml-mime@imc.org In-Reply-To: <39D8D27A.99DAD84E@w3.org> References: <3.0.32.20001002101451.02196478@pophost.arbortext.com> <200010021818.OAA32151@hesketh.net> 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 08:22 PM 10/2/00 +0200, Philipp Hoschka wrote: >They're referring to multipart-MIME - that's what ebXML is using to >assemble different documents (of any format) into one message. > >The ebXML TRP spec is online, btw - check out the ebXML website >(locatable via google search). > >This discussion is probably more appropriate for the xml-dist-app >list. Agreed - I was just irritated by the naming convention used in the article, which suggests that something more is going on between MIME and XML. Simon St.Laurent XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20883 for ietf-xml-mime-bks; Mon, 2 Oct 2000 11:21:36 -0700 (PDT) Received: from sophia.inria.fr (root@sophia.inria.fr [138.96.32.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20879 for ; Mon, 2 Oct 2000 11:21:35 -0700 (PDT) Received: from w3.org by sophia.inria.fr (8.10.0/8.10.0) with ESMTP id e92IPH721001; Mon, 2 Oct 2000 20:25:17 +0200 (MET DST) X-Authentication-Warning: sophia.inria.fr: Host nice-45-155.dial.proxad.net [213.228.45.155] claimed to be w3.org Message-ID: <39D8D27A.99DAD84E@w3.org> Date: Mon, 02 Oct 2000 20:22:50 +0200 From: Philipp Hoschka X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: "Simon St.Laurent" CC: ietf-xml-mime@imc.org Subject: Re: MIME-XML technology? References: <3.0.32.20001002101451.02196478@pophost.arbortext.com> <200010021818.OAA32151@hesketh.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: They're referring to multipart-MIME - that's what ebXML is using to assemble different documents (of any format) into one message. The ebXML TRP spec is online, btw - check out the ebXML website (locatable via google search). This discussion is probably more appropriate for the xml-dist-app list. "Simon St.Laurent" a écrit : > > Does anyone know what the "MIME-XML technology to wrap and send the > message" this article discusses might be? > > http://www.sdtimes.com/news/015/story1.htm > > It sounds at the end like there's some Sun messaging spec (JAXN) involved, > but I'm pretty irritated to find 'MIME-XML technology' set up in some kind > of weird contrast to SOAP. > > I don't love SOAP, and I doubt the journalist was given great information > about this 'MIME-XML' critter, but I'm really scratching my head. > > Simon St.Laurent > XML Elements of Style / XML: A Primer, 2nd Ed. > XHTML: Migrating Toward XML > http://www.simonstl.com - XML essays and books Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20643 for ietf-xml-mime-bks; Mon, 2 Oct 2000 11:14:22 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20635 for ; Mon, 2 Oct 2000 11:14:19 -0700 (PDT) Received: from thinkpadssl (ith1-3e6.twcny.rr.com [24.24.11.230]) by hesketh.net (8.9.3/8.9.3) with SMTP id OAA32151; Mon, 2 Oct 2000 14:18:02 -0400 Message-Id: <200010021818.OAA32151@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: ietf-xml-mime@imc.org X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 02 Oct 2000 14:21:17 -0400 To: ietf-xml-mime@imc.org From: "Simon St.Laurent" Subject: MIME-XML technology? In-Reply-To: <4.3.2.7.2.20001002112103.00bdb180@abnaki.east.sun.com> References: <3.0.32.20001002101451.02196478@pophost.arbortext.com> 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: Does anyone know what the "MIME-XML technology to wrap and send the message" this article discusses might be? http://www.sdtimes.com/news/015/story1.htm It sounds at the end like there's some Sun messaging spec (JAXN) involved, but I'm pretty irritated to find 'MIME-XML technology' set up in some kind of weird contrast to SOAP. I don't love SOAP, and I doubt the journalist was given great information about this 'MIME-XML' critter, but I'm really scratching my head. Simon St.Laurent XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17292 for ietf-xml-mime-bks; Mon, 2 Oct 2000 08:34:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17288 for ; Mon, 2 Oct 2000 08:33:58 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07612; Mon, 2 Oct 2000 09:37:43 -0600 (MDT) Received: from suneast.East.Sun.COM (suneast.East.Sun.COM [129.148.9.3]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA19735; Mon, 2 Oct 2000 11:37:42 -0400 (EDT) Received: from abnaki.East.Sun.COM (abnaki [129.148.171.26]) by suneast.East.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA09664; Mon, 2 Oct 2000 11:37:39 -0400 (EDT) Received: from flame-pc.east.sun.com by abnaki.East.Sun.COM (SMI-8.6/SMI-SVR4) id LAA14330; Mon, 2 Oct 2000 11:37:42 -0400 Message-Id: <4.3.2.7.2.20001002112103.00bdb180@abnaki.east.sun.com> X-Sender: elm@abnaki.east.sun.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Oct 2000 11:36:51 -0400 To: Paul Grosso From: "Eve L. Maler" Subject: Re: Cc: Chris Lilley , ietf-xml-mime@imc.org, symm@w3.org In-Reply-To: <3.0.32.20001002101451.02196478@pophost.arbortext.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 10:15 AM 10/2/00 -0500, Paul Grosso wrote: >I found a mention of fragment identifier and the # separator in >RFC 2396 [1], but I'm still looking for the discussion of the ? >and | separator (especially, whether they require/allow the entire >resource to be downloaded first or not and exactly where/by whom >the bit after the | or ? should get processed). Can someone give >pointers to the specs that answer these questions? (I've already >looked at RFC 1738, 1808, and 2396.) Thanks. > >[1] ftp://ftp.ietf.org/rfc/rfc2396.txt The "query component" (starting with a ?) is discussed in RFC 2396, but I'm surprised, on reading this now, that it doesn't say more about the server/user agent distinction. It does say "The query component is a string of information to be interpreted by the resource", and perhaps that's 2396-speak meaning that it's information to be interpreted by the system that serves the resource. The | separator was invented out of whole cloth in an early version of XLL/XLink; when we (the W3C XML Linking WG) broke out the XPointer stuff into its own spec, the | went away because we had been inappropriately messing with basic URI functionality. Once we got on the track of defining a fragment identifier language for a particular set of media types, the scope became somewhat simpler and clearer. Eve -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Center eve.maler @ east.sun.com Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16919 for ietf-xml-mime-bks; Mon, 2 Oct 2000 08:17:34 -0700 (PDT) Received: from hesketh.net (wasabi-eth0-1.hesketh.net [216.27.10.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16915 for ; Mon, 2 Oct 2000 08:17:30 -0700 (PDT) Received: from thinkpadssl (ith1-3e6.twcny.rr.com [24.24.11.230]) by hesketh.net (8.9.3/8.9.3) with SMTP id LAA19057; Mon, 2 Oct 2000 11:21:15 -0400 Message-Id: <200010021521.LAA19057@hesketh.net> X-Received-From: simonstl@simonstl.com X-Delivered-To: ietf-xml-mime@imc.org X-Sender: simonstl@216.27.10.33 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 02 Oct 2000 11:24:32 -0400 To: Lloyd Rutledge , Chris Lilley , ietf-xml-mime@imc.org, symm@w3.org, Philipp Hoschka From: "Simon St.Laurent" Subject: Re: Conformance value of "+xml"? (was empty, or "[symm]") In-Reply-To: <200010021207.OAA31851@mast.cwi.nl> References: 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 02:07 PM 10/2/00 +0200, Lloyd Rutledge wrote: >Having W3C require implementors of one standard be required to >implement several others from day one, if that correctly paraphrases >you, Simon, may have its merits -- and with the luxury of not being an >implementor myself, I'm inclined to see these merits. However, >(speaking as advocate-in-proxy) implementors are typically very hard >pressed to implement even the one standard for the first release, >especially is that release date is targeted to coincide with the >release of the format itself. This is complicated further if the >related standard itself is not yet released as a recommendation, as is >the case with XPointer. If every potentially related standard had to >also be implemented, it would be a long time before we see SMIL 2.0, >and other formats, first emerge in any practical sense. It may be >wise to slow release cycles as part of deliberate full step-by-step >inter-format integration, but it would put a hard-to-ignore strain on >implementors. I agree that it puts strain on implementors, but I think it points to an architectural implementation change that XML is driving: moving toward reusable code at various levels of a program. At some point I'd like to dream that this will be an integration problem rather than a development problem, but right now I can see where that's not too promising. Getting generic modules out into the world and used is pretty difficult, it seems. Simon St.Laurent XML Elements of Style / XML: A Primer, 2nd Ed. XHTML: Migrating Toward XML http://www.simonstl.com - XML essays and books Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16805 for ietf-xml-mime-bks; Mon, 2 Oct 2000 08:12:14 -0700 (PDT) Received: from sprouts.arbortext.com (IDENT:root@[198.108.59.202]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16797 for ; Mon, 2 Oct 2000 08:12:07 -0700 (PDT) Message-Id: <3.0.32.20001002101451.02196478@pophost.arbortext.com> X-Sender: pbg@pophost.arbortext.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 02 Oct 2000 10:15:45 -0500 To: Chris Lilley From: Paul Grosso Subject: Re: Cc: ietf-xml-mime@imc.org, symm@w3.org 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 02:59 2000 09 30 +0200, Chris Lilley wrote: >"Simon St.Laurent" wrote: >> At 01:33 AM 9/30/00 +0200, Chris Lilley wrote: >> >> Used in a query string, XPointers could be processed by the server, >> > >> >they could be, but then they wouldn't be fragment identifiers. besides, >> >thats what the XML Query WG is cooking up, right? >> >> I'm not sure why you feel they wouldn't be fragment identifiers. > >I am using the term fragment identifiers in the sense it is used in the >UROI specifications. I found a mention of fragment identifier and the # separator in RFC 2396 [1], but I'm still looking for the discussion of the ? and | separator (especially, whether they require/allow the entire resource to be downloaded first or not and exactly where/by whom the bit after the | or ? should get processed). Can someone give pointers to the specs that answer these questions? (I've already looked at RFC 1738, 1808, and 2396.) Thanks. [1] ftp://ftp.ietf.org/rfc/rfc2396.txt >> I strongly hope that the XML Query WG doesn't feel compelled to reinvent >> this particular wheel or worse, create a syntax that bars the reuse of >> XPointers for this work. > >My understanding is that their work builds on XPointer. You should read the following public documents if you want to know more: XML Query Requirements -- W3C Working Draft 15 August 2000 http://www.w3.org/TR/xmlquery-req XML Query Data Model -- W3C Working Draft 11 May 2000 http://www.w3.org/TR/query-datamodel/ Quoting from the Intro of the latter document: Several XML data models have been developed in the W3C Activities. The XML Information Set (http://www.w3.org/TR/xml-infoset) provides a description of the information available in a well-formed XML document. The XPath Recommendation ( http://www.w3.org/TR/xpath), which is used by both XSLT ( http://www.w3.org/TR/xslt) and XPointer ( http://www.w3.org/TR/xptr), contains a data model and a mapping that relates the XPath data model to the XML Information Set (hence ``Infoset''). The Document Object Model ( http://www.w3.org/TR/DOM-Level-2/) is an API for HTML and XML documents, but it does imply an underlying abstract data model. The XML Schema Working Group is defining features, such as structures (http://www.w3.org/TR/xmlschema-1) and datatypes (http://www.w3.org/TR/xmlschema-2), that extend an instance of the XML Information Set with more precise type information. The XML Query Data Model defines formally the information contained in the input to an XML Query processor; in other words, an XML Query processor evaluates a query on an instance of the XML Query Data Model. Our model is based on the XML Information Set, but it requires the following new features to meet the XML Query Working Group's requirements: . . . You should draw your own conclusions about the relationship between XPointer and XML Query, but it is not obvious that XML Query will end up with either a model or a syntax that is a subset of XPointer. (And I'm not saying that they should or shouldn't, but it sounded a bit like Simon might have an opinion on that question.) paul Received: by ns.secondary.com (8.9.3/8.9.3) id HAA16423 for ietf-xml-mime-bks; Mon, 2 Oct 2000 07:55:03 -0700 (PDT) Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16418 for ; Mon, 2 Oct 2000 07:55:01 -0700 (PDT) Received: from w3.org (IDENT:root@localhost [127.0.0.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA11924; Mon, 2 Oct 2000 10:58:42 -0400 Message-ID: <39D8A296.AC5A257F@w3.org> Date: Mon, 02 Oct 2000 16:58:30 +0200 From: Chris Lilley Organization: W3C X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Lloyd Rutledge CC: ietf-xml-mime@imc.org, simonstl@simonstl.com, symm@w3.org, Philipp Hoschka Subject: Re: Conformance value of "+xml"? (was empty, or "[symm]") References: <200010021207.OAA31851@mast.cwi.nl> 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: Lloyd Rutledge wrote: > > On Sat, Sep 30 2000 Chris Lilley wrote: > > OK. Your understanding is not correct. Servers do not process the fragment > > identifiers, because therse are not sent to the server (queries, following > > a ? character, *are* sent to the server and perhaps that is what you are > > thinking of?) > Thanks, Chris -- I stand corrected. Other main points from my > previous post still stand, though. Yes, of course. I was not disagreeing with your entire post - just the particular part about fragment identifiers appended to URIs. > Many SMIL constructs have values > that are XPointer subsets, rather than being SMIL-only. This > minimizes format re-learning and facilitates future further > incorporation of XPointer. Full XPointer is not required in SMIL, but > is explicitly enabled. That seems to be wise at this point; a future direction is clearly shown, and what is there is compatible (proper subset) so a general purpose XPointer inmplementation can be used. -- Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA12699 for ietf-xml-mime-bks; Mon, 2 Oct 2000 05:04:21 -0700 (PDT) Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12694 for ; Mon, 2 Oct 2000 05:04:19 -0700 (PDT) Received: from mast.cwi.nl (mast.cwi.nl [192.16.196.89]) by hera.cwi.nl with ESMTP id OAA04926 for ; Mon, 2 Oct 2000 14:07:32 +0200 (MET DST) Received: from spruit.cwi.nl (IDENT:lloyd@spruit.cwi.nl [192.16.196.101]) by mast.cwi.nl (8.9.3/8.9.3/FLW-3.11M) with ESMTP id OAA31851; Mon, 2 Oct 2000 14:07:31 +0200 Message-Id: <200010021207.OAA31851@mast.cwi.nl> To: Chris Lilley , ietf-xml-mime@imc.org, simonstl@simonstl.com, symm@w3.org, Philipp Hoschka Subject: Re: Conformance value of "+xml"? (was empty, or "[symm]") In-reply-to: Your message of "Sat, 30 Sep 2000 00:38:36 +0200." <39D519EC.D648F2E@w3.org> Date: Mon, 02 Oct 2000 14:07:31 +0200 From: Lloyd Rutledge Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, Sep 30 2000 Chris Lilley wrote: > Lloyd Rutledge wrote: > > The reason that the SMIL 2.0 spec does not require that > > browsers process XPointer is that browsers don't and can't process > > XPointer -- servers do. Please correct me if my understanding of the > > general architecture is too primitive, > > OK. Your understanding is not correct. Servers do not process the fragment > identifiers, because therse are not sent to the server (queries, following > a ? character, *are* sent to the server and perhaps that is what you are > thinking of?) > > > but servers process XPointer, > > not clients -- right?. > > No. > > > Clients send URI's to the given server, > > yes. The fragment is not part of the URI and is not sent > > > the > > server processes it and returns the located data to the client. > > Yes, and then the client locates the relevant part of this resource using > the fragment identifier. Thanks, Chris -- I stand corrected. Other main points from my previous post still stand, though. Many SMIL constructs have values that are XPointer subsets, rather than being SMIL-only. This minimizes format re-learning and facilitates future further incorporation of XPointer. Full XPointer is not required in SMIL, but is explicitly enabled. Having W3C require implementors of one standard be required to implement several others from day one, if that correctly paraphrases you, Simon, may have its merits -- and with the luxury of not being an implementor myself, I'm inclined to see these merits. However, (speaking as advocate-in-proxy) implementors are typically very hard pressed to implement even the one standard for the first release, especially is that release date is targeted to coincide with the release of the format itself. This is complicated further if the related standard itself is not yet released as a recommendation, as is the case with XPointer. If every potentially related standard had to also be implemented, it would be a long time before we see SMIL 2.0, and other formats, first emerge in any practical sense. It may be wise to slow release cycles as part of deliberate full step-by-step inter-format integration, but it would put a hard-to-ignore strain on implementors. But regardless of the merits of either side, SMIL 2.0 is in last call, and so it is unlikely such a large new requirement can be introduced. In the end, with XPointer enabled in SMIL, it is the free market that will decide to what degree XPointer is implemented and used in SMIL. This is as true with XPointer as it is with the media formats themselves that SMIL integrates. The implementors will listen to their customer base. What sweetens the pot for implementors is the availability of other XPointer implementations -- especially those in open source, of course. The fact that the W3C XPointer page has an XPointer implementation list that is empty is not encouraging [1], but over time this will surely change. As customers and implementors step forward and make themselves known, XPointer use will grow in SMIL, XHTML and other formats. -Lloyd [1] http://www.w3.org/XML/Linking -- Lloyd Rutledge vox: +31 20 592 41 27 fax: +31 20 592 41 99 CWI net: Lloyd.Rutledge@cwi.nl Web: http://www.cwi.nl/~lloyd Post: PO Box 94079 | NL-1090 GB Amsterdam | The Netherlands Street: Kruislaan 413 | NL-1098 SJ Amsterdam | The Netherlands