W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

GULP 5.7, was: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 14 Jun 2004 11:27:30 +0200
Message-ID: <40CD6F82.7090505@gmx.de>
To: w3c-dist-auth@w3.org
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>

Geoffrey M Clemm wrote:

> 
> I agree.

ok,

below the new version...:

-------------- GULP (Version 5.7) --------------

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



-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 14 June 2004 05:28:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT