Circular Bindings

Looking over the minutes from the Oslo, it appears that the main technical
issue on the advanced collection specification was circular bindings.  We
need to try to settle what we want the specification to say about circular
bindings.

Currently, the specification requires servers to detect cycles when
processing requests with Depth: infinity, and to respond with 506 (Loop
Detected).  Questions raised at Oslo were:

1. Whether it would be better to prevent circular bindings from being
created in the first place.

There was discussion of the relative costs of preventing cycles for any
method that creates a new binding vs. detecting them during Depth: infinity
processing.  Do people have opinions about whether it would be prohibitively
expensive to prevent a cycle from being created by BIND or MOVE on a
collection?

There was discussion of possible legitimate uses for cycles. Can people
offer examples of real scenarios requiring collections to contain themselves
(directly or indirectly)?

2. Whether we should allow Depth: infinity requests to succeed even when
loops are encountered.  (Possibly a parameter was being suggested, allowing
clients to direct the server whether to ignore cycles.)

Jason also suggested in earlier e-mail that there is really no reason why a
request should fail when it encounters a cycle during Depth: infinity.  For
DELETE, MOVE, COPY, and LOCK if the server can detect the cycle (which is
presumed to be easy), it can do the right thing with it and report success.
For PROPFIND, we could just have the server report 506 for a single response
element whenever it encounters a collection for the second time, and not go
into that collection.

Similarly for SEARCH, it seems that the server could simply not search the
collection a second time when it encounters a loop, and report success.

If we decide to let cycles be created, should we change the spec to have
Depth: infinity operations succeed? Or add a header to let clients specify
whether to succeed or fail when a cycle is encountered?

3. General uneasiness about the impact of cycles on all methods that can
have Depth: infinity, including new ones being introduced in versioning and
perhaps in future extensions.

Can anyone point out specific cases in versioning / configuration management
where the existence of cycles might be a problem?  Or in any other
functional area that we might tackle in the future?

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

Received on Friday, 6 August 1999 15:02:15 UTC