RE: Label header vs PROPFIND depth 1

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Tim Ellison
> Sent: Wednesday, April 24, 2002 5:40 PM
> To: 'Deltav WG'
> Subject: RE: Label header vs PROPFIND depth 1
>
>
> Julian wrote:
>
> > My position is that if you don't consider the version selected by
> > the LABEL header to be a variant (representation) of the VCR,
>
> which, as I stated, I don't.
>
> > then it MUST NOT be returned by a GET on the VCR URI.
>
> I assume this is because of the definition of GET, and not ...
>
> > RFC2616, section 1.3:
> >
> > variant
> >
> > A resource may have one, or more than one, representation(s)
> > associated with it at any given instant. Each of these
> > representations is termed a `varriant'. Use of the term
> > `variant' does not necessarily imply that the resource is
> > subject to content negotiation.
>
> This definition is fine for a variant -- and has nothing to do with the
> situation we are discussing, which is two different resources (a
> version-controlled resource and a version resource).

No, it isn't.

We are doing a GET against a single URI. GET never returns resources, it
returns *representations* (== variants) of resources. If you don't specify
the Label header, you get a representation (variant) of the VCR. If you do,
you get a representation (variant) of the version. This -- by definition --
makes the version a representation (variant) of the VCR.

If you don't like that, don't allow GET on the VCR URI to return it.

> This is the definition of the vary: header (RFC2616 section 14.44):
>
> "The Vary field value indicates the set of request-header fields
> that fully
> determines, while the response is fresh, whether a cache is
> permitted to use
> the response to reply to a subsequent request without revalidation. For
> uncacheable or stale responses, the Vary field value advises the
> user agent
> about the criteria that were used to select the representation. A
> Vary field
> value of "*" implies that a cache cannot determine from the
> request headers
> of a subsequent request whether this response is the appropriate
> representation. See section 13.6 for use of the Vary header field
> by caches.
>
>        Vary  = "Vary" ":" ( "*" | 1#field-name )"
>
>
> It is therefore reasonable to include 'label' in the vary header
> to indicate
> that a cache should consider the value of the label header when
> determining
> the correct response.  Indeed, from the same section:
>
> "The field-names given are not limited to the set of standard
> request-header
> fields defined by this specification."
>
> I cannot see anything that says a 'variant' is defined by the
> 'vary' header.

It doesn't *need* to say that.

GET returns representations (== variants) of resources. By making GET on the
*same* URI returning the VCR in one case and a version in another case, you
*make* the version a variant of the VCR.

Received on Wednesday, 24 April 2002 15:22:35 UTC