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

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 Sunday, 26 February 2006 19:47:40 UTC