[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Decision on Ref "backtracking" issue
Steve, I agree with you that a server wishing to support lookahead resolution would probably use a resolver library to do the work, and that a no-follow-refs flag in the resolver client API would be very helpful. IMHO the strongest use case for lookahead resolution is for a single server to be authoritative for multiple levels of authority to process lookahead requests. So, it makes sense for a server hosting =a*b and =a*b*c to answer for *b*c within a single round trip. That is not to say that servers should not act as a client during lookahead resolution, but it adds complexity and duplicates the effort of following refs. In the case of trusted lookahead resolution, does it mean that the server has to verify the SAML signatures once, and the client has to do the same once it receives the XRDS? This seems like the classic argument of balancing the intelligence on the server vs the client. Putting more intelligence on the server allows us to upgrade and deploy new services more easily but making the server software more feature-rich also may mean more operational load. On the other hand, putting more intelligence on the client puts more strain on the developers and possibly hider adoption. Having said that, it is a good idea to have hierarchical XML standardized, I just don't know if it would ever make it over the wire. I'm not fixated on getting rid of it, but wanted to make sure that we really need it; like Gabe, my complexity alarm is also flashing wil. > -----Original Message----- > From: Steven Churchill [mailto:steven.churchill@xdi.org] > Sent: Thursday, January 26, 2006 6:18 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 wrote: > > > 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. > > That seems like fine behavior for an Auth Res server. If I were the > server, > though, I would use the Resolver Client to perform lookahead resolution, > because the resolution behavior needs to be compliant with the Resolution > Spec (and who wants to implement the spec again?). So perhaps the Resolver > Client API needs a flag that tells it *not* to follow refs (to error out). > That way the Auth Res server can do the behavior you describe above. > > > 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. > > Again, the hierarchy is needed for Trusted resolution in order for a > client > to validate the trust chain. And for a client to do that, the format of > the > hierarchy needs to be explicit in the spec. > > Perhaps Drummond can give his reasons why it's important also for Generic > resolution. (I feel that it should be there for Generic resolution as > well, > but I'll admit that the reasons are not as compelling as the one for > Trusted > resolution.) > > ~ Steve > > > > > -----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 > > > --------------------------------------------------------------------- > 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]