There are a number of situations where MIME types don't solve the
problem for "content negotiation" because the XML bodies that are
transferred will be compound objects that contain multiple kinds
of markup. In such situations, having a "top level" type other
than "application/xml" doesn't do any good, since there's no useful
way to use MIME to describe the combination of elements that are
contained within.
For example, if, as it seems, there will be XML body parts which
contain XHTML and, embedded within (not using multipart), contain
equations using the MathML and molecular diagrams using ChemML,
and some Dublin Core metadata using RDF, there is no useful
designation of the entire top level type that accurately describes
the content, or allows you to say that you accept XHTML,
MathML but don't accept ChemML.
For *these* kind of XML bodies where multiple applications are
intermixed, having new MIME types doesn't solve the problem.
In this situation, though adding additional MIME types doesn't solve
the problem, the media feature mechanisms *do* allow content negotiation
and are appropriate.
I want to distinguish between a "protocol" (rules of engagement)
and a "protocol element" (a string or data structure used within
one or more protocols).
CONNEG developed content negotiation *protocol elements* for
describing data, sender and recipient capabilities,
characteristics and preferences. Most of the work on different content
negotiation *protocols* has happened outside of the CONNEG working group,
since content negotiation is usually in the context of some other
communication protocol. HTTP and Internet Fax both have some kind of
"content negotiation". The Internet Fax mechanisms are, IMHO, the best
you can do for email. (Section 3 of RFC 2532 describes how a sender
may determine an email recipient's capabilities.) HTTP has both "accept"
requests, "Vary" responses, and some experimental protocols (Transparent
Content Negotiation and RVSA).
------
RFC 2506 Media Feature Tag Registration Procedure. March 1999.
(Also BCP0031) (Status: BEST CURRENT PRACTICE)
How to register features. The simplest thing to do would be
to define an "XML namespace" feature and a "XML DTD" feature,
whose values are the pointer to the XML namespace and DTD
respectively.
-------
RFC 2533 A Syntax for Describing Media Feature Sets. March 1999.
(Status: PROPOSED STANDARD)
How to combine a set of features into a feature set
--------
draft-ietf-conneg-feature-hash-01.txt: Identifying composite media features
April 1999.
How to use URLs or hashes to indentify complex sets of features
or feature profiles.
and, while you're at it (although only relevant to some XML
applications):
-------
RFC 2534 Media Features for Display, Print, and Fax. March 1999.
(Status: PROPOSED STANDARD)
This is as useful for HTML as it is for anything. In fact, it
was originally motivated by wanting to do better than the
"screen size" in the User Agent field.
------
RFC 2530 Indicating Supported Media Features Using Extensions to DSN and
MDN.March 1999. (Status: PROPOSED STANDARD)
This is a way of adding content negotiation to email.
------
RFC 2531 Content Feature Schema for Internet Fax. March 1999.
(Status: PROPOSED STANDARD)
The color space description protocol elements here are applicable to
any calibrated-color application, even though designed originally
for "fax".
------
Two proposals for content negotiation *protocols* in HTTP:
RFC 2295 Transparent Content Negotiation in HTTP. March 1998.
(Status: EXPERIMENTAL)
RFC 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0. March 1998.
(Status: EXPERIMENTAL)