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


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
> 


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