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: Sat, 8 Mar 2003 11:28:19 +0100
To: "Lisa Dusseault" <lisa@xythos.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCKEDBGLAA.julian.reschke@gmx.de>

> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Friday, March 07, 2003 10:31 PM
> To: 'Jason Crawford'; 'Julian Reschke'
> Cc: 'Clemm, Geoff'; 'WebDAV'
> Subject: RE: Move and Delete (was: bind draft issues)
> >
> > > Anyway, the main issue for us is that we absolutely can not change the
> > > DELETE collection semantics (from what we have in RFC2518).
> >
> > Sure you can.  The behavior the spec outlines is compliant with 2518.
> > It does not break 2518 compliant clients.  But it does require that
> > server writers do some coding before they can claim to support
> > this new feature.
> >
> Well, yes, one can change the required behavior from 2518 to 2518bis.
> However, we don't want to do that unless there are existing
> interoperability problems.  I don't think changing the model so that
> some servers have difficulty being compliant with the new model is a
> good idea for 2518bis.

I think what Geoff is saying that the BIND spec *can* tighten RFC2518(bis)
requirements. A server has the freedom not to claim BIND spec support, and
then won't be affected (just like some people want to tighten RFC2616
requirements in RFC2518bis... :-)

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 UNBIND
semantics on the *last* binding to a collection). That's what we planned to
do in our server, and I think this behaviour should be allowed.

Making the "new" behaviour explicit in UNBIND/REBIND instead of DELETE/MOVE
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 (or
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 clients
could request a resource MOVE that will leave all dead and live properties
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?

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 only
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).


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 8 March 2003 05:28:28 UTC

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