Re: Bug 143 (lock refresh), was: WGLC of draft-ietf-webdav-rfc2518bis-14.txt

Lisa Dusseault wrote:
> 
> I'm really not at all sure we ever decided to do this.  Julian asked the 

We didn't.

> WG on Feb 20 which way we should go on this, and nobody answered.

That's correct, and that makes me really worry about the amount of 
review this is getting. Again, this is an incompatible change both to 
clients and servers, and I just don't see anybody implementing it. Have 
you heard of a single implementor who did it?

> Even assuming that we agree to go back to using "if" header to refresh 
> locks, there are some problems with the changes proposed
>  - requires refreshing *multiple* locks with one request, which RFC2518 
> doesn't clearly require, so if we're reverting for the sake of 
> backward-compatibility, that's no good.

The proposed text is meant to document what servers do. Passing multiple 
lock tokens in a single If header for LOCK refresh is definitively an 
edge case. It can only occur for shared locks, and I just don't see a 
case where a single client would hold multiple shared locks on the same 
resource.

>  - the precondition change isn't consistent with precondition use for 
> other cases, because a lock token was provided.

Error handling IMHO should be the same as for any other method that 
requires submitting lock tokens, thus the same precondition. Now the 
definition of the precondition may have to be extended so that 
refreshing a lock is covered as well. Is this what you mean?

Best regards, Julian

Received on Friday, 12 May 2006 12:06:41 UTC