content-type: image/svg; $superclass="application/xml"
First of all, this approach was discussed when MIME was first designed and
was roundly rejected at that time. At the time I was actually in favor of
doing this, but I've since decided that the people who were opposed to
it were right.
I don't recall this part of those discussions.
Second, the definition of a global parameter namespace is far from the worst
thing about this. The biggest problem this approach has is that now you have
what amounts to a mandatory parameter, one which has to appear with every
appearance of a given media type and must have a specific value in those
cases.
actually, I don't view the parameter as mandatory; I view it as advisory.
The right way to handle this is to treat it as an image/svg. Depending
on how you look at it, the information in the $superclass parameter is
either a fallback way to handle the type if you don't know how to handle
image/svg, or additional information that can be used by generic "index
everything that is XML" processors.
This is completely contrary to the entire intent of the parameter
space: Parameters were intended to convey information that isn't
invariant with the media type.
it's true that parameters were intended to convey type-specific information,
but I don't see the harm in defining another set of parameters (disjoint
from the type-specific parameters), which convey other information about
the media type.
Third, this introduces the possibility of silly states in a major way.
As far as I can tell, parameters already have tremendous potential for
silly states - nothing stops you from adding any parameter to any media
type (so you can for example have a charset parameter on an image).
But in practice, and despite widespread misuse of certain parameter
names with content-types that don't define those parameters, it doesn't
seem to cause big problems. Unrecognized parameters are generally
ignored.
Fourth, the infrastructure upgrades to handle this are far nastier
than you seem to think, and have to happen at both the sending and receiving
end.
I guess the question in my mind is whether those upgrades affect every
MIME handling agent or whether (for the time being) they only affect
things that care specifically about XML. The latter set seems a lot
smaller than the former set, and I'm less worried about the impact of
this on XML-aware agents (which after are in an emerging space anyway)
than I am worried about the impact of -xml frobs on things that need
to do content-negotiation (which includes every HTTP client and server).
Fifth, as I said before, this doesn't work with places where only media
types and not parameters are carried. Such places do exist and fixing
them all is going to be nearly impossible.
Since I see this parameter as advisory, to me it doesn't matter much.
Applications for which the advisory parameter is of sufficient utility
will get fixed to interpret or generate that parameter; those that don't
benefit sufficiently will not get fixed.
To put it another way, if it's absolutely important that every instance
of image/svg be externally labelled as XML then I'd agree with you.
But I don't see this as absolutely important.
In summary, what this amounts to is nothing less that a complete redesign of
how MIME works.
"complete redesign" seems a bit overstated. It is a slightly different
way of using parameters than originally envisioned. But it doesn't
interfere with the existing parameter space.
And while I understand that many implementations don't have the ability
to generate or the ability to interpret content-type parameters, I don't
see how this breaks anything that works now. by contrast, the -xml frob
coupled with the desire for content-negotiation languages (http accept
and conneg) to recognize anything that is XML does break things.
I'm just trying to minimize breakage.
a concrete example of something that this breaks would be helpful
in getting me to understand your concerns.
Keith