- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 5 Mar 2003 01:36:09 +0100
- To: "Jason Crawford" <nn683849@smallcue.com>, "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Clemm, Geoff" <gclemm@Rational.Com>, "'WebDAV'" <w3c-dist-auth@w3.org>
> From: Jason Crawford [mailto:nn683849@smallcue.com] > Sent: Wednesday, March 05, 2003 1:15 AM > To: 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 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. > 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. 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
Received on Tuesday, 4 March 2003 19:36:43 UTC