Uniform Resource Names (URNs)
obsoletes
Extracted elements (30)
The r-component has no syntactic counterpart in any other known URI scheme. It was added to support passing parameters to URN resolution services, distinct from q-components which pass parameters to the resource or application. Exact semantics are deliberately left to future standardization to avoid premature lock-in.
The URN syntax deliberately restricts all characters to ASCII (requiring percent-encoding for others) to maintain stability and persistence as protocols evolve. The character set and encoding issues are acknowledged as involving fundamental unresolved trade-offs in the information sciences community, so the specification imposes restrictions rather than comprehensive rules.
URN resolution is intentionally more flexible than URL dereferencing. A URN may resolve to locators, to metadata only, to representations conditionally (based on authorization), or not at all. This flexibility is a deliberate architectural choice to accommodate a wide range of use cases beyond simple document retrieval.
All URN namespaces and URNs that were valid under RFC 2141 and RFC 3406 remain valid under RFC 8141, even though it may be useful to update namespace definitions to take advantage of new features such as r-components, q-components, and the '/' character in the NSS.
Syntactical correctness of a string beginning with 'urn:' is not sufficient to make it a valid URN; the NID must be registered in accordance with the rules in this document and the NSS must conform to the registered namespace's rules. Generic URI processors must treat URNs as opaque unless the scheme is recognized.
A formal URN namespace NID MUST NOT be an already-registered NID, MUST NOT start with 'urn-', MUST be more than two characters long, MUST NOT start with two letters followed by a hyphen (reserved for ISO alpha-2 country codes), and MUST NOT start with 'X-'.
A revised URN namespace registration MUST describe differences from prior versions and SHOULD make special note of any relevant changes in the underlying technologies or URN namespace management processes.
Characters outside the ASCII range in r-components, q-components, and f-components MUST be percent-encoded using the method defined in Section 2.1 of RFC 3986.
Percent-encoded characters MUST NOT be decoded (i.e., percent-encoding normalization as specified in RFC 3986 Section 6.2.2.2 MUST NOT be applied) during the URN-equivalence comparison process.
r-components SHOULD NOT be used for URNs before their semantics have been standardized in a separate specification.
Software that is not aware of namespace-specific canonicalization and encoding rules MUST NOT construct URNs from names in a non-URN identifier system, because names valid in that system may contain characters not permitted in URN syntax.
The 'Interoperability' section of a URN namespace registration template MUST specify any known potential issues related to interoperability, including possible confusion with other URN namespaces, non-URN identifier systems, or URI schemes.
The r-component SHALL NOT be taken into account when determining URN-equivalence, but SHALL be supplied along with the URN when presenting a request to a URN resolution service.
The 'Resolution' section of a URN namespace registration template MUST specify whether resolution mechanisms are intended or anticipated for URNs within that namespace.
Two URNs are URN-equivalent if their assigned-name portions are octet-by-octet equal after: (1) converting the scheme 'urn' to lower case, (2) converting the NID to lower case, and (3) converting hex digits A-F in percent-encoded sequences within the NSS to upper case. The r-component, q-component, and f-component MUST be ignored for URN-equivalence.
URN namespaces and resolution systems MUST NOT require that q-component information be passed to them for processing; namespace design SHOULD avoid any need for a resolution service to consider the q-component.
URN namespaces SHOULD NOT allow characters outside the ASCII range unless the nature of the particular URN namespace makes such characters necessary, in order to keep URNs stable and persistent as protocols evolve.
URNs that appear in protocols or are passed between systems MUST use only Unicode characters encoded in UTF-8 and further percent-encoded as required by RFC 3986.
When URNs are transported and exchanged, they MUST be represented in the canonical format defined in RFC 8141. Applications SHOULD display the complete URI (including the 'urn' scheme and all components) to avoid confusion between URN NIDs and URI scheme identifiers.
A URN is composed of an assigned-name (scheme + NID + NSS) plus optional r-component, q-component, and f-component. The ABNF is: namestring = assigned-name [ rq-components ] [ "#" f-component ]; assigned-name = "urn" ":" NID ":" NSS; NID = (alphanum) 0*30(ldh) (alphanum); NSS = pchar *(pchar / "/").
Informal URN namespaces are assigned a NID by IANA consisting of the string 'urn-' followed by the next available positive integer (e.g., 'urn-7'). The NID syntax is: InformalNamespaceName = 'urn-' Number, where Number is a non-zero-leading decimal integer.
The f-component is an optional URN component introduced by '#' with the same syntax as the URI fragment component. It identifies a location within or region of the named resource, and its semantics are defined by the media type of the resolved representation.
The Namespace Identifier (NID) is the label identifying a URN namespace. NIDs are case insensitive ("ISBN" and "isbn" are equivalent), restricted to ASCII, and 2–32 characters long following the ABNF: NID = (alphanum) 0*30(ldh) (alphanum), where ldh = alphanum / "-".
The Namespace Specific String (NSS) is the portion of a URN that is unique within a given URN namespace and conforms to that namespace's definition. The NSS now permits '/', '~', and '&' characters that were disallowed by RFC 2141, enabling encapsulation of hierarchical names from non-URN identifier systems.
The q-component is an optional URN component introduced by '?=' used to pass parameters to the named resource or a system supplying a service. It has the same syntax as the URI query component. For URNs resolving to locator URIs, resolvers copy the q-component to the URI's query component.
The r-component is an optional URN component introduced by '?+' and used to pass parameters to URN resolution services. It ends at a '?=' sequence (q-component), a '#' (f-component), or end of URN. Its exact semantics are reserved for future standardization.
IANA maintains the URN Namespace Registry, assigning formal NIDs (chosen by applicants) and informal NIDs (assigned as 'urn-N' sequences) following the Expert Review process described in Section 6. This document updates and supersedes the procedures in RFC 3406.
RFC 8141 updates the registration of the 'urn' URI scheme in the IANA Permanent URI Registry. The scheme is described as identifying persistent, location-independent resource identifiers, with syntax and encoding defined in Section 2 of this document.
URN-equivalence comparison rules have security implications: producing false negatives (treating equivalent URNs as different) or false positives (treating different URNs as equivalent) can create exploitable ambiguity. Namespace definitions must specify equivalence rules carefully and MUST NOT introduce additional false negatives relative to the base procedure.
URN namespace definitions must account for potential spoofing: declarations ought to be taken as advisory since there is always a danger of providing misinformation. Namespace registrations should also address privacy risks such as leakage of private information when names are communicated on the public Internet and the potential for directory harvesting.