OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] Registration status

From: Ian Graham <igraham@ic-unix.ic.utoronto.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.