WebDAV Bindings - Issue Yaron.AtomicMove

The last paragraph of section 8 reads: "Although [WebDAV] allows a MOVE on a
collection to be a non-atomic operation, the MOVE operation defined here
MUST be atomic.  Even when the Request-URI identifies a collection, the MOVE
operation involves only removing one binding to that collection and adding
another.  There are no operations on bindings to any of its children, so the
case of MOVE on a collection is the same as the case of MOVE on a
non-collection resource.  Both are atomic."

As there is no way to tell the difference between a URI that was mapped
through a BIND method and a URI that was mapped through a MKCOL the effect
of this paragraph is to re-write RFC 2518 to make MOVE atomic. The issue
here is largely a repeat of the issues addressed in Yaron.AtomicDelete.

An additional issue, beyond Yaron.AtomicDelete, is that MOVE in most file
systems is actually implemented as a copy followed by a delete, at least in
the case of directories. Hence file systems can not implement atomic moves.
Hence requiring atomic moves means that file systems can not implement
WebDAV.

Furthermore even though some of the more advanced file systems can handle
atomic MOVEs, they can only do so within a single volume. This would mean
that a server which had more than one file volume would have to refuse user
requests to move files across the volumes solely because it could not do so
atomically.

Finally, the title of DAV begins with a D for a very specific reason.
Requiring atomic behavior on MOVEs will prevent all but the highest end
systems from being able to MOVE files between systems because the
cooperating systems would have to implement a transactioning system between
themselves.

As such I move that the atomic MOVE language be struck from the BIND spec on
the grounds that it reduces interoperability, requires behavior that would
preclude file system based systems from supporting WebDAV and significantly
hinders WebDAV's ability to act in a distributed manner.