Talk:Extensible Resource Identifier

From Wikipedia, the free encyclopedia

“URIs … are the most successful identifiers in history.”

The identifiers “Rome” and “Athens,” and the whole “given name + family name” system of (human) identifiers have been pretty successful historically too. Maybe this article should say “URIs … are the most successful identifiers in network computing history” or something like that. Actually I think the statement is pretty dubious — who’s to say that URIs are more successful than the domain name system, or IPv4 addresses? —Fleminra 19:55, 25 April 2006 (UTC)

[edit] watch neutrality

I didn't see anything too blatant, but the overall tone seems to be more pro-XRI than neutral. Ojcit 00:34, 18 October 2006 (UTC)

[edit] copied text from OASIS

The following text appears on the oasis xri website.[1] Is there some public domain disclaimer that I don't know about?

== Why not just use HTTP URLs? == This is one of the most frequently asked questions about XRIs (after all, HTTP URLs are the most successful identifiers of all time.) First, the current working draft of the XRI Resolution specification includes a defined HTTP URL format in which any XRI can be expressed. So in essence, XRIs can be treated entirely as HTTP URIs for the purpose of backwards compatibility with HTTP infrastructure. From a broader perspective, however, the reason HTTP URI syntax itself was not used is that it does not fulfill several of the most important requirements for abstract, cross-context identifiers. Specifically:

  • HTTP URIs are bound to a specific transport protocol. A fully abstract identifier scheme needs to be independent of any specific transport or access protocol.
  • HTTP URIs do not support sharing structured, “tagged” identifiers across contexts. A fully abstract identifier scheme will enable “identifier markup” just like XML enables data markup.
  • HTTP URIs do not define a clear way to get at metadata (as opposed to data) about a resource. A fully abstract identifier scheme can cleanly distinguish access to resource metadata vs. a resource itself.
  • HTTP URIs offer only a very limited authority delegation model. Abstract identifiers need to be able to express logical authorities and authority delegation relationships.
  • HTTP URIs do not offer a trusted resolution mechanism. A fully abstract identifier scheme can define a trusted resolution protocol independent of DNS.
  • HTTP URIs do not offer a standard syntax for persistence. A fully abstract identifier scheme can clearly distinguish between persistent and reassignable identifiers.
    Retrieved from "http://en.wikipedia.org../../../e/x/t/Talk%7EExtensible_Resource_Identifier_21a4.html"