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

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="ejw@example.com", 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="ejw@example.com", 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

Received on Thursday, 11 May 2006 23:29:15 UTC