Re: Behavior of getlastmodified, particularly with MOVE

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

Lisa wrote on 01/04/2006 01:47:53 PM:
> 
> 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.
> 
>