RE: "Lost Updates" still persist

If we decide to go the "Implementation Note" route, I would suggest
something more like the following for the new text.  The idea is to state
clearly what the problem is, why the protocol can't solve it, and what
clients and servers can do to help the situation.

4.3 Usage Considerations

Although the locking mechanisms specified here provide some help in
preventing lost updates, they cannot guarantee that updates will never be
lost.  Consider the following scenario:

Two clients A and B are interested in editing the file 'index.html'.
Client A is an HTTP client rather than a WebDAV client, and so does not
know how to do locking.

Client A doesn't lock the document, but does a GET and begins 
editing.
Client B does a LOCK, does a GET and begins editing.
Client B finishes editing, does a PUT, then an UNLOCK.
Client A does a PUT, overwriting and losing all of B's changes.

There are several reasons why the WebDAV protocol itself cannot prevent
this situation.  First, it cannot force all clients to use locking because
it must be compatible with HTTP clients that do not comprehend locking.
Second, it cannot require servers to support locking because of the variety
of configuration management systems, some of which rely on reservations and
merging rather than on locking.  Finally, being stateless, it cannot
enforce a sequence of operations like LOCK / GET / PUT / UNLOCK. 

WebDAV servers that support locking can reduce the likelihood that clients
will accidentally overwrite each other's changes by requiring clients to
lock resources before accessing them.  Such servers would effectively
exclude HTTP 1.0 and HTTP 1.1 clients.

WebDAV clients can be good citizens by using a lock / retrieve / write /
unlock sequence of operations (at least by default) whenever they interact
with a WebDAV server that supports locking.

HTTP 1.1 clients can be good citizens, avoiding overwriting other clients'
changes, by using entity tags in If-Match headers with any requests that
would modify resources. 

Information managers may attempt to prevent overwrites by implementing
client-side procedures requiring locking before accessing WebDAV resources.

--Judy




Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	(716) 422-5169
Fax:		(716) 422-2938

Xerox Corporation
Mail Stop 105-50C
800 Phillips Road
Webster, NY 14580

Received on Thursday, 19 February 1998 11:50:53 UTC