Re: [xml-dev] Registration status

On Sat, 17 Nov 2001, MURATA Makoto wrote:

> From: Ian Graham <[email protected]>
> 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