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

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

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

-----Original Message-----
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).
> >
>
> 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).

This would make discovery of the new functionality much easier.

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 7 Mar 2003 15:10:47 +0100

Geoff,

thanks for the update. I think this will allow us to make progress towards
getting the spec finished.

> DELETE/MOVE behavior, and since no user would want non-atomic

A server may want to implement *parts* of the binding spec without actually
allowing the explicit creation of new bindings. In particular, supporting
DAV:resource-id seems to be a very useful thing even if a server doesn't
plan to support *multiple* bindings.

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'
> Subject: RE: Move and Delete (was: bind draft issues)
>
>
>

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 7 Mar 2003 15:33:31 +0100

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