Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 18 Sep 2002 17:29:14 -0400

And even if we are theoretically allowed to make such a change,
I believe we should do so only for the most compelling reasons,
since a change of this kind will make an implementor much less likely
to put a great deal of effort into supporting a given RFC if
the working group has a track record of releasing later revisions
of that RFC that put their original implementation into non-compliance.

On a related topic, working to marshall new functionality through
existing machinery rewards an implementor for going to the effort of being
fully compliant, and increases the likelihood that implementors will bother
to do so.  

Otherwise, we are sending out the message that an implementor
should just implement the subset they feel like in the way that the
feel like, counting on "interoperability concerns" to cause the protocol
to be revised to match their implementation.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 2:15 PM
To: Eric Sedlar; Stefan Eissing
Cc: Webdav WG
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting

Eric,

if RFC2518bis requires ETag support, old, otherwise RFC2518-compliant and
non-ETag-supporting servers will not be compliant to RFC2518bis. So
something that was fully compliant before, isn't in the with the revision. I
don't think this is allowed at this publication stage.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Eric Sedlar
> Sent: Wednesday, September 18, 2002 8:04 PM
> To: Stefan Eissing
> Cc: Webdav WG
> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
>
>
>
> I still don't see how if RFC2518bis requires ETag support it would
> invalidate existing servers.  Clients will continue to support ETag-less
> servers to support an older version of the WebDAV spec, until ETag-less
> servers are phased out.
>
> ----- Original Message -----
> From: "Stefan Eissing" <[email-masked]>
> To: "Eric Sedlar" <[email-masked]>
> Cc: "Webdav WG" <[email-masked]>
> Sent: Wednesday, September 18, 2002 1:07 AM
> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
>
>
> >
> > Am Mittwoch den, 18. September 2002, um 09:09, schrieb Eric Sedlar:
> >
> > >
> > > RFC2518bis wouldn't invalidate a class of servers if it includes a
> > > new token
> > > in the DAV: header to indicate support for RFC2518bis.  Clients
> > > would still
> > > have to deal with no-Etag servers to support RFC2518, but this might
> > > accellerate implementation of Etags.
> >
> > But support for ETag on a resource is visible on the getETag Property.
> > What better place to look for ETag support than there?
> >
> > //Stefan
> >
> >
> > > --Eric
> > >
> > > ----- Original Message -----
> > > From: "Clemm, Geoff" <[email-masked]>
> > > To: "Webdav WG" <[email-masked]>
> > > Sent: Tuesday, September 17, 2002 7:57 PM
> > > Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
> > >
> > >
> > >>
> > >> I have no objection to such a warning (in fact, it sounds
> > >> like a good idea to me).  But I agree with Julian
> > >> that RFC2518bis should not invalidate a whole class of
> > >> valid 2518 servers, even for a worthy cause such as ETag support.
> > >>
> > >> Cheers,
> > >> Geoff
> > >>
> > >> -----Original Message-----
> > >> From: Eric Sedlar [mailto:[email-masked]]
> > >> Sent: Tuesday, September 17, 2002 8:47 PM
> > >> To: Clemm, Geoff; Webdav WG
> > >> Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting
> > >>
> > >>
> > >> As long as you don't mind a client saying something to the effect of:
> > >>
> > >> "This server does not support the minimal level of functionality that
> > >> <product> requires of a WebDAV server (ETags).  We strongly
> > >> discourage you
> > >> from using this server, as you may lose work."
> > >>
> > >> when it points at your server, then go ahead and don't support ETags.
> > >>
> > >> --Eric
> > >>
> > >> ----- Original Message -----
> > >> From: "Clemm, Geoff" <[email-masked]>
> > >> To: "Webdav WG" <[email-masked]>
> > >> Sent: Tuesday, September 17, 2002 6:50 AM
> > >> Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting
> > >>
> > >>
> > >>>
> > >>> I agree.
> > >>>
> > >>> -----Original Message-----
> > >>> From: Julian Reschke [mailto:[email-masked]]
> > >>> Sent: Tuesday, September 17, 2002 4:58 AM
> > >>> To: Lisa Dusseault; Webdav WG
> > >>> Subject: ETags, was: Issues from Interop/Interim WG Meeting
> > >>>
> > >>>
> > >>>
> > >>>> From: [email-masked]
> > >>>> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> > >>>> Sent: Sunday, September 15, 2002 8:14 PM
> > >>>> To: Webdav WG
> > >>>> Subject: Issues from Interop/Interim WG Meeting
> > >>>>
> > >>>> ...
> > >>>> -  Be clear in spec that servers MUST do ETags. Explain how
> > >>>> necessary
> > >>>> this is to solve the lost update problem.
> > >>>> ..
> > >>>
> > >>> ETags are a good thing, correct. However, HTTP (RFC2616) doesn't
> > >>> require
> > >>> them, RFC2518 doesn't require them, and they '*aren't* required for
> > >>> interoperability. So there's no way to require them in
> > >>> RFC2518bis -- it
> > >>> would break all servers that don't have them.
> > >>>
> > >>> Julian
> > >>>
> > >>> --
> > >>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
> >
> >
>

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 19 Sep 2002 11:51:48 +0200

Some more thoughts on ETags:

1) Even for a server that *in general* supplies ETags, there may be some
special resources that can't have them. So requiring them won't work.
Example: a very common implementation for WebDAV ACL principal resources
will be a proxy resource that talks to a usermanagement back-end. These
resources may have content (for instance, a vCard entity body), but they
won't have an entity tag (because they are dynamically generated from a
remote object). This basically applies to all resources that are dynamically
created and not easily cached. So is a server that has GETtable, but
non-cacheable principal resources compliant to RFC2518bis?

2) It was said that lack of ETag is an interop problem. I can see why some
authoring clients would want to require that a resource that they are going
to modify has valid ETags. However, on a RFC2518-compliant server a client
can easily detect whether ETags are supported, and thus refuse to modify the
resource accordingly. This really isn't a problem -- it just means that a
particular client can't modify a particular resource, and the user can be
notified. However, it would be a much bigger problem if a server claims that
it has ETags, but they don't work properly. In this case, the user agent
will try to take advantage of ETag handling, and this may result in lost
updates, faulty cache contents and so on. So *this* is what the revision of
RFC2518 should say: if you can't provide proper ETags for a resource, it's
better that you *don't* try and thus let clients that rely on proper ETag
handling fail in a predictable way.

Julian