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

So far, everyone has either agreed or remained silent on this topic,
so as a motivator for anyone objecting to speak up (:-), I will mark this
issue
as resolved in the errata, with the resolution being that the Label
header will be deprecated, and the DAV:labeled-version REPORT inserted
in its place.  In particular, I propose the following definition for
the DAV:labeled-version REPORT:

-------------------

8.3	DAV:labeled-version Report
The DAV:labeled-version report describes the requested properties
of the version with that label in a specified version history.
If the DAV:labeled-version report is applied to a version-controlled
resource, it is applied to the DAV:version-history of that
version-controlled resource.

Marshalling:

The request body MUST be a DAV:labeled-version XML element.

<!ELEMENT labeled-version ANY>

ANY value: a sequence of zero or more elements, with
at most one DAV:prop element and with exactly one
DAV:label-name element.

prop: see RFC 2518, Section 12.11

The response body for a successful request MUST be a DAV:multistatus
XML element.

multistatus: see RFC 2518, Section 12.9

The response body for a successful DAV:labeled-version REPORT
request MUST contain a DAV:response element for each resource
that satisfies the Depth header of the request.

8.3.1	Example - DAV:labeled-version Report

>>REQUEST

  REPORT /folder/ HTTP/1.1
  Host: www.webdav.org
  Content-Type: text/xml; charset="utf-8"
  Content-Length: xxxx 
  Depth: 1

  <?xml version="1.0" encoding="utf-8" ?>
  <D:labeled-version xmlns:D="DAV:">
    <D:label-name>tested</D:label-name>
    <D:prop>
      <D:version-name/>
      <D:version/>
    </D:prop>
  </D:labeled-version>

>>RESPONSE

  HTTP/1.1 207 Multi-Status
  Content-Type: text/xml; charset="utf-8"
  Content-Length: xxxx

  <?xml version="1.0" encoding="utf-8" ?>
  <D:multistatus xmlns:D="DAV:">
    <D:response>
      <D:href>http://www.webdav.org/folder/</D:href>
      <D:propstat>
        <D:prop>
          <D:version-name>V5</D:version-name>
          <D:creator-displayname>Fred</D:creator-displayname>
          <D:version>
            <D:href>http://repo.webdav.org/his/23/ver/V5</D:href>
          </D:version>
        </D:prop>
        <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
    </D:response>
    <D:response>
      <D:href>http://www.webdav.org/folder/foo.html</D:href>
      <D:propstat>
        <D:prop>
          <D:version-name>V8</D:version-name>
          <D:version>
            <D:href>http://repo.webdav.org/his/84/ver/V8</D:href>
          </D:version>
        </D:prop>
        <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
    </D:response>
  </D:multistatus>

-----------------------------------------

Cheers,
Geoff

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@Rational.Com]
Sent: Sunday, April 28, 2002 9:53 AM
To: 'Deltav WG'
Subject: 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 Friday, 28 June 2002 15:18:34 UTC