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

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

From: Jason Crawford <nn683849@smallcue.com>
Date: Sat, 8 Mar 2003 11:06:49 -0500
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <OFA19A99D8.E5ECBD03-ON85256CE3.0054B6B1@us.ibm.com>

> What is (or was) open to discussion whether servers may want to support
> - multiple bindings
> - BIND live properties
> - BIND MOVE semantics
> without supporting UNBIND semantics (or actually without supporting
> semantics on the *last* binding to a collection). That's what we planned
> do in our server, and I think this behaviour should be allowed.
> Making the "new" behaviour explicit in UNBIND/REBIND instead of
> allows a server to support clients that are only RFC2518-aware as before,
> yet offers newer clients the ability to rely on the tightened semantics
> reliably get the request failed if the semantics cannot be offered).
> Coming back to the new methods:
> REBIND/MOVE: I think everybody agrees that it would be a good if new
> could request a resource MOVE that will leave all dead and live
> intact. If we can't put that into RFC2518-MOVE, we'll need a new way of
> marshall the request. Do we have consensus here?
That seems valuable and I must have overlooked that view on it in the

> UNBIND/DELETE: I think there was some confusion here about why people did
> not like requiring DELETE to use UNBIND semantics. If a server *does*
> support multiple bindings, DELETEing one of many bindings indeed should
> remove that binding, and thus be atomic (does anybody disagree here?). I
> only have an issue to require this particular semantics for the *last*
> binding to a collection (in which case I'd prefer to use the old RFC2518
> DELETE semantics).
I know Julian knows this, but just in case others don't...  that
"last-binding" (from
outside the tree) check applies to all bindings in the subtree.

   would you be willing to support both in your server.  If you think
clients prefer
the non-atomic delete on the final binding, you could implement that for
and you'd still implement UNBIND atomicly?

The reason I ask is that if servers are going to implement these operations
one way, that limits the value of having two methods.  Clients will only
get the one way
that the server implements anyway (or they can buy a new server).  There is
little point
in a client implementor calling UNBIND if few servers will implement it
unless he knows
that his user wants only that behavior.  But unless he knows that, he has
to make DELETE
the default thing he calls.  A seperate UNBIND method becomes almost
Whereas if server vendors implement each semantic and each semantic are
with a predictable method, the clients can specify what they want to

Anyway, that's why I ask what you (and other server vendors) would do with
your server
if the current proposal were passed.


Phone: 914-784-7569,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com
Received on Saturday, 8 March 2003 11:12:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:27 UTC