Re: Questions on the LABEL method

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

Tim

"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
cc:
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
header,
   the response MUST be a 207 Multi-Status."

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

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
error
   on any unlabelable resources it finds (e.g. unversioned resources), or
can
   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
the
   same way?

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

   If the LABEL request URI refers to a checked-out version selector (and
there
   is no Target-Selector header), what should the response be? It appears
that
   the request should fail, since a checked-out version selector has no
target,
   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
only
   seems to apply when a Target-Selector header is used.

I agree.

Cheers,
Geoff

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