- From: Mark Baker <distobj@acm.org>
- Date: Wed, 25 Nov 2009 16:46:27 -0500
- To: Michael Nelson <mln@cs.odu.edu>
- Cc: Herbert Van de Sompel <hvdsomp@gmail.com>, Linked Data community <public-lod@w3.org>, Robert Sanderson <azaroth42@gmail.com>
Michael, On Wed, Nov 25, 2009 at 1:07 AM, Michael Nelson <mln@cs.odu.edu> wrote: > What you describe is really close to what RFC 2616 calls "Agent-driven > Negotiation", which is how CN exists in the absence of "Accept-*" request > headers. That's correct. > But the "TCN: Choice" approach is introduced as an optimization. The idea > is that if you know you prefer .en, .pdf and .gz then tell the server when > making your original request and it will do its best to honor those > requests. > > We think adding an orthogonal dimension for CN will be similar: if you know > you prefer .en, .pdf, .gz and .20091031, then tell the server when making > your original request and it will do its best to honor those requests. I understand. > In practice, agent-driven CN is rarely done (I can only guess as to why). In > practice, you get either server-driven (as defined in RFC 2616) or > transparent CN (introduced in RFC 2616 (well, RFC 2068 actually), but really > defined in RFCs 2295 & 2296). See: > http://httpd.apache.org/docs/2.3/content-negotiation.html I disagree. I would say that agent-driven negotiation is by far the most common form of conneg in use today. Only it's not done through standardized means such as the Alternates header, but instead via language and format specific links embedded in HTML, e.g. "Click here for the PDF version", or a "Language/country-selector dropdown" in the page header, or even via Javascript based selection. Server driven conneg, in comparison, is effectively unused. Ditto for transparent negotiation. > So while I think you are describing agent-driven CN (or something very > similar), I also think it would be desirable to go ahead and get the full > monty and define the appropriate Accept header and allow server-driven & > transparent CN. Agent-driven CN is still available for clients that wish to > do so. I just don't understand the desire for server driven conneg when agent driven is the clear winner and has so many advantages; - not needing to use the inconsistently-implemented Vary header, so there's no risk of cache pollution. see http://www.mnot.net/blog/2007/06/20/proxy_caching#comment-2989 - more visible to search engines - simpler for developers, as it's just links returned by the server like the rest of their app. no need for new server side modules either You might also be interested to read this, where one of the RFC 2616 editors apologizes for supporting server driven conneg; http://www.alvestrand.no/pipermail/ietf-types/2006-April/001707.html Note that he refers to HTTP conneg being broken, but is actually only talking about server driven conneg. I think that makes for a pretty strong case against it, and I haven't even elaborated on the architectural problems I perceive with it (though some of the advantages above relate closely). Mark.
Received on Wednesday, 25 November 2009 21:47:00 UTC