Sometimes it’s hard to judge whether an engineering effort has been successful or not. It can take years for an idea to catch on, to go from being the butt of jokes to becoming an international imperative (IPv6). Uniform Resource Names (URNs), which are part of the Uniform Resource Identifier (URI) family, are conceptually at least as old as IPv6. While not figuring in international directives for deployment, they-and the technology engineered to resolve them-are still going concerns.
The curious thing is that since the URN working group (WG) concluded in 2002, these two aspects (the URN itself and its resolution system) have had almost completely independent histories. Does the world have a universally supported, persistent resource-naming infrastructure for Internet applications, as envisaged at the outset of the URN WG in 1996? No, not by any stretch of the imagination. Were the six-plus years of IETF engineering effort therefore wasted? No, not that either. Rather, the URN work has contributed certain important building blocks that have been used and reused in efforts that have followed.
In the Beginning: The Intent of URNs
Along with considerable information about the expected and intended state of the Internet Information Infrastructure Architecture, RFC 1737: Functional Requirements for Uniform Resource Names, published in December 1994, outlines the requirements of Uniform Resource Names. Key to all of this is the intended purpose of a URN, which is identified as providing “a globally unique, persistent identifier used for recognition, for access to characteristics of the resource, or for access to the resource itself.” And, further, “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.”
The list of functional requirements for URNs is not that extensive, but it is constraining. That URNs are to be persistent, as well as global in scope and uniqueness, is pretty clear from the stated purpose. Additionally, the document stipulates that URNs are to be scalable (assignable to anything conceivably available on the network for hundreds of years) while supporting legacy naming systems, allowing independent assignment of identifiers by autonomous “naming authorities,” and still allowing “resolution” of URNs-that is, translation from the URN into one or more URLs.
RFC 1737 notes that it does not address the question of requirements for resolution, thereby leaving that question open. That open question was the source of many heated discussions within the URN WG over the years, with some proponents fiercely demanding “sub-second resolution!” as an imperative, while others wanted to first ensure distributed and resilient services.
A Technology Structure to Support the Intent
The URN WG was established in 1996, after proponents of several specific URN proposals had come to a high-level understanding of how to support a diversity of potential applications and needs for URNs while maintaining a generalized standard and support infrastructure. The key was to allow for independence in resolution systems while binding identifiers together under a single generic, URI-consistent syntax with a discovery system for the resolution services.
Put simply, and as captured in RFC 2141: URN Syntax, URN identifier syntax is
“urn:” <NID> “:” <NSS>
where <NID> is a namespace identifier (to distinguish between different schemes of persistent identifiers, with different authorities, etc.) and where <NSS> is the namespace-specific string. Within certain important constraints to synchronize with URI syntax, the namespace-specific string can be structured in whatever way the authority for the namespace wishes. This allows for either structured or unstructured namespaces as well as either human-readable or machine-oriented identifiers. And each namespace is completely independent of the next: each is free to reuse the same strings to different purposes.
To support that simple-yet-flexible identifier system, some level of discovery system was needed in order to be able to find the relevant final resolution services for the different namespaces. From RFC 2276:Architectural Principles of Uniform Resource Name Resolution, the architectural principles for URN resolution were based on two assumptions: “In general, we must assume that almost any piece of the supporting infrastructure of URN resolution will evolve. In order to deal with both the mobility and evolution assumptions that derive from the assumption of longevity, we must assume that users and their applications can remain independent of these mutating details of the supporting infrastructure. The second assumption is that naming and resolution authorities may delegate some of their authority or responsibility; in both cases, the delegation of such authority is the only known method of allowing for the kind of scaling expected. It is important to note that a significant feature of this work is the potential to separate name assignment, the job of labelling a resource with a URN, from name resolution, the job of discovering the resource given the URN. In both cases, we expect multitiered delegation.”
At the time, there was only one place to look for support of such multitiered delegation: the Domain Name System (DNS). So the URN WG developed a resolution discovery system, rooted at URN.ARPA and defining Naming Authority Pointer (NAPTR) DNS resource records to suit in 2000, which was originally defined in RFC 2915: The Naming Authority Pointer (NAPTR) DNS Resource Record and was updated by RFC 3403: Dynamic Delegation Discovery System (DDDS): Part Three: The Domain Name System (DNS) Database.
Simply put, the discovery system works by starting with <NID>.URN.ARPA and using the content of the retrieved NAPTR resource records to identify subsequent steps in discovering where and how to resolve a particular URN. Practically speaking, this means that the authority for resolving ISBN-based URNs could rest with an international ISBN body, while new namespaces for computing activities could be built to partition resolution responsibilities among several subauthorities that are not traditional publishers at all. Equally important, this distribution of the underlying resolution authority could change over time, because the discovery system provides dynamic rules for directing requests to appropriate authorities.
The overall principles are simple-explained in less than 500 words!-but the system also provided for a great deal more complexity and power to address the many side issues that have been raised during all the years that identifiers for the Internet have been discussed.
Initial Steps-and Immediate Divergence of Intent and Structure
Over the next few years, a number of URN namespaces were registered with the Internet Assigned Numbers Authority (IANA), per the registration process outlined in RFC 2611: URN Name-space Definition Mechanisms (and updated by RFC 3406: Uniform Resource Names [URN] Namespace Definition Mechanisms, in 2002). The key purposes of a formal registration process for URNs included ensuring that some conscious effort was put into securing a piece of real estate in the URN namespace identifier space, including a review of the principles of URNs (persistence, global uniqueness) and an indication of how URNs in the namespace are meant to be resolved. Notably, none of these registered namespaces elected to use the global resolution discovery service based in the DNS. However, almost immediately, another application was found for this dynamic, distributed approach to resolution in the work of mapping E.164 (telephone) numbers to Internet telephony resources, in the ENUM WG.
RFC 2916: E.164 number and DNS described this first non-URN application using NAPTR DNS resource records. Notably, the ENUM work was not defining a URN namespace; in other words, it was not attempting to describe a use of E.164 telephone numbers as if they were persistent identifiers of an Internet resource. Rather, the feature that ENUM wanted to leverage was the ability to put the control of the association of the number to a set of available services into the hands of the number holder. Subscribers ought to be able to control where their related Session Initiation Protocol (SIP) service terminates, for example. At the same time, the E.164 number space is hierarchically managed, so delegations are made (and managed) at higher levels in the telephone number tree than the simple end telephone number.
Generalization
The ENUM use of NAPTR records brought to light that at least one of the URN assumptions had more general applicability; in other words, it could be assumed that identifier and resolution systems for many applications might feature delegation of some authority and/or responsibility for mapping identifiers to resources, with an expectation of multitiered delegation.
With that in mind, the relevant specifications were updated and refined to produce a more generic definition of the dynamic delegation discovery system, or DDDS, that supported URNs:
RFC 3401: Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS)
RFC 3402: Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm
RFC 3403: Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
RFC 3404: Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)
RFC 3405: Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures
RFC 3401 is the umbrella document providing the road map for this comprehensive set of specifications. RFC 3402 provides the definition of the generic principles of the DDDS approach, independent of any application or implementation. RFC 3403 ties this general architectural specification to the already extant specification-the DDDS as implemented in DNS, using NAPTR records. RFC 3404 and RFC 3405 were intended to make clear how other applications could make use of the DDDS approach and NAPTR records. Those last two documents were the completing pieces to bring the URN (and URI) resolution approaches in line.
With these documents in hand, it was now possible for any new application to make use of this sort of dynamic delegation discovery system using the DNS. A number of applications seemed to need it, such as SIP. However, the set of RFCs was evidently daunting; in some cases, applications considered defining (and deploying) entirely new DNS resource records instead. DDDS can appear overpowering in its generalized state.
Powerful is good, but when you’re looking for a good tool to deal with nails, you don’t really want to be directed to the machine shop to carve a well-balanced handle and then forge a solid steel head (no matter how good the instructions are for constructing your own hammer).
It became apparent that a number of potential uses for DDDS/NAPTR were not being realized-in part because of that evident complexity. At the same time, there were some similarities between those potential uses; perhaps they represented a class of DDDS application.
To deal with that and to hopefully provide a more accessible tool for application specifications seeking to provide some (DNS-based) discovery of application services and protocols, a generic, simplified DDDS application was specified. For application services that use it, starting from any unique key mapped into a domain name, the S-NAPTR (“straightforward NAPTR”) DDDS application (RFC 3958: Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service [DDDS]defines how to find a domain’s preferred server for a given application and protocol. This gives domains a flexible and dynamic approach to homing services. It gives application specification writers a complete hammer. S-NAPTR uses only the core features of the NAPTR-based DDDS. It fit many needs but fell short of serving a few more. U-NAPTR (RFC 4848: Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service [DDDS] extends S-NAPTR to allow for returning fully formed URIs at the end of the dynamic delegation process of DNS lookups.
Today’s Reality
According to the IANA registry, there are 40 formal URN namespaces registered today. The namespaces range from identifiers for IETF protocol resources to the Digital Video Broadcasting Project, to 3GPP, to ISBN. Very diverse communities of interest have rallied around the URN concept of a persistent, unique global identifier and established a namespace for their purposes. None of these use the formally established resolution mechanism (DDDS). However, approximately 25 RFCs reference the DDDS/NAPTR RFC for uses from ENUM to SIP.
The ECRIT WG emergency services discovery work (LoST) uses U-NAPTR, and the DIME WG is considering S-NAPTR for its application.
Finally, discussions are under way to review and revise the URN syntax document, currently under way on the reestablished [email protected] mailing list.
So, both URNs as a concept and the underlying technology are alive and well, if not exactly living together in married bliss.
The Big Takeaway?
While not classically successful, the URN work produced output that clearly has had value for high-impact derivative works. The work started with a vision for persistent identifiers, with a dedicated group of IETF workers interested in the problem space, and with a perceived market need for those identifiers. That single driving market never actually appeared. Reviewing the 40 registered formal URN namespaces, one would find it hard to detect a single unifying theme between them that could have led to a single resolution system that would have supported all of them.
So, the building-blocks approach has been the most successful: Successive waves of IETF engineers have picked up on the blocks that fit their own needs and reused them. And so, we continue to build the overall Internet infrastructure not by single unifying services that solve yesterday’s problems today but, rather, by building blocks that support continued, organic evolution.
This article was posted on 26 June 2010 .