- From: <ccjason@us.ibm.com>
- Date: Thu, 2 Sep 1999 17:50:41 -0400
- To: undisclosed-recipients:;
<JS> This discussion began with Yaron's comment that saying that "it MUST NOT be possible for a principal other than the lock owner to make a locked resource inaccessible via the URI mapping used to lock the resource" is too strong. It may make sense for write locks as defined in RFC 2518, but may not make sense for other sorts of locks that don't restrict MOVE and DELETE. </JS> I believe that this is not specific to any particular type of locks. All clients need to insure that they have at the very least a way to unlock the the locks they have created. I assume that to unlock (a resource), we have to provide a URI of a (the?) resource locked by that lock... so if someone else changes the URI, it's very likely that we're not going to be able to figure out what the new URI is... and will have to leave the lock around until it times out.
Received on Thursday, 2 September 1999 17:42:45 UTC