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

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