On Sat, 17 Nov 2001, MURATA Makoto wrote:
From: Ian Graham <igraham(_at_)ic-unix(_dot_)ic(_dot_)utoronto(_dot_)ca>
Subject: Re: [xml-dev] Registration status
Date: Thu, 15 Nov 2001 18:49:00 -0500 (EST)
Any thoughts?
It is not clear to me how your proposal solves problems
described in Appendix A (especially, A.5) of RFC 3023.
A.5 Why not use a MIME parameter to specify that a media type uses XML
syntax?
For example, one could use "Content-Type: application/iotp;
alternate-type=text/xml" or "Content-Type: application/iotp;
syntax=xml".
Section 5 of [RFC2045] says that "Parameters are modifiers of the
media subtype, and as such do not fundamentally affect the nature of
the content". However, all XML-based media types are by their nature
always XML. Parameters, as they have been defined in the MIME
architecture, are never invariant across all instantiations of a
media type.
More practically, very few if any MIME dispatchers and other MIME
agents support dispatching off of a parameter. While MIME agents on
the receiving side will need to be updated in either case to support
(or fall back to) generic XML processing, it has been suggested that
it is easier to implement this functionality when acting off of the
media type rather than a parameter. More important, sending agents
require no update to properly tag an image as "image/svg+xml", but
few if any sending agents currently support always tagging certain
content types with a parameter.
My thinking is that, if an application is XML aware, it can take take
advantage of namespace identifiers to obtain more detailed 'subtype' data
than a content-type header can provide. The rationale for expanding this
outside of the content-type header is that the header is too limited to
express much detail about the payload content -- and, as you quite rightly
note, the parameter extension mechanism is largely ignored.
Another issue would be multiply-typed data -- for example, an SVG document
containing MathML and XHTML. If an app is keying on the SVG content type,
then it may simply refuse to let me do anything with it, even if the
app can ignore the SVG but still display the rest.
However, I should note that a namespace identification mechanism can't
handle backward-compatibility, nor can it handle things like */dtd+xml, so
I would see a role for both.
The background questions, however, are these -- i) how can you reveal more
about the type of a MIME part, and ii) how useful would that information
really be.
I think some on these lists are struggling with these questions.
Best wishes --
Ian