W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

RE: i69: Clarify "Requested Variant" [was: New "200 OK" status codes, PATCH & PROPFIND]

From: Brian Smith <brian@briansmith.org>
Date: Thu, 14 Feb 2008 12:39:26 -0800
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <006301c86f49$b13eae70$6501a8c0@T60>

Julian Reschke wrote:
> Brian Smith wrote:
> > If you don't want to define a new mechanism for editing specific 
> > representations, then why do you need to "select a representation 
> > before the response entity is generated"?
> Because I'd like "selected representation" to be independent 
> of request methods.

There is no such thing as a (client-)"selected representation" or a
(client-)"requested variant." There is only the "client-selected
resource" and the "server-selected variants." The client requests an
operation to be performed on a resource specified by the Request URI,
and the server selects one or more variants of that resource to operate
on. The server may or may not select variants based on the request
headers, and it may or may not use other criteria to select variants. It
does not need to indicate to the client which variants it selected. The
client cannot compel the server to select particular variants of a
resource to operate on.

If the client wants to operate on a particular representation of a
resource, then it should find a resource URI for that representation. A
client may discover this URI via the Content-Location header that the
server returned with that representation, or some other mechanism. If
so, then the client may attempt to operate on the representation as a
distinct resource by using that URI as the Request URI. Or, it might not
be able to find such a URI, in which case the client cannot operate on
the it distinctly from other representations of the same resource.

At least, the above is how HTTP currently works. And, that seems to be
how we want HTTP to move (everything that needs to be independently
addressable has its own URI). So, whatever special support PROPFIND
needs should be localized to the specification of PROPFIND. And, new
methods like PATCH need to be brought in line with the above model if
they aren't already. But, HTTP itself does not need to change, except to
clarify the above.

- Brian
Received on Thursday, 14 February 2008 20:39:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC