Subject: RE: Move and Delete (was: bind draft issues)

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 4 Mar 2003 16:41:19 -0500

Several points that Jason made here were implementation issues
(e.g. Win32 locking, and file system mappings), so those points
are not something that would appear in the spec.

The other statement he made is just locking functionality defined
by RFC2518, not something new introduced by the binding protocol.
As Julian has pointed out, multiple mappings to the same resource
is part of HTTP, and was inherited by WebDAV, not something new
defined by the binding protocol.  So multiple bindings have always
existed in WebDAV.  The binding protocol just gives a client a way
to create them.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Tuesday, March 04, 2003 2:52 PM
To: 'Jason Crawford'
Cc: 'WebDAV'
Subject: RE: Move and Delete (was: bind draft issues)

> > Would you be able to do that -- unmap a collection -- even 
> if one of its
> > children were locked? The person with the lock would then 
> lose it and
> > their resource, right?
> 
> What you are implying is correct.
> If a child is locked via a WebDAV lock and the binding to be 
> DELETEd is
> protected by the protected URL of that lock, then it can't be 
> unmapped.
> If the inode of the child is locked, then I believe it can be 
> unmapped.
> If it's locked by a Win32 lock then it probably can't be unmapped in
> the file system, so it's probably best to reject the DELETE at the
> WebDAV layer.

I don't think the bindings specification makes clear what you've just
said here. It's probably because you've internalized a data model that's
been discussed on the list, and are making conclusions based on the
model.  This kind of information should be added to the specification,
because even when models are written down, they can easily be
interpreted differently by newcomers. 

Lisa

---

From: Jason Crawford <[email-masked]>
Date: Thu, 6 Mar 2003 10:03:41 -0500

> > Were you thinking that this header (say "Atomic-Operation:") would be
> > used for only MOVE, or for all of the relevant operations (COPY,
> > DELETE, etc.)?
>
> Actually, I'd really prefer not to define additional headers.
>
> Thinking of it, we *also* can't agree on the right DELETE semantics (see
> separate discussion). So one way to address this would be to leave DELETE
> and MOVE as they are, and to add
>
> - UNBIND (that really really really removes bindings, thus has the DELETE
> semantics currently specified by the BIND draft) and
> - RENAME (which would be a true MOVE that would fail when the server
can't
> implement it as internal namespace operation).

Just a couple thoughts that I'm not going to have time to join in a
coherent manner...

My initial opinion when I saw this posting a day ago was that RENAME wasn't
necessary.  I don't recall now why I said that.   It might just have been
that it's less
necessary than DELETE... but the recent case of the deletion before MOVE
overwrite
would change that view.  If I recall any other reason why I thought RENAME
wasn't
necessary, I'll speak up.

I'm okay with UNBIND (and I can explain why later) except...

We have shown that atomic DELETE it should be
implementable and the case of a partially finished MOVE with overwrite
looks
really bad to me.  I'm not sure we should let servers do that.   (I have an
equivocating thought on this that I'll hold in reserve. :-))  So if they
can
implement the apparently atomic DELETE for MOVE, then they should be
able to do it for DELETE itself.

Previously we've discussed both headers and UNBIND.  They were rejected.
I don't recall why though, so we probably should check on that.

------------------------------------------
Phone: 914-784-7569,   [email-masked]
I do not check [email-masked]

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 7 Mar 2003 10:08:49 -0500

I think the "SHOULD" gives the implementor enough leeway in this
case, so it would be better to leave it in its slightly simpler
current form.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Friday, March 07, 2003 9:34 AM
To: Clemm, Geoff; 'WebDAV'
Subject: RE: Move and Delete (was: bind draft issues)

Geoff,

in 2.5 you say:

"If the destination collection of a MOVE request supports the REBIND method
(see Section 6), a MOVE of a resource into that collection SHOULD be
implemented as a REBIND request.  In this case, 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)."
I think it's a bit more complicated than that. For instance, if a WebDAV
server is implemented on top of a Unix file system (using inode numbers to
compute a part of the DAV:resource-id property), a target collection may
indeed support REBIND, but not for all resources that are served by the
server (in case it serves files from different filesystem partitions).

So, how about something like:

"If the destination collection of a MOVE request supports the REBIND method
(...) for a request specifying the MOVE request URL as DAV:href...."

Julian

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Friday, March 07, 2003 2:55 PM
> To: 'WebDAV'
> A few years ago, we did discuss introducing new methods
> (I prefer UNBIND/REBIND, rather than UNBIND/RENAME) so
> that a client can specify when it requires atomic behavior
> rather than "best effort" behavior.  Eventually, we concluded
> that any server that supported multiple bindings to
> a resource should also be capable of supporting atomic
> DELETE/MOVE behavior, and since no user would want non-atomic
> behavior if they could get atomic behavior, it is simplest just
> to associate the atomic behavior with the support of
> the BIND operation.
>
> But since we have folks who insist their users want non-atomic
> behavior (even when the server could support atomic behavior!),
> I'm willing to go back to the UNBIND/REBIND approach. But I'd
> like to at least provide guidance to implementors stating that
> DELETE/MOVE *should* be implemented atomically as UNBIND/REBIND
> if the server is capable of doing so.
>
> I've posted a revised version of the binding draft to the
> binding web site.  Let me know what you think.
> <http://www.webdav.org/bind/draft-ietf-webdav-bind-01.2.htm>
>
> Cheers,
> Geoff
>
> From: Julian Reschke [mailto:[email-masked]]
>
> > From: Brian Korver
> >
> > On Wednesday, March 5, 2003, at 01:48  PM, Brian Korver wrote:
>
> > > On Wednesday, March 5, 2003, at 12:34  PM, Julian Reschke wrote:
> > [snip]
>
> > >> Now I *do* agree that in many cases clients will actually *want* the
> > >> "weak"
> > >> MOVE. So maybe we should consider supporting both (either by a new
> > >> method,
> > >> or by adding parameters to MOVE).
> > >
> >
> - RENAME (which would be a true MOVE that would fail when the server can't
> This would make discovery of the new functionality much easier.
>

---

From: Jason Crawford <[email-masked]>
Date: Fri, 7 Mar 2003 20:25:33 -0500

On Friday, 03/07/2003 at 06:34 EST, "Clemm, Geoff"
<[email-masked]> wrote:
> I still vote for "SHOULD".  In particular, given the problems
> partial DELETE and partial MOVE can produce in a multiple binding
> context, a server that supports multiple bindings to a resource
> SHOULD do those operations atomically unless it
> has a very good reason to do otherwise (e.g. the scenario I
> posted earlier).

I agree.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 10 Mar 2003 14:59:45 -0500

The check for "is this the last binding" is not sufficient,
because the multiple binding might be to a parent of the
resource.  In the example I gave below, the "wife" binding
might be the only binding to the wife resource, but deleting
it is a problem because there is another binding to JEFF.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Saturday, March 08, 2003 2:35 AM
To: Clemm, Geoff; 'WebDAV'
Subject: RE: Move and Delete (was: bind draft issues)

> Sent: Saturday, March 08, 2003 3:09 AM
> To: 'WebDAV'
>    From: Brian Korver [mailto:[email-masked]]
>
>    Other than loops, what are the problems unique to multiple
>    bindings and partial MOVE?
>
> One example was posted in the message below:
>
>    From:	Clemm, Geoff [[email-masked]]
>    Sent:	Monday, March 03, 2003 6:34 PM
>    ...
>    because it can cause a DELETE in one collection to cause a change
>    in another collection, and this kind of "deletion side effect"
>    was something we explicitly were trying to avoid.  For example,
>    suppose /henry/has-friend/jeff and /jim/has-friend/jeff
>    were bindings to the same collection, JEFF, and JEFF has a binding
>    named "wife" to a resource, MARI.  Now suppose henry gets mad
>    at jeff, and issues a "DELETE /henry/has-friend/jeff" request.
>    But suppose at that moment someone else has a Depth:0 lock
>    on the /henry/has-friend collection.  The result of a "best effort"
>    deletion is the removal of the "wife" binding from JEFF.  That
>    may be OK if you were just updating the information accessible
>    from /henry (he isn't JEFF's friend anymore, and he's happy to
>    purge as much information about JEFF as he can), but with multiple
>    bindings, "best effort" deletion has now trashed the JEFF object
>    in all the other contexts in which it is still visible (and the
>    folks that still are his friends are still interested in that
>    information).
>
>    So we're not saying that "best effort deletion" is always a bad thing,
>    but we are saying that "best effort deletion" is a bad thing when
>    you care about multiple bindings to the same resource.

Geoff,

I don't think this issue exists if a server does UNBIND when removing one of
multiple bindings and non-atomic-DELETE when removing the last binding (see
[1]).

[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0263.html>

---

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 10 Mar 2003 15:07:21 -0500

This language is moving in the right direction, but it doesn't
handle the case where the additional binding is to a parent of the
resource being considered for "best effort" delete.  In this case,
even if this is the only binding to the resource, deleting it
as part of the "best effort" delete would have a side effect
of also deleting it as a member of the other collection,
which violates the desired semantics of multiple bindings.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:[email-masked]]
Sent: Saturday, March 08, 2003 1:44 PM
To: 'Clemm, Geoff'; 'WebDAV'
Subject: RE: Move and Delete (was: bind draft issues)

What about this model with respect to DELETE and bindings? Rough
specification-like language follows...

---
When a client issues a DELETE request to a collection that has internal
bindings, the preferred server behavior is naturally to achieve a
complete success, whenever possible.  However, servers may behave
differently depending on what bindings exist in the rest of the system.
The collection being deleted may contain the last bindings to one or
more resources. When the last binding to a resource is deleted, the
server may be implemented to perform some cleanup (e.g. release tied-up
storage resources).  If the server is unable to complete its cleanup,
the server MAY do an incomplete recursive delete operation, leaving some
resources behind. The server MAY leave parent collections of undeletable
bindings/resources in place in order to preserve a consistent URL
namespace -- this is equivalent to the behavior specified in RFC2518
[section ref].  The benefit of maintaining a consistent namespace, to a
server implementation, is that orphaned resources remain findable by
clients, so that clients can take actions like changing permissions or
removing locks and finish their DELETE operation.  In case of a partial
DELETE success, the server MUST report individual undeleted
bindings/resources, URL by URL, using the multi-status response body.

 At the other extreme, a DELETE request to a collection may be as simple
as an atomic unbind, which is clearly preferable because to the client's
point of view this is a complete success.

---
Lisa

> [mailto:[email-masked]] On Behalf Of Clemm, Geoff
> Sent: Friday, March 07, 2003 6:09 PM
> To: 'WebDAV'