- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 26 Feb 2003 09:27:07 -0500
- To: "'Webdav WG'" <w3c-dist-auth@w3c.org>
I agree with Julian's points below. Cheers, Geoff -----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) Lisa, > 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) Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 26 February 2003 09:27:42 UTC