[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Decision on Ref "backtracking" issue
I agree. Les, Excellent point, and I agree completely. We should never backtrack (back) up into =A as you express in the first paragraph. The only need for backtracking (the saving of traversal context, as I put it) is for the ability to locate B's next REF as in your second paragraph. (Oh yeah, and to perform the hierarchical Ref output, as I keep saying like a broken record. :-) ~ Steve > -----Original Message----- Les wrote: > I do not think we should be backtracking through all levels of a QXRI. > We should follow all REFs and resolution services in the current XRD to > find the next one. For example, given the QXRI =A*B*C. If we have > already resolved =A and *B the current XRD is the one for *B. We should > follow all REFs and authority resolution services to attempt to find *C > that are in the current XRD. If after trying all of those we cannot > locate *C then a not found should be returned. We should not back track > to =A. > > If *B's XRD has multiple REFs and the first REF returns not found I > could accept the argument that not found should be returned to the > calling client. This is exactly what is done in DNS. If that REF was > unavailable then we would need to try the next REF. > > > > I-Name: =les.chasen > > > -----Original Message----- > From: Wachob, Gabe > > 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 > > > > --------------------------------------------------------------------- > 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]