Re: Remaining issues with the bind draft -- process

Lisa Dusseault wrote:

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

I agree that sometimes it may *look* like it does. That follows from the 
specific property that locks do not only apply to the resource, but that 
they *also* protect the request URL to which the lock has been applied. 
So a namespace operation (such as removing a binding) may require a 
lock-token when that binding was protected by the lock, and otherwise 
not. In reprospective, this may have been the wrong design decision; but 
this was done in 1998, not today.

Consider the bindings "p/a1" and "p/a2" to resource A. LOCK was applied 
to the request URI "p/a1", resulting in the resource A being locked by a 
lock that protects the URL "p/a1".

Applying DELETE to "p/a1" requests that the binding "a1" is removed from 
it's parent collection "p". Applying DELETE to "p/a2" requests that the 
binding "a2" is removed from it's parent collection "p". As only the URL 
"p/a1" is protected by the lock, the first request will fail, while the 
second will succeed (if the client doesn't specify the lock token in the 
"If" request header).

What may be confusing here is that in fact the resource "A" isn't 
modified *at all*. Rather than that, it's the state of the collection 
resource identified by "p" that is being manipulated in both cases. For 
UNBIND, the BIND spec gets this right by applying the method to the 
parent collection, and having the actual member URI (to be removed) 
passed in as a parameter in the request body.

I absolutely agree that RFC2518 doesn't explain this very well (*). But 
this is true independantly of the BIND spec, and thus should be fixed in 
RFC2518bis. Alternatively we can also (as discussed in January) extract 
WebDAV locking into a separate independant spec (I'm willing to help 
working on that), but it really has little to do with BIND.

Regards, Julian

(*) For instance, I just tried to figure out where RFC2518 says that I 
can't rename "p" when "p/a1" is being locked without passing the lock 
token for A. Nevertheless, this is true, and everybody seems to agree on it.

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

Received on Monday, 5 April 2004 16:51:24 UTC