Subject: RE: BIND vs. non-movable resources in RFC3253

From: "Clemm, Geoff" <[email-masked]>
Date: Sat, 26 Oct 2002 23:00:40 -0400

From: Julian Reschke [mailto:[email-masked]]

   > From: Clemm, Geoff
   >
   > Note: This precondition actually violates the requirement
   > earlier in the text that a server support cyclic bindings.

   I wasn't aware off that being a requirement. I see why a server
   that *does* support cyclic bindings need to signal them upon depth
   infinity operations (-> 506), but why would you want to require
   support for their creation?

   Actually, I'm tempted to require servers to detect cyclic bindings
   upon creation and to reject those requests. What's the use case for
   cyclic bindings?

If you are using bindings to capture some relationship, and that
relationship is cyclic, then you can't capture that relationship
if you are not allowed to create cyclic bindings.

   > But probably a server should be allowed to reject cyclic
   > bindings, so I'm happy to add this pre-condition (and remove
   > the current requirement), if nobody objects.

   BTW: this precondition applies to all namespace-manipulating
   operations (a MOVE of a collection may fail for the same reason).

Assuming that the server does not allow you to "move" the root
(which no server does), how do you create a cycle with a move
operation?

Cheers,
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 27 Oct 2002 13:46:08 +0100

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Clemm, Geoff
> Sent: Sunday, October 27, 2002 4:01 AM
> To: [email-masked]
> Subject: RE: BIND vs. non-movable resources in RFC3253
>
>

I'd still feel better if you could give a simple example...

> (which no server does), how do you create a cycle with a move

Let /a and /b/c bind to the same collection C. Move /b to /a/b. Result is
that both /a and /a/b/c bind to the same collection C.

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760