DELETE Semantics

<gmc/> I personally believe that the best answer is to fix the LOCK
semantics so it *really* is just on the resource (and not on the
name).  Then things are simpler and consistent, even in the case of
multiple URL mappings to a resource.  Rather than "protecting" a URL
to resource mapping, I'd propose that a locked resource be allowed to
MOVE (this is just a change to the state of the parent collection, not
to the state of the resource being moved), but that an attempt to
access the MOVE'd resource with that lock just returns a 302 indicating
where it has MOVE'd to.
<jra>
But some moves will result in a change in state of the resource being
moved, and this is server dependent. The new parent collection may be
in a collection that has different OPTIONS then the old parent, e.g.,
in a different repository manager. It may also have different live
properties. This isn't just a cross-server move issue.

The semantics of MOVE can't be defined as rebind (rename)
and copy/delete at the same time. MOVE can however be implemented that
way. As a result, one doesn't know if the resource is new or not after
a MOVE, and therefore locks can't be guaranteed to be retained.
Therefore, the semantics must pick the conservative case and not move
locks. Take for example moves in typical file systems. Sometimes the
file actually moves (gets a new INODE in UNIX) and sometimes it doesn't
Users don't see this unless they are manipulating INODES directly which
is playing with the implementation, not the protocol.

Moving locks has lots of other problems too as there is a possible conflict
with the potentially inherited lock from the new destination parent collection.
Lock tokens are server dependent, and may be repository dependent too.
Seems like loosing the lock is the lesser of the evils.
</jra>


<gmc/> So there are really multiple threads here:
- Should locking be on a resource or also/instead on a URL-to-resource
  mapping?  (we know what it is now, but what *should* it be)
* I vote "on a resource".
<jra>
I agree. The resource is the thing being manipulated, not the URL. The
URL is only a way to get to the resource. There may be other ways, and
no way.
</jra>

- Does a DELETE delete all bindings to a resource, or just the one
specified in the request-URL.
* I vote "just the one named by the request-URL".
<jra>
I have to disagree with this one as it is not consistent with LOCK.
If LOCK, GET, PUT, etc. apply to the resource, then so should DELETE.
If bindings are created with a BIND method, then they should be removed with
an UNBIND method. Otherwise, URL to resource mappings (i.e., bindings)
must be exposed as separate resources (direct and redirect referencs)
so they can be managed discretely. DELETE should stick to manipulating
resources as defined in HTTP/1.1.
</jra>

- Should a DELETE delete a LOCK?
* I vote, "no".  A DELETE modifies the state of the collection containing
  the binding, not that of the resource.  In particular, all other
  mappings to that resource will continue to exist and display the
  LOCK'ed semantics.  If you want to prevent a DELETE, you put the
  LOCK on the collection whose state is being modified.
<jra>
I wish I could agree with this one, but I can't. DELETE deletes a resource
and as a side effect it modifies the state of its parent collection(s).
It is unfortunate that PUT and DELETE are resource behaviors instead
of having addMember, removeMember be operations on the parent collection.
It is hard to recover from the resulting mixed semantics, but WebDAV does
a reasonable job already. I think we should leave this alone.
</jra>

Received on Friday, 24 September 1999 09:47:11 UTC