Re: Call for consensus on UNLOCK Request-URI being lock root

Joe Hildebrand wrote:
> 
> July 6 has passed.  It looks to me like we have consensus on option 1,  
> with the following reasons:
> 
> - This is what existing implementations do
> - It's one possible way of reading 2518
> - It doesn't conflict with other decisions that have already been made
> 
> I didn't see any objections to Lisa's proposed wording:
> 
>     The UNLOCK method identifies a lock to remove with the lock token in
>     the Lock-Token request header.  The Request-URI MUST identify a
>     resource within the scope of the lock.

I'd prefer something that actually focuses on what the method does (the 
purpose of UNLOCK is not to identify a lock; it's to remove it), such as:

"The UNLOCK method removes the lock identified by the lock token in the 
Lock-Token request header from the resource identified by the 
Request-URI, and all other resources included in the lock. Note that the 
UNLOCK request may be submitted to any resource locked by that lock 
(even those that are locked indirectly)." 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.5.p.1>)

> Then later in the error code information for UNLOCK:
> 
>     400 (Bad Request) - No lock token was provided, or request was
>     made to a Request-URI that was not within the scope of the lock.

Here, I'd prefer that we define specific precondition codes that more 
clearly describe the problem:

"5.2 Preconditions

5.2.1 DAV:lock-token-matches precondition

The lock identified by the "Lock-Token" request header exists, and the 
resource identified by the Request-URI indeed is directly locked by the 
specified lock.

5.2.2 DAV:lock-removal-allowed precondition

As dicussed above, the principal authenticated for the UNLOCK request 
MUST be allowed to remove the identified lock (note that servers that 
support the "WebDAV Access Control Protocol" should use the 
DAV:need-privileges precondition defined in section 7.1.1 of 
[RFC3744])." 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.5.2>)

> Also, it appears that we have consensus that refreshing locks should  
> work the same way, namely, that you can refresh a lock by sending a  
> LOCK request to any URI covered by the lock.

Yes.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Sunday, 11 July 2004 06:58:00 UTC