Next message: Tim_Ellison@uk.ibm.com: "Re: Naive question"
To: ietf-dav-versioning@w3.org
Message-ID: <OF08A29B7A.F5AAFB47-ON8525695A.003E6DA1@raleigh.ibm.com>
From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>
Date: Thu, 14 Sep 2000 07:39:42 -0400
Subject: Re: Naive question
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.
Not according to the protocol. The target of a version is defined
by its DAV:target property. That can only be changed by updating
its DAV:target property. The Target-Selector header can be used to
make a request refer to a version instead of a version selector,
but that doesn't change the target of that version selector.
<jra>
I'm refering to the target of the method, not the target of the version
selector.
</jra>
This is
required for clients to be able to use labels to access old
versions of a resource through the version selector.
As mentioned earlier, the Target-Selector header is not required
to use labels to access old versions through the version selector,
but it does avoid one round trip (i.e. the round trip to retrieve
the version URL for that labeled revision).
<jra>
But I thought the point of the Target-Selector was that you could access
any version you wanted using a version selector URL, and overriding its
DAV:target with the Target-Selector. It's not a question of whether the
Target-Selector is required or not to access old versions through the
version selector, its just the most likely way clients will want to do it.
I don't think the protocol should require clients to keep a lot of URL
mapping state that they have to persist or reconstruct. That's what the
server should do. I know Chris wanted this flexibility in his client, but I
don't think we should require this of all clients, or even make it the
general case. So I don't think we should be requiring the use of server
generated URLs in the client any more than we have to (primarily in
properties we have to persist to maintain the version history).
</jra>
PROPFIND doesn't
return live properties of the version when accessed through the
version selector.
That's correct, you'd have to ask for the live properties of
the version if they wanted the live properties of the version.
<jra>
But this doesn't seem right. If you get the contents and dead properties
through the version selector, then why not the version's live properties?
Why are we requiring clients to get the version URL for this special case?
</jra>
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.
If you want the properties of the version, you'd use a version URL
(or use a Target-Selector header). If you want the properties of
a version, you'd use a version selector URL. No need to know whether
or not a property is live or not ... just use the appropriate URL.
<jra>
I don't get it. If I use the version selector URL, I get the contents and
dead properties of the version. So are you telling me that if I really want
all the properties of the version, dead or live, then I need to go get the
version URL and use that? If so, then why bother having some of the
properties returned by the version selector? Are you also saying that if I
use a version selector to in a PROPFIND and then use it again in a PROPFIND
with a Target-Selector that selects the same version as the DAV:target that
I'll get a different set of properties? Will down-level clients have to
understand this in order to get the live properties of a version? This
seems very confusing. But if no-one else is having any trouble with it,
I'll just get used to it.
Looks like the best thing to do might be for clients to treat a version
selector as a redirect reference and do all access through the version URL.
Then they're sure of what they're getting.
</jra>