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

["Steven Churchill" <steven.churchill@xdi.org>]

I concur with option 2.


> -----Original Message-----
> From: Chasen, Les [mailto:les.chasen@neustar.biz]
> Sent: Sunday, January 22, 2006 8:28 PM
> To: drummond.reed@cordance.net; xri@lists.oasis-open.org
> Subject: RE: [xri] Decision on Ref "backtracking" issue
> 
> After looking at this again, I realize I misunderstood what Gabe meant
> by backtracking.  I do not think that we should backtrack to the
> previous XRD.  For authority resolution only the XRD for the current
> sub-segment should be used to try to locate the next segment.  Likewise
> in service selection only the final sub-segment XRD should be used for
> service locating.
> 
> I vote for option 2.  I think that we should try all Refs in the current
> XRD and only error if they all fail.
> 
> 
> I-Name:  =les.chasen
> 
> -----Original Message-----
> From: drummond.reed@cordance.net [mailto:drummond.reed@cordance.net]
> Sent: Sunday, January 22, 2006 3: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_workgroups.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