RE: Locks and loopback bindings

> Why is that a problem? A bind loop that includes the 
> namespace root seems like an edge case to me that doesn't 
> require changing the base semantics. If it hurts to have a 
> bind loop including the namespace root, don't do it.

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.

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.

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

- Jim

Received on Friday, 3 December 2004 22:00:17 UTC