Next message: Jim Amsden/Raleigh/IBM: "Re: Naive question"
From: Tim_Ellison@uk.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8025695A.00311273.00@d06mta07.portsmouth.uk.ibm.com>
Date: Thu, 14 Sep 2000 09:55:57 +0100
Subject: Re: Naive question
Jim,
It sounds like you fell into the same trap as me -- think of the version
selector as a 'copy' of the version, DAV:target shows where it was copied
from, and SET-TARGET does the copy -- not sure how far I can push this one
:-)
Tim
"Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com> on 2000-09-13 12:17:29 PM
Please respond to "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>
To: ietf-dav-versioning@w3.org
cc: (bcc: Tim Ellison/UK/IBM)
Subject: Re: Naive question
<jra>
No problem with the dead properties, its the live properties that are at
issue. We should avoid defining the protocol so that clients have to use
different marshaling for some properties than others.
</jra>
I have seen no proposal that a client use different marshaling for
some properties than others.
<jra>
Perhaps we're not understanding each other or I'm missing something. GET on
a version selector does not return the contents of the version selector, it
returns the contents of the target version. That target version can be
specified either implicitly by the DAV:target property of the version
selector, or explicitly by overriding this property using the
Target-Selector header. This is required for clients to be able to use
labels to access old versions of a resource through the version selector.
So the target selector is being used as a redirector for GET. The same
thing is true for PROPFIND, but only for dead properties. PROPFIND doesn't
return live properties of the version when accessed through the version
selector. So clients would have to know the property they are interested in
is live on some server (the server may define its own live properties on
any resource) and that these properties have to be accessed using different
marshaling protocol - i.e., by using the version URL instead of a version
selector URL.
So the things I'm trying to unify are 1) same semantics for accessing the
target version through a version selector's target regardless if it was
implicit through the DAV:target property, explicit through the
Target-Selector header, or explicitly using the version URL, and 2)
consistent redirect semantics for version selector resources. As with the
original design of direct references, I think we need a way for the client
to say the method is operating on the version selector, not its target.
While it is true that in most cases, the expected default action would be
to operate on the target (e.g., DELETE) or on the version (GET), its
enumerating all the cases where the method does one or the other that
introduces complexity, and then there's always the case where the client
doesn't want to do the default. Unfortunately, as with the former direct
references, the expected default isn't always the same.
</jra>