W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: Questions on the LABEL method

From: <Tim_Ellison@uk.ibm.com>
Date: Wed, 18 Oct 2000 08:59:10 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <8025697C.002BE2A9.00@d06mta07.portsmouth.uk.ibm.com>

Any thoughts about where the extended status information will go in a
MultiStatus response?
The response description seems a likely candidate.


"Geoffrey M. Clemm" <geoffrey.clemm@rational.com> on 2000-10-17 08:55:06 PM

Please respond to "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>

To:   ietf-dav-versioning@w3.org
Subject:  Re: Questions on the LABEL method

   From: "Vasta, John" <jvasta@rational.com>

   The Marshalling section of the LABEL method says:

   "The request MAY include a Depth header.  If it does include a Depth
   the response MUST be a 207 Multi-Status."

   Does this mean that a multistatus response would be returned even if
   were no errors? In RFC2518, the responses for recursive operations are
   specified this way; 207 is only returned if there are errors on a
   other than that denoted by the request URI. Shouldn't LABEL be
   with that behavior? (The same question applies to the SET-TARGET

That sounds sensible to me.  If nobody objects, I will change this to
say that "a 207 MUST be returned if a Depth header is specified and
the operation fails on the collection or any of its members".

   When executing a recursive label operation, must the server return an
   on any unlabelable resources it finds (e.g. unversioned resources), or
   it silently ignore them?

It should return an error (more work for a server, but better for
the client).

   The SET-TARGET method can be applied to a
   collection which is not a version selector; should the LABEL method work
   same way?

Yes, that was the intention.  I'll fix up the wording so that SET-TARGET
LABEL are described the same way.

   If the LABEL request URI refers to a checked-out version selector (and
   is no Target-Selector header), what should the response be? It appears
   the request should fail, since a checked-out version selector has no
   but what precondition violation should be reported?

Yes, it should fail.  I'll add this missing pre-condition
(I'll just re-use DAV:must-not-be-checked-out).

   DAV:must-be-version-or-version-selector doesn't seem right, since the
   request does refer to a version selector, and DAV:must-select-version
   seems to apply when a Target-Selector header is used.

I agree.

Received on Wednesday, 18 October 2000 04:01:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:45 UTC