for names consisting of an adiminstrative hierarchy and a path, HTTP/DNS is as good as it gets

On 15-March-2005, the OASIS XRI TC released some documents for
public review...

... and the TAG started looking at them on 22 March...

Not having read the XRI docs (because of patent concerns), today I
suggested the following line of argument:

 1. XRIs follow the pattern of an administrative hierarchy
    followed by a path
 2. http/DNS handles the case of an administrative hierarchy
    followed by a path, and is ubiquitously deployed
 3. A specification SHOULD reuse an existing URI scheme
   (rather than create a new one) when it provides the
   desired properties of identifiers and their relation
   to resources.
 4. The XRI work should use http/DNS; the xri: scheme
    should not be introduced.

Point 2 seems to merit elaboration. So I'm taking a look
at the docs now...

In [XRI] section 3. How XRIs Help Solve These Problems, subsection
3.1 Persistent Identification, we see the familiar story
of a link breaking because a department gets renamed.

moves to

Then, it says, "A much better solution would be to assign the
resource ´govdoc.pdf¡ an identifier that never needs to change or
be reassigned." Quite! Absolutely! Cool URIs don't change[TBL].

[XRI] continues... "This can be accomplished using a fully
persistent XRI such as the following: xri://@!9990!A58F!1C3D/!2495 "

Well, now if the govdoc publisher had the foresight to
consider the possibility that the govdoc resource might
outlive the agency or its name, they could have used
a nice sturdy http/DNS URI in the first place, ala


That's assuming the government prefers to take responsibility
for long-term publishing of documents itself. Of course, this
could be outsourced to , who might issue the name...!1C3D/!2495

and then resolution can happen by way of HTTP (or https) redirects,
analagous to the way XRI resolution is described.

The point is
  * yes, it's useful to assign a persistent name in the
    first place, in case a resource outlives its original
    publisher, but

  * there's no reason not to use http/DNS to do this

When I started to read the next section, 3.2 Federated Identification, 
I thought maybe XRIs had made the split-point between the administrative
hierarchy and the path invisible at the syntax level, ala the
long-discussed path: scheme[DLL]. But it says,
"Once we have reached the public XRI authority*agency*department, it can switch to internal delegation"
which is nothing tricky at all; it's just like the
apache InternaRedirect mechanism (and analagous mechanisms in
other HTTP server architectures).

[XRI] ...
which bears the "Location"
which, by supreme irony, is 404


The Path URN Specification
Daniel LaLiberte (
Fri, 17 Mar 1995 16:58:25 -0600

Dan Connolly, W3C
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Tuesday, 19 April 2005 23:34:42 UTC