Re: Question about the On Linking Alternative Representations TAG Finding

So to get in context, if a generic resource redirects to a variation with 
its own URL that will return a 200, hence an IR, one argues that conneg 
should still be possible from the IR to another IR related to the original 
generic resource?

I argue that one should only allow conneg within the new scope allowed by 
the IR, so that Conneg on /genericresource with accept: application/html+xml 
will redirect to /genericresource.html, but if requested as text/plain 
should fail. /genericresource.html should however be able to conneg on other 
variables such as the language and may redirect to /genericresource(en).html

In that definition there is no real generic resource, there is a chain of 
resources that are more and more specialized, reducing at each step the 
range you can conneg against.

Seb



--------------------------------------------------
From: "T.V Raman" <raman@google.com>
Sent: Thursday, August 07, 2008 2:20 PM
To: <john.kemp@nokia.com>
Cc: <raman@google.com>; <richard@cyganiak.de>; <seb@serialseb.com>; 
<www-tag@w3.org>; <kidehen@openlinksw.com>; <tthibodeau@openlinksw.com>
Subject: 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:40:19 UTC