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

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:nn683849@smallcue.com]
  Sent: Wednesday, July 30, 2003 11:59 PM
  To: Julian Reschke
  Cc: w3c-dist-auth@w3.org
  Subject: RE: Etags changing on property value changes, WAS: rfc2518-bis-04
issues (part 1),



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