Re: registering formats in the web [uriMediaType-9] [Fwd: Request for MIME media type Application/Personal Tree - prs.]

Mark Nottingham wrote:
> It sounds like your use case is more along the lines of CC/PP 
> <http://www.w3.org/Mobile/CCPP/>; i.e., publishing profiles of 
> capabilities. Thinking out loud, 
That has such a taste indeed. thanks for the pointer!
Especially since we're trying to relay most transfer operations to an 
HTTP-request...

But the user-initiated-transfer APIs (copy-and-paste and drag-and-drop) 
I know of (mostly java) of are not aware of such standard and only allow 
MIME-types as standard ways to descibe things.

You seem to be guessing we would encounter lack of support of 
MIME-parameters ? Fortunately, we haven't met this yet...
> it could also be a media type parameter; that would be much more 
> appropriate, from a MIME perspective. E.g.,
>   Content-Type: application/mathml+xml; 
> symbol-set="http://www.example.com/foo-symbol-set/"
> The alternative that you're putting forth, as I understand it, is to 
> do something like:
>   Content-Type: application/mathml_foo_symbol_set+xml
Oh no... we are using media-types parameters! And are happy with them...
> [...] disadvantage that a well-written generic mathml handler has to 
> know about all of the media types for different versions of mathml, [...]
That's definitely true and a problem... in an HTTP negotiation, this 
seems almost impossible, indeed.

The idea of stressing importance of the cdgroup parameter (or 
symbol-set) is that we want to be able to:

- avoid client sniffing (which is, anyways, only present in HTTP 
negotiations and lacks in Copy-and-paste or drag-and-drop APIs)

- use the same negotiation and transfer methods for both tools that we 
have tuned, where extra authored symbols are supported, as well as 
generic tools for which a translation has to happen.
> Have you tried to register these symbol-set specific media types? I'd 
> imagine that doing so would run into some pushback; in particular, 
> section 4.1 of RFC 4288 says:
>>    Media types MUST function as an actual media format.  Registration of
>>    things that are better thought of as a transfer encoding, as a
>>    charset, or as a collection of separate entities of another type, is
>>    not allowed.  For example, although applications exist to decode the
>>    base64 transfer encoding [RFC2045], base64 cannot be registered as a
>>    media type.
No we haven't tried it and I don't think it's worth it.

thanks much for the feedback!

paul

> Content negotiation is tricky; some people have called conneg in HTTP 
> a failure (and indeed, there were many, many attempts at it). One of 
> the problems is that when you get more and more specific about the 
> capabilities and preferences of a device and/or service, you have to 
> be more and more verbose, and it becomes less and less likely that 
> you'll be able to come to an agreement, or use shared services like 
> caching. Media types weren't intended to allow such fine-grained 
> negotiation, and they lose a lot of their value when they're used in 
> that fashion.

Received on Tuesday, 7 February 2006 13:44:49 UTC