Now, all we need to do is upgrade the entire installed
based of Internet-connected machines that understand MIME, and I'll
agree that a MIME registration for backward compatibility is no longer
necessary.
having to upgrade that installed base is exactly the problem with
the xxx+xml proposals. If XML is served as text or application/xml
then you do get a reasonable default behaviour (for example your mail
agent might ship all such files to internet explorer for display.
IE has a reasonable default presentation of XML and its default
stylesheet could easily include special cases for things like svg and
xhtml (and until then the document can specify a specific stylesheet).
That may be your opinion. My experience has been otherwise.
But if your mail agent comes across an xxx+xml document and it doesn't
know this type, basically it's stumped. It won't even (currently) by
default do the "obvious" thing of dropping the xxx+ and trying the more
general xml mime type.
Hardly. Adding an entry for a new type is one of the things most agents allow,
and generally handle pretty well.
And some agents even support wildcarding that will allow */*+xml to be
redirected. (I'm actuaally not in favor of this. I'd rather have a new type
bring up a dialogue that lets me pick the app I want to use.)
This of course, is all IMHO, as RFC 3023 explicitly supports you serving
all XML as application/xml if you really want to. But as A.15 mentions,
there are no apparent downsides from using custom types and several
advantages.
but A.15 (which I have re-read) is about the benefits of using a +xml
suffix as opposed to not. I agree, if there is to be a mime type for
mathml then it may as well be text/mathml+xml rather than just text/mathml.
I don't think there is any argument with that. But until mime agents are
upgraded to _automatically_ fall back to text/xml if they receive a
text/mathml+xml document and they don't know that mime type, then
anyone serving mathml files would be well advised to serve them as
text/xml as they will have a much wider chance of being processed.
Incidentally it seems to be widely held belief that text/xml was a
mistake and that xml ought almost always be in application/xml. I don't
really hold that view. For decades TeX users have sent tex markup as
plain text emails and been more or less happy. I don't see
(document-oriented) XML as significantly different. If someone sends me
some email with some mathematics in, and I'm sat at a machine without a
mathml renderer, I'd much rather just see the mathml markup inline
(which can be read, in small doses, honestly:-) than just be offered a
file/save option on the grounds that the lovingly constructed mathematics
is just unreadable application specific data.
Speaking as someone who spent years and years doing technical support for
a math department, I have to say that your experience with users is
the exact opposite of mine in all of this.
Ned