Re: [xri] Backtracking

["Tan, William" <William.Tan@neustar.biz>]

I agree with everything that John and Victor said so far.
1. Authority resolution and service selection are distinct phases. When 
authority resolution completes, it is done and returns the result to the 
calling function. It might be at the 3rd Ref out of 5 possible Refs, and 
there is no way to continue where it left off.
2. During service selection, if you see a Ref, you will spawn a 
different authority resolution phase, but that has nothing to do with 
the original authority resolution. This child authority resolution phase 
also knows nothing about service selection. It completes, and returns 
(if successful) the results back to the caller, which is the service 
selection function. If this child authority resolution phase fails and 
there are more Refs, the service selection function will spawn another 
authority resolution phase on the next Ref.

I must admit to not having read any other section than 12. At the rate 
that I read, I will only impede the progress so I just learn from John's 
distilled summary. If what he says is true of ED06, then we need to 
disallow backtracking to the authority resolution phase.

I used the term "spawn" loosely, for all intents and purposes, I just 
meant "call a function".

=wil

John Bradley wrote:
>
> On 26-Oct-07, at 9:46 AM, Victor Grey wrote:
>
>> John Bradley wrote:
>>> My tendency is to code that into the authority resolution recursion 
>>> function rather than invoking the general SEP selection for each 
>>> subsegment.
>>> I envision the code as a recursive function that processes sub 
>>> segments until it reaches the last sub segment or hits a ref/redirect.
>> Yes - I've always thought of it that way too.
>>
>>> At a ref or redirect  you have one or more refs to process.  You 
>>> iterate through the list by again recursing to the same function 
>>> with the new parameters.
>>> Once you have consumed all of the sub segments you fallow the ref in 
>>> the last XRD if there is one.
>>> If the XRD cant be returned you raise an exception and unwind back 
>>> to your list of refs you are iterating through.
>>>
>>> Only then do you invoke the general SEP selection process with the 
>>> input parameter.
>> Yes if by "only then" you mean only when you have finished authority 
>> resolution successfully. If authority resolution fails, you don't 
>> have a final XRD to do SEP selection on.
>>
>
> Yes,  and in that case you backtrack to your list of refs and try the 
> next one in priority order.
>
>>> If this fails to find the SEP then there are two choices 1 return 
>>> SEP not found, or 2 rase an exception and unwind back to your list 
>>> of refs you are iterating through.
>> That's where you lost me.
>>
>> Authority resolution and SEP selection must be two distinct phases, 
>> it seems to me. During authority resolution, you are either following 
>> SEPs of type $res*auth, or REFs or REDIRECTs. If I understand ED 06 
>> correctly, any particular XRD can contain either $res*auth SEPs, or 
>> REFs or REDIRECTs, but not mix and match from those - if there are 
>> XRD level REFs, there cannot also be $res*auth SEPs in the same XRD. 
>> So if you follow a $res*auth SEP, and you are not able to consume all 
>> of the subsegments in the authority resolution process that way, you 
>> can back up and try another URI from the same $res*auth SEP, or a URI 
>> from a lower priority $res*auth SEP in the same XRD. If none of those 
>> result in successfully consuming all of the subsegments in the 
>> authority resolution process, you have to error out. Same for 
>> following REFs - if following a REF does not lead to successful 
>> authority resolution, you can try another REF in the same XRD. 
>> Otherwise you're done.
>>
>> Once you have successfully finished the authority resolution process 
>> and obtained a final XRD, you can start SEP selection. Here's where 
>> it gets really confusing I think. If there are no matching SEPs, but 
>> there are XRD level REFs, you can follow the REFs looking for your 
>> service. But following a REF involves starting -another- authority 
>> resolution chain. But this is separate and distinct from the original 
>> authority resolution chain that had to finish before you could start 
>> SEP selection.
>>
>> Have I got that right?
>>
>> =vg
>>
> This is the tricky bit.  I am informed that the current spec sec 11.5 
> intends that if the final XRD is returned and you do service selection 
> on it,  and if that "*d**oes no*t" find the required SEP then you must 
> unwind back to the same point that you would have if the XRD was 
> not returned.
>
> In working it through with Steve it became clear that this is a mixing 
> of SEP selection and Authority resolution from the programing perspective.
>
> This can be programed but will cause a much larger tree to be 
> walked especially if you were to try and select for a 
> non existent SEP.  Think DOS.
>
> I think the preferred way for authors to do this is use the SEP 
> refs elusively.  That way you can directly point at the target SEP 
> without having to wander through a large tree asking each final XRD if 
> they have what you want.
>
> If failing to return the final XRD was the only thing that caused the 
> XRD level ref to try its next sibling then I think It would discourage 
> bad authoring and make the code simpler.
>
> I see the the larger symmetry of having the refs at the XRD level 
> service selection.  I am willing to go along as long as people ace all 
> clear on what we are doing.
>
> =ve7jtb
>>
>>
>