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: 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]