Re: Question about the On Linking Alternative Representations TAG Finding

Correct, that is why I carefully separated out user-agents that
send accept=*/* from other types of agents. When a user-agent
sends out an explicit list of mime-types that it will accept for
content negotiation I think the client and server should do full
content negotiation as was originally intended by HTTP's content
negotiation scheme.

John Kemp (Nokia-S&S/Williamstown) writes:
 > ext T.V Raman wrote:
 > 
 > [...]
 > 
 > > Returning to your final question, where the user-agent does
 > > content-negotiation, indicates a preference for one type, but
 > > asks by URI for the other, I would say respect the URI. I dont
 > > claim this to be *correct* in any sense, other than that I would
 > > break the tie this way. Reasoning: The client, by asking for a
 > > URI that directly resolves to a given representation has
 > > essentially bypassed content-negotiation.
 > 
 > I think your interpretation is OK. But other servers may wish to respect 
 > the HTTP Accept header sent in the request, rather than (or in addition 
 > to) parsing the URI. This is server-driven negotiation, and the server 
 > is attempting to meet the needs of its client. If the server feels 
 > unable to adequately determine what the client wants, it may return an 
 > HTTP 303 or 406 status code and allow the client to make a choice itself.
 > 
 > All of that is in the HTTP 1.1 specification. Anything other than HTTP 
 > would presumably define a similar mechanism.
 > 
 > I believe it makes sense to recommend that HTTP 1.1 content negotiation 
 > via the HTTP Accept: header is the preferred mechanism for "breaking the 
 > tie". If the user-agent can set the Accept header value to something 
 > more specific than */* then it is already likely capable of setting the 
 > _correct_ value for this header to get the content type it is asking for.
 > 
 > Regards,
 > 
 > - johnk

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Thursday, 7 August 2008 13:21:24 UTC