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: Thoughts on the conceptual model for XRI resolution


Per the minutes just posted on last week's XRI TC calls about the conceptual
model for XRI resolution, after thinking about it over the weekend, I offer
the following thoughts.

At the conclusion of Friday's call, we identified that there were three
potential functions of XRI resolution:

1) Authority resolution, i.e., a defined mechanism for constructing the next
resolution HTTP URI for any additional subsegments in the authority segment
of an XRI.

2) "Path" or "Local" resolution, i.e., a defined mechanism for constructing
an HTTP URI corresponding to the local part of an XRI.

3) Lightweight service discovery, i.e., a defined mechanism for associating
other service endpoints besides authority resolution endpoints and local
resolution endpoints associated with the identified resource.

The proposal Gabe made late last week
(http://www.oasis-open.org/committees/download.php/15006/HTTP-Aligned%20Reso
lution.doc) emphasized the first two of these, and suggested that the third
should possibly be treated as a separately-defined interaction with the HTTP
endpoint discovered via functions #1 and #2 above.

However on Friday's call there was a great deal of feedback about the value
of #3, and how much more efficient it can be to have lightweight service
discovery as part of XRI resolution.

In this light, let me suggest how the general approach suggested in
http://wiki.oasis-open.org/xri/Xri2Cd02/ReSolution/I9NamespaceRefactor and
http://wiki.oasis-open.org/xri/Xri2Cd02/ReSolution/I10XridRefactor can
enable us to achieve all three functions simply and consistently.

The conceptual model of this approach is to treat XRIDs as a mechanism for
discovering two types of information associated with any XRI-identified
resource (whether the resource is at the authority level or the local
level):

1) Synonyms - alternate XRIs for the identified resource.

2) Service endpoints: concrete, typed URIs that can be used to further
interact with the identified resource.

In the second category, authority resolution endpoints (both those
supporting generic and trusted authority resolution) and local resolution
endpoints are two specific types of service endpoints that would be defined
in the XRI resolution specification. But the same pattern for describing
these specific types of service endpoints could be extended to any other
type of service endpoint that may be associated with a resource, e.g., an
authentication service endpoint, a contact service endpoint, a data sharing
service endpoint, etc.

The pattern for this lightweight service endpoint description is very simple
and applies uniformly to all service endpoints, including authority
resolution and local resolution. It consists of four elements, all optional,
and all except MediaType having a datatype of anyURI.

1) Service provider ID. This element fulfills exactly the same role that
"AuthorityID" serves in Committee Draft 01. It provides a unique persistent
identifier for the provider of the service, which supports trust models such
as SAML for trusted interactions with this authority. (Note that
http://wiki.oasis-open.org/xri/Xri2Cd02/ReSolution/I10XridRefactor proposes
to call this element "Authority", but to avoid confusion with XRI syntax, it
simply be called "ProviderID".)

2) Service type. This element identifies the type of the service.

3) Media type. This element can be used to further describe the resource
type to a service endpoint that understands this, e.g., an HTTP or HTTPS
endpoint.

4) Service endpoint URI. The concrete URI of the service endpoint.

With these four elements, we can not only describe any authority resolution
service endpoint, and any local resolution service endpoint, but any other
type of resolution endpoint, and all in the same simple conceptual
framework.

=Drummond 



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