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

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 2 May 2001 14:24:51 -0700

WebDAV people:  RFC2518 leaves it carefully open whether 'getlastmodified'
changes when properties of the resource change.  It seems useful either
way -- users might want to get the last time the content was changed, or
they might want to see the last time the file was touched at all.  Is there
some precedent?  Really, one might best be served by a new timestamp
property, so the suite of timestamp-like properties would be
 - creationdate
 - time the content was last modified (etag changes, but etag doesn't
provide a timestamp)
 - time the file was last touched

Which one of the last two is most commonly handled by getlastmodified?
Implementors speak up?

DeltaV people: What does it mean to get the time file content was last
"modified", if the file is versioned?  I don't see that the behaviour of
getlastmodified is specified for a Version-Controlled Resource, can this be
a recommendation in the spec to promote consistency?  For one thing, should
'getlastmodified' on the VCR change when it is checked out, or when it is
checked in, or both?

lisa

---

From: "Douglas R. Steen" <[email-masked]>
Date: Wed, 2 May 2001 19:41:16 -0500

re: WebDAV.

My vote would be changing getlastmodified when the properties change.  As we
use properties more and more, they become a true part of the file in the
user experience.  Trying to distinguish between the two ("I know you changed
the billing number yesterday, but you didn't change the _content_ so the
date still reads last week...") can be difficult.

Unfortunately, it's a very easy shorthand for server implementations to use
the file last-modified date for getlastmodified, and for the operating
systems I know that reflects the date/time of the last content modification.

  Douglas R. Steen
  [email-masked]
  Drag-and-Drop Web File Management
  http://www.eKeeper.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Lisa Dusseault
Sent: Wednesday, May 02, 2001 4:25 PM
To: DeltaV; [email-masked]
Subject: File creation date, version creation date, and getlastmodified

lisa

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 2 May 2001 14:58:25 -0700

We update getlastmodified whenever properties or contents change.  Either
of these is reflected in the ETag.  I'm not sure we need another property
to handle changes to the properties separately.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Wednesday, May 02, 2001 2:25 PM

---

From: "Dan Brotsky" <[email-masked]>
Date: Wed, 2 May 2001 19:09:00 -0700

At 2:24 PM -0700 5/2/01, Lisa Dusseault wrote:
>some precedent? ...

At Adobe our various servers take different positions on this.  We 
have found that clients which have transitioned from doing FTP to 
doing DAV and HTTP 1.0 clients tend to use getlastmodified where they 
really should be using etags, so servers that cater to those clients 
("general purpose servers" :^) are careful not to tamper with 
getlastmodified unless the content changes.  But our high-end 
workflow servers expect savvy clients and users who really care about 
property (read workflow) changes, so they update whether or not 
content changes.

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:[email-masked]>

---

From: "Adam Freeman" <[email-masked]>
Date: Thu, 3 May 2001 12:03:42 -0700

Hello,
why not have two different last modified dates, one for the content and one
for the metadata?
- Adam

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Douglas R. Steen
Sent: Wednesday, May 02, 2001 5:41 PM
To: [email-masked]
Subject: RE: File creation date, version creation date, and
getlastmodified

re: WebDAV.

  Douglas R. Steen
  [email-masked]

-----Original Message-----

lisa

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 9 May 2001 16:11:13 -0700

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

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 9 May 2001 16:32:56 -0700

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
"getlastmodified".

--Eric

> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Wednesday, May 09, 2001 4:11 PM
> To: Lisa Dusseault; DeltaV; [email-masked]
> Subject: Summary: File creation date, version creation date, and
> getlastmodified
>
>

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 10 May 2001 10:44:41 -0700

> "proplastmodified" or "lasttouched", along with disambiguating

Since the mailing list is the final arbiter of consensus, why not resolve
the issue on the list? Many issues in other IETF standards get resolved this
way...

One thing that could help move this issue forward is for someone to post a
message to the list, in specification langiuage, giving a concrete proposal.
I haven't seen one yet...

- Jim