Re: Remaining issues with the bind draft -- process

On Apr 5, 2004, at 1:11 PM, Julian Reschke wrote:

>
> Lisa Dusseault wrote:
>
>> In this discussion, I asked whether a user can UNLOCK a binding that  
>> wasn't
>> the binding where the LOCK was issued (these are both bindings to the  
>> same
>> resource).  One of the email answers was that the client software  
>> could always
>> use the "lockroot" element in the lock information to discover which  
>> URI was
>> locked and thus they could find out which one to unlock.
>> I find that answer unacceptable for two reasons.  First, 'lockroot'  
>> isn't standardized -- it's
>> only a proposed extension to WebDAV/RFC2518, and not all servers  
>> implementing
>> bindings must implement this proposed extension.   Second, it doesn't  
>> answer the
>> question of how server implementations of bindings MUST behave.
>
> 1) First of all, clients are not supposed to remove locks they haven't  
> created. If the lock was created by themselves, they *know* the  
> original request URI. If they didn't, this is definitively an edge  
> case.
>
> 2) That being said, the *resource* is locked; and thus it doesn't  
> matter what request URI is used to submit the UNLOCK request to. This  
> is consistent with the general statement that additional bindings only  
> create additional access paths, but that the methods interact with the  
> *resources*. In general, the access path does not matter. See  
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind 
> -05.html#rfc.section.1.p.4>:
>
> "The BIND method defined here provides a mechanism for allowing  
> clients to create alternative access paths to existing WebDAV  
> resources. HTTP [RFC2616] and WebDAV [RFC2518]  methods are able to  
> work because there are mappings between URIs and resources. A method  
> is addressed to a URI, and the server follows the mapping from that  
> URI to a resource, applying the method to that resource. Multiple URIs  
> may be mapped to the same resource, but until now there has been no  
> way for clients to create additional URIs mapped to existing  
> resources."
>
> So in general, the access path does not matter. That's the whole point  
> of the binding spec.

Except for the cases where it does matter, like BIND/UNBIND, MOVE and  
DELETE.  The spec is not clear enough about which methods apply to the  
binding and which apply to the resource, and when.  The spec doesn't  
say whether LOCK behaves more like PUT, or more like BIND.

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

Received on Monday, 5 April 2004 16:16:37 UTC