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

From: Jason Crawford <[email-masked]>
Date: Mon, 5 Jul 2004 11:40:15 -0400

On Monday, 07/05/2004 at 01:16 ZE2, Julian Reschke wrote:
> Jason Crawford wrote:
> 
> > I'd relax the server side to accept refresh requests at any resource 
in
> > the scope of the lock.   Unless given a reason though, I'd still
> > encourage servers to send the refresh requests to the root of the 
lock.
> 
> I guess you mean "clients" in the second sentence.
Correct.

> 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. 

J.

---

From: Elias Sinderson <[email-masked]>
Date: Tue, 06 Jul 2004 08:45:04 -0700

Jason Crawford wrote:

> 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.

Cheers,
Elias

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 6 Jul 2004 12:09:18 -0400

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

> 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.

---

From: Elias Sinderson <[email-masked]>
Date: Tue, 06 Jul 2004 13:36:16 -0700

Geoffrey M Clemm wrote:

> [...] 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. 

Ah, thanks, I had indeed misunderstood the specific issue (while 
frantically trying to catch up on my email). So, in that case, I think I 
would still prefer option 1, given the evidence of current 
implementation behaviour. I'll try to read more carefully in the 
future...  ;-)

Cheers,
Elias