Re: target selector again

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 5 Oct 1999 13:53:04 -0400 

Date: Tue, 5 Oct 1999 13:53:04 -0400
Message-Id: <9910051753.AA14183@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <1999Oct05.125900.1250.1342242@otismtp.ott.oti.com>
Subject: Re: target selector again


   From: Jeff_McAffer@oti.com (Jeff McAffer OTT)

   <jm>
   Here's a more fundamental question for clarification.

   Is the Target-Selector intended to only be used when processing the last   
   segment of the Request-URI?

<gmc/> Good catch, Jeff!  Yes, the DAV:revision-id was intended to apply
only to the resource identified by the last segment of the URL, with the
default workspace used to identify collection revisions (if any).

<gmc/> Note that the DAV:rsr-revision-id selector is primarily for
clients and servers that do not support versioned collections.  This
is a special case, but an important special case since core versioning
does not require versioned collections.

   If the answer is yes, then specing a revision-id makes sense but how do I   
   specify the workspace in which I should find all of the parents and allow   
   me to get to the resource of interest (i.e., the last segment)?  Default   
   worksapce?  any activities?

<gmc/> The default workspace.  I'll add this to the spec.

   If the answer is no, specifying a revision-id is pretty bogus I am unable   
   then to spec the selection of the resource's parents.  How are they   
   selected?

<gmc/> I agree (which is why the answer needs to be "yes" :-).

   I vote that revision-ids are not valid Target-Selectors.

<gmc/> They provide an easy way for a simple core versioning client/server
to select an arbitrary revision.  I believe that's an important use case
for us to support.

   Follow on question.  If I spec a Target-Selector (say a configuration)   
   and the resource is not found in that scope, does the server return 404   
   or does it use the default workspace to continue the search?
   </jm>

<gmc/> Definitely a 404.  We should make this clear in the protocol.