[Bug 29] refreshing locks

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=29

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|-06                         |-07



------- Additional Comments From julian.reschke@greenbytes.de  2005-10-03 05:02 -------
Update -07, spec now says
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.8.11.1.p.1>):

"A lock is refreshed by sending a LOCK request without a body to a resource
within the scope of the lock. A LOCK request to refresh a lock 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). This request MUST NOT contain a
body, but it may contain a Timeout header. A server MAY accept the Timeout
header to change the duration remaining on the lock to the new value. A server
MUST ignore the Depth header on a LOCK refresh, and the client SHOULD NOT send
the Depth header on a LOCK refresh as the server will not convert the lock or
confirm the depth."

This can be stated much simpler; also the new client requirement on the Depth
header is new and unnecessary.

Just state:

"A lock is refreshed by sending a LOCK request without a request body to the URL
of a resource within the scope of the lock. This request 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."



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

Received on Monday, 3 October 2005 12:02:26 UTC