RE: MOVEs across file systems

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Jason Crawford

   > We might have to accept that for the single binding cases and
   > encourage them to do better, but if they don't support cross-file
   > system bindings and they do a move to another file system and the
   > source resource also has additional bindings to it from the
   > original file system, then the request MUST be rejected.  If it
   > is not, the server can not claim to support the bind spec.

   Well, I think that's up to discussion. MOVE suffers from it's
   RFC2518 definition (COPY then DELETE). REBIND doesn't. I don't see
   a problem with a system supporting both (REBIND will fail for some
   operations, while MOVE won't).

The problem with this approach (leaving the behavior of MOVE and
DELETE unconstrained in the presence of multiple bindings) is that it
makes multiple bindings relatively useless, since most people will be
coming at these advanced servers with legacy clients that support MOVE
and DELETE, not REBIND and UNBIND.  If you leave the multiple binding
semantics of MOVE and DELETE undefined, these legacy clients will just
trash the multiple bindings you've created.

So I'm happy to limit the constraints on MOVE and DELETE to exactly
what is needed to preserve the semantics of multiple bindings, but
leaving them unconstrained makes the binding protocol pointless in
practice.

Cheers,
Geoff

Received on Monday, 10 March 2003 14:56:26 UTC