Review solicited for
ak.miller at auckland.ac.nz
Wed Apr 12 00:13:17 CEST 2006
Quoting Larry Masinter <LMM at acm.org>:
> > > GET /models/SomeModel.xml HTTP/1.1
> > > Host: www.example.org
> > > Accept: application/cellml-1.0+xml; q=0.5, application/cellml-1.1+xml;
> HTTP content negotiation was one of those "nice in theory" protocol
> additions that, in practice, didn't work out. The original theory of
> content negotiation was worked out when the idea of the web was that
> browsers would support a handful of media types (text, html, a couple
> of image types), and so it might be reasonable to send an
> 'accept:' header listing all of the types supported. But in
> practice as the web evolved, browsers would support hundreds of
> types of all varieties, and even automatically locate readers for
> content-types, so it wasn't practical to send an 'accept:' header
> for all of the types.
Although it is certainly a goal(towards which some progress has been made) of
the CellML project to enable CellML models to load in a browser so that they
can be viewed or run, many CellML tools also download files themselves.
Likewise, while CellML models are sometimes placed on static web-servers, they
are also commonly served by scripts. This combination makes HTTP content
negotiation more useful to CellML tools than it is, for example, to a
> So content negotiation in practice doesn't use accept: headers
> except in limited circumstances; for the most part, the sites send
> some kind of 'active content' or content that autoselects for itself
> code to detect the client's capabilities and figure out which other
> URLs to load.
The embedding of scripts in CellML is not recommended, not defined by any
specifications, not (as far as I know) supported by any software packages, and
if vendors do want to support scripts, they should only use it express
functions which cannot be represented in MathML, not for content negotiation.
Therefore, scripts are not a viable option for CellML negotiation.
> The most common kind of content negotiation uses
> the 'user agent' identification header, or some other 'x-...'
> extension headers to detect browser versions, among other things,
> to identify buggy implementations or proprietary extensions.
For HTML this is necessary because browsers accept more or less than what the
HTML specification allows. CellML is much simpler(although it is true that you
can express a wide variety of models in MathML, and tools will not support all
of them. However, CellML defines a 'core set' of MathML elements which all
tools must support). In terms of returning the correct version, however,
content-negotiation seems like a good solution.
> I think we should deprecate HTTP content negotiation, if only to
> make it clear to people reading the spec that it doesn't really
> work that way in practice.
I'm not sure that content-negotiation is non-useful. After all, HTTP is used for
a lot more than just serving HTML documents.
BTW I assume you are talking purely about Accept: and not Accept-Language:, as
Accept-Language: is widely used by multilingual sites to determine which
language to serve.
> Many people seem to use HTTP content negotiation as a motivation
> for adding 'version' parameters to MIME types or registering
> new MIME types, with the hopes that the MIME types or parameters
> would be useful in HTTP content negotiation, and we should warn
> them that it isn't really productive to do so.
That may be true for formats designed primarily to be viewed in web-browsers,
but I don't believe that it is true in general.
> That's why it
> might be useful advice to add to the guidelines for registering
> MIME types, should those ever be updated.
This message was sent using IMP, the Internet Messaging Program.
More information about the Ietf-types