To make matters more concrete, here is a draft RFC.
Actually, I have found it a little hard to work out from the RFCs whether
the "xml." goes on the content type (left) or the subtype (right). I am
assuming that it goes on the right.
If registration trees go on the left, then my fallback suggestion is that
the XML RFC also allow subtyping of application/xml under some
registration authority. This accomplishes exactly the same thing, with
the same syntax.
Rick
-----<snip>
Network Working Group
Rick Jelliffe
Request for Comments: nnnn Academia Sinica Computing Centre
Obsoletes:
May 1999
Category: Internet Best Current Practices
MIME Registration Tree for XML
Status of this Memo
This draft provides information on a MIME registration tree for XML.
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Abstract
RFC 2048 [1] provides for the registration of Additional Registration
Tree (s2.1.5). This RFC specifies procedures and scope for a registration
tree for XML [3] documents to augment RFC nnn [4]
The proposed mechanism is an automated registration system for
XML-based MIME media types under an "xml." registration tree.
Table of Contents
...
1. Introduction
XML [] is a subset of SGML [] optimized for distributing
certain kinds of documents over the WWW. RFC nnn [] gives
the MIME Media Types which can be used for generic, browsable
XML documents: text/xml and application/xml.
A generic, browsable XML document contains enough markup inside
it for a generic XML browser to use that document: in particular
this means stylesheet information.
However, XML will also be used to create large numbers of
application-specific document types. Documents of these
types are XML, but they require specific MIME media types.
Because of the large numbers of these document types,
it is feared that they either will swamp the IETF registration
process or, more likely, that their creators will simply
not follow Best Internet Practise and create media types for
these types, willy nilly.
Furthermore, because RFC nnn [] exists, the registration of
an application-specific document type under the IETF tree will
not provide much, if any, additional information. It is
onerous to the registrees, time-wasting for IANA, and uninformative
for readers.
2. Registration Tree
The registration tree has the prefix "xml".
For example, the MIME media type for the "Question and
Answer Markup Language", QAML, would be text/xml.qaml
and application/xml.qaml.
All document types registered under the XML tree have both
text/xml.* adn application/xml.* media types. Any parameters defined in RFCs
for generic XML MIME media types [] also may be used.
If the document type describes some kind of literature,
for example from a word processor, the recommended
content type is text/xml.*
Otherwise the media type should be application/xml.*
In accordence with RFC 2046[] (s1), image/xml.*
and the other top-level content types should not be used.
2. Automated Registration
The XML registration tree is an automated process.
People or organizations seeking to register an application-specific
XML document under this tree submit, using an online form, a subset of the
information required by IANA for IETF-tree registration [1]: including
- registree name and contact details,
- the requested MIME content-type identifier,
- URL of the DTD or schema giving the document's structures and purpose,
- URI of the document's namespace,
- URL for user documentation of that document type.
The automated process checks if the media type has been registered. If
it is available, the media type is registered, and the requester notified
by email. If it is already allocated, the requester is instead notified
of the contact address of the person of organization who has already
registered that content-type; the requestor can then negotiate directly
with them.
3. Management
XML is a trademark of the World Wide Web Consortium (W3C).
Management of the XML registration tree is to be performed by
a person or organization (the "registrar") to be agreed by
IETF and W3C.
The registrar will make available lists of registered
types in the XML registration tree over Internet and to
IANA, W3C and ISO SC34.
There is no provision for handling different versions of
application-specific document types at the MIME level.
Versions must be signified inside the XML document, signified
by markup or by fixed attributes in the DTD; applications
should be designed to handle version variants gracefully.
4. Security Considerations
This RFC raises no security issues beyond those given in [],
as far as document types registered under the "xml." tree.
For security of the automation process, automatic registrations
should be periodically checked at the discretion of the
registrar. Bogus registrations should be removed, and the
registree notified. A bogus registration includes the registration
of a MIME type for document type which does not exist, or which
has not been adequately described by a DTD or other schema, or
which has been registered by some body for the purposes of hijacking
an established or new technology.
5. References
[1] Freed, N., Klensin, J., Postel, J.,
"Multipurpose Internet Mail Extensions (MIME) Part Four: Registration
Procedures"
RFC 2048, November 1996
[1] Freed, N., Borenstein, N.
"Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"
RFC 2046, November 1996
[2] Bray, et al "XML 1.0 Specification",...
[3] Whitehead, J., and Mutata, M., "MIME Media Types for XML",
RFC nnn, xxx, October 1998.
[4] IS 8879:1986 (ammended 1998) "Information Technology --
Standard Generalized Markup Language", ISO SC34
6. Author's Address
Rick Jelliffe
Computing Centre, Academia Sinica
P.O. Box 1-8, Nankang
Taipei 11529,
Taiwan, ROC
Phone: +8862-2-2789-9380
Fax: +8862-2-2783-6444
EMail: ricko(_at_)gate(_dot_)sinica(_dot_)edu(_dot_)tw