Received: by ns.secondary.com (8.9.3/8.9.3) id LAA25341 for ietf-xml-mime-bks; Mon, 28 Aug 2000 11:05:03 -0700 (PDT) Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25337 for ; Mon, 28 Aug 2000 11:05:02 -0700 (PDT) Received: from 146-115-74-136.c5-0.brl-ubr1.sbo-brl.ma.cable.rcn.com ([146.115.74.136]) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.15 #2) id 13TTIA-0000Gt-00 for ietf-xml-mime@imc.org; Mon, 28 Aug 2000 14:05:54 -0400 Mime-Version: 1.0 X-Sender: sgmlworks@mail.earthlink.net Message-Id: In-Reply-To: References: Date: Mon, 28 Aug 2000 12:11:59 -0400 To: From: Dave Peterson Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard 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 7:25 AM -0700 8/28/00, Larry Masinter wrote: >More often than not, people just fix specs that are broken, and pay >attention to backward compatibility when it affects deployed software, >not theoretical compatibility. For what it's worth, in my opinion blind worship at the altar of backward compatibility is one thing that prevented SGML from accepting XML points of view and caused XML to become a separate standard. Don't do it again. -- Dave Peterson SGMLWorks! davep@acm.org Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15769 for ietf-xml-mime-bks; Mon, 28 Aug 2000 07:24:02 -0700 (PDT) Received: from sjgw.attlabs.att.com (gate.attlabs.net [135.197.57.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15765 for ; Mon, 28 Aug 2000 07:24:01 -0700 (PDT) Received: from exchsj06.ipo.att.com (exchsj06.attlabs.att.com [135.197.72.26]) by sjgw.attlabs.att.com (8.8.5/8.8.8) with ESMTP id HAA05936; Mon, 28 Aug 2000 07:23:51 -0700 (PDT) Received: from ugnfw (ugnfw-qfe3.attlabs.att.com [135.197.40.41]) by exchsj06.ipo.att.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QSZSA89S; Mon, 28 Aug 2000 07:18:12 -0700 From: "Larry Masinter" To: "Dan Kohn" , "'Paul Grosso'" , Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard Date: Mon, 28 Aug 2000 07:25:13 -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: <25D0C66E6D25D311B2AC0008C7913EE0AE5379@tdmail2.teledesic.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For backward compatibility, application/xml and text/xml MAY, but SHOULD NOT, also be used for "external parsed entities", "external DTD subsets", and "external parameter entities". I don't think "MAY but SHOULD NOT" is a valid state in RFC 2119 terminology, or called for. How about: application/xml and text/xml MUST NOT be used for "external parsed entities", "external DTD subsets", and "external parameter entities". Note that RFC 2376 (obsoleted) allowed this usage, although in practice it is likely to be rare. The justification > ... It is generally considered bad form to invalidate > implementations that made a good faith effort to conform to the previous > form of the standard. isn't consistent with policy or practice; from RFC 2026 section 4.1.1: A Proposed Standard specification is generally stable... However, further experience might result in a change or even retraction of the specification before it advances. More often than not, people just fix specs that are broken, and pay attention to backward compatibility when it affects deployed software, not theoretical compatibility. Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14654 for ietf-xml-mime-bks; Wed, 23 Aug 2000 14:39:10 -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 OAA14650 for ; Wed, 23 Aug 2000 14:39:09 -0700 (PDT) Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 Aug 2000 14:39:54 -0700 Message-ID: <25D0C66E6D25D311B2AC0008C7913EE0AE5379@tdmail2.teledesic.com> From: Dan Kohn To: "'Paul Grosso'" , ietf-xml-mime@imc.org Subject: RE: Fwd: Last Call: XML Media Types to Proposed Standard Date: Wed, 23 Aug 2000 14:39:14 -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: We would prefer that application/xml and text/xml did not allow these kinds of entities as well, but they are explicitly allowed in the predecessor document, RFC 2376. It is generally considered bad form to invalidate implementations that made a good faith effort to conform to the previous form of the standard. Thus, we used SHOULD NOT rather than MUST NOT. Of course, we expect the availability of text/xml-external-parsed-entity and application/xml-external-parsed-entity will do more than any SHOULD/MUST distinction to cause implementers not to overload */xml. - dan -- Dan Kohn -----Original Message----- From: Paul Grosso [mailto:pgrosso@arbortext.com] Sent: Wednesday, 2000-08-23 13:53 To: ietf-xml-mime@imc.org Subject: Re: Fwd: Last Call: XML Media Types to Proposed Standard At 08:55 2000 08 17 +0900, MURATA Makoto wrote: >Dan, Simon, and I have very slightly revised the I-D, on the basis of >comments in this ML and comments we directly received. The new I-D is now >available at: > > http://www.ietf.org/internet-drafts/draft-murata-xml-07.txt I note in section 3: For backward compatibility, application/xml and text/xml MAY, but SHOULD NOT, also be used for "external parsed entities", "external DTD subsets", and "external parameter entities". I don't see how external DTD subsets or external parameter entities could be parsed or accessed as application/xml or text/xml. I'm concerned that, by allowing such entities to be given an application/xml or text/xml MIME type, we will be saying, for example, that XPointer can now be used to access them (since XPointer is the fragment identifier syntax for resources of MIME type application/xml and text/xml) and yet such resources don't have infosets and accessing them using an XPointer is not defined. I don't fully understand the backward compatibility argument, but I'd prefer not to allow application/xml and text/xml to be used on "external DTD subsets", and "external parameter entities". paul Received: by ns.secondary.com (8.9.3/8.9.3) id NAA14061 for ietf-xml-mime-bks; Wed, 23 Aug 2000 13:52:54 -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 NAA14056 for ; Wed, 23 Aug 2000 13:52:52 -0700 (PDT) Message-Id: <3.0.32.20000823154928.00689e74@pophost.arbortext.com> X-Sender: pbg@pophost.arbortext.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 23 Aug 2000 15:53:08 -0500 To: ietf-xml-mime@imc.org From: Paul Grosso Subject: Re: Fwd: Last Call: 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: At 08:55 2000 08 17 +0900, MURATA Makoto wrote: >Dan, Simon, and I have very slightly revised the I-D, on the basis of >comments in this ML and comments we directly received. The new I-D is now >available at: > > http://www.ietf.org/internet-drafts/draft-murata-xml-07.txt I note in section 3: For backward compatibility, application/xml and text/xml MAY, but SHOULD NOT, also be used for "external parsed entities", "external DTD subsets", and "external parameter entities". I don't see how external DTD subsets or external parameter entities could be parsed or accessed as application/xml or text/xml. I'm concerned that, by allowing such entities to be given an application/xml or text/xml MIME type, we will be saying, for example, that XPointer can now be used to access them (since XPointer is the fragment identifier syntax for resources of MIME type application/xml and text/xml) and yet such resources don't have infosets and accessing them using an XPointer is not defined. I don't fully understand the backward compatibility argument, but I'd prefer not to allow application/xml and text/xml to be used on "external DTD subsets", and "external parameter entities". paul Received: by ns.secondary.com (8.9.3/8.9.3) id QAA17617 for ietf-xml-mime-bks; Wed, 16 Aug 2000 16:54:31 -0700 (PDT) Received: from prserv.net (out2.prserv.net [32.97.166.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17613 for ; Wed, 16 Aug 2000 16:54:29 -0700 (PDT) Received: from lute.attglobal.net ([129.37.169.229]) by prserv.net (out2) with SMTP id <2000081623532922901qnmeme>; Wed, 16 Aug 2000 23:53:29 +0000 Message-Id: <200008162355.AA00268@lute.attglobal.net> Date: Thu, 17 Aug 2000 08:55:40 +0900 To: ietf-xml-mime@imc.org Subject: Fwd: Last Call: XML Media Types to Proposed Standard From: MURATA Makoto MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.11 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan, Simon, and I have very slightly revised the I-D, on the basis of comments in this ML and comments we directly received. The new I-D is now available at: http://www.ietf.org/internet-drafts/draft-murata-xml-07.txt We entered into the last call phase at IETF. Cheers, Makoto > The IESG has received a request to consider 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 plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by September 15, 2000. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-murata-xml-07.txt >