Re: Call for consensus on UNLOCK Request-URI being lock root

You cannot create a new exclusive write lock rooted at the indirectly
locked resource, because that would violate the requirement that a
resource can only be locked by one exclusive lock.  So the issue being
discussed is just whether or not the refresh of the lock has to be
applied to the URL of the root of the lock, or whether it can be applied
to the URL of an indirectly locked resource and then be automatically
redirected by the server to the URL of the root of the lock.

Cheers,
Geoff

Elias wrote on 07/06/2004 11:45:04 AM:

> Jason Crawford wrote:
> On Monday, 07/05/2004 at 01:16 ZE2, Julian Reschke wrote:
> > The problem with this approach is that it makes little sense in a
> > specification. If we say that servers SHOULD allow refresh against
> > indirectly locked resources, it doesn't make sense to tell clients not
> > to use it. 

> I think it does make sense from the perspective of flexibility, and 
> we've done it before, but I don't have a strong preference.  My 
> stronger preference is that we move forward. 
> I agree with Jason: servers SHOULD allow refresh against indirectly 
> locked resources, thereby allowing for clients the option to refresh
> the lock on a single resource while letting the lock expire on other
> resources. Without supporting this, the client would have to unlock 
> and the lock the resource, thereby making it possible for another 
> client to lock the resource in the interim.