Behavior of getlastmodified, particularly with MOVE

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.

Received on Wednesday, 4 January 2006 18:48:07 UTC