OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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




Gabe,

Yes a meta-error for this would be good.

In my discussion in the previously attached email, the need for the stack is
synonymous with the need for backtracking (unwinding). My point about the
backtracking was that it is needed for the hierarchical (bracketed) XML
output AS WELL AS for following sibling Refs.

For reasons I discuss in that email(abstracting away the traversal), I don't
feel backtracking adds complexity. (Put another way, we can have both the
sibling Ref traversal and the hierarchical XML output without additional
complexity.)

~ Steve



> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com]
> Sent: Monday, January 23, 2006 1:46 PM
> To: Steven Churchill; drummond.reed@cordance.net; xri@lists.oasis-open.org
> Cc: drummond.reed@gmail.com
> Subject: RE: [xri] Decision on Ref "backtracking" issue
> 
> Steve-
> 	I understand the need for a stack. I still think that
> "backtracking" up that stack (er, down the stack, depending on how you
> draw it) adds complexity - I'd rather say that if you get stuck
> somewhere, that you don't even bother unwinding the stack to a decision
> point and try something else.
> 	But, I will defer to those implementing the spec to tell me
> whether this really adds complexity. One thing I know is that we might
> need to have a special error (was this mentioned before) that basically
> is "tried all ref's possible and had failures everwhere" - this is
> really a "meta-error" since the errors for each ref-traversal might be
> different.
> 
> 	My complexity warning light is going off and I'm trying to reset
> it... ;-)
> 
> 	-Gabe
> 
> 
> > -----Original Message-----
> > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > Sent: Monday, January 23, 2006 1:21 PM
> > To: Wachob, Gabe; drummond.reed@cordance.net; xri@lists.oasis-open.org
> > Cc: drummond.reed@gmail.com
> > Subject: RE: [xri] Decision on Ref "backtracking" issue
> >
> >
> > Gabe,
> >
> > Backtracking is needed in any case, because it's needed for the XML
> > bracketing as well as for the following of sibling Refs.
> >
> > I've attached my previous email that talks about this in more detail.
> >
> > ~ Steve
> >
> >
> > > -----Original Message-----
> > > From: Wachob, Gabe [mailto:gwachob@visa.com]
> > > Sent: Monday, January 23, 2006 10:07 AM
> > > To: drummond.reed@cordance.net; xri@lists.oasis-open.org
> > > 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: drummond.reed@cordance.net
> > [mailto:drummond.reed@cordance.net]
> > > > Sent: Sunday, January 22, 2006 12: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_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
> >
> 
> ---------------------------------------------------------------------
> 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]