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

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:julian.reschke@gmx.de]
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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, March 07, 2003 2:55 PM
> To: 'WebDAV'
> Subject: RE: Move and Delete (was: bind draft issues)
>
>
>
> 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:julian.reschke@gmx.de]
>
> > 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.
>

Received on Friday, 7 March 2003 10:08:57 UTC