W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: MOVEs across file systems

From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 10 Mar 2003 14:40:19 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED6F8@SUS-MA1IT01>
To: "'WebDAV'" <w3c-dist-auth@w3.org>

I think the comments in the recent threads have pointed to
the appropriate path forward.  In particular, we can replace
the SHOULD statements with stronger MUST statements that have
a narrower target (SHOULD statements are pretty useless in a
spec anyway, so getting rid of them is a good thing).

In particular, instead of saying:

  "DELETE SHOULD be UNBIND if UNBIND is supported"

we should say something like:

  "When DELETE is applied to a collection, it MUST NOT modify the
   membership of another collection, except when the collection
   being deleted is itself a member of that other collection.

   For example, suppose /a/b/.../x identifies a collection C, and there
   is a second binding to C in a collection that is not a member of
   /a/b, then "DELETE /a/b" MUST NOT delete the internal member
   named "y" from C.

And instead of saying:

   "MOVE SHOULD be REBIND if REBIND is supported"

we should say something like:

   "When MOVE is applied to a resource, the other bindings
    to that resource MUST be unaffected, and if the
    resource being moved is a collection, the bindings to any
    members of that collection MUST be unaffected.
    Also, if MOVE is used with Overwrite:T to delete an
    existing resource, the constraints specified for DELETE apply."

Clearly, these constraints can be addressed by implementing DELETE
as an UNBIND and MOVE as REBIND, but in those situations that are
"safe" (i.e. there are not multiple bindings to the resources being
moved or deleted), the "best effort" semantics allowed by 2518
can be applied.

Is this an acceptable compromise?


-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]

> In this case, the resource at the target URL of the MOVE request
> would *not* be the "same" resource anymore (it would have a
> different DAV:resource-id).

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.
Received on Monday, 10 March 2003 14:40:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC