W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2002

Section 7.5, lock semantics

From: Jason Crawford <ccjason@us.ibm.com>
Date: Sat, 5 Oct 2002 13:55:14 -0400
To: "'Webdav WG'" <nnw3c-dist-auth___at___w3c.org@smallcue.com>
Cc:
Message-ID: <OF80951127.0A3184AF-ON85256C49.00620EA0@us.ibm.com>




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 14:46:39 GMT

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