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