Conformance value of "+xml"?
Mark Baker <mark.baker@Canada.Sun.COM> Wed, 20 September 2000 18:37 UTC
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA04134 for ietf-xml-mime-bks; Wed, 20 Sep 2000 11:37:08 -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 LAA04130 for <ietf-xml-mime@imc.org>; Wed, 20 Sep 2000 11:37:07 -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 LAA20772 for <ietf-xml-mime@imc.org>; Wed, 20 Sep 2000 11:39:52 -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 OAA21457 for <ietf-xml-mime@imc.org>; Wed, 20 Sep 2000 14:39:51 -0400 (EDT)
Message-ID: <39C9069B.AC981E1D@canada.sun.com>
Date: Wed, 20 Sep 2000 14:48:59 -0400
From: Mark Baker <mark.baker@Canada.Sun.COM>
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: Conformance value of "+xml"?
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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>
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