GULP (Lock Semantics), was: Agenda for 12/6 telecon

Hi,

as we're going to concentrate on locking issues, I'd like to remind 
everybody that the WG did compile a very short (but complete) summary of 
high-level locking semantics a long time ago. RFC2518bis will need to 
reflect the contents of this document in some way, potentially by just 
adopting it and making it an appendix.

Including the latest version 5.8 from 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0177.html>:

-------------- GULP (Version 5.8) --------------

- A lock either directly or indirectly locks a resource.

- A LOCK request with a non-empty body creates a new lock, and the
   resource identified by the request-URL is directly locked by that lock.
    The "lock-root" of the new lock is the request-URL. If at the time of
    the request, the request-URL is not mapped to a resource, a new
    resource with empty content MUST be created by the request.

- If a collection is directly locked by a depth:infinity lock, all
    members of that collection (other than the collection itself) are
    indirectly locked by that lock.  In particular, if an internal
    member resource is added to a collection that is locked by a
    depth:infinity lock, and if the resource is not locked by that lock,
    then the resource becomes indirectly locked by that lock.
    Conversely, if a resource is indirectly locked with a depth:infinity
    lock, and if the result of deleting an internal member URI is that
    the resource is no longer a member of the collection that is
    directly locked by that lock, then the resource is no longer locked
    by that lock.

- An UNLOCK request deletes the lock with the specified lock token.
    The request-URL of the request MUST identify a resource that
    is either directly or indirectly locked by that lock.
    After a lock is deleted, no resource is locked by that lock.

- A lock token is "submitted" in a request when it appears in an If
    header.

- If a request would modify the content for a locked resource, a dead
    property of a locked resource, a live property that is defined to be
    lockable for a locked resource, or an internal member URI of a
    locked collection, the request MUST fail unless the lock-token for
    that lock is submitted in the request.  An internal member URI
    of a collection is considered to be modified if it is added,
    removed, or identifies a different resource.

- If a request causes a directly locked resource to no longer be
    mapped to the lock-root of that lock, then the request MUST
    fail unless the lock-token for that lock is submitted in the
    request.  If the request succeeds, then that lock MUST have been
    deleted by that request.

- If a request would cause a resource to be locked by two different
    exclusive locks, the request MUST fail.

Best regards, Julian

Received on Wednesday, 7 December 2005 07:37:32 UTC