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

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