- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Mon, 22 Apr 2002 17:24:58 +0200
- To: "Tim Ellison" <Tim_Ellison@uk.ibm.com>, "Deltav WG" <ietf-dav-versioning@w3.org>
> From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Tim Ellison > Sent: Monday, April 22, 2002 5:16 PM > To: Deltav WG > Subject: RE: Label header vs PROPFIND depth 1 > > > > > The semantics of the depth header is explicitly defined for PROPFIND. So > you > > can think of it as a parameter to PROPFIND. Headers that select variants > > simply are different. > > The label: header causes the method to be applied to the version -- a > version is not a variant of a version-controlled resource, that is, a > version is not another representation of the version-controlled resource, > it is a whole new resource. In absence of the LABEL header feature I would agree. However, the label header exactly does what HTTP 1.1 defines a selecting a variant. So if you use it to get a version rather than a VCR, you *make* the version a variant of the VCR (like it or not). > > > "the multistatus XML element for a collection resource with > member URIs > > > MUST include a response XML element for each member URI of the > collection, > > > to whatever depth was requested" > > > > > > If the label: applied to each member of the version-controlled > collection, > > > then the results would be a set of versions that were not related by > > > membership. > > > > No, the result isn't a set of versions anyway. It is a set of *variants* > of > > the member VCRs. You will not see the version URIs in the response body. > > What do you mean by the _variants_ of a version-controlled resource? My > understanding is that a variant is an alternate representation of a > resource, and that is not the case here. Yes, it is. The label header is a variant selector as defined per RFC2616. If this wouldn't be the case, including "label" in the "vary" header would be wrong.
Received on Monday, 22 April 2002 11:25:53 UTC