RE: Summary of ETag related issues in RFC2518bis

We're getting closer... :) 

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

Yes.

> 
> - 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
that.

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

Yes.

> 
> 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.

    dan

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