RE: [xri] Decision on Ref "backtracking" issue

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

After looking at this again, I realize I misunderstood what Gabe meant
by backtracking.  I do not think that we should backtrack to the
previous XRD.  For authority resolution only the XRD for the current
sub-segment should be used to try to locate the next segment.  Likewise
in service selection only the final sub-segment XRD should be used for
service locating.  

I vote for option 2.  I think that we should try all Refs in the current
XRD and only error if they all fail.

 
I-Name:  =les.chasen 
 
-----Original Message-----
From: drummond.reed@cordance.net [mailto:drummond.reed@cordance.net] 
Sent: Sunday, January 22, 2006 3: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_workgroups.php