Subject: RE: Etags changing on property value changes, WAS: rfc2518-bis-04 issues (part 1),

From: Jason Crawford <[email-masked]>
Date: Wed, 30 Jul 2003 17:58:47 -0400

> > I vote for the wording that is in there.  I think we've already 
reached
> > consensus that changing property values should not be changing etags.
> 
> Where and when?

Sorry.  I don't have a particular posting that declares consensus.  It was
just what I heard over and over again in postings.  People seemed 
comfortable declaring that changing properties should not change ETags. 
There was no significant opposition to it that I recall.

The issues list lists...

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0067.html

But I seem to recall that it was discussed more often than this.

As you (and Geoff in the referenced page) point out, some products will
become incompatible with 2518bis.   I believe people were aware of this,
but if they were not, you've just pointed it out.  They should speak up...

J.

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 31 Jul 2003 00:53:39 +0200

I guess we need to distinguish two cases:

- a PROPPATCH that indeed changes the result of a subsequent GET -- this is
a perfectly legal implementation, and I think nobody claims that if a
PROPPATCH changes what GET returns the etag shouldn't change as well --
thus: a PROPPATCH MAY change the etag if it changes the content as well,

- a PROPPATCH that does not affect the GETtable content -- I'm tempted to
agree that this SHOULD NOT change the etag.

The other issue was whether once we require this for etags, do we *also*
need to require it for getlastmodified? My concern here is that once we
normatively de-couple DAV:getlastmodified from property changes, there's no
standard date property left that a client could use to monitor *any* state
changes of the resource (which I think would be a really useful thing to
have).

So if RFC2518bis changes the requirements for DAV:getlastmodified, this
should *at least* appear in the issues list and should properly discussed on
the mailing list.

Julian

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

  -----Original Message-----
  From: Jason Crawford [mailto:[email-masked]]
  Sent: Wednesday, July 30, 2003 11:59 PM
  To: Julian Reschke
  Cc: [email-masked]
  Subject: RE: Etags changing on property value changes, WAS: rfc2518-bis-04
issues (part 1),

reached

  The issues list lists...

  J.

---

From: Elias Sinderson <[email-masked]>
Date: Wed, 30 Jul 2003 16:54:50 -0700

Julian Reschke wrote:

> - a PROPPATCH that indeed changes the result of a subsequent GET -- 
> this is a perfectly legal implementation, and I think nobody claims 
> that if a PROPPATCH changes what GET returns the etag shouldn't change 
> as well -- thus: a PROPPATCH MAY change the etag if it changes the 
> content as well,
>  
> - a PROPPATCH that does not affect the GETtable content -- I'm tempted 
> to agree that this SHOULD NOT change the etag.

I think we're converging on this...

> The other issue was whether once we require this for etags, do we 
> *also* need to require it for getlastmodified? My concern here is that 
> once we normatively de-couple DAV:getlastmodified from property 
> changes, there's no standard date property left that a client could 
> use to monitor *any* state changes of the resource (which I think 
> would be a really useful thing to have).

If clients can rely upon ETags not changing unless the GETable content 
has changed, then there is no reason to depend on DAV:getlastmodified 
for this. Furthermore, if this were the case, the notion of a PTag is 
superfluous as a client could simply check that the ETag hasn't changed 
while the DAV:getlastmodified value had...

> So if RFC2518bis changes the requirements for DAV:getlastmodified, 
> this should *at least* appear in the issues list and should properly 
> discussed on the mailing list.

Agreed.

Cheers,
Elias

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 31 Jul 2003 09:30:46 +0200

What I  recall from the discussions is that we do not want the ETag or
getlastmodified to change when the content of the resource stays
as it is.

Some people had the notion that ETag/lasmodified needed to change
on PROPPATCH and that is definitely not desired. However iff upon
PROPPATCH the content of a resource also changes, the ETag MUST
change.

So, saying that PROPPATCH MUST not change the ETag is not what
we want.

What the intention of our consensus-reaching discussion was is:

PROPPATCH on a resource SHOULD NOT modifiy the ETag/getlastmodified
live properties unless the content/representation of the resource
changes as well. On content changes ETag/getlastmodified MUST
change as already required by HTTP/1.1 (RFC2616).

This issue is not heavy enough to render existing implementations
non-compliant. One can look at it as a word of advise to server
implementors in order to improve HTTP caching performance.

//Stefan

Am Mittwoch, 30.07.03, um 23:58 Uhr (Europe/Berlin) schrieb Jason