RE: Proposal: BIND method

Geoff Clemm wrote:
> "If a server cannot support BIND semantics (in particular,
> could not support the fix-up stage for MOVE, or could not guarantee
> that GET/PUT/LOCK on this URL affect the same resource as a
> GET/PUT/LOCK to all other bindings to this resource), the BIND call
> MUST fail."

This makes sense to me, although it might need to be broadened out to
describe the multi-URL semantics for all methods.

> The second supplement is:
>
> "A MOVE request MUST fail if the binding fix-up cannot be done.  A client
> can always issue explicit COPY/DELETE in this situation".

Hmm, this seems to be taking us down the route of having strong integrity,
which some people had previously objected to as being too onerous on the
server in the past.  But, perhaps a binding will be less difficult for
implementors to give strong integrity semantics.

I personally don't object to this requirement.

> The one modification is the semantics of DELETE:
>
> In the context of "BIND", there are two important
> delete-like operations.  The first is "UNBIND xxx", which says
> that the binding of xxx to a resource should be deleted.  The second
> is "DESTROY xxx", which says that *all* bindings to the resource
> bound to xxx should be deleted.
>
> Jim's proposal says that DELETE should have DESTROY semantics
> (and that some other method be created to have UNBIND semantics).
> While I agree with Jim that associating DELETE with DESTROY is
> probably more "natural", given the current wording in RFC 2068,
> I believe that for Advanced Collections to be usable for versioning,
> it is essential that a downlevel "DELETE" have "UNBIND" semantics.
>
> I also believe that associating UNBIND with DELETE is fully
> compatible with current client expectations, namely that after
> they do a "DELETE xxx", a "GET xxx" will fail (perhaps with a 404),
> any entity caching associated with xxx should be invalidated,
> and a "PUT xxx" will return a 201 (Created).

I discussed this with Roy today, and it's his belief that the definition in
the HTTP spec. was made assuming that the binding and the resource were
indistinguishable, and hence "deleting the resource" in the HTTP spec. can
safely be reinterpreted as "remove the binding of the resource to the
Request-URI", since a downlevel client would not be able to distinguish
between a server following this unlink behavior, or the destroy semantics
that are implied by the current definition.

Thus I now feel much more comfortable reworking the definition of DELETE in
the Advanced Collections specification.

> The reason why it is essential for DELETE to have UNBIND semantics
> for versioning, is that a key characteristic of versioning is that
> you be able to recover previous "states" of the web site.  In particular,
> when one client issues a DELETE, another client with a different
> "workspace" still wants to be able to see that resource, and even after
> all clients have "accepted" that DELETE, a client will want to be able
> to find that old resource (in the revision history of the web site).
>
> All of this is possible if DELETE is interpreted as UNBIND, since
> the deletion of one binding is compatible with the resource still being
> visible under another binding (at a different URL).  So a versioning
> server can just perform an UNBIND whenever a client issues a DELETE.
>
> But if DELETE is interpreted as DESTROY, then a versioning server is
> forced to refuse to accept any DELETE calls (or risk violating one
> of the key goals of versioning), even though a client would
> have been been perfectly happy if just an UNBIND were performed.
> And then we would have to introduce a DESTROY operation anyway, for those
> times when you really *did* want to do a DESTROY.

This, in my mind, is a compelling reason to reinterpret the definition of
DELETE.


> In summary, our choices appear to be either:
>
> - interpret DELETE as UNBIND, and introduce a new DESTROY method, or

This is my choice.

- Jim

Received on Wednesday, 7 April 1999 20:30:53 UTC