Detailed technical reasons why I'm against XRIs

I am against about XRIs because I believe the benefits, which can achieved in other designs, do not come close to warrant the costs, including complexity of software, user experience and harm to the Web.  The W3C TAG, chaired by Sir Tim Berners-Lee and Stuart Williams, recommends against XRIs.  Henry Thompson and I have gone into much more detail previously in the draft TAG finding http://www.w3.org/2001/tag/doc/URNsAndRegistries-50

My concerns can be categorized into 3 major categories:

1. Replacement of ICANN/DNS
2. Replacement of URIs
3. Replacement of HTTP

These will be examined in order.  Then I will go through a few of the claims that are made by XRI.

1. Replacement of ICANN and DNS.
XRI and XRI resolution are a replacement for ICANN and DNS.  I believe that wanting to replace the core naming system on the internet had better have some huge benefits to the users and developers, certainly more than XRI owners receiving a few dollars per name instead of domain registrars.  There is the obvious duplication of issues around persistence of names and naming conflicts.  The costs appear to be similar, that is =orchard and orchard.name cost roughly the same.   There are many claims as to the benefits of using iNames instead of domains, yet the comparisons against ICANN appear to be unfounded or marginal.  For example, there are claims that domain names will be "lost", yet many domain registrars provide 10 year or more terms and numerous renewal messages   There are claims that XRIs help prevent "phishing" but that smacks of fear-mongering. 

Dan Brickley did a great job of extracting the business model and IPR issues around XRIs, even back to the earlier incarnation as XNS in http://danbri.org/words/2008/01/29/266

2. Replacement of URIs by XRIs 
There are a number of concerns related to the replacement of URIs by XRIs. 

2.1 Unregistered URI scheme requiring escaping to be legal URI characters

XRI syntax specifies a new URI protocol/scheme but has not registered it.   (from http://www.oasis-open.org/committees/download.php/15376/xri-syntax-V2.0-cs.html)
"However because XRI syntax includes syntactic elements other than those defined in [IRI] and [URI], this specification defines a new protocol element,"XRI", along with rules for transforming XRI references into generic IRI or URI references for applications that expect them ".

The crucial problem is the requirement that any document containing XRIs MUST be processed by an XRI processor before any URI resolution is done, without any clue from the media type or even a URI used to retrieve the document.  This requirement for pre-processing adds considerable complexity.  It is effectively inserting a new processing step at the beginning of the XML Processing Pipeline.    

Additionally, any new protocol elements should be registered as URI schemes, though I expect it would be rejected because of the escaping required to become valid URI characters.

I would expect that registering a new URI scheme, especially for a specification that has been fairly done for 3 years, would be done before finalization.  The W3C does this with registering media types and the same process is very reasonable.   Waiting to do registration after standardization is far too long. 

2.2 Replacing relative URIs 

XRI introduces base XRIs that mirror base URIs.  In many situations, relative URIs may be mistakenly used as relative XRIs, and relative XRIs may be mistakenly used as relative URIs.  This could be incredibly harmful and seems similar to mistaking pounds for kilograms.  A key part of this is that setting base XRI is unclear.   

There is a claim that "=orchard" will only be recognized as a relative XRI in the presence of a base XRI.  This claim is unsupported in the specifications.  There is no text that specifies that a URI starting with XRI special characters is a relative URI when a base XRI is available.  There is no specification of what behaviour is expected when a base URI is available, a base XRI is available, and a URI contains a relative XRI.  Harmfully, it is not clear what behaviour should occur when a base URI and a base XRI are available and the URI string contains a relative URI, ie "orchard".  

The issue of short names grounded in URI (or even XRI) space continues to surface.  Namespaces, QNames, CURIEs, Microformats, RDFa, and many technologies are looking into this area.  With all the diversity and potential issues around interpretation of short names in strings or URI types, probably the last thing that the community needs is a short name grounded in non-URI and even non-HTTP space.

2.4 Extra Effort and Confusion 

The choice of XRIs versus URIs causes extra effort on the part of implementors and users.  For example, OpenID allows XRIs for user IDs as well as namespace declarations.   There are a number of special rules added for XRIs, adding significantly to the development cost.

2.5 Lack of Interoperability

Any time a specification, such as OpenID, has optional features, implemenations may and often will ignore them.  It is a continual source of problems for users and implementors.  A factor in whether a specification is testable and interoperable is the amount of such optional features, lower being better.

In the case of OpenID, when providers and consumers do not support OpenID, of which there are many, it will invariably lead to confusion and problems. 

2.6. Version confusion.

The TC is publishing the XRI Syntax V2 Committee Specification, 14 November 2005 and XRI Resolution V2 Committee Specification 1 12 April 2008.  The  XRI Resolution V2 specification specifies that it is related to Extensible Resource Identifier Syntax V2, Committee Specification, December 2005, which I cannot resolve and I assume is the November 2005 specification. 

OpenID uses the XRI Syntax Committee Specification, 14 November 2005 and XRI Resolution Working Draft 10, 18 March 2006.   I cannot find the differences between the Resolution March 2006 draft compared to April 2008 and whether those changes are applicable to OpenId. 

Presumably this means that OpenID 2.0 would need to be updated to refer to the latest version of XRI Resolution.  Such an update cycle would be more usefully spent removing XRI from OpenID.

3. HTTP Replacement 
Instead of using http based content negotation, the requested media-type is encoded in the URI.  For example,

Request URI:
http://xri.example.biz/=example*book?_xrd_m=application/pdf;sep=true
The "sep=true" media type subparameter indicates the proxy resolver should
perform service endpoint selection using the media type requested; the
absence of an _xrd_r parameter means it must return a redirect as specified
in section 11.7.

Again, they've re-invented something from HTTP.

Specific XRI Claims

I posted a response to XRI solves Real Problems in http://www.pacificspirit.com/blog/2008/05/28/xri_solves_what_real_problems.  In general, I didn't find real user problems in document.

There are a few detailed claims that I have found that can be examined.

1. HTTP URIs are bound to a specific network protocol. XRIs are by definition protocol independent.

Technically, no.  The TAG, in http://www.w3.org/2001/tag/doc/SchemeProtocols.html, and Roy Fielding have all regularly disputed this. 

If the desire is to be protocol independent, then I suggest that there are specifications like SOAP and WSDL that are designed for protocol independence that are more suitable for achieving that goal.  Interesting that they aren't that trendy, in large because they are protocol independent.  Protocol independence appears to be a bug on the web, not a feature.

2. HTTP URIs do not provide any standard way to determine if they are reassignable or persistent. XRIs provide unambiguous syntax to distinguish between persistent and reassignable identifiers..

The XRI community could have easily provide a URI template that myself, Mark Nottingham, Joe Gregorio, and others have worked on (http://bitworking.org/projects/URI-Templates/draft-gregorio-uritemplate-00.html)  that used http: URIs.  The approved TAG Finding on Metadata in URIs (http://www.w3.org/2001/tag/doc/metaDataInURI-31) explicitly licenses the relevent authorities to assign metadata in URIs. 

3. HTTP URIs do not have a standard service discovery format or protocol.
XRIs are discoverable using the XRDS format created by the XRI TC (and now widely adopted by OpenID, OAuth, Higgins, and other identity frameworks).

Deferencing an HTTP URI can easily retrieve a representation.  That is a fine and widely adopted protocol.  There is a lot of working in various communities to standardize how to get metadata given an identifier, such as Semantic Web, Web Services (WSDL and WS-MetadataExchange), Microformats, RDFa, Link Header (http://tools.ietf.org/id/draft-nottingham-http-link-header-01.txt) and more.  

I think the use of XRDS and XRDS-Simple is interesting as there does need to be a metadata specification for services.  I've worked on WSDL and WS-MetadataExchange and I'm intimitely familiar with many of the issues. 

But XRDS is completely separable from XRI.  The XRDS format and protocol could easily build on http: URIs. 

There are a couple more claims, but I desparately need to get this article published so I'll discuss them slightly later.

Summary

I believe that XRIs as a new naming schema and identifier format do not nearly justify the deployment costs associated.  The Web is built on URIs, HTTP and DNS.  For our users sake, we should use deployed technologies where possible.  In the case of XRIs, it is very possible, proven by the fact that most OpenIDs are http: URIs.