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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 7 Mar 2003 19:10:59 +0100
To: "Jason Crawford" <nn683849@smallcue.com>, "Clemm, Geoff" <gclemm@Rational.Com>
Cc: "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCCEBGGLAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> Sent: Friday, March 07, 2003 6:18 PM
> To: Clemm, Geoff
> Cc: 'WebDAV'
> Subject: RE: Move and Delete (was: bind draft issues)
> > 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>
> Sorry to be a pain, but the reason we say that we are splitting in to
> because some people claim that clients prefer the non-atomic DELETE
functionality.    But the
> new bindings document says that if the server can implement UNBIND, then
DELETE should
> be implemented that way.    This leaves me scratching my head.
> 1) Do users ever want the old DELETE functionality if they can
> have UNBIND?

I think so. Where it's not really (only) about what the user (client) wants,
but it also depends on what the server is willing to offer. It maybe
technically possible to implement UNBIND (that's very likely if you have a
proper BIND implementation), yet still undesired.

> 2) If we really believe that they do, why do we suggest that the server do
> the UNBIND anyway?

Do we? I think what the spec says is that if a server supports UNBIND on a
collection, DELETE should behave the same. So the choice is on the server's
side. This doesn't give the *client* the ability to decide, though. Do we
need that?

> It sounds like we really haven't decided (1).   Let's really decide that
and then spec this to match
> what we resolve.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 7 March 2003 13:11:08 UTC

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