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

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 17 Sep 2002 22:57:16 -0400

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: "Eric Sedlar" <[email-masked]>
Date: Wed, 18 Sep 2002 00:09:31 -0700

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.

--Eric

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 18 Sep 2002 10:07:42 +0200

> 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

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 18 Sep 2002 10:33:36 +0200

Eric,

the problem in requiring things is that you may get what you thought you
want, but then discover it was wrong to ask for it.

If you declare a server that doesn't have entity tags non-compliant, you
might get the server implementor to reconsider his/her decision. In some
cases, there may be a very good technical reason not to supply entity tags -
for instance, if your store is a file system, and you don't have any
additional place for metadata. Computing a reliable entity tag just from the
file's properties (timestamp, length...) is impossible, but the implementor
might attempt it anyway. In the end you'll get a server that *does* supply
entity tags, but they only work most of the time, so they aren't reliable.
That's worse than not having them at all.

So, there are valid reasons for RFC2616 to make these things optional (same
for server timestamps). I'm happy with language that explains that entity
tags are an important feature, but it should also make clear that if a
server can't provide reliable entity tags, it shouldn't attempt to.

Julian

> [mailto:[email-masked]]On Behalf Of Eric Sedlar
> Sent: Wednesday, September 18, 2002 9:10 AM
> To: Webdav WG

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 18 Sep 2002 11:04:21 -0700

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.

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 18 Sep 2002 11:08:48 -0700

Well, it really all depends on how compelling the use cases are that require
ETag support.  It's ok to make servers do things that may be hard for some
implementations if it delivers solid benefits for the client.  I heard some
pretty solid use cases at the Interop event.

In your filesystem example, as long as all of the access to the files can be
intercepted by the server software somehow, keeping around an ETag is not a
big problem as you can bump up a sequence number on each write.  A simple
filesystem based server may also have problems with supporting UUIDs as
well.

--Eric

----- Original Message -----
From: "Julian Reschke" <[email-masked]>
To: "Eric Sedlar" <[email-masked]>; "Webdav WG"
<[email-masked]>
Sent: Wednesday, September 18, 2002 1:33 AM
Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 18 Sep 2002 20:15:19 +0200

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

> Sent: Wednesday, September 18, 2002 8:04 PM
> To: Stefan Eissing
> Cc: Webdav WG

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 18 Sep 2002 20:28:14 +0200

> Sent: Wednesday, September 18, 2002 8:09 PM
> To: Webdav WG

Hard yes, impossible no.

If a server that complies to RFC2518 doesn't comply to RFC2518bis, then
we've broken the IETF publication process, haven't we?

> big problem as you can bump up a sequence number on each write.  A simple

Incrementing sequence numbers isn't the problem. Persisting them may be.

> filesystem based server may also have problems with supporting UUIDs as

UUIDs for what?

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 18 Sep 2002 11:52:38 -0700

> we've broken the IETF publication process, haven't we?

I don't think that's necessarily true.  I checked with my local IAB
member, and we don't think it's forbidden to upgrade a standard from
Proposed Standard to Draft Standard, even if in the process the standard
becomes somewhat more stringent in what constitutes compliance from
implementations. (He says particularly if the requirement is a SHOULD
now.)  It's a difficult judgement call, and one must weigh the
interoperability concerns of both making and not making the change. But
in principle, it's not forbidden. 

Our ADs will certainly weigh in on this when we've hashed it out more
amongst ourselves, but in the meantime we shouldn't have to restrict
ourselves rigidly in this matter.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 18 Sep 2002 21:11:13 +0200

> Sent: Wednesday, September 18, 2002 8:53 PM
> To: 'Julian Reschke'; 'Webdav WG'

But it isn't a SHOULD right now.

RFC2518 says:

"The getetag property MUST be defined on any DAV compliant resource that
returns the Etag header."

So if I have an HTTP resource for which HEAD/GET wouldn't return an ETag
header, it's absolutely OK not to return the DAV:getetag property.