RE: [xri] Decision on Ref "backtracking" issue

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

The way I understood Drummond's wording was that =SecretAgent and
=PublicAgent are both in the same XRD, i.e. the one describing =Mike. So
#2 says that you should try =PublicAgent and if it fails, return error.

#3 says that if =PublicAgent fails, try =Dave.

wil. 

> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com]
> Sent: Tuesday, January 24, 2006 2:07 AM
> To: drummond.reed@cordance.net; xri@lists.oasis-open.org
> 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: drummond.reed@cordance.net [mailto:drummond.reed@cordance.net]
> > Sent: Sunday, January 22, 2006 12:41 AM
> > To: xri@lists.oasis-open.org
> > Cc: drummond.reed@cordance.net
> > 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: gwachob@visa.com; steven.churchill@ootao.com; Chasen,
> > Les; Tan, William
> > Cc: drummond.reed@cordance.net
> > 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