1. Problem statement
We would like the MIME parser to be able to dispatch different sorts
of XML documents to different applications, such as specialized
programs that handle just one type of XML document. Because MIME
parsers do not look inside the MIME parts, identifiying the sort of
documents must be done in the MIME headers. However, neither text/xml
nor application/xml allow such information.
2. Possible solutions
Three approaches have been proposed. They are (1) specialized media
types such as text/calendar, (2) a top-level media type xml and its
subtypes such as xml/calendar, and (3) a new parameter "externalid" of
text/xml and applcation/xml.
You left out the obvious one: for some kinds of media, it is necessary
for the handler of the MIME media type to actually dispatch to one
of several possible media type handlers. Rather than fixing MIME,
which does the job of labelling data adequately, why not fix the software?
In general, you cannot solve the problem of "dispatch to the appropriate
handler" by modifying MIME, since finding the appropriate handler is
platform and installation dependent.
Some elements of this argument were taking place in a discussion with
the W3C HTML working group, which was considering registering
"text/xhtml" as a way of representing the XMLified version of HTML.
MIME types are also used in some instances in "content negotiation"
(prospectively telling a recipient what something would be if it
were to be subsequently retrieved), as well as in "content labelling".
New media types and media parameters don't help much with either,
unfortunately.
Many current implementations of content dispatch don't allow dispatch
based on media type parameters, in any case. E.g., you can't select
one handler for "text/plain;charset=us-ascii" and a different one
for "text/plain;charset=utf8", even though you might have a more
desirable ascii-only editor and a slower or fuller Unicode-based
editor installed. So adding more parameters doesn't really help
for content-dispatch with current implementations.
And adding more MIME types for each kind of combination of XML
seems like a recipe for disaster. If we have html, xhtml,
html-netscape, html-microsoft, html-optimized-for-msie-on-windows-nt50,
each with slightly different definitions, would they get separate
MIME types?
The same arguments apply for profiles of TIFF, and probably apply
to profiles of Postscript. Postscript-2-laserwriter-fonts isn't
a separate MIME type from Postscript-1, even though in situations,
you might have the capability of displaying one but only printing
the other.