OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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?


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

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?


> -----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
> 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 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]