- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 10 Mar 2003 14:56:16 -0500
- To: "'WebDAV'" <w3c-dist-auth@w3.org>
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