RE: Label header vs PROPFIND depth 1

"Julian Reschke" <julian.reschke@greenbytes.de>

> I think it breaks a very basic assumption about PROPFIND's depth
handling:
> for a given collection member, you will get the same response element for
> depth:1 on it's parent and depth:0 for a PROPFIND on itself.

Wait, maybe I didn't make it clear.  The label: header applies to the
version-controlled resource identified by the request-URL; and then the
depth operation proceeds on the labelled *version*.  The only version with
members is a versioned collection, whose members are version histories.

> What's the motivation for this change? Currently I can't think of a
reason,
> and it certainly makes it harder to come up for consistent variant
handling
> in WebDAV.

It is a short-hand for referencing the version associated with a
version-controlled resource.

Regards,
Tim


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Tim Ellison
> Sent: Monday, April 22, 2002 2:49 PM
> To: Deltav WG
> Subject: Re: Label header vs PROPFIND depth 1
>
>
>
> "Julian Reschke" <julian.reschke@greenbytes.de> wrote:
>
> > 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
> >
> > ?
> >
> > According to section 8, the label header should only be applied when
the
> > request URL is a VCR (which isn't the case here). However, a
> >
> > PROPFIND /a/b
> > Depth: 0
> > Label: labeltest
> >
> > *would* take the label header into account.
> >
> > 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).
>
> Your interpretation is correct.  The label: header is only applied to the
> request-URL.  Why is this undesirable?
>
> Regards,
> Tim
>
>

Received on Monday, 22 April 2002 09:09:58 UTC