W3C TAG posted a note that it is against XRI.

http://lists.w3.org/Archives/Public/www-tag/2008May/0078.html

Here is the arguments that lead to the above decision.

http://lists.w3.org/Archives/Public/www-tag/2005Apr/0095.html

http://lists.w3.org/Archives/Public/www-tag/2008Feb/0009.html

Unfortunately, the recomendation does not specify what exactly is unhappy about. So, I was going over each reason sited in the above documents (which has been replied by Gabe Wachob before.)

1) All access to resources identified by XRIs
require (at least) two round trips, the
first to retrieve metadata (XRDS, XRD or

uri list) and the second to retrieve
(a representation of) the resource itself?

Quite right. And if it were just for simple resolution of XRI, XRDS probably would not be required, but as a service selection language as used in OpenID, it would be very useful. It would also provide a sort of failover capability. Thus, at a glance, the requirement to make two round-trips to get to an actual resource is a burden, it has the merits.

2) HTTP content negotiation can be used in
requests for XRIs to force either metadata
return or redirection to actual resource

representations?

This actually is what is being done in XRI specification for HTTP binding. (XRI Resolution Section 6)

For non-http protocols (well, XRI does not have to be on TCP/IP network), of course, it cannot.

Looks like W3C TAG is assuming everything would happen over TCP/IP and HTTP forever.

3) Relative XRIs are of course allowed in the
normal way when a full-form XRI has been

established as the base URI. Are they also
allowed _without_ any full-form XRI as a
base URI? That is, for example, is