Summary
- RFC 3406 made a URN namespace a managed assignment regime: a registrant had to explain syntax, uniqueness, persistence, assignment authority, equivalence, validation and any resolution process. Registering the namespace did not promise a live resolver.
- RFC 8141 later modernized the framework but preserved its institutional core. A durable name depends on non-reassignment, a common definition and a continuity path; a resolver answer is a dated service result, not proof of identity or permanence.
A name is not the place where it points
Suppose a library catalogue contains a name for a book that was printed thirty years ago. The library moves its website, replaces its search software and changes the address of the digital copy. If the name was designed to endure, none of those moves should require the book to become a different thing. The name and the route to a current representation have different jobs.
That separation sits at the centre of the Uniform Resource Name project. RFC 1737, published in 1994, set persistence and location independence among the functional requirements. It also drew an institutional boundary: naming authorities issue names, while resolvers or location services help translate them into locations. There could be one resolver, many, an authoritative service, a third-party service or different services optimized for different uses.
The distinction became more consequential as the design moved from aspiration to registration. A string beginning with urn: might look right and still be invalid. Someone had to define which namespace identifier governed the rest of the string, who could assign names inside that space, how collisions were prevented and what would happen when the original organization changed or disappeared.
Leslie Daigle helped turn that institutional problem into an Internet procedure. The IETF Datatracker lists her as an author of RFC 2611 and RFC 3406. The latter, published in October 2002 as BCP 66, was a collective work by Daigle, Dirk-Willem van Gulik, Renato Iannella and Patrik Faltstrom. The attribution matters: Daigle’s role is part of a shared standards result, not evidence that she invented every URN concept or controls any registered namespace today.
Two managed spaces, not one clever string
RFC 3406 begins with two premises. Assigning a URN is managed, and the space of URN namespaces is managed. Those statements remove a seductive shortcut. Syntax alone cannot confer legitimacy. A valid name must be formed and assigned according to a recognized namespace’s rules; the namespace itself must have a recognized definition and identifier.
The namespace identifier, or NID, is more than a prefix. ISBNs, serial identifiers and other systems can all contain the same-looking run of digits. Putting them under different NIDs prevents one local identifier from accidentally becoming the same global name for two different resources. The NID tells a parser and a human which assignment regime owns the rest of the string.
But global separation is only the first promise. Inside a namespace, the name must be assigned to no more than one resource and must not later be reassigned. A resource may acquire several names for different purposes; the reverse move—recycling one name for a new resource—breaks the historical chain. Once past documents, databases and legal records have used the old meaning, no resolver can reconstruct which meaning a reader was supposed to recover.
This is why persistence is not merely long uptime. A resolver can be perfectly available while serving a freshly recycled name. Conversely, a name can remain valid during a resolver outage because the assignment record and namespace definition still bind it to the same resource. Availability changes what can be reached now. Non-reassignment preserves what the name means across time.
RFC 3406 made the steward show its work
The registration template in RFC 3406 exposed the operating institution behind the identifier. It asked for the registering organization and designated contact, the identifier’s structural syntax, relevant documentation, uniqueness and persistence considerations, the assignment process, any resolution process, rules for lexical equivalence, validation mechanisms, scope and security implications.
Each field answers a different audit question. Syntax says which strings fit. Assignment says who is allowed to issue one. Uniqueness says how two authorities avoid allocating the same name. Lexical equivalence says when different spellings or encodings should compare as the same identifier. Validation says whether conformance can be checked mechanically, against a ledger, through an online service or not at all. None of those answers can be inferred safely from a successful click.
Formal namespaces carried a heavier burden. A proposer had to explain why an existing namespace was insufficient, how the intended community and a general Internet user would benefit, and what action IANA should take. The maintaining organization was expected to show stability and competence, commit not to reassign old names and explain how the namespace could remain useful if the organization could no longer support it.
The standard was candid about the limit of review. Institutional longevity is difficult to predict objectively. Technical review could identify designs likely to undermine persistence, but it could not guarantee that a company, society or public body would exist forever. Registration therefore created a visible commitment and an accountable record. It did not turn IANA into the operator of every namespace or the insurer of every registrant.
Resolution is valuable—and subordinate
RFC 3406 treated global resolution as a separate registration step. A namespace that wanted such service could join a resolution-discovery system and state who could operate recognized resolvers. The template also allowed a namespace to say it was not listed and that resolution was not relevant.
That flexibility is not a defect. Some URNs identify resources whose useful representation changes by country, licence, format or time. One service might return a current URL, another metadata, another a local copy, and another a statement that the resource is no longer available. A single permanent target would freeze a location into a name designed precisely not to depend on location.
The hierarchy of evidence follows. A resolver response can show that a particular service, at a particular moment and under a particular policy, returned a result for a name. It cannot show that the name was authorized originally. It cannot prove that another resolver agrees. It cannot make a stale target true, and it cannot promise that the same answer will exist tomorrow.
The most dangerous resolver is not always the unavailable one. A clean failure exposes a service problem. A resolver that confidently maps an old URN to a new, unrelated resource destroys the very historical distinction the name was meant to preserve. RFC 3406 therefore separated the absence of continued resolution from false or stale resolution: an old name might cease to resolve, but it must not be recycled or made to lie.
The successor changed procedure, not the duty
RFC 8141 replaced RFC 3406 in 2017 and combined modern URN syntax with namespace registration. It credits Daigle and her co-authors for the namespace foundation. The new document changes several procedures, including use of Expert Review for community registrations, but carries forward the core model: names are unique, consistently assigned and governed by a common definition.
Its organizational test is unusually practical. A formal namespace’s assigning body should be stable enough to maintain the namespace for a long time, or the proposal should explain how continuity survives that body. It should be competent at assignment and committed to keeping old names valid even when the assignee or named resource disappears. The rule protects the reference, not a commercial relationship.
RFC 8141 also describes the stable namespace specification as a contract with the intended community. Applicants complete a template, expose it to discussion and designated-expert review, revise it when needed and obtain an IANA registration after approval. Updates must identify changes, especially changes in technology or management processes. That produces versioned institutional evidence instead of treating a registry row as a timeless blessing.
Resolution remains explicit but conditional. The template must say whether resolution is intended or anticipated. If it is, the namespace should describe the operating or recommended services and the requirements for public advertisement. The requirement is disclosure of intent and control—not universal, eternal reachability.
The current IANA register shows why this distinction scales. Its formal namespace list includes publishing identifiers such as ISBN and DOI as well as protocol, scientific and industry namespaces. They share a registration framework, not a common resolver architecture. In the captured registry snapshot there were 97 formal and 8 informal records; those totals are a dated observation, while each registration’s reference and template are the durable evidence to inspect.
Four receipts for one apparent lookup
An operator evaluating a URN should resist one green check mark. The evidence is better recorded as four receipts.
The namespace receipt identifies the registered NID, the current template and the specification version. The assignment receipt shows that an authorized party issued this identifier under the declared rules and did not reassign it. The resolution receipt names the resolver, time, policy and exact answer. The resource receipt records whether the returned target was fetched or validated and whether it represents the intended resource.
A string can pass syntax and fail assignment. An authorized URN can outlive every current resolver. A legitimate resolver can return a target that is temporarily unavailable. A target can load successfully and still be the wrong resource. Separating the receipts keeps operational convenience from becoming an unsupported claim about identity.
Daigle’s namespace work is therefore less a story about a prefix than about jurisdiction. Who may name, what they must never do, which records survive them, and how outsiders can distinguish identity from discovery: those questions determine whether “persistent” remains meaningful after the first system that made the name clickable has gone away.
Sources
- IETF Datatracker profile for Leslie Daigle
- IANA Uniform Resource Names registry
- Official IETF portrait reference
- Internet Society profile for Leslie Daigle
- RFC 1737: Functional Requirements for Uniform Resource Names
- RFC 2611: URN Namespace Definition Mechanisms
- RFC 3406: revised URN namespace mechanisms
- RFC 8141: Uniform Resource Names
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
