RE: DELETE vs. UNBIND

> 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

So, the upside was that DELETE would "do the right thing" for downlevel HTTP
and DAV clients (like Office 2000), 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.

- Jim