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] New thread: Rethinking ref processing


Steve, with our new Section 6 (Yadis), there's no difference between
identifying a resource in an XRDS with an HTTP(S) URI or an XRI, except that
the latter can do delegation, HXRI encapsulation, etc. while the former
cannot.

So there's no longer "non-relationship" semantics to conflate. (To be sure,
there WAS in the way service refs have been defined up until this last
thread, but no longer).

See also my next email about the "flushing of authority refs" and the other
output of the meetings today.

=Drummond 

> -----Original Message-----
> From: Steven Churchill [mailto:steven.churchill@xdi.org]
> Sent: Wednesday, September 26, 2007 10:55 PM
> To: xri@lists.oasis-open.org
> Cc: andy.dale@ootao.com; 'Kermit Snelson'
> Subject: RE: [xri] New thread: Rethinking ref processing
> 
> 
> By the way, I am not opposed to moving the relationship semantics from the
> authority level to the service level (and flushing the authority Ref in
> the
> process). What I am very opposed to is the conflating of relationship and
> non-relationship semantics in the service ref element.
> 
> The solution to this is pretty simple: Separate the non-relationship
> semantics (that is, the support for the HTTP(S) URI) away from the service
> Ref and into another element. I suggest naming it Service:XRDProxy or
> something. (The name should reflect the fact that its being used to
> replace
> the metadata for the current authority with that obtained from performing
> a
> HTTP(S) get.)
> 
> ~ Steve
> 
> 
> -----Original Message-----
> From: Steven Churchill
> Sent: Wednesday, September 26, 2007 4:28 PM
> To: xri@lists.oasis-open.org
> Cc: andy.dale@ootao.com; 'Kermit Snelson'
> Subject: RE: [xri] New thread: Rethinking ref processing
> 
> 
> Drummond said:
> 
> > I think maybe you misunderstood my proposal. I'm saying "I want to
> > switch Service Ref to the relationship semantics of 1 and GET RID
> > of the non-relationship semantics in 2".
> 
> and also said:
> 
> > Now a ref is a ref is a ref, and will always be processed the
> > same way, no matter where it appears in the XRD, no matter whether its
> > value is an XRI or HTTP(S) URI, and no matter ....
> 
> which says that the service ref can still contain an HTTP(S) URI.
> 
> I explained this below in this thread, but I will explain it again.
> Following a service ref's URI can *only* return an XRD describing the same
> identity that contains the service ref. It *cannot* be used to express a
> relationship between two identities. (If you want further explanation, see
> my text below.)
> 
> Drummond, if you want to GET RID of non-relationship semantics, then you
> must also get rid of using an HTTP(S) URI in the service ref -- and, if
> you
> do that, you then you get rid of the original use case (requirement) that
> drove the current service ref semantics in the first place.
> 
> ~ Steve
> 
> 
> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Wednesday, September 26, 2007 12:03 AM
> To: 'Steven Churchill'; xri@lists.oasis-open.org
> Cc: andy.dale@ootao.com; 'Kermit Snelson'
> Subject: RE: [xri] New thread: Rethinking ref processing
> 
> Steve,
> 
> You say, "3) [Drummond] wants to add to the Service Ref the relationship
> semantics of 1 while having it keep the non-relationship semantics in 2."
> 
> I think maybe you misunderstood my proposal. I'm saying "I want to switch
> Service Ref to the relationship semantics of 1 and GET RID of the
> non-relationship semantics in 2".
> 
> In other words, I want to give service refs exactly the same semantics as
> authority refs.
> 
> I talked this over with Gabe, Andy, and John Bradley today and we are all
> in
> agreement that this will make life much simpler. Markus also agrees in his
> message, and Kermit was ecstatic about it in the email he sent me. (Anyone
> who disagrees, please speak up now.)
> 
> If so, I believe the only question remaining is whether we should limit
> either "breadth" or "depth" of ref traversal. Gabe, Andy, John, and Markus
> all agree with Wil that we should "keep it simple" and not place any
> limits
> on ref traversal in the spec and let implementations decide. They are not
> worried about backtracking since: a) resolvers can do it efficiently, esp.
> from caches, and b) going more than one or two refs wide or deep is likely
> to be an edge case anyway.
> 
> I think I am persuaded at this point to agree with them -- keep the spec
> simple and get it done and let implementation feedback guide us in future
> revisions.
> 
> Kermit made the suggestion to me we should change the refs= parameter to
> an
> integer that specifies the depth and let consuming applications control it
> in the resolution request. That would be a simple change from the current
> boolean true/false use of that parameter.
> 
> 
> Both Kermit and Andy also suggest variations on another idea, which is to
> have a parameter that instructs the resolver not just to follow refs when
> the specified SEP is missing, but to follow them all, and return back the
> complete aggregated "logical union" of XRDs.
> 
> All good thinking. All of them will all be at the Identity Open Space at
> Digital ID World tomorrow afternoon, so I think we'll hold a session on
> this
> topic to see if we can get to consensus with everyone who is there in
> person. Anyone who can't make it, please do post your opinion on these
> topics to the list.
> 
> Thanks,
> 
> =Drummond
> 
> 
> > -----Original Message-----
> > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > Sent: Tuesday, September 25, 2007 11:19 AM
> > To: xri@lists.oasis-open.org
> > Cc: andy.dale@ootao.com; 'Kermit Snelson'
> > Subject: RE: [xri] New thread: Rethinking ref processing
> >
> >
> > Drummond,
> >
> > Here's the problem:
> >
> > 1) The Authority Ref currently has these relationship semantics: An
> > Authority Ref establishes a parent-child relationship between the parent
> > of
> > the authority containing the Ref and the target of the Ref. (This sounds
> > like mumbo-jumbo, but it is carefully described in Figures 4 and 5 at
> > <http://www.oasis-open.org/committees/download.php/22395/xri-polyarchy-
> > artic
> > le.pdf>.)
> >
> > That is, the Authority Ref establishes a parent-child relationship
> between
> > two XRI authorities (between two different identities).
> >
> > 2) The current Service Ref *does not have* relationship semantics--it
> does
> > not establish any relationship between XRI authorities. It simply says:
> > replace the XRD for the current authority with the XRD obtained by
> > performing http(s) GET on this URI. This is why the CanonicalID must be
> > the
> > same--the Service Ref is about a single XRI identity, not a
> relationship.
> >
> > 3) You want to add to the Service Ref the relationship semantics of 1
> > while
> > having it keep the non-relationship semantics in 2.
> >
> > In my opinion, this simply cannot be done.
> >
> > ~ Steve
> >
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Tuesday, September 25, 2007 1:14 AM
> > To: 'Steven Churchill'; xri@lists.oasis-open.org
> > Cc: andy.dale@ootao.com; 'Kermit Snelson'
> > Subject: RE: [xri] New thread: Rethinking ref processing
> >
> > Steve,
> >
> > You say, "I feel that this would be a gross overloading of semantics for
> > the
> > service ref element." I understand that, from the perspective of how
> > service
> > refs are currently defined in ED05, the proposal to treat service refs
> the
> > same way as authority refs could be interpreted as a "gross overloading
> of
> > semantics for the service ref element".
> >
> > However if you stand back one step further, there's a different way to
> > look
> > at it: it's a dramatic simplification of the whole concept of ref
> > processing. Now a ref is a ref is a ref, and will always be processed
> the
> > same way, no matter where it appears in the XRD, no matter whether its
> > value
> > is an XRI or HTTP(S) URI, and no matter what resolution trust model is
> > being
> > applied. In other words, a ref:
> >
> > 1) Always produces a nested XRDS document.
> >
> > 2) Always starts a new CanonicalID verification chain.
> >
> > 3) Always repeats the same resolution query that was applied to the
> parent
> > XRDS document that caused the ref to be traversed in the first place.
> >
> > Yes, it was a novel idea when it first came up this morning as a way to
> > solve the CanonicalID verification issue. But now that I've had all day
> to
> > think about it, it increasingly looks like a classic example of an
> obvious
> > solution that we just never saw when we first came up with the idea of
> > service refs last spring.
> >
> > Let me put it this way: this approach is so simple and straightforward,
> > can
> > anyone think of a reason we should NOT adopt it and do away with the
> > current
> > complexity we have in ED05 of needing different identifier rules,
> > processing
> > rules, and XRDS inclusion rules for authority refs and service refs?
> >
> > Again, to be crystal clear about this proposal, here's a summary of the
> > key
> > points that would go into a revised section 12 in ED06:
> >
> > 1) First, we would explain that a ref (whether at the authority or
> service
> > level) is a way for an XRDS author to tell a resolver, "If you don't
> find
> > the service you need in this XRD, then start a new resolution chain with
> > the
> > same query parameters using this other identifier."
> >
> > 2) Second, the processing rules would always the same: the ref always
> > results in a new nested XRDS document, starting at the point the ref is
> > encountered. If one ref leads to another ref, then that leads to another
> > level of nesting.
> >
> > 3) The CanonicalID verification rules remain the same because each time
> a
> > new ref is encountered, CanonicalID verification restarts at the new
> > community root authority.
> >
> > 4) The ONLY remaining difference between an authority ref (the
> > xrd:XRD/xrd:Ref element) and a service ref (the
> > xrd:XRD/xrd:Service/xrd:Ref
> > element) is that the former is used IF THE LATTER IS NOT PRESENT.
> >
> > I think this is a huge point, and one that IMHO might also solve the ref
> > processing policy issue that started this whole thread. So let me
> explain
> > in
> > more detail.
> >
> > The logic goes like this: first, ref processing is ALWAYS triggered by a
> > resolver not finding the SEP URI that it needs. For example, during the
> > authority resolution process, the resolver ALWAYS needs a URI within a
> SEP
> > with the xri://$res*auth*($v*2.0) type (and with the appropriate trust
> > media
> > type parameter if applicable).
> >
> > There are two ways a resolver could fail to find this SEP URI and thus
> > trigger ref processing:
> >
> > 1) A SEP of this type was present but didn't contain a
> > xrd:XRD/xrd:Service/xrd:URI element, only a xrd:XRD/xrd:Service/xrd:Ref
> > element.
> >
> > 2) A SEP of this type was absent altogether but the XRD contained an
> > xrd:XRD/xrd:Ref element.
> >
> > Option #1 above is very fine grained. It is specific to just one service
> > type -- the xri://$res*auth*($v*2.0) service. This lets an XRDS author
> > insert an xrd:XRD/xrd:Service/xrd:Ref element to repoint the browser at
> > the
> > exact XRI or HTTP(S) URI for the XRDS document the XRDS author wants to
> > use
> > for this type of service.
> >
> > Option #2 above is a "catch all". If the resolver finds no fine-grained
> > service ref at the SEP level, the resolver checks to see if there is a
> > catch-all ref at the XRD level. If so, the resolver interprets this as
> an
> > instruction from the XRDS author: "For any query where don't find either
> > the
> > specific SEP URI you are looking for, or a specific service ref, then
> use
> > this general catchall ref."
> >
> > The beauty is that these ***exact*** same ref logic/processing rules can
> > apply once the resolver has finished the authority resolution process
> and
> > moves into the service endpoint selection process. Not one word above
> > needs
> > to change: just substitute "[requested SEP query parameters here]" for
> > "xri://$res*auth*($v*2.0)".
> >
> > *******
> >
> > My final thought in this message is whether this unified ref processing
> > model might also help solve our ref policy debate. Because XRDS authors
> > would now have very precise fine-grained control over refs -- both the
> > level
> > at which they appear, and also whether they use XRIs or HTTP(S) URIs as
> > their value -- I believe there's less reason for the spec to impose any
> > limitations on their use.
> >
> > In my mind it boils down to one question: should "backtracking" be
> allowed
> > or not? By backtracking, I mean that once a resolver starts down a ref
> > resolution chain, if it finds it is a "dead end" (i.e., the resolver is
> > not
> > able to successfully satisfy its resolution query), should it:
> >
> > 1) Start "backing up" through the chain of XRDs it has resolved within
> > this
> > new XRDS resolution chain to try their refs?
> >
> > 2) If that fails, should it back up into the XRD that contained the
> > "dead-end" and try its next ref?
> >
> > 3) If THAT fails, should the resolver back up still further, i.e., into
> > the
> > parent of the current XRD, to see if IT might have a ref that can be
> > successfully followed?
> >
> > This illustrates my discomfort with any form of backtracking: as soon as
> > you
> > allow backtracking at any point in the chain, does it not apply
> > recursively
> > right back all the way up the chain to the community root authority? If
> > not,
> > what's the rule about where you stop backtracking?
> >
> > A "no backtracking" rule (limited breadth, unlimited depth) avoids this
> > problem by saying that once you successfully resolve a ref to a new XRDS
> > document, you never back up out of that document. You only either: a)
> move
> > forward to another new XRDS document (either directly, or by following a
> > ref), or b) error out.
> >
> > Even with a no-backtracking rule, Andy's use case is still fully
> > supported,
> > because with this unified ref processing model, every node in his tree
> of
> > authorities can be reached via either a service ref (directly) or an
> > authority ref (indirectly, as the authority ref processing would have to
> > walk the entire set of potential authority nodes).
> >
> > Thoughts?
> >
> > =Drummond (back at Digital ID World tomorrow, so responses may be slow)
> >
> >
> > > -----Original Message-----
> > > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > > Sent: Monday, September 24, 2007 3:52 PM
> > > To: xri@lists.oasis-open.org
> > > Cc: andy.dale@ootao.com; 'Kermit Snelson'
> > > Subject: RE: [xri] New thread: Rethinking ref processing
> > >
> > >
> > > Drummond,
> > >
> > > The overriding concern is that the CanonicalID in the XRD obtained by
> > > following an http(s) URI must be identical to the CanonicalID in the
> XRD
> > > containing the service ref. This is required from a security
> standpoint,
> > > because a different CanonicalID cannot be validated outside of XRI
> > > resolution. (It cannot be validated via http(s) GET.)
> > >
> > > Your proposal below allows the (final) CanonicalID coming back
> different
> > > when the service ref contains an xri.
> > >
> > > I feel that this would be a gross overloading of semantics for the
> > service
> > > ref element.
> > >
> > > Keep in mind that I originated this thread because I felt that the
> > OpenID
> > > resolver implementation does not match the Ref semantics that Andy
> > > describes
> > > in his write-up. To do this, the resolver simply needs to "follow the
> > next
> > > ref when the previous ref comes up empty." (The spec is ambiguous and
> > > needs
> > > to be clarified in either case.)
> > >
> > > ~ Steve
> > >
> > > -----Original Message-----
> > > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > > Sent: Monday, September 24, 2007 12:19 PM
> > > To: 'Steven Churchill'; xri@lists.oasis-open.org
> > > Cc: andy.dale@ootao.com; 'Kermit Snelson'
> > > Subject: [xri] New thread: Rethinking ref processing
> > >
> > > All,
> > >
> > > I hate to throw a twist into this whole discussion, but after writing
> > > response to Steve's email last night regarding: a) the limitations we
> > > currently have on service refs, and b) how CanonicalID verification
> > > processing works with all refs, more thinking this morning made me
> > realize
> > > that two of our assumptions about Ref processing should be revisited.
> > > Specifically, I'm referring to:
> > >
> > > 1) The differences between authority refs and service refs.
> > > 2) Our current rules for how we nest XRDS documents in authority ref
> > > processing and add XRD documents in service ref processing.
> > >
> > > I'll treat these in turn (warning: this is a long and meaty topic):
> > >
> > > PART 1: THE DIFFERENCE BETWEEN AUTHORITY REFS AND SERVICE REFS
> > >
> > > At that time we designed service refs last spring, we decided that a
> > > service
> > > ref should be limited to:
> > >
> > > a) Only using an HTTP(S) URI.
> > > b) Only resulting in an additional XRD in the current XRDS.
> > >
> > > Steve's points made me stop and revisit those assumptions. After the
> > whole
> > > CanonicalID verification discussion and all it taught us about
> delegated
> > > resolution chains, when I asked myself, "Why isn't service ref
> > processing
> > > identicial to authority ref processing?", my answer was, "Hmmm. It
> > should
> > > be."
> > >
> > > In other words, we could both simplify the spec and provide more
> > > tightly-directed references if service refs functioned identically to
> > > authority refs. What this would mean is:
> > >
> > > 1) A service ref can be an XRI just like an authority ref (note: it
> can
> > > also
> > > be an HTTP(S) URI just like an authority ref too, as we have now fully
> > > specified HTTP(S) URI resolution in ED05 section 6).
> > >
> > > 2) A service ref would be processed according to the same rules as an
> > > authority ref, i.e., if successfully resolved, it would result in the
> > same
> > > nested XRDS document as an authority ref.
> > >
> > > 3) The only difference between an authority ref and a service ref
> would
> > be
> > > that the latter is constrained to obtaining an XRDS that satisfies a
> > > pre-specified service endpoint selection criteria (selection of an
> > > xri://$auth*res*($v*2.0) service type), whereas the former can satisfy
> a
> > > service endpoint selection criteria specified at runtime.
> > >
> > > For example, to resolve =a*b for a service of type
> > http://foo.service.org,
> > > if the XRD A for =a had no authority resolution service but had an
> > > authority
> > > ref to @x*y*z, and the XRD for =a*b had a service ref for its
> > > http://foo.service.org service to =m*n, the resolver would take the
> > > following steps:
> > >
> > > 1) It would resolve =a, look for an authority resolution service
> > endpoint,
> > > and finding none, begin ref processing of @x*y*z.
> > >
> > > 2) It would resolve a nested XRDS for @x*y*z.
> > >
> > > 3) From the final XRD, it would choose the authority res service
> > endpoint.
> > >
> > > 4) From that endpoint, it would resolve *b (note that under our
> current
> > > rules, the resulting XRD goes back in the outermost non-nested XRDS
> > > document).
> > >
> > > 5) From that XRD, the resolver would look for a service ref for the
> > > http://foo.service.org service. There it finds a service ref to =m*n.
> > >
> > > 6) The resolver resolves =m*n, finds the http://foo.service.org
> service,
> > > and
> > > it's job is done.
> > >
> > > Note again that both the authority ref to @x*y*z and the service ref
> to
> > > =m*n
> > > are resolved the same way and result in the same nested XRDS
> documents.
> > > Which brings us to...
> > >
> > > PART 2: THE XRDS NESTING PROBLRM
> > >
> > > The second problem that Steve's message led me to see was the way we
> are
> > > currently nesting XRDS documents. Under ED05, the closest we can get
> to
> > > the
> > > scenario above is the following outline.
> > >
> > > <XRDS for =a*b >
> > > 	<XRD for =a />
> > > 		<XRDS for @x*y*z >
> > > 			<XRD for @x />
> > > 			<XRD for *y />
> > > 			<XRD for *z />
> > > 		</XRDS>
> > > 	<XRD for *b />
> > > 	<XRD for service ref to HTTP(S) URI for =m*n />		;service ref
> > > </XRDS>
> > >
> > > The final XRD is the one resolved by the service ref, which under ED05
> > is
> > > constrained to being an HTTP(S) URI that results in a single
> additional
> > > XRD.
> > >
> > > Now, if we remove that constraint as proposed above, so that the
> service
> > > ref
> > > can itself be a nested XRDS document, we'd get the following:
> > >
> > > <XRDS for =a*b >
> > > 	<XRD for =a />
> > > 		<XRDS for @x*y*z >
> > > 			<XRD for @x />
> > > 			<XRD for *y />
> > > 			<XRD for *z />
> > > 		</XRDS>
> > > 	<XRD for *b />
> > > 		<XRDS for =m*n >			;XRDS for service
> > > ref
> > > 			<XRD for =m />
> > > 			<XRD for *n />
> > > 		</XRDS>
> > > </XRDS>
> > >
> > > Note that the nested XRDS for @x*y*z looks just like the nested XRDS
> > =m*n.
> > > The reason this makes so much sense is that authority refs ARE a form
> of
> > > service ref! They are just specialized for a specific service:
> > > http://$res*auth*($v*2.0).
> > >
> > > But now let's look at what happens with CanonicalID verification in
> > EITHER
> > > of these models. ED05 currently specifies how CanonicalID verification
> > > works
> > > with nested XRDS documents: it restarts with each nested XRDS, and
> > tracks
> > > through that XRDS only. Here's what that would look like for the above
> > > resolution chain using the second model above:
> > >
> > > <XRDS for =a*b >
> > > 	<XRD for =a />			;asserts CID for =a as child of =
> > > 		<XRDS for @x*y*z >
> > > 			<XRD for @x />	;asserts CID for @x as child of @
> > > 			<XRD for *y />	;asserts CID for *y as child of @x
> > > 			<XRD for *z />	;asserts CID for *z as child of @x*y
> > > 		</XRDS>
> > > 	<XRD for *b />			;asserts CID for *b as child of =a
> > > 		<XRDS for =m*n >
> > > 			<XRD for =m />	;asserts CID for =m as child of =
> > > 			<XRD for *n />	;asserts CID for *n as child of =m
> > > 		</XRDS>
> > > </XRDS>
> > >
> > > The problem this reveals is that @x*y*z cannot assert a valid
> > CanonicalID
> > > for *b because only =a can assert a valid CanonicalID for =a*b -- in
> > ED05
> > > we
> > > are very explicit that each verified CanonicalID MUST be a direct
> child
> > of
> > > the parent authority that asserts it.
> > >
> > > Ouch.
> > >
> > > So for CanonicalID verification to work, whenever you hit an authority
> > > ref,
> > > you MUST restart the CanonicalID verification chain starting with the
> > new
> > > community root authority in the new XRDS document. You CAN'T return
> > > control
> > > to the previous CanonicalID verification chain in the previous XRDS
> > > document.
> > >
> > > It didn't take very long looking at this to realize that the only
> > solution
> > > compatible with CanonicalID verification as we've specified it is for
> > XRDS
> > > documents to ONLY delegate to other XRDS documents. It's like walking
> > down
> > > flights of stairs: each flight can lead to a new flight, but the
> > direction
> > > is only down - you never go back up to a previous flight.
> > >
> > > That would mean the outline for the example scenario above would look
> > like
> > > this:
> > >
> > > <XRDS for =a*b >
> > >   <XRD for =a />			;asserts CID for =a as child of =
> > >     <XRDS for @x*y*z >
> > >       <XRD for @x />		;asserts CID for @x as child of @
> > >       <XRD for *y />		;asserts CID for *y as child of @x
> > >       <XRD for *z />		;asserts CID for *z as child of @x*y
> > >       <XRD for *b />		;asserts CID for *b as child of
> @x*y*z
> > >         <XRDS for =m*n >
> > >           <XRD for =m />	;asserts CID for =m as child of =
> > >           <XRD for *n />	;asserts CID for *n as child of =m
> > >         </XRDS>
> > >     </XRDS>
> > > </XRDS>
> > >
> > > Key characteristics of this structure:
> > >
> > > 1) Authority refs and service refs are both treated identically.
> > >
> > > 2) XRDS documents are only nested; once the "baton is passed" via, it
> is
> > > never passed back.
> > >
> > > 3) CanonicalID verification works as specified in ED05. When a ref is
> > > encountered (either an authority ref or service ref), CanonicalID
> > > verification restarts with the new community root authority. Which
> means
> > > the
> > > only verification CanonicalID you can get back within the final nested
> > > XRDS
> > > is rooted in the community root authority for that XRDS. (Of course,
> it
> > > can
> > > assert a verifiable CanonicalEquivID rooted on any community root
> > > authority.)
> > >
> > > ********
> > >
> > > I'm at Digital ID World today and have been typing this during
> sessions
> > > here. Andy Dale and John Bradley are here and we're going to try to
> > spend
> > > time today going over this. We'll send notes from our discussion as
> soon
> > > as
> > > we can. I invite everyone on the list (and the cc list) to cogitate on
> > > this
> > > and share your thoughts.
> > >
> > > I'd suggest we first need to answer these more fundamental design
> > > questions
> > > about ref processing behaviour before we can return to close the
> policy
> > > issues we have been discussing previously.
> > >
> > > Also, I definitely think this must be the main topic of this Thurday's
> > > telecon (10-noon Pacific Time), so please do set aside time for that
> > call
> > > if
> > > you can.
> > >
> > > =Drummond
> > >
> > >
> > > > -----Original Message-----
> > > > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > > > Sent: Monday, September 24, 2007 7:01 AM
> > > > To: xri@lists.oasis-open.org
> > > > Cc: andy.dale@ootao.com; 'Kermit Snelson'
> > > > Subject: RE: [xri] Clarity around Ref processing behavior.
> > > >
> > > >
> > > > Drummond,
> > > >
> > > > Service Refs won't work because if an XRI client requests
> CanonicalID
> > > > verification then an error is returned when the CanonicalID in the
> XRD
> > > > returned by following the service Ref does not match the CanonicalID
> > in
> > > > the
> > > > XRD containing the Service Ref.
> > > >
> > > > ~ Steve
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > > > Sent: Sunday, September 23, 2007 11:37 PM
> > > > To: 'Steven Churchill'; xri@lists.oasis-open.org
> > > > Cc: andy.dale@ootao.com; 'Kermit Snelson'
> > > > Subject: RE: [xri] Clarity around Ref processing behavior.
> > > >
> > > > Steve,
> > > >
> > > > Good point about resolvers doing caching. That can help with the
> > latency
> > > > problem.
> > > >
> > > > However I disagree about service refs not being a better solution to
> > > > Andy's
> > > > use case. Ironically, one reason is that all you need to do to give
> a
> > > > service ref those same semantics is make it a call to an HXRI. Now
> > that
> > > > service ref can return you exactly what you want from the target
> > > > authority.
> > > >
> > > > My gut tells me this "rifle shot" approach is faster and more
> precise
> > > than
> > > > "random hunting" across a set of authority refs. Both are equally
> > valid
> > > > types of refs. But I'm increasingly feeling like authority refs are
> a
> > > very
> > > > blunt instrument, more suited for wholesale delegation of an entire
> > > XRDS,
> > > > whereas service refs are much better suited for granular delegation
> of
> > > > specific services.
> > > >
> > > > What am I missing?
> > > >
> > > > =Drummond
> > > >
> > > > > -----Original Message-----
> > > > > From: Steven Churchill [mailto:steven.churchill@xdi.org]
> > > > > Sent: Sunday, September 23, 2007 10:35 PM
> > > > > To: xri@lists.oasis-open.org
> > > > > Cc: andy.dale@ootao.com; 'Kermit Snelson'
> > > > > Subject: RE: [xri] Clarity around Ref processing behavior.
> > > > >
> > > > >
> > > > > Victor,
> > > > >
> > > > > Regarding performance, whether an XRI client (the program asking
> > =andy
> > > > for
> > > > > a
> > > > > given service type) uses a local resolver or a proxy resolver is a
> > > > matter
> > > > > of
> > > > > configuration. In either case, the latency you speak of would take
> > > place
> > > > > in
> > > > > the resolver, and only in the cases where it doesn't have the
> > > requested
> > > > > XRD
> > > > > already in its cache. Translated: if nothing happens to be cached,
> > > then
> > > > > the
> > > > > requesting XRI client will need to wait longer for the result the
> > > first
> > > > > time
> > > > > the request is made. (As for too much load on proxy resolvers,
> their
> > > > CPUs
> > > > > don't spin while they wait on TCP/IP requests, and, besides, if a
> > > proxy
> > > > > resolver cannot stand the load, then it should be load balanced or
> > it
> > > > > should
> > > > > not be running in the first place.)
> > > > >
> > > > > Regarding using Service Refs, these have different semantics than
> > XRD-
> > > > > level
> > > > > Refs. Service Refs can only be HTTP(S) endpoints; and they do not
> > > > support
> > > > > the "if I can't find the service here then follow the Ref"
> > semantics.
> > > > That
> > > > > is, they really don't address Andy's use case.
> > > > >
> > > > > ~ Steve
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Victor Grey
> > > > > Sent: Sunday, September 23, 2007 4:18 PM
> > > > > To: Steven Churchill
> > > > > Cc: xri@lists.oasis-open.org; andy.dale@ootao.com; 'Kermit
> Snelson'
> > > > > Subject: Re: [xri] Clarity around Ref processing behavior.
> > > > >
> > > > > Steven Churchill wrote:
> > > > > > Les has repeatedly called for other people's view on this issue,
> > > > > > and Andy
> > > > > > has prepared an excellent article that I have attached. (Andy is
> > not
> > > > > > registered to send to the mailing list.)
> > > > >
> > > > > I find Andy's argument compelling from a philosophical point of
> > view.
> > > > >
> > > > > But what worries me is that in his example, a proxy resolver would
> > > > > have to make calls to at least 8 different network endpoints to
> > > > > ascertain that a SEP was not available, or find all the SEPs of a
> > > > > particular type:
> > > > > 1. resolve andy at =
> > > > > 2. resolve ooTao at @
> > > > > 3. resolve andy at @ooTao
> > > > > 4. resolve mfkd at =
> > > > > 5. resolve yahoo at @
> > > > > 6. resolve mfkd at @yahoo
> > > > > 7. resolve wow at @
> > > > > 8. resolve mfkd at @wow
> > > > >
> > > > > Given indeterminate network latency, the proxy resolver could be
> > > > > spinning its wheels for an unacceptable length of time.
> > > > >
> > > > > Pardon me if I'm just not getting it, but wouldn't Refs at the
> > > > > Service level provide the same capabilities that Andy's use case
> > > > > requires, but in a more efficient way? So that if =andy wants to
> > > > > assert a freetime svc, it would include a Service element with
> that
> > > > > type, but no URI, only a Ref to @ooTao*andy.
> > > > >
> > > > > It does make provisioning more complex, because the service would
> > > > > have to be provisioned both at @ooTao*andy and at =andy.
> > > > > But provisioning doesn't need to happen in real time, resolution
> > > > > does. Besides, that could be a feature, providing even more
> > > > > flexibility about what can be discovered from where.
> > > > >
> > > > > =vg



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