Re: Need an XBL media type

On Wed, 17 Jan 2007, Mark Baker wrote:
> On 1/12/07, Ian Hickson <ian@hixie.ch> wrote:
> > > >
> > > > What would the use cases be for a new MIME type that couldn't be 
> > > > handled by application/xml? (Consider in particular that XBL's 
> > > > processing model is defined in terms of handling any DOM, not in 
> > > > terms of handling HTTP payloads or similar.)
> > >
> > > Any use case which follows the findings of the authoritative 
> > > metadata finding with respect to using external metadata to 
> > > determine the semantics of the payload (i.e. no sniffing);
> > >
> > > http://www.w3.org/2001/tag/doc/mime-respect.html
> > 
> > But XBL already handles those cases with a generic XML MIME type --
> 
> But using a generic XML media type doesn't license a recipient to infer 
> XBL (or SVG or XHTML or any XML vocabulary) semantics.

Sure it does. application/xml is defined in RFC3023, which says:

#   An XML document labeled as text/xml or application/xml might contain
#   namespace declarations, stylesheet-linking processing instructions
#   (PIs), schema information, or other declarations that might be used
#   to suggest how the document is to be processed.  For example, a
#   document might have the XHTML namespace and a reference to a CSS
#   stylesheet.  Such a document might be handled by applications that
#   would use this information to dispatch the document for appropriate
#   processing.
 -- RFC 3023, section 3


> There's even a section in RFC 3023 which warns against this 
> interpretation.  I helped write it (blame Larry for its lameness though 
> 8-);
> 
>   An XML document labeled as text/xml or application/xml might contain
>   namespace declarations, stylesheet-linking processing instructions
>   (PIs), schema information, or other declarations that might be used
>   to suggest how the document is to be processed.  For example, a
>   document might have the XHTML namespace and a reference to a CSS
>   stylesheet.  Such a document might be handled by applications that
>   would use this information to dispatch the document for appropriate
>   processing.

Hm. We're using the same text to argue opposite positions. That's a bad 
sign. (I actually found and quoted the above text before reading your own 
quote of that text.)


> If you dispatch an XML document labelled as */xml (or any unknown 
> */*+xml type) to a processor based on namespaces, then that's sniffing 
> because it's using embedded metadata to infer contained document 
> semantics.  Even if it were licensed, which it isn't (although I agree 
> that some browsers agree on interpreting those documents that way[1]), 
> it's still sniffing, so there's still advantages (e.g. security) to 
> supporting an approach which doesn't require sniffing.

It's not sniffing. Sniffing is the process of using heuristics to 
determine data type, and has security implications because of differing 
implementations -- one UA interpreting the data in one way and another 
interpreting it in another, less secure, way (e.g. a browser thinking a 
document is a text file, passing it to its operating system, which then 
treats it as an executable).

Namespace dispatch is no more "sniffing" than Content-Type dispatch, and 
as far as I am aware, it has no more security implications. If you are 
aware of specific security problems, I would be very interested in hearing 
more about them.


> Another thing to keep in mind is that XML and XML namespaces are 
> independent specs, and one needn't author XML using namespaces.  In such 
> a case there is no option but to use media types specific to the 
> vocabulary (and an external-metadata supporting envelope, such as MIME 
> multipart).  Using namespaces shouldn't change that for the reasons 
> given in the TAG's authoritative metadata finding (regarding external 
> metadata).

While that may be generally true, it is not relevant to this case, since 
XBL processors are required to have namespace support.


So far your request has been primarily based on deferring to "best 
practices" documents and general principles. This would not be a problem, 
except that I disagree with your interpretation of those documents and do 
not think the principles are relevant to this particular scenario.

It would be helpful if you could elaborate on your request by explicitly
noting how it affects XBL directly, with concrete examples and use cases.

In the meantime I have marked your issue as a potential formal objection 
in the disposition of comments.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 17 January 2007 22:08:50 UTC