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".

that would only be an option if this would be the only difference between
RFC2518 and RFC2518bis, and then if there would be no other future
extensions.

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 03:24:00 UTC