This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). URNs fit within a larger Internet information architecture, which in turn is composed of, additionally, Uniform Resource Characteristics (URCs), and Uniform Resource Locators (URLs). URNs are used for identification, URCs for including meta-information, and URLs for locating or finding resources. It is provided as a basis for evaluating standards for URNs. The discussions of this work have occurred on the mailing list firstname.lastname@example.org and at the URI Working Group sessions of the IETF.
The requirements described here are not necessarily exhaustive; for example, there are several issues dealing with support for replication of resources and with security that have been discussed; however, the problems are not well enough understood at this time to include specific requirements in those areas here.
Within the general area of distributed object systems design, there are many concepts and designs that are discussed under the general topic of "naming". The URN requirements here are for a facility that addresses a different (and, in general, more stringent) set of needs than are frequently the domain of general object naming.
The requirements for Uniform Resource Names fit within the overall architecture of Uniform Resource Identification. In order to build applications in the most general case, the user must be able to discover and identify the information, objects, or what we will call in this architecture resources, on which the application is to operate. Beyond this statement, the URI architecture does not define "resource." As the network and interconnectivity grow, the ability to make use of remote, perhaps independently managed, resources will become more and more important. This activity of discovering and utilizing resources can be broken down into those activities where one of the primary constraints is human utility and facility and those in which human involvement is small or nonexistent. Human naming must have such characteristics as being both mnemonic and short. Humans, in contrast with computers, are good at heuristic disambiguation and wide variability in structure. In order for computer and network based systems to support global naming and access to resources that have perhaps an indeterminate lifetime, the flexibility and attendant unreliability of human-friendly names should be translated into a naming infrastructure more appropriate for the underlying support system. It is this underlying support system that the Internet Information Infrastructure Architecture (IIIA) is addressing.
Within the IIIA, several sorts of information about resources are specified and divided among different sorts of structures, along functional lines. In order to access information, one must be able to discover or identify the particular information desired, determined both how and where it might be used or accessed. The partitioning of the functionality in this architecture is into uniform resource names (URN), uniform resource characteristics (URC), and uniform resource locators (URL). A URN identifies a resource or unit of information. It may identify, for example, intellectual content, a particular presentation of intellectual content, or whatever a name assignment authority determines is a distinctly namable entity. A URL identifies the location or a container for an instance of a resource identified by a URN. The resource identified by a URN may reside in one or more locations at any given time, may move, or may not be available at all. Of course, not all resources will move during their lifetimes, and not all resources, although identifiable and identified by a URN will be instantiated at any given time. As such a URL is identifying a place where a resource may reside, or a container, as distinct from the resource itself identified by the URN. A URC is a set of meta-level information about a resource. Some examples of such meta-information are: owner, encoding, access restrictions (perhaps for particular instances), cost.
With this in mind, we can make the following statement:
More specifically, there are two kinds of requirements on URNs: requirements on the functional capabilities of URNs, and requirements on the way URNs are encoded in data streams and written communications.