Re: Question on GULP - resources added to locked collection

Lisa wrote on 01/06/2006 12:26:58 PM:

> So in the case of a locked collection bound to an internal member of 
> itself, the locked collection is both directly locked and indirectly 
> locked.

That's OK with me. 

> Is the text *still* ok though?  In the case of the collection being 
> bound to a child URL of itself, the collection still becomes indirectly 
> locked, right?  (Just not to the exclusion of being also directly 
> locked).   Here's the proposed text again:
> 
>   > >  >     "In particular, if an internal member resource is added to
>   > >  >     a collection that is locked by a depth:infinity lock,
>   > >  >     then the resource becomes indirectly locked by that lock."

Yes, if we allow a resource to be both directly and indirectly locked
by the same lock, then the text above is fine (and preferable, because
it is simpler).

> We may want to add the principle that in the presence of bindings a 
> resource may be both directly and indirectly locked (though personally 
> I'd prefer the bindings spec to say that).

It's a situation that can arise when two URL's are mapped to the same
resource (defined by the base HTTP spec) and a result of a MOVE call,
so it should be documented in the WebDAV base spec, not just in
the BIND spec.

> Then of course, there's the possibility for an infinitely locked 
> collection to contain a member URL that binds to a resource that is 
> locked by a *different* lock.  Because of the model of only the binding 
> that was locked being protected, it seems that other bindings could be 
> added to the locked collection but the resource would not become 
> indirectly locked.  E.g. if A is locked with lockA, and B is locked 
> with lockB, and B' is an unlocked binding to the locked resource also 
> bound to B, then if B' is moved into A, the resource under B' cannot 
> become indirectly locked with lockA.

This is an error case (i.e. the MOVE or BIND should fail because it
would result in a given resource have two locks).

> Is this text correct then?

Yes, your rewording makes it clearer that this is an error case, and
is superior to my original wording for this reason as well.

> "In particular, if an internal member resource is added to a collection 
> that is locked by a depth:infinity lock (and if the new member resource 
> is not already locked by any lock), then the resource becomes 
> indirectly locked by that lock."
> 
> Seems that this kind of text goes beyond almost any implementation of 
> RFC2518 (only servers implementing bindings would need to worry about 
> the nuances we're discussing) and is quite confusing without examples.

I agree that we can (and should) delete this sentence (i.e., the sentence
beginning with "In particular, ...".

Cheers,
Geoff