To say something in Larry's defense, language negotiation in HTTP works reasonably well (Accept-Language). The list of languages that the average person reads is reasonably small, and most languages only take two (or sometimes three) letters to indicate, so all the information can be put in a header line. Quite a few sites use language negotiation, although there are many more that could use it but don't. It's always good to have a manual way to switch languages, but it's a hassle if the first page on a site is used just to allow a user to select the language if the browser tells the server what the preference is anyway. Most browsers come preconfigured with the Accept-Language set to the language of the browser (user interface) itself, and allow further configurations (adding other languages). Servers also got better, in Apache it was a pain to set up default languages, but now it works much better. For more information, please see the relevant topics at http://www.w3.org/International/resource-index.html#lang. There is also an IETF WG (LTRU) that works on extending the syntax for language tags to e.g. include scripts where necessary. Please check http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt (IESG approved, in RFC Editor queue) and http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt Regards, Martin. At 02:32 06/04/12, Larry Masinter wrote:
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