Replacing the Label header with a DAV:labeled-version report

Since this is a fairly significant change, I'd like to
hear from a few more folks before adding this to the 3253 Errata.

Thanks,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Saturday, April 27, 2002 5:09 AM
To: Clemm, Geoff; 'Deltav WG'
Subject: RE: Label header vs PROPFIND depth 1


> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, April 26, 2002 6:06 PM
> To: 'Deltav WG'
> Subject: 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?

Yes. But I think it's Tim's turn to say whether this would work for him or
not...

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

As stated before, I think that's not the single problem. Having GET return a
(representation of a) version rather than (a representation of) the VCR
makes the version *by definition* a variant (representation) of the VCR --
and it seems that most of us want to avoid that interpretation.

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

...and also use DAV:supported-live-property-set to discover the
DAV:label-name-set property.

Received on Sunday, 28 April 2002 09:54:21 UTC