Re: Locks and loopback bindings

Jim Whitehead wrote:
> Julian writes:
> 
> 
>>So, for a set of bindings that are part of that cyclic graph, 
>>which one is "causing" it?
> 
> 
> Ah, now I see what you and Stefan are getting at. The binding "causing" a
> loop can depend on the traversal through the graph.

I'd rephrase slighty differently: given a cyclic graph caused by a set 
of bindings, there is no single binding "causing" it. Remove any of 
them, and the loop will be broken.

> ...

>>IMHO it doesn't because it doesn't need to. As far as I can 
>>tell, until we say something else, the standard semantics 
>>apply (and as far as I can tell, it's clear what they define 
>>in this case).
> 
> 
> But because of the existence of loopback bindings, and their ability to have
> an operation bleed out to the entire resource space of a server, its not
> clear that the standard semantics should apply here, and hence saying
> nothing is ambiguous.

If a bind loop bleeds out to the entire resource space, it's because it 
includes the root collection. IMHO, this is definitively an edge case, 
and the base locking semantics should not be made more complex to take 
care of edge cases like this.

With the removal of lock-null resources and the work on GULP 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0177.html>), 
we have achieved a really simple set of rules that fully define locks. 
Adding special cases here just for edge cases IMHO would be a step into 
the wrong direction.

>>As long as a server stops descending into a collection when 
>>it detects that it has visited that collection before, there 
>>doesn't seem to be an issue.
> 
> 
> We agree here. The problem comes when you visit a parent collection of the
> starting point of a Depth infinity lock.

I'm still not sure why you call that a "problem". As far as I can tell, 
it works exactly as designed.

>>IMHO deep locks on bind loops are an edge case, in particular 
>>if the bind loop includes the namespare root (as in the 
>>example we discussed). 
> 
> 
> So, how do we distinguish between edge cases we should address in the
> specification, and edge cases we shouldn't? Being an "edge case" doesn't
> immediately translate to "don't have to deal with this."

I'm not saying we're not dealing with it; what I'm saying is that 
because it is an edge case it doesn't need *special* treatment. Adding 
special treatment for this case makes the base locking semantics 
significanly more complex, and it's still unclear what that would buy us.

>...
>>BTW, another thing to keep in mind is that you don't need the 
>>BIND spec to create bind loops. Once you accept the existence 
>>of multiple URIs to the same resource, and the fact that 
>>these resources can be collections, a simple MOVE operation 
>>can create a BIND loop.
> 
> 
> You seem to roughly have the following criteria for whether to include
> language in the bind specification:
> 
> * specifically addresses behavior defined in the bind specification
> * is not behavior explicitly defined in another specification
> 
> These are reasonable. I feel I've addressed them by noting:
> 
> * The ability to create bind loops is made much easier by the existence of
> the BIND and REBIND operations.
> 
> * The interaction of bind loops and locking is hence raised far more
> forcefully by the bind specification. Furthermore, there is some difference
> of opinion over what this interaction should be among people who are experts
> in the area (you, me, and Geoff).

That's fine and why we are discussing it. As far as I can tell, Geoff 
and I argue that the base semantics are just fine, and that's why we 
don't need to say anything about ut. If you argue that we need special 
semantics, that's a change to the base locking semantics (no matter 
where we write those down), and thus certainly needs working group 
consensus.

> * It's not clear that the authors of 2518 clearly knew whether their
> containment model was broadly inclusion-containment-like, or
> referential-containment-like. Certainly the amount of thought we put into
> this particular case was close to zero, and 2518 reflects this.

Yes. So let's fix it in RFC2518bis.

> Since I feel I've made this case pretty well, I'd prefer that we focus our
> attention on the technical issue, that is, developing appropriate language
> for handling this feature interaction. We're writing essays over the
> inclusion of a page of text, tops.

As far as I can tell, we currently disagree fundamentally about what the 
desired semantics are. You seem to ask for a change of the locking 
semantics, while Geoff and I say that the base semantics are just fine. 
I think it's up to you to (a) make a proposal what the intended 
semantics should be (did I miss that?) and (b) try to get support in the 
working group for that change.

Best regards, Julian


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

Received on Tuesday, 7 December 2004 11:13:06 UTC