[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Decision on Ref "backtracking" issue
IMO, you are trying a REF to try to locate either a sub-segment, for authority resolution, or a service, for service selection. If you try a REF and that XRD does not have it but does have other REFs then those REFs should not be followed. This is a simple case of not found. So if you are trying to resolve =GabeW*coworker*Mike and the coworker XRD has no $res*authority services but does have REFs then those references should be followed. If those references do not know anything about *Mike then a 'not found' should be returned on *Mike. I-Name: =les.chasen -----Original Message----- From: Wachob, Gabe [mailto:gwachob@visa.com] Sent: Monday, January 23, 2006 1:07 PM 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]