- From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
- Date: Thu, 2 Sep 1999 21:44:23 -0400
- To: w3c-dist-auth@w3.org
From: ccjason@us.ibm.com <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. <gmc> Since the server needs to deal with this in case the client just neglects to remove the lock, and if having another client MOVE your locked resource is a rare occurrence (which I believe it is), then this does not seem to be especially problematical. Cheers, Geoff
Received on Thursday, 2 September 1999 21:44:25 UTC