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

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

From: Eric Sedlar <eric.sedlar@oracle.com>
Date: Wed, 9 May 2001 16:32:56 -0700
To: "DeltaV" <ietf-dav-versioning@w3.org>, <w3c-dist-auth@w3.org>
Message-ID: <NDBBKNOGFKEBJOOOIOOLKEKACBAA.eric.sedlar@oracle.com>
I believe that one or more of the possible solutions to this could
receive a consensus after a face-to-face discussion.  I suggest bringing
this one up again at the next IETF.  I for one would be happy with either
"proplastmodified" or "lasttouched", along with disambiguating


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Whitehead
> Sent: Wednesday, May 09, 2001 4:11 PM
> To: Lisa Dusseault; DeltaV; w3c-dist-auth@w3.org
> Subject: 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:29:20 UTC

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