W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

Re: ETags, was: Issues from Interop/Interim WG Meeting

From: Eric Sedlar <eric.sedlar@oracle.com>
Date: Wed, 18 Sep 2002 11:04:21 -0700
Message-ID: <01e001c25f3d$d0b45c40$9b114498@esedlar>
To: "Stefan Eissing" <stefan.eissing@greenbytes.de>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>

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" <stefan.eissing@greenbytes.de>
To: "Eric Sedlar" <eric.sedlar@oracle.com>
Cc: "Webdav WG" <w3c-dist-auth@w3c.org>
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" <gclemm@rational.com>
> > To: "Webdav WG" <w3c-dist-auth@w3c.org>
> > 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:eric.sedlar@oracle.com]
> >> 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" <gclemm@rational.com>
> >> To: "Webdav WG" <w3c-dist-auth@w3c.org>
> >> 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:julian.reschke@gmx.de]
> >>> Sent: Tuesday, September 17, 2002 4:58 AM
> >>> To: Lisa Dusseault; Webdav WG
> >>> Subject: ETags, was: Issues from Interop/Interim WG Meeting
> >>>
> >>>
> >>>
> >>>> From: w3c-dist-auth-request@w3.org
> >>>> [mailto:w3c-dist-auth-request@w3.org]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
> >>>
> >>>
> >>
> >>
> >
> >
>
>
>
>
Received on Wednesday, 18 September 2002 14:08:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:01 GMT