- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 23 Oct 2002 12:58:30 +0200
- To: "Jason Crawford" <nn683849@smallcue.com>, "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Stefan Eissing" <stefan.eissing@greenbytes.de>, <w3c-dist-auth@w3c.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Tuesday, October 22, 2002 6:46 PM > To: Julian Reschke > Cc: Stefan Eissing; w3c-dist-auth@w3c.org > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > > This seems to be a discussion of "bindings and versioning", not bindings. Yes and no. It certainly is an issue with the versioning spec, and it needs to be resolved independantly of what BIND says. However, it proves that the real world can be much more complicated than what the BIND spec suggests, and I think the spec should reflect that. In particular, not all of the bindings to a resource are indeed equal, and the order of DELETE requests on several binds to the same resource may affect the results (for instance, because a server fails the DELETE to the last binding because the user doesn't have the privilege to destroy the resource). > I think the binding spec should allow servers to reject DELETE/MOVE requests. Yes. > The binding spec should not be concerned about all the possible reasons a > server might reject a request, and in particular it shouldn't devote any time to > versioning specific reasons a server might reject a request. For interoperability, we may need to define how a client can find out why a DELETE failed. For instance, *if* we allow a model where a particular binding must be removed last, there should be a way for the client to find out about that. > If a particular spec, like the versioning spec, has a particular semantic constraints > that it wants to support, it can spec that DELETE/MOVE should not be supported > in the situations where DELETE/MOVE would break those semantic > constraints. The issue here is that if we allow a DELETE to fail because other bindings exist, a client may never be able to delete a binding (because due to race conditions, there will always be additional bindings left). I'm not saying that this can be avoided, however it *really* sounds ugly. As I said, I haven't seen a convincing argument why we need this restriction in RFC3253 (and yes, this discussion should be moved to the other mailing list). > Can we agree that servers can reject DELETE/MOVE requests and move the > versioning specific discussion to the versioning mailing list? Yes. Still, we may have to define additional precondition values for - resource does not support additional bindings - new member name can't be used (in deltav: because it was already used for a stable URI) Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 23 October 2002 06:59:04 UTC