Re: target selector again & again

Chris Kaler (ckaler@Exchange.Microsoft.com)
Wed, 6 Oct 1999 14:25:58 -0700 

Message-ID: <FD7A762E588AD211A7BC00805FFEA54B041DD938@HYDRANT>
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
To: "'Tim_Ellison@oti.com'" <Tim_Ellison@oti.com>, ietf-dav-versioning@w3.org
Date: Wed, 6 Oct 1999 14:25:58 -0700 
Subject: RE: target selector again & again

Sorry, but "ick" :-)...  I shouldn't have to make multiple 
calls to the server to determine the revision-specific URL.

I also don't think we should dictate the form of this URL.
This will make it hard for some servers to support it.  I
suspect we would end up with vendor-specific properties that
define the URL staright out.

Chris

-----Original Message-----
From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com]
Sent: Wednesday, October 06, 1999 2:04 PM
To: ietf-dav-versioning@w3.org
Subject: RE: target selector again & again



<sarge>
     So precisely how do you get the revision's URL?
     Assuming you normally use the versioned resource's
     URL you have to query to discover the revision's URL
     (or the history URL and the revision-id).  This is not a new
     problem, but I don't immediately see how it's done with
     the current protocol.
</sarge>

<tpe>
How about this:
     1) PROPFIND myresource -> DAV:history-uuid
     2) PROPFIND myresource -> DAV:revision-id
     3) some random call to find out where in the namespace the server 
creates history resources; maybe OPTIONS myresource??
     4) the URL is 
http://foo.com/<history_place>/<history_uuid>/<revision-id>

Problems:
     a) it's three calls to the server to deduce this fundamental 
information,
     b) step (3) has not ben defined, indeed there are suggestions that the 
server should not dictate this information.
</tpe>