http://lists.w3.org/Archives/Public/www-tag/2008May/0078 The W3C TAG has finally finally said what we've been wanting for a long time. http: URIs are a very very very good thing. Replacing ICANN/DNS and http: URIs are a bad thing. 'nuff said
Although the XRI TC deeply respects the work of the W3C TAG, we believe the market is already demonstrating the utility of abstract structured identifiers and interoperable service discovery. We further believe they advance World Wide Web architecture in ways that are fully compatible with the W3C TAG's vision. We therefore urge OASIS members to support this innovation by voting in favor of the XRI 2.0 specifications
I still don't know what real world problems XRI solves. They posted a wiki page called XRI solves real problems. Looking through it, most of the material is about discussions with the TAG and where XRIs are being used, but very little about what real problems are solved despite the misnamed title. Let's go through the page step by step.
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
永続的か, 非永続的か
http://xri.net/@!B1E8.C27B.E41C.25C3!A7B8.4D42.3EF6.C2A9
I have now mixed what may be an in-persistent DNS authority with a
persistent XRI.
I have certainly lost the benefit of it being a URN, unless we move
forward with one of the proposals to create "Special DNS Authorities"
... or http://someproxy.com/boeing.com how is the application going to detect that it is a xri? In the current spec IRI authorities MUST always be represented with the xri: scheme to prevent...
Use beta.xri.net for testing accept header behavior in HXRI If an... parameters to control the proxy behavior. http://beta.xri.net/=jbradley?query&_xrd_r=application/xrds+xml returns...
the default behavior of the HXRI proxy - If the request contains no query parameters the proxy will provide some defaults / Public service discovery via XRDS documents is used in: 1, openID 2, oAuth 3, infocard r-card (higgins) 4, ID-WSF via openID and...
just as a URN is designed to be resolved into metadata about a resource, so is an XRI / an XRI proxy resolvers can service two different types of requests
XRI Syntax は IRI を受け継いでて, Resolution は DNS みたいだという話 / The XRI-TC has stated that they are willing to... accessed over SS7. / The only thing native XRI resolution has to do with http: is a...
XRI is a way of representing identifiers that are designed to be
resolved with a protocol that is more distributed and reliable than
the standard HTTP resolution mechanism.
In order to invoke that extra resolution machinery, it must be
possible for client apps to recognize these identifiers when they are
used as URIs. This recognition must necessarily happen before
resolution, not after.
XRIs will be used (as http or FTP URIs are used) in contexts where
there is no hypermedia to be the engine of state, or where the goal is
to bootstrap the hypermedia-based communication.
It would be incredibly valuable for XRIs to be backwards compatible
with HTTP clients through the use of HTTP URIs.
Therefore the current proposal as I understand it is to treat HTTP
URIs in subdomains of XRI.net as XRIs.
そもそも TAG が XRI-TC に "Good Practice: Identify with URIs" と言ったのが始まりじゃないか説
According to the May 10, 2005 TAG minutes XRI becomes an issue of
concern at that point and DanC is tasked to reply to the XRI-TC
pointing to http://www.w3.org/TR/webarch/#pr-use-uris
This states "Good Practice: Identify with URIs"
So the XRI-TC proceeds with a plan to register a URI scheme and make
XRI URI compatible.
If the message had been don't register a URI scheme re-use the http:
URI scheme perhaps the XRI-TC might have proceeded differently.
There was a bunch of unofficial back and forth at the time and some
things that may have only been stated in the private http://lists.w3.org/Archives/Member/tag/2005Apr/0097.html
. Its difficult to unwind it all. I was not involved at the time.