W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

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

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

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

- 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:22 UTC