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

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

From: Elias Sinderson <elias@cse.ucsc.edu>
Date: Wed, 30 Jul 2003 16:54:50 -0700
Message-ID: <3F285ACA.5000000@cse.ucsc.edu>
To: w3c-dist-auth@w3.org
Julian Reschke wrote:

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

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
Received on Wednesday, 30 July 2003 19:54:51 GMT

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