W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

Re: Locks and loopback bindings

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 06 Dec 2004 23:10:53 +0100
Message-ID: <41B4D8ED.3020401@gmx.de>
To: ejw@cs.ucsc.edu
CC: 'Stefan Eissing' <stefan.eissing@greenbytes.de>, "'WebDAV (WebDAV WG)'" <w3c-dist-auth@w3.org>

Jim Whitehead wrote:
>>May I ask what the definition of a "loopback binding" is and 
>>how it differs from other bindings?
> 
> 
> A rough definition is any binding that converts an acyclic containment graph
> into a cyclic graph. This is also how it differs from other bindings. 

So, for a set of bindings that are part of that cyclic graph, which one 
is "causing" it?

>>Some servers will require 
>>acyclic graphs while others will allow cycles.
> 
> 
> Right. In the case where servers support cycles, and also support depth
> locks, they'll need to develop semantics for the interaction of these two
> features. At present, the bind specification provides no guidance for this
> situation.

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

>>The set of deep-locked nodes is the set of nodes reachable 
>>from the starting point. We could provide an algorithm for 
>>server implementors, and even more important for clients, on 
>>how to find this set and not get lost in possible cycles.
> 
> 
> We could do this, although I'd rather not get into specifying which kind of
> traversal algorithm servers should use (depth first vs breadth first, etc.),
> since that's implementation detail. 

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.

> I'd rather point out that, no matter which kind of traversal you use to
> compute closure, there are certain edges (loopback edges) that should not be
> followed in computing the closure.

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). 
Is there anybody how already supports both or plans to support both and 
will *not* implement the standard RFC2518 deep lock semantics?

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.

Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 6 December 2004 22:11:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:51 UTC