RE: BIND vs. non-movable resources in RFC3253

   From: Elias Sinderson [mailto:elias@cse.ucsc.edu]

   Recursive operations such as a depth infinity MOVE/COPY/PROPFIND
   will have problems if there is a cycle.

These problems are all solvable in a straightforward fashion.  A MOVE
has no problems with a cycle (it is just the deletion of one binding
and the creation of another).  A COPY would have to check for any
resource that has multiple entries in its DAV:parent-set, to see if it
has already been copied (in which case a second binding to the copy is
created).  A PROPFIND has to keep track of what resources it has
already visited.

   I see two possible alternatives to address this problem:

   a) model cyclic relationships as properties or

   b) disallow following links during recursive operations in the same
   way that a filesystem does.

and:

c) handle cycles appropriately when they are encountered

   I have no problem with the creation of cyclic bindings. My primary
   concern is that the server should not be required to detect the
   existence of a cycle.

Detection of the existence of a cycle at binding creation time
can be hard.  Handling the existence of a cycle during the
operation of a WebDAV method is straightforward (at least for
the currently defined WebDAV methods).

   Since there is no way to avoid the creation of cyclic bindings in a
   versioned collection context, option (a) won't buy us anything,

Agreed.

   so option (b) seems to be the only alternative.
   Is it reasonable to specify that recursive operations
   treat bindings differently than other resources?

In a versioned-collection context, all of the bindings are created by
PUT and MKCOL, but with an appropriate set of collection versions, a
cycle results.  So option b doesn't solve the problem, because even if
you marked all the bindings created by BIND as special, all of the
bindings may have been created by PUT and MKCOL, and still result in a
cycle.

So that leaves option (c) as the only alternative.

Cheers,
Geoff