RE: Summary of ETag related issues in RFC2518bis

> The last part is important for a WebDAV client, since it wants to use 
> ETAG for optimistic  locking. It is not really interested in ETAG for 
> caching purposes.

Actually, I think a WebDAV client cares about both optimistic locking 
and caching.   
 
I strongly disagree.  I think the first author's statement is correct.
 
 Also note that they are rather intimately linked, since 
optimistic locking is based on knowing that the client's edits are based
on the 
text that is currently on the server, while caching is based on knowing 
that what the client currently has is based on the text that is
currently on 
the server.  
 
No.  Optimistic locking is based on knowing that the client's edits are
being applied to the content the client last sent to the server, and are
not overwriting other client's edits.  Caching is based on knowing that
the content you *last received* is the same as what you *would receive*
on your next get.
 
HTTP clients, whether webdav or not, know they must have *received* the
content associated with an etag in order to avoid fetching it again.
That's caching.
 
WebDAV clients only need to know that they *sent* the content associated
with an etag in order to avoid overwriting someone else's edits.  That's
optimistic locking.
 
    dan