- 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>
> 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? That seems valuable and I must have overlooked that view on it in the previous discussions. > 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). 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. Julian, 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 DELETE and you'd still implement UNBIND atomicly? The reason I ask is that if servers are going to implement these operations only 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 pointless. Whereas if server vendors implement each semantic and each semantic are invokable with a predictable method, the clients can specify what they want to happen. Anyway, that's why I ask what you (and other server vendors) would do with your server if the current proposal were passed. J. ------------------------------------------ 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