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

From: Lisa Dusseault <[email-masked]>
Date: Thu, 15 Jun 2006 11:32:00 -0700

By the way, I'd fix this bug in a heartbeat if I thought this would  
get us done.  The example is inconsistent, although the precondition  
is correct as is -- the problem is not that the lock token needed to  
be submitted (one was), the problem is that the lock token does not  
match the resource.

But rather than make just this one change to the document,  I'm  
waiting for somebody to help us make progress on other issues or  
somebody to agree that other issues are closed.  Jim, maybe if you're  
less swamped now you can review the state?

Lisa

On May 21, 2006, at 1:18 PM, Julian Reschke wrote:

> Lisa,
>
> thanks for the changes in draft 15. I still think that the  
> precondition now doesn't fit anymore (it's not the Lock-Token  
> header that was missing). Furthermore, the example is now  
> inconsistent with the spec. Suggested changes:
>
> Section 9.10.6., para. 6:
> OLD:
>
>     412 (Precondition Failed), with 'lock-token-matches-request-uri'
>     precondition code - The LOCK request was made with a If header,
>     indicating that the client wishes to refresh the given lock.
>     However, the Request-URI did not fall within the scope of the lock
>     identified by the token.  The lock may have a scope that does not
>     include the Request-URI, or the lock could have disappeared, or  
> the
>     token may be invalid.
>
> NEW:
>
>     412 (Precondition Failed), with 'lock-token-submitted'  
> precondition
>     code - The LOCK request was made with an If header, indicating  
> that
>     the client wishes to refresh the given lock.  However, the  
> Request-
>     URI did not fall within the scope of the lock identified by the
>     token.  The lock may have a scope that does not include the  
> Request-
>     URI, or the lock could have disappeared, or the token may be  
> invalid.
>
>
> Section 9.10.8., para. 2:
> OLD:
>
>       LOCK /workspace/webdav/proposal.doc HTTP/1.1
>       Host: example.com
>       Timeout: Infinite, Second-4100000000
>       Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
>       Authorization: Digest username="ejw",
>         realm="[email-masked]", nonce="...",
>         uri="/workspace/webdav/proposal.doc",
>         response="...", opaque="..."
>
> NEW:
>
>       LOCK /workspace/webdav/proposal.doc HTTP/1.1
>       Host: example.com
>       Timeout: Infinite, Second-4100000000
>       If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
>
>       Authorization: Digest username="ejw",
>         realm="[email-masked]", nonce="...",
>         uri="/workspace/webdav/proposal.doc",
>         response="...", opaque="..."

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jun 2006 20:53:55 +0200

Lisa,

thanks for following up.

> By the way, I'd fix this bug in a heartbeat if I thought this would get 
> us done.  The example is inconsistent, although the precondition is 
> correct as is -- the problem is not that the lock token needed to be 
> submitted (one was), the problem is that the lock token does not match 
> the resource.

I'm not sure what section you're referring to here. If lock refresh uses 
  the "If" header to specify the token of the lock to be refreshed, 
using a precondition code that refers to the "Lock-Token" request header 
simply is misleading.

> But rather than make just this one change to the document,  I'm waiting 
> for somebody to help us make progress on other issues or somebody to 
> agree that other issues are closed.  Jim, maybe if you're less swamped 
> now you can review the state?

Agreement. We need to get the process back on track. If I had the 
impression that work would be useful, I'd start to make suggestions for 
all open issues mentioned in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html>.

Best regards, Julian