RE: [xri] Clarity around Ref processing behavior.

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

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.