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

Mark,

On 25 Nov 2009, at 21:46, Mark Baker wrote:
> 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.

If you choose such a rather broad definition for agent-driven  
negotiation, then you surely must count the practice of sending  
different responses based on client IP or User-Agent header, both of  
which are common on the Web, as examples for server-driven conneg.

So server-driven conneg is actually quite common.

Best,
Richard



> 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 Thursday, 26 November 2009 00:05:24 UTC