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


Hi Steve,

Should lookahead resolution really proceed to following Refs? I would
prefer the server receiving the additional segments to stop at the point
before it needs to follow a Ref and return the XRD's so far.

I still don't see a need for hierarchical XRDS to be defined in the
specs. IMO it adds complexity to, if not implementations, the
specifications.

wil. 

> -----Original Message-----
> From: Steven Churchill [mailto:steven.churchill@xdi.org]
> Sent: Wednesday, January 25, 2006 9:39 AM
> To: Tan, William; 'Wachob, Gabe'; drummond.reed@cordance.net;
> xri@lists.oasis-open.org
> Cc: drummond.reed@gmail.com
> Subject: RE: [xri] Decision on Ref "backtracking" issue
> 
> 
> Wil,
> 
> The proposal is that the hierarchical XML is compiled in the Resolver
> client
> (via recursion that is "abstracted out" of the flowchart as per my
> previously attached email.)
> 
> The hierarchical XML would not be returned by an Authority Resolution
> Services (except in the case of lookahead resolution where the Auth
Res
> Service is acting as a client.)
> 
> I think the client resolver spec needs a MUST for the hierarchy, at
least
> for Trusted Resolution, because each of the signatures must be
verified in
> an inorder traversal of the tree. Whether or not it's a MUST for
generic
> resolution is a different story.
> 
> Drummond, please chime in if I'm totally off base.
> 
> ~ Steve
> 
> 
> > -----Original Message-----
> > From: Tan, William [mailto:William.Tan@neustar.biz]
> > Sent: Tuesday, January 24, 2006 12:50 PM
> > To: Steven Churchill; Wachob, Gabe; drummond.reed@cordance.net;
> > xri@lists.oasis-open.org
> > Cc: drummond.reed@gmail.com
> > Subject: RE: [xri] Decision on Ref "backtracking" issue
> >
> > Steve,
> >
> > Do we really need hierarchical XML on the wire? It seems to me that
this
> > is only ever going to be composed by the resolver library to the
> > application, not between the authority server and the resolver
library.
> > Therefore, I'm arguing that we do need some way of representing the
> > final resolution result after having been through Ref processing,
but it
> > does not have to be standardized at the specifications; it is just
an
> > implementation issue e.g. a data structure exposed in the resolution
API
> > would do.
> >
> > Having missed out on the TC calls when you guys discussed the Ref
stuff,
> > I am sure there is a somewhat bigger picture or an obvious point
that
> > I'm missing.
> >
> > Thanks.
> >
> > wil.
> >
> > > -----Original Message-----
> > > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > > Sent: Tuesday, January 24, 2006 6:20 AM
> > > 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,
> > >
> > > 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
> > >
> > >
> > >
---------------------------------------------------------------------
> > > 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]