RE: Section 7.5, lock semantics

I agree that the scenario described in the 2nd paragraph can only occur when
it's a deep lock.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> Sent: Saturday, October 05, 2002 7:55 PM
> To: 'Webdav WG'
> Subject: Section 7.5, lock semantics
>
>
>
>
>
>
> In section 7.5 we read...
>
>   7.5 Write Locks and Collections
>
>    A write lock on a collection, whether created by a "Depth: 0" or
>    "Depth: infinity" lock request, prevents the addition or removal of
>    member URIs of the collection by non-lock owners.  As a consequence,
>    when a principal issues a PUT or POST request to create a new
>    resource under a URI which needs to be an internal member of a write
>    locked collection to maintain HTTP namespace consistency, or issues
>    a DELETE to remove a resource which has a URI which is an existing
>    internal member URI of a write locked collection, this request MUST
>    fail if the principal does not have a write lock on the collection.
>
>    However, if a write lock request is issued to a collection
>    containing member URIs identifying resources that are currently
>    locked in a manner which conflicts with the write lock, the request
>    MUST fail with a 423 (Locked) status code.
>
>    If a lock owner causes the URI of a resource to be added as an
>    internal member URI of a depth-infinity locked collection then the
>    new resource MUST be automatically added to the lock.  This is the
>    only mechanism that allows a resource to be added to a write lock.
>    Thus, for example, if the collection /a/b/ is write locked and the
>    resource /c is moved to /a/b/c then resource /a/b/c will be added to
>    the write lock.
>
> I think the second paragraph is only true if we're talking about a depth
> infinity lock.   The paragraph doesn't mention that though.
>
> Another set
> of eyes should  read this though and see if I'm just being dense...
>
> J.
>
> ------------------------------------------
> Phone: 914-784-7569
>

Received on Saturday, 5 October 2002 15:19:06 UTC