RE: Changing etag and getlastmodified on move/rename

Lisa,

you are right that WebDAV absolutely can't overrule what RFC2616 (HTTP/1.1) says about the Last-Modified header and caching. Thus

1) We probably should clarify the COPY/MOVE behaviour. Currently the draft says:

"COPY/MOVE behaviour: This property value is dependent on the final 
            state of the destination resource, not the value of the 
            property on the source resource. It MUST NOT be set in 
            PROPPATCH during a cross-server copy. "

How is the previous DAV:getlastmodified date of the destination resource relevant?

I think the only safe way to respect RFC2616 semantics is to require that after a COPY/MOVE, DAV:getlastmodified is set to the current date.


2) I also agree that this is likely to cause complaints from people who actually want a time stamp for *resource* modifications. A proper way to address this may be to define a new optional property (if we make it optional, we may be able to get it into RFC52518bis), for instance:

   Name:    modificationdate 
   Namespace:   DAV: 
   Purpose:     Records the time and date the resource was modified. 
   Value:   date-time   
   COPY/MOVE behaviour: This property value SHOULD be kept during a 
            MOVE operation, but is re-initialized when a resource is 
            created with a COPY. It should not be set in a remote COPY. 
   Description: The creationdate property should be defined on all DAV 
            compliant resources.  If present, it contains a timestamp 
            of the moment when the resource was last modified (i.e., the 
            moment when content and/or propertoes last changed).
            This property is live and 
            protected. The Internet date-time format is defined in 
            [RFC3339], see the ABNF in section 5.6. 
    
   <!ELEMENT modificationdate (#PCDATA) > 
    
Julian


--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Sunday, 17 August 2003 06:52:14 UTC