Re: DELETE vs. UNBIND

   From: Jim Whitehead <ejw@ics.uci.edu>

   > From: Geoff Clemm <geoffrey.clemm@rational.com>
   > This proposal has the downside that instead of just issuing a DELETE
   > request, an advanced-collection aware client must first issue an UNBIND
   > request, and if that fails because the resource is not a member of an
   > advanced collection, it then issues a DELETE request.
   >
   > But I don't see any upside ... a server that supports advanced collections
   > must support UNBIND semantics, so how does it provide any benefit to
   > say that an UNBIND request MUST have unbind semantics, while a DELETE
   > request MAY have unbind semantics?  Perhaps I'm just missing what the
   > upside is?

   As discussed in the teleconference, the proposal was:

   UNBIND: MUST remove binding, MUST NOT destroy any state on the server
   DELETE: MUST remove binding, MAY destroy state on the server
   DESTROY: MUST remove binding, MUST destroy state

Yes, I remember the proposal.  It was the updside that I couldn't reconstruct.

   So, the upside was that DELETE would "do the right thing" for downlevel HTTP
   and DAV clients (like Office 2000),

That's what I don't get.  How can "MAY destroy state" be any more desireable
for a client (or serve to increase interoperability) than "MUST NOT destroy
state".  Requiring that DELETE on an advanced collection member be UNBIND
still gives downlevel HTTP and DAV clients no more or less than they could
expect from a conforming server.

   but that clients which understand the
   advanced collections specification could do more precise operations by
   selecting either UNBIND or DESTROY, where they'll know exactly what the
   server will do.

They can get the same precision with less effort if we define DELETE to
be UNBIND.  I still don't see any benefit to either an up or down level
client or server that results from introducing a separate UNBIND operation.

Cheers,
Geoff

Received on Saturday, 1 May 1999 23:27:35 UTC