Subject: WGLC of draft-ietf-webdav-rfc2518bis-14.txt

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Feb 2006 07:42:18 -0800

I am absolutely thrilled to be able to Working Group Last Call (WGLC)
draft-ietf-webdav-rfc2518bis. The WGLC will end on March 15, 2006.

I am aware of one complex open issue with this version of the draft. The use
of ETAGs in the response to a HTTP PUT is not exactly clear in the HTTP spec
and this has implications for WebDAV. Some folks are working on a draft to
clarify this in HTTP. I'm sure this issue will be discussed during the Last
Call. 

On minor issues, Julian will be proposing new text for bug 143.

The "if header" section needs particularly careful review.

I would like to ask everyone to read this. We really need to get some fresh
eyes reading this document. Did we get it right? Is there enough detail that
you can implement it? Does this clarify previous interoperable problems?

Thank you,
Cullen

I'd like to take this moment to thank the several contributors that put in a
ton of work to make this happen and to all the folks on the mailing list
that put up with the roughly two thousand email posts from bugzilla. I
really hope the volume of these will be reducing.

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 23 Feb 2006 10:33:42 +0100

Congratulations to the working group!

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Feb 2006 20:46:25 +0100

Cullen Jennings wrote:
 > ..
> ..

...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