RE: BIND vs. non-movable resources in RFC3253

> 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