Re: Remaining issues with the bind draft -- process

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.

Regards, Julian

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

Received on Monday, 5 April 2004 16:12:42 UTC