Subject: RE: BIND vs. non-movable resources in RFC3253

From: Jason Crawford <[email-masked]>
Date: Tue, 22 Oct 2002 12:46:18 -0400

This seems to be a discussion of "bindings and versioning", not bindings.

I think the binding spec should allow servers to reject DELETE/MOVE 
requests.
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.

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.

Can we agree that servers can reject DELETE/MOVE requests and move the
versioning specific discussion to the versioning mailing list?

J.

------------------------------------------
Phone: 914-784-7569

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 22 Oct 2002 18:49:27 +0200

+1

//Stefan

Am Dienstag, 22.10.02, um 18:46 Uhr (Europe/Berlin) schrieb Jason

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 23 Oct 2002 12:58:30 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Tuesday, October 22, 2002 6:46 PM
> To: Julian Reschke
> Cc: Stefan Eissing; [email-masked]
> Subject: RE: BIND vs. non-movable resources in RFC3253
>
>
>

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

requests.

Yes.

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.

constraints
supported
> in the situations where DELETE/MOVE would break those semantic

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

> 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