[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Clarity around Ref processing behavior.
Les has repeatedly called for other people's view on this issue, and Andy has prepared an excellent article that I have attached. (Andy is not registered to send to the mailing list.) ~ Steve -----Original Message----- From: Drummond Reed [mailto:drummond.reed@cordance.net] Sent: Saturday, September 22, 2007 5:17 PM To: 'Chasen, Les'; 'Steven Churchill'; xri@lists.oasis-open.org Cc: andy.dale@ootao.com; 'Victor Grey'; 'Kermit Snelson' Subject: RE: [xri] Clarity around Ref processing behavior. It sounds like we should have a call about this ASAP (see the end of this message for a proposed time). It's disconcerting that all these questions are coming up after months of a stable Ref processing section. Two points: 1) On the plane yesterday as I was doing the minutes of Thursday's telecon I went over the logic in the flowchart in 8.1.2, because I was very surprised to hear that after all the previous TC discussiona about no backtracking, the flowchart was ambiguous about this. When I read the flowchart carefully, I was relieved to see that it is not ambiguous about backtracking. The logic is thus: a) When you reach the "Service endpoint selected?" decision diamond, if the answer is "No", you branch to the Authority Reference Selection Flowchart. b) That flowchart either selects a Ref element or errors out (it does not resolve anything, just does selection). c) If a Ref is selected, and if the Refs parameter is not false, then the resolver does a recursive resolution of the Ref to obtain another XRDS. d) ONLY if an error is returned in step (c) instead of an XRDS does the resolver return to select the next Ref. Note: that's NOT backtracking. The resolver hasn't found any path forward yet, so it's just trying the next Ref. e) If an XRDS is returned in step (c), the logic returns to the main branch to select an authority resolution service endpoint. If one is not found, the loop above (a to d) is repeated - BUT ONLY FOR THE NEW XRDS. Either there is a Ref in that *new* XRDS, or the process errors out. In other words, no backtracking. I feel very strongly that no backtracking is the right decision. We've been over this at least four times now as a TC and always come to that conclusion. It keeps resolution deterministic. Les, you have a point that it is similar to saying "Ref has a cardinality of zero or one", however I think the logic is no different than why we allow multiple URIs in a service endpoint -- it is for redundancy. They all identify the same logical service -- in case you can't reach it through one URI, you try another. I think exactly the same thing applies here, i.e., multiple Ref elements at the XRD level should be treated the same way as multiple URI elements at the service endpoint level. (Of course, the same goes for Service Refs too, i.e., multiple Service Ref elements in a service endpoint should be treated exactly the same way as multiple URI elements at the service endpoint level.) 2) Les, I understand your concern about the authority publishing the XRD containing the Ref being able to control the depth of delegation, i.e., whether the authority to whom it delegates can have a Ref. If we want to support this, we should add a "depth" attribute to the Ref element that takes a positive integer as a value that controls the depth. If the depth is "1", only one Ref is followed. If it is "2", one additional Ref can be followed, and so on. I'm not completely convinced it is needed, but if you feel it is important I would support it. When can folks do a telecon? I fly to Digital ID World tomorrow and Monday is pretty hectic, but Tuesday I could probably find a slot, especially in the morning. How about 11:30AM PT/2:30PM ET on Tuesday? =Drummond > -----Original Message----- > From: Chasen, Les [mailto:les.chasen@neustar.biz] > Sent: Saturday, September 22, 2007 1:22 PM > To: Drummond Reed; Steven Churchill; xri@lists.oasis-open.org > Cc: andy.dale@ootao.com > Subject: RE: [xri] Clarity around Ref processing behavior. > > > -----Original Message----- > > From: Drummond Reed [mailto:drummond.reed@cordance.net] > > Sent: Saturday, September 22, 2007 3:55 PM > > To: Chasen, Les; 'Steven Churchill'; xri@lists.oasis-open.org > > Cc: andy.dale@ootao.com > > Subject: RE: [xri] Clarity around Ref processing behavior. > > > > Les, Steve, Wil: > > > > I was on a plane yesterday and only just this morning uploaded the > minutes > > from Thursday's meeting that explained why: a) we didn't want > > backtracking, > > and b) directional Refs to any depth were fine. > > > > I've quickly read this thread and have to go to my son's soccer game, > > however I believe the decisions we made on Thursday's call are the > right > > ones. Again, these decisions were: > > > > 1) Once a resolver has followed a Ref and successfully obtained a new > XRDS > > document, it is in a new XRDS "path" and MUST NOT backtrack from that > > path, > > but can only move forward on that path. > > [Chasen, Les] > [Chasen, Les] I think this is wrong and essentially makes the > cardinality of the ref 0 or 1. > > > > > 2) A resolver continues down that XRDS path, and if necessary > continues to > > follow additional Refs on that path, until it: a) satisfies the query > it > > was > > given, b) errors out, or c) hits its own internal maximum number of > refs. > > > > I read Steve's use case and while I agree that in theory a resolver > COULD > > backtrack to try additional Refs, as Wil says, that produces much more > > complex behavior. Instead, Steve's use case is beautifully handled by > the > > new Service Ref feature, because that way Steve can direct each > service > > type > > to another specific authority. > [Chasen, Les] Based on my conversation with Wil after the Thursday call > I don't think what you incorrectly call backtracking is complex. Steve > is correct in his discussion on this topic. > > > > > This is, IMHO, much finer-grained than using a full XRD-level Ref, > which > > is > > a much coarser approach. > > > > Regarding Les's concern about following a Ref to an XRDS that has > another > > Ref, since a Ref is fundamentally delegation of service endpoint > authority > > to another entity, I think it is exactly what should happen. Does that > > mean > > authorities should be extremely careful about delegation of XRD-level > > Refs? > > Yes. > [Chasen, Les] With this model it is impossible to be *careful*. I > strongly feel that ref's should be handled in a breadth mode rather than > this proposed depth model. It is much more important to ensure that a > ref is only between the two authorities in which it was declared. Some > very bad and unexpected things will happen if you go to an XRD with > greater degrees of separation. > > > I would like to here what others think.
Thoughts on ref processing.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]