RE: [xri] Clarity around Ref processing behavior.

["Drummond Reed" <drummond.reed@cordance.net>]

Steve,

In ED05, it says that the synonyms in the XRDS returned by following the
Service Ref MUST be identical to those in the preceeding XRD, or else
CanonicalID verification fails. In other words, with a Service Ref, you're
just moving the physical location of the XRDS, not the logical parent.

That said, I've been thinking about service refs since sending that last
message last night, and I have some new thoughts. I'll send them next in a
separate message to start a new thread.

=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