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

From: Jason Crawford <[email-masked]>
Date: Tue, 4 Mar 2003 19:14:57 -0500

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

------------------------------------------
Phone: 914-784-7569,   [email-masked]
I do not check [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 5 Mar 2003 01:36:09 +0100

> From: Jason Crawford [mailto:[email-masked]]
> Sent: Wednesday, March 05, 2003 1:15 AM
> To: Julian Reschke
> Cc: Clemm, Geoff; 'WebDAV'
> Subject: RE: Move and Delete (was: bind draft issues)
>
>
>
>
>

It may be compliant to RFC2518, but it may not be compliant to other
non-WebDAV semantics of the server. Previously the server *was* able to
support them, now it can't anymore.

> server writers do some coding before they can claim to support

Again: it's not a question of avoiding new code. A server that claims to
understand bindings will need to have all the proper code in place anway.
The question is whether the particular DELETE semantics is *desired*.

Gentleman, we're (or at least some of us :-) aren't building servers just
for fun, or only to implement specific RFCs. They also need to support
private/proprietary semantics as well. WebDAV is just an (or another) open
protocol that allows accessing these systems. Putting specific requirements
into the specs that can't be implemented by these systems just means that
these systems will

- break the specs (leading to interop surprises),
- do not offer the functionality through HTTP methods or
- come up with proprietary protocol extensions.

I think it's highly desirable to avoid this, and IMHO the solution is to
give servers enough freedom so that they can make WebDAV and internal
semantics compatible. Just like RFC2518 did.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 7 Mar 2003 13:30:41 -0800

> server writers do some coding before they can claim to support

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.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 8 Mar 2003 11:28:19 +0100

> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Friday, March 07, 2003 10:31 PM
> To: 'Jason Crawford'; 'Julian Reschke'
> Cc: 'Clemm, Geoff'; 'WebDAV'

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

Julian