Review solicited for application/cellml-1.0+xmlandapplication/cellml-1.1+xml

[Larry Masinter]

> > 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;
q=1

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.

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
what else to download; e.g., a HTML page which contains Javascript
code to detect the client's capabilities and figure out which other
URLs to load. 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.

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.

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's why it
might be useful advice to add to the guidelines for registering
MIME types, should those ever be updated.

(I think this situation is mainly my fault, fwiw, so: I'm sorry).

Larry