On Jun 2, 2004, at 7:26 AM, Julian Reschke wrote:

> Jason Crawford wrote:
>> The old way of overloading If seems pretty lame.   Can't new clients 
>> do both?
> Agreed, but it works (if it ain't broke, don't fix it). Why are we 
> adding completely new requirements for both servers and clients with 
> the inevitable interoperability issues if the present protocol does 
> what it's supposed to do?

We have been conservative about changes in RFC2518bis, generally only 
changing things where interoperability testing shows that there is a 
problem.  In this case, confusion over where to put the lock token in 
refresh requests came up in actual implementations and early 
interoperability testing.  In addition, it was unclear what to do if 
multiple lock tokens appeared in the If header (the Lock-Token header 
allows only one).  IOW, the present protocol didn't quite do what it 
was supposed to do.

> IMHO the only thing we should say is that LOCK without a request body 
> *with* an If header will refresh all locks on the resource identified 
> by the request URI (possibly deprecating the use of the Time-Out 
> request header here -- I don't think there's a strong use case for 
> changing the timeout after the lock already exists; and as far as I 
> know existing servers do not support it anyway).

It doesn't really fit our shared lock model (such as it is) to refresh 
all locks on the resource.  Some may have been taken out by other 


Received on Wednesday, 2 June 2004 11:00:41 UTC