Jump to content

Talk:Extensible Resource Identifier

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 66.31.39.76 (talk) at 17:50, 10 September 2007 (→Licensing: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
“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)[reply]

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)[reply]

I agree completely, how about a counter-point from the W3C's perspective on XRIs?

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.

Licensing

I changed the licensing section as it is pretty misleading. I am an OASIS voting rep, the fact is that XRI is a proprietary technology and the xri.org kabuki dance fools nobody. The directors of this organization are not independent and even if they were the licensing terms currently on offer would not meet anyone's definition of an open standard. They do not meet the generally understood requirements for RAND, let alone free! The statement about offering RAND terms before the work is made final is also a red herring since nobody seriously expects the group to ever finish, if they did the OASIS membership would get the opportunity to vote the documents down. -- 66.31.39.76 17:50, 10 September 2007 (UTC)[reply]

  1. ^ http://www.oasis-open.org/committees/xri/faq.php#_Toc121168721
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Extensible_Resource_Identifier&oldid=156967379"