Re: Version selector properties

> 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