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

Julian Reschke wrote:

> 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.

Ack, I meant to put an item on the agenda to discuss GULP - my bad, 
thanks for bringing this up. My recollection is that there seemed to be 
general consensus among the WG to include GULP as an appendix to 
2518bis, but I'd need to check the archives to be sure... At any rate, 
the information you posted will be relevant to todays telecon...


Thanks again,
Elias

> 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 17:10:39 UTC