RE: MOVEs across file systems

I've made the proposed modifications to the MOVE and DELETE
constraints in the binding protocol in a new revision (01.3) of the
binding protocol, as well as added a constraint to COPY,
and posted it to the webdav binding web site.  Here
are the modified sections.  This will be on the agenda for the
WebDAV meeting next week, so if possible, please review this
before then.

Cheers,
Geoff

------------------------------------------------

2.3	COPY and Bindings

As defined in Section 8.8 of [RFC2518], COPY causes the resource
identified by the Request-URI to be duplicated, and makes the new
resource accessible using the URI spechified in the Destination
header.  Upon successful completion of a COPY, a new binding is
created between the last path segment of the Destination header, and
the destination resource. The new binding is added to its parent
collection, identified by the Destination header minus its final
segment.

The following figure shows an example: Suppose that a COPY is issued
to URI-3 for resource R (which is also mapped to URI-1 and URI-2),
with the Destination header set to URI-X.  After successful completion
of the COPY operation, resource R is duplicated to create resource R',
and a new binding has been created which creates at least the URI
mapping between URI-X and the new resource (although other URI
mappings may also have been created).

URI-1   URI-2    URI-3                           URI-X
   |       |        |                              |
   |       |        |   <---- URI Mappings ---->   |
   |       |        |                              |
+---------------------+                 +------------------------+
|     Resource R      |                 |     Resource R'        |
+---------------------+                 +------------------------+

It might be thought that a COPY request with "Depth: 0" on a
collection would duplicate its bindings, since bindings are part of
the collection's state.  This is not the case, however.  The
definition of Depth in [RFC2518] makes it clear that a "Depth: 0"
request does not apply to a collection's members.  Consequently, a
COPY with "Depth: 0" does not duplicate the bindings contained by the
collection.

If a COPY causes one or more existing resources to be updated, the
bindings to those resources MUST be unaffected by the COPY.  Using the
preceding example, suppose that a COPY is issued to URI-X for resource
R', with the Destination header set to URI-2.  The content and dead
properties of resource R would be updated to be a copy of those of
resource R', but the mappings from URI-1, URI-2, and URI-3 to resource
R remain unaffected.

2.4	DELETE and Bindings

When there are multiple bindings to a resource, a DELETE applied to
that resource MUST NOT remove any bindings to that resource other than
the one identified by the request URI.  For example, suppose the
collection identified by the URI "/a" has a binding named "x" to a
resource R, and another collection identified by "/b" has a binding
named "y" to the same resource R.  Then a DELETE applied to "/a/x"
removes the binding named "x" from "/a" but MUST NOT remove the
binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues
to identify the resource R).  In particular, although Section 8.6.1 of
[RFC2518] states that during DELETE processing, a server "MUST remove
any URI for the resource identified by the Request-URI from
collections which contain it as a member", a server that supports the
binding protocol MUST NOT follow this requirement.

When DELETE is applied to a collection, it MUST NOT modify the
membership of any other collection that is not itself a member of the
collection being deleted.  For example, if both "/a/.../x" and
"/b/.../y" identify the same collection, C, then applying DELETE to
"/a" MUST NOT delete an internal member from C or from any other
collection that is a member of C, because that would modify the
membership of "/b".

If a collection supports the UNBIND method (see Section 5), a DELETE
of an internal member of a collection MAY be implemented as an UNBIND
request.  In this case, applying DELETE to a Request-URI has the
effect of removing the binding identified by the final segment of the
Request-URI from the collection identified by the Request-URI minus
its final segment. Although [RFC2518] allows a DELETE to be a
non-atomic operation, when the DELETE operation is implemented as an
UNBIND, the operation is atomic.  In particular, a DELETE on a
hierarchy of resources is simply the removal of a binding to the
collection identified by the Request-URI.

2.5	MOVE and Bindings

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.

If the destination collection of a MOVE request supports the REBIND
method (see Section 6), a MOVE of a resource into that collection MAY
be implemented as a REBIND request.  Although [RFC2518] allows a MOVE
to be a non-atomic operation, when the MOVE operation is implemented
as a REBIND, the operation is atomic.  In particular, applying a MOVE
to a Request-URI and a Destination URI has the effect of removing a
binding to a resource (at the Request-URI), and creating a new binding
to that resource (at the Destination URI).

As an example, suppose that a MOVE is issued to URI-3 for resource R
below (which is also mapped to URI-1 and URI-2), with the Destination
header set to URI-X.  After successful completion of the MOVE
operation, a new binding has been created which creates the URI
mapping between URI-X and resource R.  The binding corresponding to
the final segment of URI-3 has been removed, which also causes the URI
mapping between URI-3 and R to be removed.  If resource R were a
collection, old URI-3 based mappings to members of R would have been
removed, and new URI-X based mappings to members of R would have been
created.

>> Before Request:

 URI-1   URI-2    URI-3
   |       |        |                                
   |       |        |      <---- URI Mappings
   |       |        |
+---------------------+                   
|     Resource R      |
+---------------------+                   

>> After Request:

 URI-1   URI-2    URI-X
   |       |        |                                
   |       |        |      <---- URI Mappings
   |       |        |
+---------------------+                   
|     Resource R      |
+---------------------+                   

Although [RFC2518] allows a MOVE on a collection to be a non-atomic
operation, a MOVE implemented as an UNBIND MUST be atomic.  Even when
the Request-URI identifies a collection, the MOVE operation involves
only removing one binding to that collection and adding another.
There are no operations on bindings to any of its children, so the
case of MOVE on a collection is the same as the case of MOVE on a
non-collection resource.  Both are atomic.
------------------------------------------------

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Tuesday, March 11, 2003 1:11 PM
To: 'Clemm, Geoff'; 'WebDAV'
Subject: RE: MOVEs across file systems


This is pretty good!  I look forward to seeing it in context of the
draft, when we can submit drafts again of course.

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff
> Sent: Tuesday, March 11, 2003 9:10 AM
> To: 'WebDAV'
> Subject: RE: MOVEs across file systems
> 
> 
> 
> Yeah, I didn't think that Julian's suggestion would be popular (:-).
> 
> So I think realistically, we should focus on constraining the
> behavior of MOVE/DELETE in the presence of multiple bindings
> to the same resource, so that they don't violate the basic 
> requirements of multiple bindings.
> 
> The current form of that proposal is:
> 
> ----------------------------
> 
> 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."
> 
> ------------------
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Tuesday, March 11, 2003 11:40 AM
> To: 'Clemm, Geoff'; 'WebDAV'
> Subject: RE: MOVEs across file systems
> 
> 
> This is equivalent to the previous behavior as long as 
> clients continue
> to issue the same MOVE and DELETE requests they have in the 
> past (which
> they will for quite a while).  Therefore, I don't see how this is a
> change, or how this could possibly be acceptable if the previous
> behavior was unacceptable.
> 
> Servers must be able to support the binding specification, and to
> support ordinary WebDAV clients, and to do what the server 
> implementors
> consider to be the most appropriate and best job they can of 
> fulfilling
> the request, and to report the results.  This proposed statement does
> not meet that requirement because it forces all servers to do atomic
> MOVE/DELETE in handling requests from ordinary WebDAV clients.
> 
> Lisa
> 
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org 
> > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff
> > Sent: Monday, March 10, 2003 12:18 PM
> > To: 'WebDAV'
> > Subject: RE: MOVEs across file systems
> > 
> > 
> > 
> > That would be fine with me as well.
> > 
> > Just to be clear, this means the binding spec would state:
> > 
> > A server that supports BIND MUST implement MOVE/DELETE with
> > rebind/unbind semantics.  We will also define a parameter to
> > MOVE/DELETE that allows a user to explicitly request the
> > "best effort" style processing (that is OK because the user is
> > explicitly stating that trashing multiple binding semantics is
> > what they want).
> > 
> > Cheers,
> > Geoff
> > 
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > 
> > > From: Clemm, Geoff
> > > 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.
> > 
> > On the other hand, a system that allows a "weak" MOVE if and 
> > only if there
> > aren't any multiple bindings seems very weird to me. So maybe 
> > we should
> > consider make MOVE "strong" by default, and only allow the 
> > old COPY/DELETE
> > semantics upon specific request?
> > 
> > 
> 
>

Received on Thursday, 13 March 2003 14:01:52 UTC