URN Syntax

Percent-encoding must not be decoded during lexical equivalence testing because `%`-encoded and literal characters may have different meanings within a given namespace (a namespace may assign special meaning to a literal character while using its percent-encoded form as a literal).

The characters `/`, `?`, and `#` are reserved rather than forbidden because RFC 1630 assigns them particular purposes in URIs; since the URN WG had not yet defined their semantics within URNs, they are held in reserve for future specification rather than being permitted or prohibited outright.

The leading `urn:` token is case-insensitive and the NID is case-insensitive to accommodate legacy naming systems and reduce transcription errors, while still requiring a single canonical form for transport to ensure interoperability.

The NID syntax excludes `.` and `+` characters (unlike the URL scheme syntax in RFC 1630) to avoid ambiguity with potential resolution schemes and to keep the namespace identifier space clean.

A URL resolver conforming to the URL syntax specification will extract `urn:` as the scheme value rather than `urn:<nid>`, so URN resolution requires either a built-in URN resolver or an external one that the URL resolver can delegate to.

A `%` character in a URN MUST be followed by exactly two hexadecimal characters. Literal `%` characters in a namespace MUST be encoded as `%25`.

A character MUST NOT be percent-encoded if it is not a reserved character. Namespace registrations must publish which characters have special meaning and require encoding.

A URL browser SHOULD display the complete URN including the `urn:` tag to avoid confusion between URN namespace identifiers and URL scheme identifiers.

A URL resolver MUST treat a URN as an opaque URL and pass it (with the `urn:` tag) to a URN resolver for resolution rather than attempting to resolve it directly.

Additional lexical equivalences defined by a namespace MUST be documented as part of namespace registration, MUST only eliminate false negatives from the standard procedure, and MUST NEVER declare two URNs inequivalent when the standard procedure declares them equivalent.

registry

All URN transport and interchange MUST take place in canonical format. All URN-aware applications MUST offer the option of displaying URNs in canonical form to allow direct transcription.

Any proposed URN namespace that contains characters outside the URN character set MUST translate those names into canonical NSS form as specified in section 2.2.

Identifiers containing characters outside the URN character set MUST be translated into canonical NSS form by UTF-8-encoding each such character and then percent-encoding each resulting octet before use as protocol elements.

Namespace developers SHOULD NOT use the reserved characters `/`, `?`, and `#` in unencoded form in URNs, as their semantics within URN context have not yet been defined.

The NID value `urn` is reserved and MUST NOT be used as a namespace identifier, to avoid confusion with the `urn:` scheme prefix.

Two URNs are lexically equivalent after: (1) normalizing the case of `urn:`, (2) normalizing the case of the NID, and (3) normalizing the case of any `%`-escape sequences. Percent-escaping MUST NOT be removed during normalization.

Functional equivalence of URNs is determined within each namespace and managed by that namespace's resolvers; it is explicitly out of scope for this document. Namespace registrations must include guidance on determining functional equivalence.

registry

Lexical equivalence is the primary mechanism for comparing URNs without resolution: it normalizes `urn:` prefix case, NID case, and percent-escape case, but does not decode percent-encoded characters. For example, `URN:FOO:a123%2c456` and `urn:foo:a123%2C456` are lexically equivalent, but `urn:foo:a123,456` and `urn:foo:a123%2C456` are not.

This document defines only the syntax of URNs and assigns no security properties. Namespace resolvers may assign special meanings to NSS characters, and any resulting security considerations are the responsibility of the namespace registration process, not this specification.

security

All URNs follow the structure `urn:<NID>:<NSS>`, where the leading `urn:` token is case-insensitive, `<NID>` is the Namespace Identifier, and `<NSS>` is the Namespace Specific String.

dns, registry

Excluded characters (octets 1–32, `\`, `"`, `&`, `<`, `>`, `[`, `]`, `^`, `` ` ``, `{`, `|`, `}`, `~`, octets 127–255, and null) are explicitly outside the URN character set and MUST be percent-encoded if used. Octet 0 must NEVER appear in any form.

The Namespace Identifier (NID) must match `<let-num> [ 1,31<let-num-hyp> ]`, allowing letters, digits, and hyphens (but not as the first character). The NID is case-insensitive and limited to 32 characters total.

The Namespace Specific String (NSS) consists of one or more URN chars, where each URN char is either a member of the allowed character set (`<trans>`) or a percent-encoded octet (`%<hex><hex>`). Characters outside the URN character set MUST be encoded as UTF-8 and then percent-encoded.

The reserved character set is `{ %, /, ?, # }`. These characters may not appear literally in an NSS without percent-encoding. The `%` introduces escape sequences; `/`, `?`, and `#` are reserved for future use.