RE: Stronger requirements for ETags

I agree with Julian that the most/best we can do is explain why
it is a SHOULD.  In particular, making it a MUST is very likely
to cause new client writers to write clients that will fail to
to work with a large number of existing servers, and that I think
would be a serious problem.

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 06/22/2003 10:06:55 AM:

> 
> > ...
> >
> > So, what now?  Does the current language (03) make mod_dav or IIS 
> > (or other implementations) uncompliant with 03?  Is that a 
> 
> I think so, because both use a "promotion strategy", in which upon 
> PUT only a weak ETag is returned, which, after some delay, is 
> "promoted" into a strong ETag.
> 
> > problem?  Would it be a bad idea to upgrade mod_dav or IIS to 
> > become compliant with RFC2518bis if it goes to RFC with these 
> 
> Of course that would be good, but these servers use this approach 
> for a very good reason (being that they *can't' produce the strong 
> variant at resource creation time).
> 
> > requirements?  I'd point out that there are other changes that 
> > already make servers slightly uncompliant with RFC2518bis -- e.g. 
> > the removal of specially-behaving lock-null resources makes 
> > existing servers supporting lock-null resources "uncompliant". 
> 
> True.
> 
> > But being uncompliant with a spec that the server doesn't declare 
> > compliance to shouldn't be a problem!  A server will continue to 
> > be compliant with 2518 because that can never be replaced. Server 
> > implementors may upgrade their code/product to become compliant 
> > with RF2518BIS (whatever rfc number that turns out to be) and 
> > then declare compliance with that new, more stable standard.
> 
> True as well.
> 
> My primary concern is that if we put in a change that isn't and 
> furthermore *won't* be implemented by the two must widely used 
> implementations, we have a severe problem with the spec. So it would
> be really good to understand the issue (maybe Greg Stein can say 
> something about it) and find out whether at least Apache/mod_dav is 
> going to be updated.
> 
> I personally see no use in the "promotion" strategy. If you can't 
> produce a useful ETag upon PUT, don't.
> 
> > IF the language must be weakened, is there any point to this at 
> > all?  I'm afraid we've got to make a hard choice.  Either we do 
> > something real to encourage ETag support, even though it makes 
> > existing servers "uncompliant".  Or we do nothing, and we leave 
> > the problem unmitigated.
> 
> But then there's the risk that popular servers like mod_dav never 
> will be updated to RFC2518bis conformance, just because it ask for 
> things that can't be implemented. Or worse yet, the servers may 
> claim compliance although they don't comply.
> 
> So I agree to any kind of text that explains *why* strong ETags are 
> important, but I object to make them mandatory unless we can at 
> least mod_dav support them properly.
> 
> > As a server implementor, my personal opinion is that it's a good 
> > idea to make, and follow, stricter requirements for ETag support. 
> >  It's so helpful to clients and users (in terms of robust and 
> > reliable distributed authoring) that it's worth the cost. 
> 
> How do you calculate the cost in the case of mod_dav/fs, where 
> clearly robust strong ETags can't be calculated without having 
> additional metadata? Keep in mind that mod_dav is just an extension 
> to the base HTTP server, such mod_dav's ETag handling must be 
> identical to Apache/Httpd's.
> 
> Julian
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
> 
>