RE: LOCK NULL reserves what?

  <yg>
 To quote from section 7.5:

   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.

  Hence if a/b is WRITE locked then a singleton WRITE lock on a/ will fail
  because the WRITE lock on a/b, as specified in section 7.1, reserves the
  write for DELETE.
  </yg>

I take it you mean the "right to delete" rather than "write for DELETE".
If not perhaps you can explain your phrasing.

Also 7.1 of RFC 2518 doesn't talk about rights that the lock gives you,
only what it prevents other folks from doing.

  <yg>
  In other words:

  1. a/b is WRITE locked and thus has exclusive use of DELETE
  2. The depth: 0 WRITE lock on a/ reserves the write to DELETE on a/ and its
  immediate children.
  3. Since a/b is WRITE locked the WRITE lock depth:0 request on a/ MUST fail.
  </yg>

1. Hmm. Since I guess I asked for original intent, I guess this is fine, but my
reading of the spec is that it doesn't give rights as much as it blocks other
people's rights.  If it's write locked, you have to hold the lock to modify it.
If it's exclusively locked, noone else can get a write lock on it.
  BTW, I take it you mean that the write lock on a/b gives the holder the right
to delete a/b.  Although believable, that's interesting, because deletion has
been thought to be an operation on the parent collection.  And because this is
the only case (except for URI protection) where a lock would lock a specific
part of a collection.  I do think this is valuable though.

2. Once again, I miss the part where the spec says a lock reserves a right...
other than to block another principle.  This might be implicit in the spec
though.  Of course, I asked intent, not what the spec says.

2. Also, Does a lock on a/ reserver the right to DELETE a/?  We have been saying
that locking a/ only controls the membership of a/ and doesn't apply to deleting
a/ itself.  If what you say was the intent, I think something has changed since
this was originally conceived.

3. Interesting. Thanks.  This definitely deserves discussion.


BTW, the reason I make the distinction between a write lock giving one the right
to modify a resource and a lock simply blocking others is because of URI
protection.  (You also provided a potential example.)   I had assumed that if a
resource deep in a tree was locked and therefore the URI was protected,  another
principle would still be allowed to write lock an ancestor collection.  But that
that write lock wouldn't give the second principle the right to break the
protected URI.

    /a/b/c

If /a/b/c is locked and the /a/b/c URI is protected...  I assume someone else
(person S) can write lock /a/.  And I assume that the write lock on /a/ doesn't
actually give person S the right to delete /a/b because that binding is
protected by the lock at /a/b/c which he doesn't hold.  But it does give person
S the right to prevent someone else from deleting /a/b.

This does of course beg the question of the effect of obtaining these locks in
reverse order.  This might be contrary to our expectations.  I don't think of
this as a problem with protection as much as a problem with our definitions of
write lock... or more importantly, our lack of any other type of lock.

J.

Received on Tuesday, 21 September 1999 17:27:14 UTC