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

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 26 Feb 2003 09:27:07 -0500

I agree with Julian's points below.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
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

---

From: Jason Crawford <[email-masked]>
Date: Wed, 26 Feb 2003 18:36:26 -0500

Again, I agree with Julian.  This doesn't look like chicken/egg problem to
me.   The check doesn't appear to be difficult/expensive for most clients
and it's definitely valuable.

If there is no reason for a client to believe that checking the etag will
create a breakage or incompatibility, clients will implement etag checking.

------------------------------------------
Phone: 914-784-7569,   [email-masked]
I do not check [email-masked]