RE: Locks and loopback bindings

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.

For a given DAV operation, there is an out, though, in that you have a
starting node for the operation. Given this, the binding causing a loop is
one that either:
A) points to a resource already traversed (child loop)
or
B) points to a resource that is both on the path of the starting node, and
has shorter pathlength than the starting node (parent loop)

(Let's see how this flies -- I have a sneaking suspicion I'm forgetting some
edge case). 

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

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

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


> Is there anybody how already supports both or plans to 
> support both and will *not* implement the standard RFC2518 
> deep lock semantics?

I could say that the Catacomb server plans on doing this, though frankly I
still haven't made up my mind yet.
 
> 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).

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

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.

- Jim

Received on Monday, 6 December 2004 23:16:31 UTC