RE: Label header vs PROPFIND depth 1

   From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

   - 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

Is the proposed DAV:labeled-version report OK with you?

   - I'm unsure about other methods that are currently affected by the
   header -- what were the requirements...?

The other methods are LABEL, CHECKOUT, GET, and COPY.  
For Depth:0 variants of these operations, the Label header
just provided an optimization to save one roundtrip
(i.e. first getting the version URL via the DAV:labeled-version report).
I believe we can easily do without that Depth:0 optimization.

For Depth:infinity (only relevant for LABEL and COPY), the savings
would be more significant, but unfortunately the semantics is broken
(since if the namespace is being versioned, you'll get the wrong
resources if you simply do a Depth operation on the current namespace).

The Depth:infinity Label header operations are really just a way of
trying to have the client fake workspaces and baselines, instead of
having the server support them directly.  Since it is much more
efficient and reliable to have the server layer these constructs
above a labeling infrastructure, rather than having the client do
so, I believe the cost of maintaining these Depth:infinity Label
header operations in the protocol is not warranted.

Note though that (depth:0) labeling and baselining go very well
together.  Instead of doing a Depth:infinity LABEL, you can create a
baseline (which under the hood the server may well implement with
reserved labels, but maybe not), and then LABEL that baseline.  Then
when you want to do a Depth:infinity COPY, you retrieve the
DAV:baseline-collection of the labeled baseline (using the
DAV:labeled-version report), and copy that to wherever you want.

Alternatively, if you want a "modifiable" selection, you can create a
workspace (which under the hood the server may well implement with
reserved labels, but maybe not).  When you want to adjust the versions
being selected, you just use UPDATE.  Then when you want to do a
Depth:infinity COPY, you just copy from that workspace to wherever you
want.

   - 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.

That's probably right.  A client can find out if the LABEL operation
is supported by querying the DAV:supported-method-set property values
of a VCR.

Cheers,
Geoff

   > From: Clemm, Geoff
   >
   > 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.

Received on Friday, 26 April 2002 12:06:34 UTC