(1) Specialized mime types
For each specialized applications of XML, we introduce a new subtype.
It may introduce more parameters and might even have some added
security consideration. This is the approach that has been assumed by
the authors of RFC2376.
And it is what is already happening. We've registered several dozen of
these already.
Pros:
Each application will be documented by some RFC.
This isn't true. The standards say that RFC documentation is only required for
registration in the IETF tree, and in practice none of the many registered
XML-based types have been backed up with RFCs.
Cons:
When the MIME parser does not know of such a subtype, the only
available fallback is text/plain or application/octet-stream. That
is, the MIME parser cannot invoke generic XML parsers/viewers, but has
to display the document as a plain text file or save the document in a
file.
This is a legitimate concern, although in practice what happens is that
applications let you assign a viewer to an unknown type in fairly flexible
ways. In other words, in practice this isn't all that much of a problem.
Each specialized application will require a new subtype registration,
which takes a lot of time and therefore can have long delays.
This isn't true. Registrations now routinely take only a few days if
they don't contain egregious errors. And we've been known to get them done
in less than a day in some cases.
Registrations containing errors take longer, of course. But feedback is quick,
typically taking only a day or two, so the burden is on the person doing the
registration to turn the thing around in a timely way.
(2) New top-level media type xml and its subtypes
Pros:
Fallback to "xml/plain" allows the use of generic XML parsers/viewers.
We can also lift the line termination rule of the top-level media type
"text".
Most XML objects have no business being registered under text anyhow, so this
isn't much of an advantage.
Cons:
It is extremely difficult to register a new top-level media type and
therefore can have long delays (practically, who wants to do this?).
The default behavior is probably not a good enough reason.
It isn't a question of difficulty, it is a question of legitimacy. To do
this you have to write a document that justifies the creation of such a thing.
Do so and you likely won't have much of a problem, fail to do so and
this approach isn't viable.
Each specialized application will require a new subtype registration,
which takes a lot of time and therefore can have long delays.
Again, this just isn't true.
(3) A new parameter "externalid" for text/xml and application/xml
This parameter specifies the externalID from the DOCTYPE of the XML
document (if the DOCTYPE is present). Examples would be:
Content-type: text/xml;
externalid="http://www.foo.com/whizzy.dtd";
or
Content-type: application/xml; charset="utf-16be";
externalid="-//IETF//DTD vCard v3.0//EN"
Pros:
This is probably the easiest solution which also provides XML-specific
fallback.
Requires no registration with a central authority.
Other parameters can be added in the future when we have new schemata
or when we find new usage patterns for DTDs. The definitions for those
parameters can define which sets of parameters can appear together.
Cons:
...
I'm afraid you've missed the biggest problem with this approach -- one
that makes it almost a complete nonstarter: The lack of ability to dispatch
on parameters in most applications that support MIME. Not only do applications
lack this ability, there are also quite a few contexts where MIME labelling
is used that don't support parameters, period. So in all these cases you
end up being reduced to a single dispatch path for everything that's based
on XML. As I say, its a total nonstarter.
(4) Yet another parameter "optinfo" or "ADD-PARAM"
This has all the problems of (3).
Ned