IMO, you are trying a REF to try to locate either a sub-segment, for
authority resolution, or a service, for service selection. If you try a
REF and that XRD does not have it but does have other REFs then those
REFs should not be followed. This is a simple case of not found.
So if you are trying to resolve =GabeW*coworker*Mike and the coworker
XRD has no $res*authority services but does have REFs then those
references should be followed. If those references do not know anything
about *Mike then a 'not found' should be returned on *Mike.
I-Name: =les.chasen
-----Original Message-----
From: Wachob, Gabe [mailto:]
Sent: Monday, January 23, 2006 1:07 PM
To: ;
Subject: RE: [xri] Decision on Ref "backtracking" issue
I'm not sure that the way #2 is specified, its any different than #3.
If I "try" a REF, and in resolving the resulting XRI, I end up with a
set of REFS, am I required to try that set of REFs that result from
resolving the XRI I got from choosing the first REF?
Specifically:
Lets say =GabeW*coworker resolves to refs that point to =Mike and =Dave,
and I choose =Mike and =Mike ends up with a ref to =SecretAgent and
=PublicAgent.
Lets say resolution of =SecretAgent fails.
What do I do? Is that a failure that requires me to go back to =Dave? Or
should I try =PublicAgent? What happens if =PublicAgent fails?
Note that I think the wording of #2 and #3 both require me to go back to
=Dave is =SecretAgent and =PublicAgent fail. This is still
backtracking... Right?
-Gabe
> -----Original Message-----
> From: [mailto:]
> Sent: Sunday, January 22, 2006 12:41 AM
> To:
> Cc:
> 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: ; ; Chasen,
> Les; Tan, William
> Cc:
> 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_workgr
> oups.php
>
>
---------------------------------------------------------------------
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
