RE: [xri] Clarity around Ref processing behavior.

["Chasen, Les" <les.chasen@neustar.biz>]

I would hope that we can decide this without having to have a special
telecon.  There are three choices that we should be able to decide on
easily on email.

1. The current depth model.  This model follows a ref and as long as it
finds an XRD continues resolution following the XRD path.  This model I
feel essentially makes ref's a cardinality of 0 or 1 except in the case
where a ref fails to produce an XRD.  Drummond, where I agree that a ref
is somewhat similar in function to multiple refs I do not think
multiples exist for the same reason.  In the case of URI they are by
definition multiple network endpoints that service up the same thing.
Refs on the other hand are not for redundancy but multiple relationships
with differing authorities. 

2. A breadth only model.  This is a model where all ref's in the current
xrd are checked for a specific SEP.  REFs are not followed in subsequent
XRDs in search of the SEP.  Drummond, I do not propose that there is
another attribute to allow following to a specified levels of depth.  I
think it is better to keep this extremely simple. 

3.  A combined depth and breadth model.  This model follows REFs as deep
as needed, maintaining respect for a max depth set by a resolver.  If a
SEP is not found after following a REF path then try the next REF until
the SEP is found.

My vote is for #2.  It is simple and predictable for both developers of
resolvers and more importantly users of XRIs.

contact: =les
sip: =les/(+phone)
chat: =les/skype/chat
 
 

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Saturday, September 22, 2007 8: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.
>