[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Decision on Ref "backtracking" issue
I think the reason you'll see hierarchical XML over the wire is for proxy resolution (not the HTTP proxy - the old fashion authority resolution proxy). The history: Without hierarchical XML, in the old days (ie CD-01) a client was simply given the answer up to the point of the "redirect" and was expected to follow the "redirect" (synonym/ref/term-of-the-day) itself. The proxy wouldn't do it for you. Because we've done this HXRI proxy stuff, which implies that the proxy will do *complete* resolution, we have had to define a more complete behavior for proxies. In defining the more complete behavior for proxies, somewhere along the line, it was decided that proxies (even non-HXRI proxies) would do complete (ie following refs) resolution - therefore proxies needed to be able to return the results of this complete resolution - hence the need for the hierarchical results. If we went back to CD-01 and said that normal authority proxies *don't* follow refs, then we wouldn't need hiearchical results - except I spose when an HXRI proxy is asked for the media type of XRDS? (I'm not even sure then..) -Gabe > -----Original Message----- > From: Tan, William [mailto:William.Tan@neustar.biz] > Sent: Friday, January 27, 2006 12:43 AM > 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, > > 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 > > > --------------------------------------------------------------------- > 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]