W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 29 Nov 2005 21:07:29 +0100
Message-ID: <438CB501.9070001@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: Wilfredo Sánchez Vega <wsanchez@apple.com>, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, WebDav <w3c-dist-auth@w3.org>, Cullen Jennings <fluffy@cisco.com>

Lisa Dusseault wrote:
> I hadn't thought that a client could use weak etags at all for 
> authoring.  I had started from considering the cases of a JPG or a 
> Photoshop file or a Word document.  What does a weak ETag mean for those 
> documents?  If I edit a Word document on a WebDAV server and all I do is 
> fix a couple inconsistent fonts and a space or two, one might think that 
> the weak ETag need not change -- but I would not find the system very 
> usable if these changes were lost on a subsequent update.

Of course it's not always simple to define what "semantically 
equivalent" means. For instance, if a server would take the Word 
document and remove all implementation artefacts (for which there are 
cleanup tools nowadays), I'd call that "semantically equivalent", and a 
useful feature.

Servers like these exist, and making the revision of WebDAV inherently 
incompatible with them IMHO is an extremely bad idea. Fortunately, I'm 
pretty confident that the community wouldn't let us get away with that.

It seems that you have a very specific authoring scenario in mind, which 
you'd like to be simpler to support in a client. How about summarizing 
the *precise* requirements first, then think about the right technical 
approach, and only then discuss a way what to do in the spec? Yes, 
that's more work to do then simply stating "Strong ETags are now 
required", but it's the better approach nevertheless.

Best regards, Julian
Received on Tuesday, 29 November 2005 20:09:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC