W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 26 Feb 2003 09:27:07 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201FC3BC5@SUS-MA1IT01>
To: "'Webdav WG'" <w3c-dist-auth@w3c.org>

I agree with Julian's points below.


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Wednesday, February 26, 2003 3:23 AM
To: Lisa Dusseault; 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)


> It's still possible to make a stronger statement about Etag support in
> 2518bis.  Servers that are compliant with that, whatever RFC number it
> will be (maybe '4???'? )  must support strong Etags. Servers that are
> compliant with RFC2518 don't need to.
> I'm guessing Some clients will interoperate against both RFC2518 servers
> and RFC2518bis servers since they're very similar. But eventually,
> clients will be written that want the guarantees of "bis", including
> Etag support, and these clients will prefer to interoperate with servers
> supporting "bis".

Clients can detect the presence of etags right now. Clients are free not to
author (PUT/PROPPATCH) resources without etags right now. I really don't see
how this change will help anybody.

- it *will* make IIS and Apache/moddav (and a some others) non-conformant

- it *may* encourage server developers to claim strong etag support,
although their etags aren't really strong -- *this* will cause harm because
it may cause undetected lost updates

We really should restrict the changes to those for which we do have
consensus (and these really are clarifications):

- servers SHOULD support etags on authorable resources

- clients MUST be able to reliably detect etag support for a resource

- also add language that describes why locks may not prevent lost updates
(and therefore why strong etags are so desirable)


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 26 February 2003 09:27:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC