RE: Conformance value of "+xml"?
Dan Kohn <dan@dankohn.com> Thu, 21 September 2000 06:06 UTC
Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA15978 for ietf-xml-mime-bks; Wed, 20 Sep 2000 23:06:07 -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 XAA15974 for <ietf-xml-mime@imc.org>; Wed, 20 Sep 2000 23:06:06 -0700 (PDT)
Received: by mgate-01.teledesic.com with Internet Mail Service (5.5.2650.21) id <SQZQ8WGM>; Wed, 20 Sep 2000 23:09:37 -0700
Message-ID: <25D0C66E6D25D311B2AC0008C7913EE0010598E2@tdmail2.teledesic.com>
From: Dan Kohn <dan@dankohn.com>
To: ietf-xml-mime@imc.org, Mark Baker <mark.baker@Canada.Sun.COM>
Subject: RE: Conformance value of "+xml"?
Date: Wed, 20 Sep 2000 23:08:50 -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: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-ID: <ietf-xml-mime.imc.org>
List-Unsubscribe: <mailto:ietf-xml-mime-request@imc.org?body=unsubscribe>
I believe the guarantee you are looking for is in the last sentence of the last paragraph of Section 7: The registration process for these media types is described in [RFC2048]. The registrar for the IETF tree will encourage new XML-based media type registrations in the IETF tree to follow this guideline. Registrars for other trees SHOULD follow this convention in order to ensure maximum interoperability of their XML-based documents. Similarly, media subtypes that do not represent XML entities MUST NOT be allowed to register with a '+xml' suffix. MIME types with a +xml label are XML. Stated in the negative (i.e., the contrapositive), it is violation of the spec to send +xml MIME objects that are not XML. Note though, that not all XML MIME types are required to use a +xml label (see Section A15). That is the main reason for the SHOULDs. Secondarily, certain registrations may have additional or slightly different concerns, so it didn't seem reasonable to constrain them to the identical registration language that we used. The concern with fragment identifiers was that certain media types developed before the XLink spec (I remember SVG being mentioned), might not confirm to the later linking spec. If all it takes to conform to the linking spec is to be valid XML, than by definition all +xml media types do so, so there's no problem with the current draft. If something extra is required, than the SHOULD language is appropriate since some media types may not do so, so there's still no problem with the current draft. Let me close by quoting the RFC 2119 definitions for MUST and SHOULD, to point out that the distance between them is really quite large. We worked hard to only use MUST when interoperability guarantees demanded it: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Thanks for the note on the email address, which we'll ask the IESG to fix in their note to the RFC editor, if they approve the draft when it finishes last call on 2000-09-27. - dan -- Dan Kohn <mailto:dan@dankohn.com> <http://www.dankohn.com> <tel:+1-650-327-2600> -----Original Message----- From: Mark Baker [mailto:mark.baker@Canada.Sun.COM] Sent: Wednesday, 2000-09-20 11:49 To: ietf-xml-mime@imc.org Subject: Conformance value of "+xml"? Greetings, I've been writing the registration of a new media type in the HTML WG for XHTML using draft-murata-xml-0[78]. In doing this, I've come to the conclusion that the draft does not provide implementors and authors enough guarantees in order to be able to do anything more than is done today without the "+xml" convention. Before actually implementing the recommendations in this draft, I was under the impression that using or seeing a media type suffixed with "+xml" could provide me, as a user agent implementor, certain guarantees. However, because of a lack of any MUSTs in 7.1, I am not guaranteed that *any* of those things in 7.1 actually hold. It is quite possible that I could receive a document described as "text/foo+xml", yet not be able to do anything with it except fallback as text/plain. Granted, that isn't any worse than today, but if I wanted that behaviour, I don't need "+xml" to get it. Therefore, I'd like to propose the following modifications for 7.1; - first paragraph; SHOULD to MUST - second; SHOULD to MUST - forth; SHOULD to MUST For the fifth paragraph I'd recommend changing the wording to reflect that for fragment identifiers at least, registrations are free to *extend* the syntax, but must at least support the XML syntax; "These registrations SHOULD also make reference to RFC XXXX in specifying magic numbers, but MUST reference it for base URIs and use of the BOM. Fragment identifier syntax MAY be extended by the registration, but it MUST at least reference RFC XXXX. BTW, Appendix C references an incorrect email address for this list, "xml-mime-types@imc.org". MB
- Re: Conformance value of "+xml"? muraw3c
- Re: Conformance value of "+xml"? Mark Baker
- Re: XPointer scheme names (was Re: Conformance va… Martin J. Duerst
- Re: Conformance value of "+xml"? Tim Bray
- XPointer scheme names (was Re: Conformance value … Eve L. Maler
- Re: Conformance value of "+xml"? Simon St.Laurent
- Re: Conformance value of "+xml"? Chris Lilley
- Re: Conformance value of "+xml"? Simon St.Laurent
- Re: Conformance value of "+xml"? Mark Baker
- Re: Conformance value of "+xml"? Martin J. Duerst
- Re: Conformance value of "+xml"? Chris Lilley
- Re: Conformance value of "+xml"? Mark Baker
- RE: Conformance value of "+xml"? Dan Kohn
- Conformance value of "+xml"? Mark Baker