Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings

Lisa Dusseault wrote:
> 
> One could imagine the lock applying to the resource and to all its 
> bindings, considering  the bindings to be part of the state of the 
> resource.  If I recall, I think this is the model I'd always assumed 

Well, I'm not aware of a single server that supports multiple bindings 
to one resource, but which considers bindings as part of the state of 
the resource. Do you?

I also note that this point of view is incompatible to the model used in 
RFC3744, where you need a DAV:unbind privilege on the parent collection 
to remove a binding 
(<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.B>).

> until GULP.  With this model, if A and B are bindings to a resource, and 
> a LOCK token to A is successful, then for the duration of the lock the 
> token is required to change either A or B.

Are you aware of a single implementation working that way?

> In today's server implementations, does a LOCK of depth 0 on a 
> collection prevent MOVE from being used to change resource names inside 
> the collection?  This is another possible case that might be different 
> depending on whether bindings were considered part of the collection, 
> part of the resource state, or both.

I'll claim that all servers that implement depth 0 locks on collections 
work that way, and that RFC2518 requires them do work that way 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>):

"A write lock on a collection, whether created by a "Depth: 0" or 
"Depth: infinity" lock request, prevents the addition or removal of 
member URIs of the collection by non-lock owners. As a consequence, when 
a principal issues a PUT or POST request to create a new resource under 
a URI which needs to be an internal member of a write locked collection 
to maintain HTTP namespace consistency, or issues a DELETE to remove a 
resource which has a URI which is an existing internal member URI of a 
write locked collection, this request MUST fail if the principal does 
not have a write lock on the collection."

Again, if you have evidence of servers working differently, please 
provide it.

Best regards, Julian

Received on Wednesday, 14 December 2005 22:20:15 UTC