RE the ongoing W3C TAG discussions (http://lists.w3.org/Archives/Public/www-tag/, look for [XRI] in the header), I have reviewed the threads from when I was on vacation and have one thought that I want to run by XRI TC members on tomorrow's telecon before posting to the TAG list.

The thought regards persistence, which as we all know is just one of many requirements of XRIs, but which is a simple enough requirement that has long been embodied by URNs.

In this area, the XRI TC had two functional requirements in common with URNs:

1) To be able to express a fully persistent identifier as defined in section 2 of RFC 1737, Functional Requirements for URNs:

Persistence: It is intended that the lifetime of a URN be permanent. That is, the URN will be globally unique forever, and may well be used as a reference to a resource well beyond the lifetime of the resource it identifies or of any naming authority involved in the assignment of its name.

2) To be able to recognize a fully persistent XRI purely by inspection, i.e., without requiring resolution of any kind.

URNs meet both these requirements very easily:

1) All identifiers using the URN scheme are required to be persistent by definition. 2) All URNs can be unambiguously recognized purely by the urn: scheme prefix.

With XRIs it can't be quite that simple because XRIs by definition encompass both persistent and reassignable abstract identifiers (or any combination of persistent and reassignable subsegments). But XRIs still satisfy the same two requirements with just one modification:

1) An XRI is fully persistent if it consists entirely of persistent subsegments (subsegments that are delimited with the ! character). 2) All XRIs in URI normal form can be unambiguously recognized by the xri: scheme.

So here's the issue: the TAG has asserted (back during the OASIS vote in May) that all XRI requirements can be met by HTTP identifiers. While we have many other requirements beside persistence for which we do not believe that to be true, I don't think we need look any further than these very simple URN requirements. I've thought about this for hours and I cannot see how existing http: URIs can meet them.

The logic is not complex:

1) The http: scheme does not require http: URIs to be persistent. 2) The http: scheme does not define any syntax for indicating persistence.

Therefore, if an http: identifier is to serve the same function as a URN, and this quality is to be recognizable purely by inspection, it must be done with some additional semantics beyond the scope of the http: scheme.

QED. Unless, of course, I'm missing something, which is why I'm posting this to the list and asking for feedback. If you see a hole in this logic, by all means please do post a reply (especially if you can't make tomorrow's telecon).

Note that I'm _not_ saying that such semantics cannot be added to an http: URI. Indeed, that's just what we did with HXRIs. In fact on the W3C TAG discussions John Bradley has coinied the term "http: subscheme" to describe this URI-scheme-to-http:-URI mapping. I'm a big supporter of this because it makes sure all XRI-addressable resources can be fully exposed/integrated with the http: information space.

But I think the URN requirement issue alone shows why we still need the functionality of the xri: scheme. In fact, it appears that it is this type of requirements that is specifically in section 1.1 of RFC 3986 as it explains the rationale for URIs and different URI schemes:

This specification does not place any limits on the nature of a resource, the reasons why an application might seek to refer to a resource, or the kinds of systems that might use URIs for the sake of identifying resources. This specification does not require that a URI persists in identifying the same resource over time, though that is a common goal of all URI schemes. Nevertheless, nothing in this specification prevents an application from limiting itself to particular types of resources, or to a subset of URIs that maintains characteristics desired by that application.

******* Thoughts?

=Drummond