XRIs are icky
By
Chronos Tachyon
on February 24, 2007
While I can see a certain appeal in providing short identifiers like =foo, I think XRI is one of those standards like X.500 that would be better off lost and forgotten.
For one, the process for resolving an XRI is hideously complicated and lengthy under the hood. It hides a whole mess of Lovecraftian request-response trips, all gibbering madly in the dark. Diagnosing a problem in the XRI resolution chain is going to make the chicken-and-egg problems of DNS delegation look like child's play, especially since the whole mess still depends on DNS anyway.
Second, the delegation free-for-all that will happen if i-names take off is going to be the .name TLD all over again, except this time you lose 1d6 Sanity points.
The problem, of course, is that XRI doesn't actually solve the problem it tries to. It's applying technology to a social problem. Just like best practice with HTTP is already to make URIs permanent -- yet it rarely actually happens due to human behavior -- XRIs won't actually be as permanent as OASIS wants them to be, and then we'll be stuck with a twenty-fold increase in the number of TCP handshakes to do all this XRI authority resolving, with no tangible benefit over DNS.
Discussion (1)
I tried reading the XRI spec, and I didn't understand the major points in 20 minutes. It fails the primary test I have for standards.
We would do much better with hash based URNs for DTDs and other pieces of relatively static data that are shared by many sites. I especially like that idea for Javascript libraries as it makes it so much nicer when multiple sites are using the same (rather largish) libraries.