RE: Changing etag and getlastmodified on move/rename

I agree with all of this.  I have no problems putting an optional modificationdate in RFC2518bis if we can get agreement quickly because I think it could be implemented extremely quickly in several implementations.  

Lisa

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> Sent: Sunday, August 17, 2003 3:51 AM
> To: Lisa Dusseault; 'Julian Reschke'; 'Webdav WG'
> Subject: 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 22:08:05 UTC