Compare names without decoding them
03Generic URN-equivalence compares assigned names after specific case normalization. It deliberately does not decode percent-encoded characters.
urn:example:a123,z456 is not generically URN-equivalent to urn:example:a123%2Cz456. Similarly, ordinary NSS letter case and slash suffixes remain significant unless namespace rules add equivalence.
Source for this drawing: RFC 8141 · Read RFC section 3.1 ↗
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.
Lowercase the scheme and NID; preserve NSS letters and encoded bytes.
- Compare the assigned-name portions octet by octet after lowercasing urn and the NID, and uppercasing A–F in percent triplets within the NSS.
- Percent-encoded characters MUST NOT be decoded for this comparison. Optional r-, q- and f-components MUST be ignored when determining URN-equivalence.
- Namespace definitions MAY add equivalence rules that remove false negatives, but MUST NOT turn a pair equivalent by the generic procedure into a nonequivalent pair. NSS case and slashes otherwise remain significant.
Equal names do not imply equal full requests, equal fragments, current availability or authorization. The published examples use the example namespace. Generic URI normalization that decodes an unreserved character is not this URN-specific algorithm; visually similar Unicode strings can also remain different.
Read the RFC section ↗