- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 22 Apr 2002 10:36:07 -0400
- To: Deltav WG <ietf-dav-versioning@w3.org>
From: Julian Reschke [mailto:julian.reschke@greenbytes.de] given a collection "/a" and a VCR "/a/b", where "/a/b" has a version "/versions/b/1" with a label "labeltest", what would I expect from a PROPFIND /a Depth: 1 Label: labeltest ? A PROPFIND request applied to a collection with a Depth header is applied to the collection every member of the collection that satisfies that Depth header. So it is applied to /a and /a/b. Assuming /a is not version-controlled, then the effect of the Label header is undefined, so your implementation could just ignore the Label header and return the properties of /a, or it could indicate that it is an error for /a. Since /a/b is version-controlled, the effect is defined by section 8.6, and you would return the properties of the version labeled "labeltest". According to section 8, the label header should only be applied when the request URL is a VCR (which isn't the case here). Section 8 just gives you the *additional* semantics for PROPFIND when a Label header is present. It doesn't change anything about the existing semantics of PROPFIND, i.e. that any header in the request is applied to each of the nested applications of PROPFIND. However, a PROPFIND /a/b Depth: 0 Label: labeltest *would* take the label header into account. A PROPFIND always takes all of its headers into account when it is applied to each of the members that it applies to. This would make the PROPFIND results for /a/b depend on which is the request URL for the PROPFIND, which definitively doesn't seem to be desirable. (A similar problem applies to COPY with depth > 0). Similar answer for COPY ... COPY has all of its normal semantics when the Label header is present, i.e. all headers are applied to each of the "nested" copies that result from a Depth copy. So, bottom line is, it does what you want (:-). Cheers, Geoff
Received on Monday, 22 April 2002 10:36:48 UTC