Re: Locks and loopback bindings

Jim Whitehead wrote:

> The reason I think this is an issue is that I can't envision a scenario
> where you would ever want the lock to follow a loopback binding. That is,
> the reason it is a problem is the locks-follow-the-loopback-binding
> semantics are never what a client would want.

I'll not argue with that. But to me this means that if you don't want 
that, don't do it. The fact that depth:infinity locks have interestings 
results for bind loops doesn't necessarily mean that the base semantics 
need to be changed; not doing it if you don't want to certainly is an 
option as well (and a much simpler one spec-wise).

> You can make consistent semantics here, by saying that locks always
> propagate down a hierarchy, but never up. Yes, this is changing the base
> lock semantics somewhat, but in my opinion it doesn't violate the intent of
> 2518. This is essentially adapting the COPY depth infinity semantics for
> locks.

Sounds interesting; but as I'd like to hear feedback from those who 
actually see bind loops being used in practice. Geoff??

>>>In both cases, this seems like undesirable semantics. Lock really 
>>>should ignore any loopback binding. While loopback bindings could 
>>>theoretically have existed in the 2518 world, it really is only the 
>>>introduction of the BIND specification that starts raising 
>>
>>these issues with any urgency.
>>
>>Well, there are good reasons not to implement bind loops at 
>>all (this is why the spec explicitly allows servers to reject 
>>requests creating them, see DAV:cycle-allowed precondition 
>>for BIND). The presence of bind loops creates all kinds of 
>>issues, including those what to do with 
>>PROPFIND/depth:infinity and code that walks hierarchies and 
>>gets into infinite loops. I'm not surprised that 
>>Depth:infinity locks in bind loops are hard to handle, but 
>>IMHO that only means that one should avoid bind loops :-)
> 
> 
> Saying "tut-tut" doesn't make the problems of the interactions of loopback
> bindings and depth locks go away.
> 
>>Personally, I'd say: "the way they are defined by RFC2518, 
>>and if this hurts, don't do it".
> 
> 
> We can be more nuanced than this.

We *could*. The question is: do we want to complicate the spec for 
something that seems to be an edge case? As far as I am concerned, bind 
loops are something that most implementers won't implement anyway. Let's 
hear from those who actually want bind loops about what they think about 
how they should behave with locking.

Julian


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

Received on Friday, 3 December 2004 22:27:40 UTC