RE: Move and Delete (was: bind draft issues)

To emphasize an earlier comment, it is true that the bind protocol
places constraints on how a server is allowed to implement the DELETE
and MOVE methods.  In particular, a server that supports the bind
protocol is not allowed to do a partial MOVE or a partial DELETE (even
though 2518 allows it).

In addition, section 2.3 does identify a way in which the bind
protocol differs from the semantics defined in 2518, i.e.:

 Section 8.6.1 of [RFC2518] states that during DELETE processing, a
 server "MUST remove any URI for the resource identified by the
 Request-URI from collections which contain it as a member."  Servers
 that support bindings MUST NOT follow this requirement."

A 2518 server that cannot (or does not want to) support the 
bind protocol constraints can certainly choose to not
support the bind protocol.

Cheers,
Geoff


-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]

On Monday, Brian Korver wrote:

> On Saturday, March 1, 2003, at 06:27  AM, Clemm, Geoff wrote:
> >
> >    From: Brian Korver [mailto:briank@xythos.com]
> >
> >    Move and Delete
> >
> >    The spec states that move and delete are merely operations
> >    on bindings.  At the very least, this is inconsistent with
> >    2518,
> >
> > How is this inconsistent with 2518 (other than the use of
> > terminology not defined in 2518)?
>
> 2518 correctly states that MOVE (and COPY) also may involve
> a DELETE with "Depth: infinity" operation in the case of
> overwrite.

It supports that.  What you're possibly refering to is the fact that
2518 let's the DELETE on a collection to delete some of the children
and abort before removing the colection itself and without backing out
what it did.  In the Bind Spec, there is no requirement to unbind
those child resources and in many cases you definitely don't want to
do that.  You only have to unbind the collection.  There is no partial
DELETE.  You just have to unmap that collection.  Whether that
reclaims resources is a different matter.


> DELETE also operates on more than bindings.  Consider,
> for instance, what happens to locks.

Yes, you can't break a lock without having the proper lock token
submitted, but you're not allowed to break the lock, but abort the
DELETE.  Nor are you somehow allowed to unmap the resource but not
remove the lock.  (At least not yet. :-))


> My reading of the document is different, so the language should be
> cleaned up so that it doesn't sound like it is prohibiting the
> semantics spelled out in 2518.  Would it help if I provided that
> text?

I actually just read it for the first time in a long time and it's
very clear that it doesn't speak of freeing up resources.  Except to
say that you "MAY" do it.

Received on Monday, 3 March 2003 16:45:26 UTC