Lightweight Resolution Protocol for XRI?
There is a simplified resolution protocol discussed at Oasis XRI TC right now. I have been hopelessly falling behind in the recent development at XRI/XDI due to other tasks, but simplifying things generally are good thing, at least for me.
However, looking at the current draft, I started to think “why not more?”.
Maybe, it is different in other people’s mind, but to me, XRI simply is a protocol independent URI coupled with a resolution mechanism which is bound to protocols. In principle, I would not need a sophisticated XML files be returned on the way of resolution. In case of HTTP, just reveraging on 302 (or 307 in HTTP1.1) Redirect would do.
In the XRI resolution process, there has to be a default resolver to start with. In HTTP context, it can be a web server URI. Let this be http://example.com/xriresolver.php . Then, when one wants to resolve xri://=sakimura*nat/(+phone), the client throws the whole string to the resolver url. i.e., it will be something like:
Most probably, example.com has no knowledge about the whole string. It however does know about = (it is a GCS character). It may also know about =sakimura due to the resolution that other client did previously (cache). Suppose this is the case, and authority of xri://=sakimura specifies http://xri.sakimura.org/ as the authoritative resolver. Then, example.com can just return the Location: HTTP header like:
Now, in this case, “*nat” is a delegated authority, so xri.sakimura.org probably does not know anything after that. It only knows that =sakimura*nat points to http://nat.name/xri_resolver.rb . So, xri.sakimura.org, as the result of the resolution returns another location header:
By repeating these, in the end, we get the physical ID==URL of the resource. In the above example, it would be something like
It could be just a string or xml or html or metadata about the resource.
Note that in this mechanism, we needed no special client. Just a web browser will do.
For authentication, we could add a= as parameter standing for artifact. So, to start with, the query to the first resolver would become something like:
If the authorization fails during the resolution path, the resolution ends there.
I wounder what is the problem about this approach…