RE: Label header vs PROPFIND depth 1

Jim,

even of depth operations aren't supported, we still have several issues with
the LABEL header. In particular, allowing GET to act on the label makes the
version by *definition* a variant of the VCR. I didn't have the impression
that anybody is willing to support that design decision...

Julian

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Amsden
> Sent: Friday, May 03, 2002 3:56 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Label header vs PROPFIND depth 1
>
>
> I'd be happy with deprecating non-0 depth header. There are
> better ways to
> get related versions of resources. This would seem to solve the problem
> with minimal effect on the spec, and provide one-trip access to a
> specific
> version of a resource (for diff purposes, etc.).
>
>
>
>
> Geoff,
>
> - I'd like to see the label *header* deprecated
> - I'm happy with the LABEL method and the label-name-set property
> - I think that PROPFIND/label should be replaced by a specific REPORT
> - I'm unsure about other methods that are currently affected by the
> header -- what were the requirements...?
> - Servers that decide to implement LABEL and DAV:label-name-set, but no
> not
> support the label header should *not* report the LABEL feature in OPTIONS.
>
> Julian
>
> > -----Original Message-----
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> > Sent: Friday, April 26, 2002 4:54 PM
> > To: 'Deltav WG'
> > Subject: RE: Label header vs PROPFIND depth 1
> >
> >
> > I am not surprised the Label header is proving to be problematic.
> > The last time I tried to get rid of it (obviously unsuccessfully)
> > was about a year ago.
> >
> > My first choice would be to deprecate the Label header altogether, and
> > to instead define a DAV:labeled-version report on a VCR, whose
> > parameters were a label and a list of property names.  The result of
> > this report would be the values of the specified properties on the
> > version selected by the specified label from the VCR identified by the
> > request-URL.
> >
> > An alternative approach would be to deprecate the use of the Label
> > header with a non-zero Depth request (either because of an explicit
> > non-zero Depth header, or because a request is non-zero Depth by
> > default).
> >
> > I'd be interested in responses on the following three questions:
> >
> > (1) Do these approaches address the issues raised?
> > (2) Is there another approach that could be considered?
> > (3) Which approach do you prefer?
> >
> > If we can get consensus on an approach, I'll add it to the RFC 3253
> > Errata document.
> >
> > Cheers,
> > Geoff
> >
> >
>
>
>
>
>
>
>

Received on Friday, 3 May 2002 10:05:21 UTC