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

RE: Summary of ETag related issues in RFC2518bis

From: Dan Brotsky <dbrotsky@adobe.com>
Date: Tue, 20 Dec 2005 22:08:34 -0800
Message-ID: <E1F796B37FB8544FA09F6258E7CED3BB4B934C@namail3.corp.adobe.com>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Geoffrey M Clemm" <geoffrey.clemm@us.ibm.com>, <w3c-dist-auth@w3.org>

We're getting closer... :) 

> So let's look at what clients are interested in again:
> - they want to avoid fetching an ETag after PUT,


> - in some cases, they want to be able to find out whether the 
> server stored exactly what they sent,

No.  I claim no client wants to know this.  Ever.  If they really want
to know that the content matches what they have, then they use a server
that supports MD5 hashes and they rely on those.

If they are worried about network corruption then TCP/IP has things for

> - if they interleave PUT and PROPPATCH, they want their ETags 
> to continue to work.


> I believe all of these things can be accomplish by protocol 
> extensions, and I'll be happy to spec them out. On the other 
> hand, I don't think it would be a good idea to rush them into 
> RFC2518bis, which was supposed to be finished around this 
> time of year (if I may remember).

I believe all of these things that clients want are accomplished with
what we have, as long as we have servers hand back strong etags on PUT.

Received on Wednesday, 21 December 2005 06:08:47 UTC

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