Subject: Behavior of getlastmodified, particularly with MOVE

From: Lisa Dusseault <[email-masked]>
Date: Wed, 4 Jan 2006 10:47:53 -0800

Currently RFC2518 has a hole where the behavior of DAV:getlastmodified 
is underspecified.  Servers can do a variety of things and clients 
can't be sure what the value means or when it changes -- particularly 
on a MOVE.  This email is intended to open a discussion on how we might 
close this spec hole.

Some overarching goals for a discussion on the behavior of 
DAV:getlastmodified (naturally these goals also open for debate but 
it's good to state one's assumptions):
  - We still want the property value to be consistent with the 
Last-Modified header value
  - We don't want to break caching based on Last-Modified (such as it is)
  - Although we do have to be aware of existing implementations, it 
would improve the situation if we can start server implementations on a 
path to be more consistent with each other.  (Just like with 
preservation of XML prefixes, we know that there are implementations 
that don't preserve those, but with RFC2518bis we move them towards 
preserving them.)

So what kind of behavior could we specify for DAV:getlastmodified?
  1. We can't say that DAV:getlastmodified is always preserved on a 
MOVE.  That breaks cachability in many cases -- the case where the 
destination already has a resource, or previously had a resource, with 
a DAV:getlastmodified value later than the value of the source 
resource.  If that happened, then the client might see a resource with 
a Last-Modified date which goes backwards in time[1].
  2. Another absolutist approach would be to say that 
DAV:getlastmodified is always reset on a MOVE.  This would never break 
cachability, I believe.
  3. There might be a middle-of the-road proposal but it would certainly 
be less principled.

As part of the discussion on this, it would be interesting to hear:
  - What are peoples' thoughts on how DAV:getlastmodified ought to work, 
regardless of what implementations do?
  - What do specific implementations do?
  - Are there other unspecified holes besides MOVE behavior?

Lisa

[1]  Note that this description of Last-Modified dates going backwards 
in time has been reported as occurring in some implementations.  This 
is a particular reason to give server implementors some more guidance 
on how to handle MOVE and Last-Modified.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 4 Jan 2006 14:30:21 -0500

Given the range of WebDAV implementations that I'd want to allow,
I don't believe DAV:getlastmodified is underspecified in 2518.
In particular, I believe a server implementation needs the freedom
to do whatever it wants/needs to do, as long as it satisfies the
current specification in 2518 (i.e., that it should contain
the value of the Last-Modified header as defined by HTTP).

So for MOVE, a server can do whatever it wants as long as it satisfies
the 2518 specification, which means that in some cases, the
DAV:getlastmodified property of a resource will have to change after that
resource has been MOVE'd, but in some cases (such as when no 
resource existed at the MOVE destination), the DAV:getlastmodified
will not have to be modified (and therefore it is up to the server
as to whether or not it modifies the DAV:getlastmodified property).

Cheers,
Geoff