- From: <Tim_Ellison@uk.ibm.com>
- Date: Mon, 20 Nov 2000 10:04:11 +0000
- To: ietf-dav-versioning@w3.org
> But back to my original point, that should be determined > from the definition of that live property, and should > not be something that the versioning spec should need > to define. You've been so successful at mindreading thus far, that I figured you know that I wasn't suggesting a definition in the spec (we couldn't enumerate all the possible live props even if we wanted to) -- but was looking for concensus on a few key live props that we know about already. > Why? One reasonable form of getetag is to use some MD5 > "footprint", and in that case, the DAV:getetag of the > version and the version selector whose target is that > version will be the same. I agree. Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> on 2000-11-17 09:54:13 PM Please respond to "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> To: ietf-dav-versioning@w3.org cc: Subject: Re: Version selector properties From: Tim_Ellison@uk.ibm.com From the versioning spec (section 2.2): "Although the content and dead properties of a checked-in version selector are required to be the same as those of its current target, its live properties may differ." I would have thought that some live properties should(must?) not be different. If so, that should be determined from the definition of that live property, and should not be something that the versioning spec should need to define. Hopefully, we would agree that the DAV:getContentLength property must not be different. That would follow from the requirement that the content of the version-selector be the same as that of the target version. Ok, how about the DAV:resourcetype? I think that that would most likely not be different, but maybe it would (interpret the same content as different types, editing url and execute url maybe?) Comments? It would seem natural for them to be the same, but as you indicate, a server might come up with reasons for making them different, especially if DAV:resourcetype ends up with a structured value. DAV:getlastmodified? Well you probably do want that to be different to the version that was the target of the SETTARGET. I suspect that having the getlastmodified time go 'backwards' when setting the target to an earlier version would screw up caching proxies, and clients that rely on If-Unmodified-Since: et al headers. I agree. I think we would agree that the DAV:getetag property should be different. Why? One reasonable form of getetag is to use some MD5 "footprint", and in that case, the DAV:getetag of the version and the version selector whose target is that version will be the same. A successful SETTARGET should result in new last modified and etag values for a version selector. A new last modified, yes. A new etag, not necessarily. But back to my original point, that should be determined from the definition of that live property, and should not be something that the versioning spec should need to define. Cheers, Geoff
Received on Monday, 20 November 2000 05:11:25 UTC