Re: BIND vs. non-movable resources in RFC3253

Clemm, Geoff wrote:

> [...] how does requiring that cyclic relationships be modeled
> by properties instead of collection membership solve
> anything, other than pushing the burden of cycle detection
> onto the client instead of the server?
>
Recursive operations such as a depth infinity MOVE/COPY/PROPFIND will 
have problems if there is a cycle. 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 even if one believes that modeling cyclic relationships
> should be done with properties, in a versioned collection
> context, there is no way to avoid the cyclic binding problem.  [...]
>
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. Since there is no way to avoid the creation of 
cyclic bindings in a versioned collection context, option (a) won't buy 
us anything, so option (b) seems to be the only alternative. Is it 
reasonable to specify that recursive operations treat bindings 
differently than other resources?


Elias