Re: RDF Update Feeds + URI time travel on HTTP-level

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