Gabe,
Backtracking is needed in any case, because it's needed for the XML
bracketing as well as for the following of sibling Refs.
I've attached my previous email that talks about this in more detail.
~ Steve
> -----Original Message-----
> From: Wachob, Gabe [mailto:]
> Sent: Monday, January 23, 2006 10:07 AM
> To: ;
> Subject: RE: [xri] Decision on Ref "backtracking" issue
>
> I'm not sure that the way #2 is specified, its any different than #3.
>
> If I "try" a REF, and in resolving the resulting XRI, I end up with a
> set of REFS, am I required to try that set of REFs that result from
> resolving the XRI I got from choosing the first REF?
>
> Specifically:
>
> Lets say =GabeW*coworker resolves to refs that point to =Mike and =Dave,
> and I choose =Mike and =Mike ends up with a ref to =SecretAgent and
> =PublicAgent.
>
> Lets say resolution of =SecretAgent fails.
>
> What do I do? Is that a failure that requires me to go back to =Dave? Or
> should I try =PublicAgent? What happens if =PublicAgent fails?
>
> Note that I think the wording of #2 and #3 both require me to go back to
> =Dave is =SecretAgent and =PublicAgent fail. This is still
> backtracking... Right?
>
> -Gabe
>
> > -----Original Message-----
> > From: [mailto:]
> > Sent: Sunday, January 22, 2006 12:41 AM
> > To:
> > Cc:
> > Subject: [xri] Decision on Ref "backtracking" issue
> >
> > First, for anyone unfamiliar with the Ref "backtracking" issue in XRI
> > resolution, the question is where we draw the line in terms
> > of required
> > behavior for a resolver when it comes to following the XRIs
> > contained in
> > Ref elements (which I'll just call "Refs" in this message).
> >
> > Based on the discussion among the editors so far, it appears
> > we have three
> > choices:
> >
> > 1) Stop at the very first Ref in the current XRD and error if
> > it fails.
> >
> > 2) Try all Refs in the current XRD and error only if all of them fail.
> >
> > 3) Try all Refs in the current XRD, and if they all fail,
> > then "backtrack"
> > to any previous XRDs and try all of them, and only if they
> > ALL fail should
> > the resolver fail.
> >
> > Gabe has proposed that we not require #3, since it is both the most
> > complex and can take the most time. I agree.
> >
> > At the other end of the spectrum, Les' message below proposes
> > that we not
> > stop at #1, since there may be a good reason if the first Ref
> > in an XRD
> > doesn't work that the resolver should try the others.
> >
> > So the proposal on the table now is to take a middle course
> > and require
> > only that if resolution of the first Ref in an XRD fails, the resolver
> > must (subject to its own timeout constraints) try the others
> > in priority
> > order, but it is NOT required for a resolver to "backtrack"
> > to previous
> > XRDs and try earlier "untried" Refs.
> >
> > Anyone who disagrees with this proposal, please send email to the list
> > with an alternate (preferably by end of day Monday USA --
> > silence will be
> > deemed consensus ;-)
> >
> > For reference, here's what the actual wording might look
> > something like:
> >
> > "If a client resolver is not able to find the requested
> > service endpoint
> > in the current XRD, or if the URI(s) for that service endpoint do not
> > produce a successful response, the client resolver MUST
> > (subject to its
> > own timeout constraints) attempt resolution of the highest
> > priority Ref of
> > the current XRD. If that resolution is successful, the final
> > XRD of the
> > resulting XRDS document becomes the current XRD and
> > resolution continues.
> > If that resolution is not successful, the client resolver MUST attempt
> > resolution of the next highest priority Ref of the current
> > XRD, and so on.
> > If resolution of all Refs in the current XRD fails, the
> > client resolver
> > MAY return an error 27, VALID_REF_NOT_FOUND, or the client
> > resolver MAY
> > "backtrack" to previous XRDs in the resolution chain and
> > attempt to follow
> > any untried Refs. Note that the latter behavior is not
> > required and should
> > not be expected."
> >
> > =Drummond
> >
> >
> > ----ORIGINAL MESSAGE FROM LES CHASEN------
> >
> > Do we really want to stop resolution if one REF is
> > unresponsive? It seems
> > to me to be a good idea to have multiple authority services
> > (either via
> > SEPs, URIs or REFs) in case one is having a problem. It
> > seems to me the
> > resolver should do what ever it can, within reason, to locate
> > the answer
> > for a request. In DNS a domain can have upto 13 nameservers.
> > If one is
> > not responding for what ever reason the resolver tries another.
> >
> > I-Name: =les.chasen
> >
> > --------------------------------------------------------------
> > -------------
> >
> > From: Drummond Reed
> > Sent: Friday, January 20, 2006 11:33 AM
> > To: ; ; Chasen,
> > Les; Tan, William
> > Cc:
> > Subject: Gabe's feedback and reference "backtracking"
> >
> > Gabe and Res Editor's:
> >
> > Note that since I can only send from Gmail, I can't send this
> > to the list.
> > One of you is welcome to forward this to the list.
> >
> > I just went over Gabe's comments. Fantastic stuff. There's
> > many that we
> > need to go over (I *really* wish I could be on the call
> > Friday morning but
> > I gotta go to bed now...). Anyway, the single biggest issue
> > is the one of
> > whether a resolver needs to do "backtracking" of references
> > (as currently
> > indicated in ED 04) or whether, as Gabe recommends, the
> > resolver should
> > just stop and report an error if it gets an error.
> >
> > I tend to agree with Gabe on this with one exception: I think
> > that *within
> > a single service endpoint* if the resolver gets a network
> > error on one URI
> > and more then one URI is supplied, the resolver should try the next
> > highest priority URI, and so on. Same for the next highest priority
> > service if there is >1 Service of that type in the XRD.
> >
> > But I agree with Gabe that if a resolver follows a reference
> > and hits an
> > error, it should not need to "backtrack" but just stop and report the
> > error.
> >
> > If everyone agrees to that on today's call, please publish it in the
> > minutes and I'll update the flowcharts to match (and start
> > working on ED
> > 05 to make those changes.)
> >
> > All of Gabe's other comments made sense to me. Please do record in the
> > minutes any others that the editors have consensus on and I'll start
> > getting those into ED 05. I'd then like to send it to Gabe (or ???) to
> > take the pen and make whatever other changes we feel are
> > necessary before
> > publishing it as WD 10.
> >
> > =Drummond
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. You may a link to this group and all
> > your TCs in OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> > oups.php
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
