- From: <ccjason@us.ibm.com>
- Date: Tue, 21 Sep 1999 17:27:02 -0400
- To: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>
- cc: w3c-dist-auth@w3.org
<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