Subject: Circular Bindings

From: "Slein, Judith A" <[email-masked]>
Date: Fri, 6 Aug 1999 15:02:07 -0400

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
[email-masked]
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

---

From: [email-masked]
Date: Fri, 13 Aug 1999 20:23:04 -0400

<GC>
   ... this also reminds me that with AdvColl, it is possible that a
   portion of the source tree and the destination might be common.  And
   that initial deletion phase of the COPY might actually essentially
   delete a portion of the source tree.  It's probably a red herring, but
   it's probably also something we should mention in the spec.

I agree that it is something that should be explicitly mentioned
(and disagree that it is a red herring :-).

In particular, I'd suggest some words to the effect that a COPY should
be semantically equivalent to a COPY to a temporary URL (that identifies
a null resource) followed by a MOVE from the temporary URL to the
destination URL.
</GC>

Geoff, I don't understand your wording.  Whoops.  Yes, I do.  The COPY would
create a new instance of the resources that were in the source tree.  The MOVE
would UNBIND the destination and rebind the newly created copy to the
destination URI.  (Am I using our "bind" vocabulary/object-model correctly? :-))
Got it.  Of course, that's the AdvColl. way of explaining it.  And it still has
this odd behavior with the the DELETE phase if we use your wording with
RFC2518... so we still should flag it there.     Hopefully we can move to
AdvColl. and not worry too much about this.  (It's only a problem for AdvColl if
the UNBIND of the MOVE phase destroys a binding that happens to be in the source
tree.  Fortunately that one binding is the only thing that gets destroyed (at
least explicitly) as a result of the COPY.  I said explicitly because a bunch of
resources might lose their only mapping(s) as a result of that unbind and thus
become inaccessable in the absense of versioning.)

The caveat is... even with AdvColl, I think we need to define what COPY/MOVE do
across machines that don't cooperate on bindings.  Your definition of COPY seems
to work across machines as long as we say the COPY phase copies to a temporary
location on the *destination* machine.  MOVE across machines is another matter.
We should say if we allow MOVE if the intended semantics can't be achieved.  Or
if best effort is acceptable.  Or if the client can specify if best-effort is
acceptable.