The relation between &nris; and the information resource they identify should persist indefinitely.

Or, more realistically, that individual &nris; should manifest syntactically whether or not they are intended to persist indefinitely.

This goal is difficult to get to grips with, as it appears to mean different things in different contexts:

http: URIs support persistence as well as it is in-practice possible to do so.

As has been frequently observed, achieving either of the numbered types of persistence above is not a technology issue, it's a management issue. It's up to the owners and operators of the mechanisms which implement &nri; resolution to enforce whatever degree of persistence they choose. It follows that there is no difference here between &nri; and http:.

What of the more sophisticated reading, that &an; &nri; should manifest its minter's intentions with respect to persistence? That's just a matter of naming conventions, and perfectly possible using http:. We could, for example, say that all versionable/time-varying resources on our site are named with all lower-case letters, and all persistent/stable/non-varying resources are named with all upper-case letters.

&nris; should be susceptible to standardization within administrative units

This goal appears to be directed at guaranteeing certain invariants, for example with respect to the structure of identifiers and the availability of the resources they identify. This means they should not be creatable in a distributed or unsupervised fashion.

Again, this is largely a management issue, not a technical one. Whatever invariants are in view can as well be enforced on (sub-parts of) http:-served resource collections as on those identified via &nris;.

Nothing in a specification can stop people from uttering URIs of any kind. Domain names are as good, or as bad, at conveying ownership of a particular form of URI as URN namespaces or URI schemes.

Centralized authorities can be established for parts of domain space as easily as for areas "off the web", and enforcement mechanisms can be as effective. For example, my employers constrain the mechanisms by which web pages are accepted for serving from certain parts of their domain so as to enforce invariants both of path structure and content markup.

Access to resources identified by &nris; should not be dependent on any particular protocol.

Exactly what this means is not clear -- although it is listed as a requirement in several cases, there is little or no discussion, so exactly why it should be a requirement for &nris; is not clear.

http: URIs are no more protocol-dependent than any other identification mechanism.

For pure naming, that is, if retrieval is never intended, http: is as good as any &nri; approach, because no protocol at all is involved. If retrieval is anticipated, then any &nri; approach must specify a mapping to one or more protocols. All existing &nri; approaches in practice specify only one such mapping, to the HTTP protocol. So they are in exactly the same position as http: -- if for some reason in the future the HTTP protocol becomes unavailable or inappropriate, both &nris; and http: will have to specify a new mapping.

True protocol independence is difficult to imagine in practice, as many protocols depend on a tight coupling between message formats and client/server application models. Protocols which don't allow servers any escape mechanism are thereby pretty much ruled out as transports for retrieval from &nris; (or http: URIs).

It's appropriate to note here that in cases where the necessary form of client/server interaction for a particular kind of information resource, for example streaming video, cannot be provided by the protocols normally associated with existing URI schemes, new schemes may be appropriate. Detailed discussion of this point can be found in . But none of the &nri; proposals are for resources of this kind.

&nris; should not be locations.

Practical realities and administrative changes will always defeat any attempt to guarantee that the representation of a particular resource will always be stored in exactly the same host/server/filestore/directory/file. Any naming mechanism which equates locations in that sense with names is by construction inadequate. It follows that this goal is a sensible one.

http: URIs are not locations.

Misunderstanding of http: URIs as locations has a long and, in part, justifiable history (they were, after all, originally called Uniform Resource Locators). But it's not longer justifiable either in principle (the RFC for URIs is quite clear on the subject) or in practice (there's lots of software support for server-side management of the relationship between http: URIs and their representations). See for example the classic for a more detailed discussion of these points.

&nris; should provide for structuring resource identifiers with shareable tags

This requirement has only been suggested by the authors of . It amounts to a wish to structure resource names using name/value pairs, with the names having some standardized, widely understood meaning. This requirement is related to requirements appealed to in the design of End Point References , .

The query component of http: URIs supports non-hierarchical structured naming.

It is open to any naming authority to establish conventions for the use of the query component of http: URIs under its control. Since the query component is already structured in terms of simple name/value pairs, it is a good fit for the requirement.

&nris; should provide as well for access to metadata about as to representations of a resource.

Several &nri; proposals establish a constructive relation between the &nri; for a resource and the &nri; for metadata about that resource.

Naming conventions or response headers can provide this already

Naming authorities can impose such constraints on the http: URIs under their control. Alternatively, and particularly where it is appropriate to allow for meta-metadata, etc., the Link: response header may provide equivalent functionality in a more extensible way.

&nris; require different approaches to identifying namespace authorities, in some cases simpler and in others richer than that provided by hierarchical domain names administered by IANA and resolved via DNS.

http: URIs can encode arbitrarily complex (or simple) namespace authority expressions.

Complex encodings of dependent and delegated naming authority can be implemented using proxies and redirection. In the other direction, proper management of domain names for http: URIs can produce names which are very little different from the equivalent &nri; (compare e.g. http://lccn.info/2002022641 to info:lccn/2002022641), while gaining all http:'s benefits of scalability and installed base.

The XML Namespaces specification is the context-defining specification for namespace names. It specifies that namespace names are for use in expanded names consisting of a namespace name (or no value) plus a local name. An expanded name may be compared against other expanded names. Very common scenarios are for performing well-formedness checking and for content model validation. The namespace specification, roughly speaking, says that a namespace name cannot be assumed to be dereferenceable. Any software component that is written assuming that any namespace name must be dereferencable is violating the namespace specification. It may be that the namespace owner has guaranteed that they will provide a document at the namespace name, but namespace owners are not required to do so and not all do. As a result of this, generic XML software should not be written to assume dereferencability of namespace names.

Any use of identifiers, from namespace names to isbn numbers to invoices, requires a context. The context will define the use of the identifier and includes social and technical context. A URI on the side of a bus will probably convey the social meaning that it can be typed into a browser. Other contexts for the use of URIs include namespace names, references to documents, and identifiers for things. It is never the case that a URI is simply "found" without a context.

First we examine the use of an http: URI for a namespace name. We will choose the OASIS WS-RM TC's HTTP Namespace name as an example.

Compare this with the use of a urn: URI for the namespace name. We will use the OASIS UBL rules for namespace names. The UBL rules are roughly that the namespace names for UBL Schemas holding OASIS Standard status must be of the form: urn:oasis:names:specification:ubl:schema:<subtype>:<document-id>. For example, the first namespace name for the first major release of the Invoice document has the form urn:oasis:names:tc:ubl:schema:xsd:Invoice-1.0, such as:

In all XML namespace software, both approaches work correctly. The software-only interaction pattern is clearly erroneous if it assumes that a namespace name is dereferenceable, and it is unlikely that XML software written today requires this assumption be valid.

Let us know examine the persistence of the identifiers. The oasis URN namespace, as used in urn:oasis:names:tc:ubl:schema:xsd:Invoice-1.0, is assigned by the OASIS organization and registered with IANA. OASIS has the authority to change its identifying scheme, subject to IANA review. Additionally, the actual names are decided by OASIS. As with all URNs, the persistence of any particular identifier and scheme are up to the registering organization.

An http: URI for OASIS namespace names, such as http://docs.oasis-open.org/ws-rx/wsrm/200602, is assigned by the OASIS organization because it owns the oasis-open.org domain. They do not have to register the complete URI anywhere. OASIS has the authority to change the template on it's own, without any review. Additionally, the actual URIs are decided by OASIS. As with all URIs, the persistence of any particular identifier and schema are up to the owner of the domain. It is possible for the domain to cease being owned by OASIS, through lack of maintenance or even error.

We might imagine a scenario many years down the road where OASIS no longer exists. It would not maintain the oasis-open.org domain name and http: identifiers using that domain would no longer be assigned. Alternatively, OASIS does not produce or mint any new URNs. In either case, the identifiers are not dereferenced so all the existing software works.

In URN and http: scheme cases, the persistence of the identifier is accomplished by the organization. The ongoing existence of the organization does not affect the persistence of the identifiers.

But, if one of these identifiers appears in a document, how will a human find out the meaning? One approach is examine the context surrounding the identifier, in this case the XML document and the Namespaces specification. They will look in the XML Namespace specification and see what it says about namespaces. There is no benefit to the xri: versus http: as the work in examining the XML document and XML namespace specifications are the same. Alternatively, they may try to dereference the namespace name, but it's not deferenceable so they get no information.

It is natural for a human reading an XML document with an unknown namespace name to want to understand more about the namespace. This is why recommends providing a document at a namespace name that provides both human and machine readable information. The use of http: namespace names enables 3 separate scenarios:

an identifier can be created in a decentralized manner;

These are two distinct interaction patterns, without and with human involvement.

In all dereferencable identifier scenarios, an identifier must be usable to generate an authority. There may be interactions with multiple authorities to determine the "final" authority for the identifier. The final authority uses the identifier to produce a document.

In the http: identifiers, the authority is specified immediately after the scheme. The authority system in http: URIs is the internet's DNS and IP systems. One or more DNS authorities produces an IP destination as the final authority. That authority is then sent the remaining part of the URI for dereferencing. In the case of http://docs.oasis-open.org/ws-rx/wsrm/200602, the HTTP interaction is

A common reason given for needing &nris; for namespace names is that an http: identifier appears to humans as a location and hence dereferencable. The argument that http: URIs are "locations" is based upon incomplete understanding of the use of URIs. A classic scenario is that a human looks at an XML document using a word-processing application, and the application formats the value of an xmlns attribute as a hyperlink, because it is an http: URI, say http://example.org/ns/foo. But as there is no document dereferencable from that URI, when the user clicks on the link an HTTP 404 will be returned. The obvious downside is that the user has wasted some time, typically around 5-10 seconds. There is no additional harm than that in clicking and getting a 404.

Under what circumstances are identifiers viewed as "clickable", that is what are the contexts? In this document, neither of the xmlns links have shown up as clickable. When these documents were pasted into an email, they were not converted to clickable. The http: link was converted to clickable only when the myns attribute was typed by hand and auto-complete was on. It was the e-mail program's "auto-complete" that saw an http: within a pair of quotes and made it clickable. It also required that rich text or HTML formatting is selected in creator and receiver/viewer. When viewed in plain text, the link is not clickable. The clickable link arises when a document is typed by hand, with auto-complete turned on, and then viewed by with HTML formatting. Neither of these applications is treating the document as XML, rather they are treating it as HTML. In particular, none of the applications know anything about XML or the xmlns attribute. Thus the context of usage has incorrectly view the xmlns attribute as HTML. When this happens, that is people are reading and writing sample XML documents using HTML formatting, the worst downside is that a person may waste 5-10 seconds.

Contrasting with this is the approach of using &an; &nri;. &An; &nri; provides an identifier. A human looking at an xml document with &an; &nri; namespace name will not be confused about whether it is dereferencable or not. No software will "auto-complete" e.g. an xri:... identifier into a clickable link. The 5-10 seconds of potentially wasted time are avoided.

Namespace names are just one example of a context of use. Any use of an identifier, or any datatype for that matter, in an XML document has the same issues. A provider of a identifier must specify how the identifier will be used in each specific sub-context of their XML language, whether it is intended as an identifier, a location, or both. Using &an; &nri; instead of an http: URI does not make the software or human's job any easier.

This section has shown that http: uris have a large benefit over urns: when used as namespace names because the namespace name could optionally be dereferencable, and the only downside is a fairly minimal amount of wasted time when a namespace name appears dereferencable but isn't.

This sections provides an overview of document retrieval of http: versus XRI: For comparison purposes, it shows document retrieval for a given URI and for a given XRI. Consider the worked example from , in which a department of a government agency published a document named govdoc.pdf. It assigns a URI http://department.agency.example.org/docs/govdoc.pdf. observes that changing the organizational structure represented in the URI, for example to http://newdept.agency.example.org/docs/govdoc.pdf, or the path structure, for example to http://newdept.agency.example.org/documents/govdoc.pdf, breaks access.

suggests that an xri: URI for the same resource can be designed to be location independent, for example xri://@example.org*agency*department/docs/govdoc.pdf deals with delegation by using stars ("*"). Another solution advised by is to use identifiers that have bang ("!") symbols to indicate persistence. An example is xri://@!9990!AF8F!1C3D/!2495. We examine this scenarios in order.

Another common reason for a new identifier scheme is to come up with an identifier that is location-independent or "movable" from one location to another. The idea is that the document changes location but the identifier should still resolve to the same document. In all cases, there must be some kind of mapping of the identifier to the "new" location if a location is changed. There is a publishing step, where the "new" location is added into the registry for the identifier.

The persistence of an identifier has operational and expressive characteristics.

Protocol independence is a goal of XRI. The previous HTTP redirects have shown that HTTP can do redirects, and it can do redirects to non http resources. Starting from HTTP, a redirect to an ftp: resource is possible. An important but subtle aspect of the web architecture is that the http: scheme for identifiers does not require the HTTP protocol to be used. This is explored in .

We suggest XRI should create URIs using the http: scheme, rather than inventing a non-URI based scheme. The thread of documented good practices is that leads to this conclusion starts from :

To benefit from and increase the value of the World Wide Web, agents should provide URIs as identifiers for resources.

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.

Intent is part of the potential metadata in URIs discussed in .

URI assignment authorities and the Web servers deployed for them may benefit from an orderly mapping from resource metadata into URIs

The XRI community could define constraints on http: uris containing a particular domain, such as xri.net. The rules for persistence and location independence can be defined. They could start with http://xri.net followed by roughly the current XRI rules and taking into account URI character constraints. For example, the previous XRI persistent identifier could be similar to: http://xri.net/@;9990;AF8F;1C3D/;2495. An alternative common practice for persistent identifiers is using UUIDs in the URI, ie:http://example.org/6B29FC40-CA47-1067-B31D-00DD010662DA. Location independent identifiers can be achieved using HTTP redirects. There are many varieties of constraints upon any URIs and use of HTTP redirects. One generalized framework for mapping XRIs or URNs to http: URIs is at .

We have shown that http: identifiers for XRIs can achieve the goals of XRI with substation benefits. The XRI goals of persistent identifiers and location independence are already available with http: identifiers. There are two concrete benefits to using XRIs identified in the previous analysis: that users cannot waste time by erroneously dereferencing namespace names that do not have namespace documents, and that an extra HTTP GET request is avoided when documents move. The XRI identifier solution's downsides are adding a new identifier scheme with the software and human costs and seemingly mandatory increased network costs ( our example shows 2 HTTP GETs instead of 1). Given these costs and benefits, deploying a new registrar, resolution mechanism and related software to layer on top of existing web functionality is not justified.

Our analysis has shown that if the scheme definition for xri: says that it is dereferencable, and specifies a mechanism, then either that mechanism is HTTP, or it will have to provide all the functionality, and thus be heir to all the weaknesses, of HTTP. In either case little benefit has been gained over just using the http: scheme itself. Note we have not yet compared the authority resolution mechanisms and the dependence upon centralized authority. We have also not compared the distributed authoring of identifiers either.

In the &nri; identifier scenario, the "location" to be used for knowledge is somewhere in the application or in some property of the &nri; such as a URI scheme or URN (sub)scheme. The &nri; proposals includes means to transform &an; &nri; into a dereferencable address via lookup using a registry server. This in turn requires the use of a dereferencable address for the server, or else all software intended for use with &nris; must have the registry server locations "hard-coded". As far as we can tell, all the &nri; proposals expect the results of server lookup to be an http: URI, and also appear to use an http: URL to identify the location of the registry server.