[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Decision on Ref "backtracking" issue
Steve- I understand the need for a stack. I still think that "backtracking" up that stack (er, down the stack, depending on how you draw it) adds complexity - I'd rather say that if you get stuck somewhere, that you don't even bother unwinding the stack to a decision point and try something else. But, I will defer to those implementing the spec to tell me whether this really adds complexity. One thing I know is that we might need to have a special error (was this mentioned before) that basically is "tried all ref's possible and had failures everwhere" - this is really a "meta-error" since the errors for each ref-traversal might be different. My complexity warning light is going off and I'm trying to reset it... ;-) -Gabe > -----Original Message----- > From: Steven Churchill [mailto:steven.churchill@xdi.org] > Sent: Monday, January 23, 2006 1:21 PM > To: Wachob, Gabe; drummond.reed@cordance.net; xri@lists.oasis-open.org > Cc: drummond.reed@gmail.com > Subject: RE: [xri] Decision on Ref "backtracking" issue > > > 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:gwachob@visa.com] > > Sent: Monday, January 23, 2006 10: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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]