- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Mon, 22 Apr 2002 17:00:20 +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 4:51 PM > To: Deltav WG > Subject: RE: Label header vs PROPFIND depth 1 > > > > "Julian Reschke" <julian.reschke@greenbytes.de> wrote: > > > > No, the label: header does not apply to the members of the > > > collection, just > > > the request-URI resource. It behaves the same way as the > Depth: header > of > > > RFC2518, i.e. Depth: 1 only applies to the method at the request-URI > > > resource and not recursively to the members. > > > > Well, again I think that this is a major problem. It makes handling of > the > > "Label" header different from handling of other headers that selection > > variants of a resource. > > How is it different to the Depth: header? Ignoring the fact that Depth: 0 > and Depth: infinity degenerate into the 'right thing'. 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. > .. > > > So this is different from for instance handling of the "accept-language" > > header. Can you give a reason why this would be desirable? > > Rather than decide whether it should be different from the handling of a > "accept-*" header, we should agree on what is the most useful definition. Well, it should also be consistent with the handling of other headers, right? > Unless you are suggesting that this difference makes it > impossible/difficult to implement, and I don't think that it does. > > So, I think the reason it is the way it is, is so that the results of the > depth operation conform to the definition of multistatus, i.e. that the > results are related by collection membership. They are -- keep in mind that *I* am discussing the case where the target collection resource is *not* version-controlled. > "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.
Received on Monday, 22 April 2002 11:00:56 UTC