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