One alternative - not necessarily one I am advocating, but just
listing for
completeness - is to use a similar approach but swapped round:
image/svg;ContentLanguage=xml
I favor something like this. it seems like it will interact more
cleanly with content negotiation mechanisms (as opposed to those
mechanisms having to acquire new pattern-matching facilities)
it's true that as MIME is architected the parameter space is on a
per-content-type basis. but I don't see any great harm if we define
some global parameter name space (say, parameter names that begin
with "$" are global). Then we could do something like:
content-type: image/svg; $superclass="application/xml"
ned - i agree with your take that having global parameters is a major change
to MIME.
suppose we were just to have something like:
Content-type: image/svg; representation="xml"
where "representation" is just a plain old MIME parameter.
would you object to something along these lines?
Yes. Most of the problems I have with global parameter still apply to this
usage.
If we absolutely have to do this with a separate piece of information, I would
opt for a content-feature tag. That way there's a clear delineation between
when feature information is or is not present, and we don't mess up MIME
parameter space. And we need the feature tag anyway for negotiation purposes.
I still strongly prefer the suffix, however.
Ned