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

From: Lisa Dusseault <[email-masked]>
Date: Thu, 11 May 2006 16:29:05 -0700

I'm really not at all sure we ever decided to do this.  Julian asked  
the WG on Feb 20 which way we should go on this, and nobody answered.

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 precondition change isn't consistent with precondition use  
for other cases, because a lock token was provided.

Lisa

On Feb 26, 2006, at 11:46 AM, Julian Reschke wrote:

> Cullen Jennings wrote:
> > ..
>> On minor issues, Julian will be proposing new text for bug 143.
>> ..
>
> ...did that. Summary in <http://lists.w3.org/Archives/Public/w3c- 
> dist-auth/2006JanMar/0670.html>, proposed text in <http:// 
> ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=143#c11>, and below:
>
> Section 9.10.2., para. 1:
> OLD:
>
>     A lock is refreshed by sending a LOCK request to the URL of a
>     resource within the scope of the lock.  This request MUST NOT  
> have a
>     body and it MUST specify which lock to refresh by using the 'Lock-
>     Token' header with a single lock token (only one lock may be
>     refreshed at a time).  It MAY contain a Timeout header, which a
>     server MAY accept to change the duration remaining on the lock  
> to the
>     new value.  A server MUST ignore the Depth header on a LOCK  
> refresh.
>
> NEW:
>
>     A lock is refreshed by sending a LOCK request to the URL of a
>     resource within the scope of the lock.  This request MUST NOT  
> have a
>     body and it MUST specify which lock to refresh by submitting the
>     corresponding lock token in the 'If' request header (see
>     Section 10.4).  It MAY contain a Timeout header, which a server  
> MAY
>     accept to change the duration remaining on the lock to the new  
> value.
>     A server MUST ignore the Depth header on a LOCK refresh.
>
>
> Section 9.10.2., para. 2:
> OLD:
>
>     If the resource has other (shared) locks, those locks are  
> unaffected
>     by a lock refresh.  Additionally, those locks do not prevent the
>     named lock from being refreshed.
>
> NEW:
>
>     If the resource has other (shared) locks, those locks are  
> unaffected
>     by a lock refresh.  Additionally, those locks do not prevent the
>     named locks from being refreshed.
>
>
> Section 9.10.2., para. 3:
> OLD:
>
>     Note that in [RFC2518], clients were indicated through the  
> example in
>     the text to use the If header to specify what lock to refresh  
> (rather
>     than the Lock-Token header).  Servers are encouraged to  
> continue to
>     support this as well as the Lock-Token header.
>
>     Note that the Lock-Token header is not returned in the response  
> for a
>     successful refresh LOCK request, but the LOCK response body MUST
>     contain the new value for the DAV:lockdiscovery body.
>
> NEW:
>
>     The response body MUST contain a DAV:lockdiscovery property with
>     'activelock' child elements indicating the current status of each
>     lock that was refreshed.
>
>
> Section 9.10.6., para. 6:
> OLD:
>
>     409 (Conflict), with 'lock-token-matches-request-uri' precondition
>     code - The LOCK request was made with a Lock-Token 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="..."
>
>
> Section 16., para. 14:
> OLD:
>
>     Purpose: (precondition) -- A request may include a Lock-Token  
> header
>        to identify a lock for the purposes of an operation such as
>        refresh LOCK or UNLOCK.  However, if the Request-URI does  
> not fall
>        within the scope of the lock identified by the token, the  
> server
>        SHOULD use this error.  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:
>
>     Purpose: (precondition) -- A request may include a Lock-Token  
> header
>        to identify a lock for the purposeof UNLOCK.  However, if the
>        Request-URI does not fall within the scope of the lock  
> identified
>        by the token, the server SHOULD use this error.  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.
>
>
> Appendix E., para. 14:
> OLD:
>
>     o  There is no implicit refresh of locks anymore.  Locks are only
>        refreshed upon explicit request.  Furthermore, the lock  
> token for
>        the lock to be refreshed is now specified in the Lock-Token
>        request header rather than the If header (see Section 9.10.2).
>
> NEW:
>
>     o  There is no implicit refresh of locks anymore.  Locks are only
>        refreshed upon explicit request (see Section 9.10.2).
>
>
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 May 2006 14:04:07 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 21 May 2006 22:18:47 +0200

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:

     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.

NEW: