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

Hi Paul,

I'm no MIME expert (compared to quite a few folks in the IETF,  
certainly), but it seems to me that that's outside the scope of what  
a Media type should be expected to do.

It sounds like your use case is more along the lines of CC/PP <http://>; i.e., publishing profiles of capabilities.  
Thinking out loud, 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://"

The alternative that you're putting forth, as I understand it, is to  
do something like:
   Content-Type: application/mathml_foo_symbol_set+xml

... with other media types for each other kind of symbol set. This  
approach has the disadvantage that a well-written generic mathml  
handler has to know about all of the media types for different  
versions of mathml, so it can catch their dispatch, and has to update  
the dispatch mechanism every time there's a new one.

If I understand you, you're saying that implementations that dispatch  
only on the media type and nothing else (not even content type  
parameters) constrain you, and force you to use media types for *all*  
dispatch. If so, that's a shame, but I think the proper thing to do  
is to fix those implementations (by providing more capable dispatch/ 
negotiation mechanisms), rather than devaluing the entire media type  

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.

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.


> As you probably know, the only way to negotiate inter-application  
> copy-and-paste or drag-and-drop are mime-types... so I have to be  
> sure that these are working for our purpose.
> One requirement I have on these mime-types is the necessity to  
> describe the set of mathematical symbols supported by the clients.  
> One such set is the MathML-content specification set of symbols.  
> But, typically, there are others:
> - for example if you go to some mathematical systems which have  
> traditionally different set of symbols (I think Maple needs some  
> classical symbols to be non-MathML-symbols).
> - for example if you go  to some places where  the input is highly  
> limited hence even supporting the whole MathML-content is too much.
> I even think these set of symbols should even be authorable.
> Enabling this to be declared at the negotiation allows source- 
> applications (or their authors) to respond to such limitations by  
> providing the necessary translators, if possible. Right now, I also  
> serve these clips by HTTP GETs and I dare say that a request for  
> text/xml can only be honoured in a completely arbitrary fashion...
> Are you saying that such set of symbols should not be declarable as  
> easy as a web-publication ? I tend to believe that my requirements  
> say the contrary...
> paul

Mark Nottingham

Received on Monday, 6 February 2006 22:25:59 UTC