ETags, next call, was: Notes on call from today ...

Hi,

two more things.

1) Next call is *tomorrow*, Friday, 9am Pacific time (2005-11-25T17:00Z).

2) We also talked about issue 13 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13>):

I'd like to clarify that yes, I also do prefer resources that support 
strong ETags, and do that upon PUT. I also realize that a huge class of 
clients will have trouble synchronizing when a server behaves differently.

On the other hand, WebDAV is *not* a remote file system protocol. This 
is important!

There is a big spectrum of Web servers that may have WebDAV support, and 
those that effectively can be used as a file system replacement
are only a subset. Baking new requirements into the base spec that would 
make other servers non-compliant is IMHO an extremely bad idea.

For example, vendors (Software AG, Oracle?) have implemented (or may be 
implementing) WebDAV on top of XML-based stores. These stores may 
support strong ETags, but not guarantee octet-for-octet equivalence 
between those things you PUT, and those you'll GET later. This is OK in 
HTTP, and it currently is in WebDAV. Do we really want to make it 
impossible to run WebDAV on top of these stores???

So what I would propose is to

a) agree on a certain set of server features that those clients expect 
(strong ETag on PUT, octet-for-octet identity of representations, ...), then

b) define a profile for WebDAV that covers this, and a simple way for 
clients to discover whether any given resource supports this.

IMHO this definition should go into a separate document. This will also 
  reduce the amount of open issues on RFC2518bis for now.

Best regards, Julian

Received on Thursday, 24 November 2005 13:33:24 UTC