[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Decision on Ref "backtracking" issue
Hi Steve, Should lookahead resolution really proceed to following Refs? I would prefer the server receiving the additional segments to stop at the point before it needs to follow a Ref and return the XRD's so far. I still don't see a need for hierarchical XRDS to be defined in the specs. IMO it adds complexity to, if not implementations, the specifications. wil. > -----Original Message----- > From: Steven Churchill [mailto:steven.churchill@xdi.org] > Sent: Wednesday, January 25, 2006 9:39 AM > To: Tan, William; 'Wachob, Gabe'; drummond.reed@cordance.net; > xri@lists.oasis-open.org > Cc: drummond.reed@gmail.com > Subject: RE: [xri] Decision on Ref "backtracking" issue > > > Wil, > > The proposal is that the hierarchical XML is compiled in the Resolver > client > (via recursion that is "abstracted out" of the flowchart as per my > previously attached email.) > > The hierarchical XML would not be returned by an Authority Resolution > Services (except in the case of lookahead resolution where the Auth Res > Service is acting as a client.) > > I think the client resolver spec needs a MUST for the hierarchy, at least > for Trusted Resolution, because each of the signatures must be verified in > an inorder traversal of the tree. Whether or not it's a MUST for generic > resolution is a different story. > > Drummond, please chime in if I'm totally off base. > > ~ Steve > > > > -----Original Message----- > > From: Tan, William [mailto:William.Tan@neustar.biz] > > Sent: Tuesday, January 24, 2006 12:50 PM > > To: Steven Churchill; Wachob, Gabe; drummond.reed@cordance.net; > > xri@lists.oasis-open.org > > Cc: drummond.reed@gmail.com > > Subject: RE: [xri] Decision on Ref "backtracking" issue > > > > Steve, > > > > Do we really need hierarchical XML on the wire? It seems to me that this > > is only ever going to be composed by the resolver library to the > > application, not between the authority server and the resolver library. > > Therefore, I'm arguing that we do need some way of representing the > > final resolution result after having been through Ref processing, but it > > does not have to be standardized at the specifications; it is just an > > implementation issue e.g. a data structure exposed in the resolution API > > would do. > > > > Having missed out on the TC calls when you guys discussed the Ref stuff, > > I am sure there is a somewhat bigger picture or an obvious point that > > I'm missing. > > > > Thanks. > > > > wil. > > > > > -----Original Message----- > > > From: Steven Churchill [mailto:steven.churchill@xdi.org] > > > Sent: Tuesday, January 24, 2006 6:20 AM > > > 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, > > > > > > Yes a meta-error for this would be good. > > > > > > In my discussion in the previously attached email, the need for the > > stack > > > is > > > synonymous with the need for backtracking (unwinding). My point about > > the > > > backtracking was that it is needed for the hierarchical (bracketed) > > XML > > > output AS WELL AS for following sibling Refs. > > > > > > For reasons I discuss in that email(abstracting away the traversal), I > > > don't > > > feel backtracking adds complexity. (Put another way, we can have both > > the > > > sibling Ref traversal and the hierarchical XML output without > > additional > > > complexity.) > > > > > > ~ Steve > > > > > > > > > > > > > -----Original Message----- > > > > From: Wachob, Gabe [mailto:gwachob@visa.com] > > > > Sent: Monday, January 23, 2006 1:46 PM > > > > To: Steven Churchill; drummond.reed@cordance.net; xri@lists.oasis- > > > open.org > > > > Cc: drummond.reed@gmail.com > > > > 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 > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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 > > > > > > --------------------------------------------------------------------- > > 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]