Keep assignment unique over time
06Namespace management makes names persistent: an assigned name is not recycled for a different resource, even after it becomes obsolete.
Separate allowed case: where namespace rules permit it, another properly assigned URN can also identify resource A. Name comparison is not a complete test of resource identity.
Source for this drawing: RFC 8141 · Read RFC section 5 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Change locators or records without rebinding a name to a different resource.
- A name in a namespace is never assigned to more than one resource and never reassigned to a different resource, even if deprecated or obsolete.
- The NID is unique across the urn scheme; the NSS is unique within that namespace. Assignment follows an organization’s rules or a defined process or algorithm.
- A single resource MAY have more than one URN, within a namespace if permitted or in different namespaces. Different names therefore do not prove different resources.
The resource cards A and B are hypothetical objects, not private records. Obsolete does not mean available for reuse. The example namespace is used only for this documentation fixture; it is not an issuance service for real collections. Syntax correctness alone does not prove registered or properly assigned status.
Read the RFC section ↗