Resolution Architecture Proposal

["Wachob, Gabe" <gwachob@visa.com>]

Please consider this note a proposal for an architectural view of the
XRI resolution scheme. This has undergone some discussion between
several of us offlist, and now feels ready enough to discuss in the
group. This is my summary of the groupthink, so it really only 
reflects my views as TC participant at this point. 

Note that after this high level description of the XRI resolution
process there are some further notes below discussing things we've 
"thought through" and what we haven't.

--------------------------------------------------------------------
WHAT IS RESOLUTION:
Resolution is the process of taking an identifier (in this case an XRI
identifier - URI or URN) and discovering data/metadata/attributes
associated with that identifier. For those who are technical, think of
resolution as a function which takes an identifier as a parameter and
returns a set of data. f(id)={data}

In the case of XRI, we have gone a ways down the road in defining the
domain of the function (the types of IDs that the function takes). We
have not yet discussed (except in the strawman) the range of the
resolution function (ie what data is returned from the function) nor
the specific process or algorithm that the function takes.

This note attempts to lay out the thinking of the myself and several
other TC participants on the architectural precepts, assumptions, and
open questions we have on a particular resolution scheme that we've
devised (and is reflected, albeit without much rigor, in the
strawman proposal of April 15, 2003).

ARCHITECTURAL CONCEPTS:

Several architectural assumptions have been made to make resolution of
XRIs practical on the scales we envision for XRIs. The most
fundamental assumption is that XRIs are all associated with naming
authorities. XRIs are thus broken down into two parts: the "naming
authority part" and the "local part". The XRI TC will define a
resolution scheme for the "naming authority part" and at least one
scheme for interacting with a naming authority to "access" or
"lookup" the entire XRI (including the "local part").

The process of discovering the network endpoints for a naming
authority is called "naming authority resolution" and the process for
accessing resources relative to a naming authority (which may be in a
read, write, or read/write mode) "local access". It is expected that
there will be more than one "local access" protocol, and that these
"local access" protocols may in the form of directory protocols or
data exchange protocols.

Furthermore, it is the intent that these "local access" protocols may
should be common protocols such as LDAP, UDDI, plain HTTP, or may be
new protocols based on SOAP, REST or other modes of interaction. The
TC will not neccesarily require use of one "local access" protocol but
should define a binding to at least one or two very common external
protocols like those just mentioned.

Thus, the XRI TC will primarily add value as a way of unifying
identifiers across multiple namespaces, each of which is potentially
hosted in a different data store or directory. This is described in
the requirements and reflected in the syntax in the form of
hierarchical (delegated) naming authority parts.


GENERAL ARCHITECTURE OF THE RESOLUTION PROCESS:

It is now possible to see the general thrust of the XRI resolution
algorithm/process. A client wishing to "resolve" an XRI into some data
must first discover how to talk to a naming authority using "naming
authority resolution". Next, the client uses then use a "local access"
protocol to conclude the interaction with the data or resource
identified by the XRI URI/URN. Therefore, XRI resolution is really a
composition of two "subprocesses": "naming authority resolution" and
"local access".

The "handoff" between the "naming authority" resolution and the "local
access" protocol is an area where there needs to be a great deal more
brainstorming. One line of thought is that naming authority resolution
always results in something looking like (or in fact) a DNS NAPTR
record, where "local access" service instances are identified with
service type identifiers and network endpoints. Another approach is to
assume that all "local access" servics can be described with WSDL
(without assuming they are SOAP-based) so that the end result of any
naming authority resolution is a WSDL file. Another approach may be to
use a more generic description XML document like RDDL.

DATA AND IDENTIFIER INDEPENDENCE

Note that this algorithm doesn't make any assumptions about the type
of data the client expects when resolving an identifier. It also makes
no assumptions about the type of thing the identifier identifies.

For example, this resolution process should work when an identifier is
expected to return a document describing a resource (e.g. a RDDL file
about a concept identified with an XRI), a SOAP endpoint (e.g. a
WSDL file), or a application-specific document (e.g. a purchase
order). The process should also work whether the identifier
corresponds to a concept, a person, and organization, a system, or any
other sort of "thing".

---------------------------------------------------------------------


Things we have thought through (but are, of course, up for
discussion):

1) The TC is defining a way to resolve the "naming authority" into a
network-endpoint (or transport URI at least) to which a client can
talk a "local access" protocol. The lookup of the naming authority we
are calling "resolution".

2) The "resolution" process we are defining looks ONLY at the naming
authority part of the XRI URI/URN

3) There can be more than one "local access" protocol - there is no
one single "XRI local access protocol". In fact, it would be good to
define how protocols like LDAP or UDDI could be "local access
protocols".

3) The "local access protocols" are not neccesarily defined by the XRI
TC (though the TC should define one or more to make the XRI TC work
useful).

4) The output of the naming authority resolution process may point to
several network endpoints and may include other information such as
type of the local access protocol, or features of the local access
protocol so that a client can select which network endpoint to talk
to.

Things we HAVE NOT thought through:

5) Are "Local access protocols" always specific to a particular data
type, are they always generic data services, or can some be generic,
and some specific.

6) How do security tokens (e.g. digsig) get attached to the resolution
steps?

7) Is resolution carried out over DNS and HTTP as per the strawman?

	-Gabe