- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Wed, 9 May 2001 16:11:13 -0700
- To: "Lisa Dusseault" <lisa@xythos.com>, "DeltaV" <ietf-dav-versioning@w3.org>, <w3c-dist-auth@w3.org>
Let me see if I can summarize points of consensus I saw in this thread. Problem Statement ----------------- The initial problem statement appears to be: In RFC 2518, the definition of the getlastmodified property is intentionally ambiguous on the issue of whether property changes cause the getlastmodified property to be updated. As well, the underlying definition of the Last-Modified header in HTTP is also ambiguous. The implied (but never explicitly stated) problem is that client implementors might want getlastmodified to have more precise semantics. In particular, it might be useful to know (a) *if* any (dead) property was changed (b) *when* any (dead) property was changed. (c) *when* the body (and only the body) was changed A client can observe the value of getetag to determine *if* the body has changed. However, no scenarios were provided to motivate this capability. Solution Space -------------- I detected no rough consensus on any solution. Assuming such a rough consensus is not developed, the likely outcome will be: - The specification of getlastmodified will remain the same. Solutions that were discussed, but which did not receive widespread support: - Introduce an "propetag" property that contained an etag for all (dead) property content. - Introduce a "proplastmodified" property that contained the last modified date for (dead) property modifications. - Introduce a "lasttouched" property that contained the timestamp of the last time the resource (either body or properties) was updated - Jim
Received on Wednesday, 9 May 2001 19:13:06 UTC