RE: Summary of ETag related issues in RFC2518bis

I agree we won't get this done for 2518bis.  Too bad.  Clients will just
have to keep sending head after put, and hoping nothing changed in
between.
 
    dan


________________________________

	From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm
	Sent: Thursday, December 22, 2005 06:00
	To: webdav
	Subject: Re: Summary of ETag related issues in RFC2518bis
	
	

	I agree with Julian that this is not something we should try to
resolve 
	in 2518bis, and given the need to focus this group on 2518bis, 
	I will restrain myself from using up any additional working
group bandwidth 
	on this (from my perspective, interesting) topic until 2518bis
(and BIND) 
	is finalized. 
	
	Cheers, 
	Geoff 
	
	
	Julian wrote on 12/22/2005 01:30:46 AM:
	> > Let me ask the  converse question: If the server has the
file, why
	> > can't it send the etag?  That's all the spec is saying it
should do.
	> 
	> 1) RFC2518 isn't saying it
	> 2) RFC2616 doesn't say what that means (or if it does it's
doing that in 
	> such a vague way that reasonable people disagreed about what
it means)
	> 3) The most widely deployed servers do not return an ETag (IIS
5.1, does 
	> anybody know about IIS 6), or return a weak ETag first
	> 
	> So this would be a normative change introducing a
less-than-well-defined 
	> requirement, which doesn't even reflect what most servers do
today.
	> 
	> So my proposal is to resolve 2) first, and then discuss an
extension of 
	> RFC2518 that relies on it (conceivably containing other stuff
like the 
	> requirement to store arbitrary dead properties and such). I
really don't 
	> see how we can get this done in the time that has been
allocated to us.