RE: [xri] Clarity around Ref processing behavior.

["Drummond Reed" <drummond.reed@cordance.net>]

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.

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.

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.

Must run to soccer now. If need be, we should have a dedicated call on this
specific subject early this week, as I'm trying to finish a final final
ED06.

=Drummond 

> -----Original Message-----
> From: Chasen, Les [mailto:les.chasen@neustar.biz]
> Sent: Friday, September 21, 2007 12:31 PM
> To: Steven Churchill; xri@lists.oasis-open.org
> Cc: andy.dale@ootao.com
> Subject: RE: [xri] Clarity around Ref processing behavior.
> 
> Steve and Andy -
> 
> I think it is very important to limit the following of refs to only
> level.  The reason is because there is a lot of danger in allowing the
> use of some service by someone that is unintended.  Let's say I have a
> ref to wil (which is legal since we removed synonym semantics) because
> we are teammates and Wil has a ref to his wife.  I have no relationship
> to his wife I should not be able to fall into her XRD and select one of
> her services.  It gets even worse if she then designate refs to others.
> 
> I agree with you that this is less flexible but I think we need to trade
> flexibility for tight control.  Without tight control unexpected things
> will happen and given this federated world we are moving to it will be
> harder to (1) recognize and (2) debug the unexpected problem.
> 
> Anybody else have any thoughts?
> 
> - Les
> 
> > -----Original Message-----
> > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > Sent: Friday, September 21, 2007 2:34 PM
> > To: xri@lists.oasis-open.org
> > Cc: andy.dale@ootao.com
> > Subject: RE: [xri] Clarity around Ref processing behavior.
> >
> >
> > Wil,
> >
> > Les's is an interesting proposal to just go "one deep" on the Ref
> > following.
> >
> >
> > However, I just chatted with Andy, who has been a big proponent of the
> Ref
> > use case from the start, and the proposal does seem to limit
> flexibility.
> > For example, if @ootao*steven "designates" (I don't want to use the
> loaded
> > term "delegates" here) his OpenID service to =steven.churchill, then,
> > certainly he wouldn't be at all upset if =steven.churchill decided to
> > designate it one step further.
> >
> > In the resolver implementation, I think a "magic number" approach
> would
> > work
> > well. Any traversal should stop and error out when it visits that many
> > authority nodes. The number would simply apply to "nodes visited"--
> that
> > is,
> > the number could be exceeded by drilling too deep in a traversal or
> just
> > by
> > having too many sibling Refs.
> >
> > ~ Steve
> >
> > -----Original Message-----
> > From: Tan, William
> > Sent: Friday, September 21, 2007 10:23 AM
> > To: Steven Churchill
> > Cc: xri@lists.oasis-open.org
> > Subject: Re: [xri] Clarity around Ref processing behavior.
> >
> > Steve,
> >
> > After thinking through what you wrote and having a chat with Les, I
> > agree with you that we should not sacrifice this otherwise basic
> > use-case for performance concerns. However, my concern was never about
> > speed, it was about usability and predictability when the Ref tree
> gets
> > too complicated.
> >
> > It is fine if @ootao*steven has a ref to =steven.churchill and another
> > to @xdi*steven because these are all controlled by you. Since we shed
> > the synonymity semantics from Refs, two authorities with a Ref between
> > them do not necessarily have to represent the same entity (dare I say
> > identity? gasp!)
> >
> > Les brought up a very good point that if A has a Ref to B, which in
> turn
> > has a Ref to C. A has a relationship with B, but it doesn't mean that
> A
> > has a relationship with C. So, he suggested that we:
> > 1. We keep the original semantics of trying each Ref in turn if no
> > services were selected.
> > 2. When creating a new request to resolve a Ref, that the "refs"
> > parameter be turned off. This means that you only follow the Ref but
> not
> > any Ref that it has.
> >
> > We did talk about having this constraint in the call yesterday, but we
> > somehow drifted in the other direction (probably my fault). I am very
> > much in favor of Les's proposal above because it constrains the use of
> > Refs to a much more predictable (therefore usable) feature. What do
> you
> > think about this middleground?
> >
> > And you're right that "backtracking" is not the right term to use at
> > all. It's basically not doing a breadth search, which essentially
> makes
> > Ref having a cardinality of 0-to-1.
> >
> > Thanks.
> >
> > =wil
> >
> > Steven Churchill wrote:
> > > Wil,
> > >
> > > It would be a shame to see the original semantics get morphed into
> the
> > those
> > > you describe below.
> > >
> > > 1) These original semantics are currently presented in the spec. It
> is
> > > difficult to imagine that one could interpret the flowcharts in
> 8.1.2
> > and
> > > 11.1 to express the semantics you describe. In any case, if you and
> I
> > can
> > > disagree so much on this, then this points to a flaw in the spec
> from an
> > > interoperability standpoint--the spec needs to be clear either way.
> > >
> > > 2) The semantics that you describe were invented after the
> fact--arising
> > > from implementation considerations--they have nothing to do with the
> > > original use case that motivated Refs. Allow me to explain how Refs
> were
> > > originally intended to work.
> > >
> > > I will do so by example.
> > >
> > > Consider the XRI authority for @ootao*steven.
> > >
> http://beta.xri.net/@ootao*steven?_xrd_r=application/xrd%2Bxml;sep=false
> > >
> > > As you can see by the XRD, this authority defines no OpenID SEP but
> > contains
> > > a Ref to =steven.churchill in the form of =!C5FB.53B6.6E94.824.
> > >
> > > Therefore, if I resolve the identifier @ootao*steven for it's OpenID
> > > service, I get back the authority for =steven.churchill.
> > >
> > >
> >
> http://beta.xri.net/@ootao*steven?_xrd_t=http://openid.net/signon/1.0&&_
> xr
> > d_
> > > r=application/xrd+xml;sep=true;
> > >
> > > Why does a Ref behave this way? Because that was the original use
> case:
> > it
> > > allows @ootao*steven to use a service from another authority. In
> this
> > > example @ootao*steven is using the OpenID service for
> =steven.churchill.
> > >
> > > Now let's say that I decide that I want @ootao*steven to use the XDI
> > service
> > > from a different authority, say @xdi*steven. I should be able to
> simply
> > > place a Ref to @xdi*steven (and, of course, not define the XDI
> service
> > for
> > > @ootao*steven.)
> > >
> > > Your semantics do not allow this basic use case. Again: your
> semantics
> > are
> > > about implementation considerations: speed, debugging, etc--not
> about
> > > satisfying the requirements.
> > >
> > > ~ Steve
> > >
> > > PS: The term "backtracking" is a red herring. All recursion
> backtracks,
> > > because all recursion uses a stack. What you are trying to say is
> that
> > you
> > > don't want to traverse a second child.
> > >
> > > -----Original Message-----
> > > From: Tan, William
> > > Sent: Thursday, September 20, 2007 2:35 PM
> > > To: Steven Churchill
> > > Cc: xri@lists.oasis-open.org
> > > Subject: Re: [xri] Clarity around Ref processing behavior.
> > >
> > > We have discussed this before -- whether multiple Ref's have
> round-robin
> > > semantics or aggregation semantics.
> > >
> > > While I agree that aggregation semantics is cool and is in fact more
> > > intuitive, I have always felt uncomfortable with it from the
> standpoint
> > > of predictability.
> > >
> > > After discussing this at the TC call today, we led ourselves back to
> the
> > > "no back-tracking rule" which has the following advantages:
> > > 1. It exposes any error that it encounters early. If we found an
> error
> > > but ignored it moving on to the next Ref, the error could stay
> > > undiscovered for a long time while causing strange resolution
> behaviors.
> > > 2. It enforces a more predictable Ref usage pattern that follows
> down a
> > > single Ref chain instead of a Ref tree. This is often easy to
> understand
> > > and troubleshoot.
> > > 3. Having the constraint above, resolution will probably be faster
> > > because the resolver wouldn't have to try other Refs.
> > >
> > > Drummond also brought up an interesting point that XRD/Ref has a
> focused
> > > but limited role in allowing one to aggregate services. Rather, the
> new
> > > Service/Ref provides more fine-grained control.
> > >
> > > Look for Drummond's minutes for the call and let us know what you
> think.
> > >
> > > =wil
> > >
> > > Steven Churchill wrote:
> > >
> > >> The "processing" flowcharts in sections 8.1.2 and 11.1 both contain
> a
> > >> box saying "Resolve Authority Ref to new XRDS document or error".
> If
> > >> "Error" is true, then there is a branch to obtain the next Ref.
> > >>
> > >> The original use case for Ref processing held that the "error"
> > >> occurred either if a Ref could not be followed due to network error
> or
> > >> if following the Ref came up empty for the requested service type.
> > >> That is, in both cases, the code should try following the next Ref.
> [I
> > >> will omit for now the explanation as to why this use case is
> > >> important, but will gladly explain if asked.]
> > >>
> > >> I've heard Wil say at some point that the current OpenXRI
> > >> implementation only tries the next Ref due to network failure-but
> > >> doesn't try the next Ref if the "Resolve Authority Ref to new XRDS
> > >> document or error" comes up empty for the given service type.
> > >>
> > >> Wil, is my statement accurate? If so, I propose that the OpenXRI
> > >> behavior be changed to (what I consider) match the flowcharts.
> > >>
> > >> ~ Steve
> > >>
> > >> PS: the "note" in the both flowchart refers to section 10. This is
> > >> incorrect.
> > >>
> > >>