Summary: File creation date, version creation date, and getlastmodified

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