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(_at_)dankohn(_dot_)com>
<http://www.dankohn.com> <tel:+1-650-327-2600>
-----Original Message-----
From: Mark Baker [mailto:mark(_dot_)baker(_at_)Canada(_dot_)Sun(_dot_)COM]
Sent: Wednesday, 2000-09-20 11:49
To: ietf-xml-mime(_at_)imc(_dot_)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(_at_)imc(_dot_)org".
MB