Summary
- RFC 3151 normalized an XML public-identifier string and transcribed spaces, structural separators and literal reserved characters into a deterministic
urn:publicid:form; correct conversion proved a name transformation, not a valid owner or resource. - Lexical equivalence was deliberately narrow: after normalization, two namespace URNs were equivalent only when lexically identical. Equal names still did not guarantee equal catalog context, retrieved bytes or application behavior.
- Resolution remained plural—catalogs, local path mappings, built-in knowledge and caches could all participate—so the resolver choice, mapping, retrieval, parsing and outcome required receipts beyond the URN itself.
A persistent-looking string met a URI-only world
XML external entities carried two identifiers. The system identifier was a URI by definition. The public identifier was a character string. In inherited SGML practice, a system identifier often named a local or system-specific location, while the public identifier supplied the more portable and persistent name.
That division worked until newer specifications increasingly required external identifiers to be URIs. XSLT and XML Schema belonged to a Web architecture in which a bare public-identifier string did not fit cleanly. RFC 3151 did not discard the installed names or pretend that every local system identifier had become durable. It introduced a formal URN namespace, publicid, so a public identifier could be expressed in URI syntax.
The distinction is easy to lose because a URI-shaped result looks more authoritative than its source. The transformation gave the old string a transportable syntax. The uniqueness and persistence of the result remained those of the underlying public identifier. If the source owner was unregistered or the naming policy weak, the prefix did not repair it.
The RFC was Informational. It explicitly did not specify an Internet standard. Its examples were pedagogical and not guaranteed to be real. Those status sentences are part of the mechanism's boundary: a worked conversion illustrates the algorithm, not an operational namespace entry, deployed catalog or reachable resource.
Normalization intentionally erased one kind of history
Before transcription, XML public identifiers had to be normalized. Every run of space, tab, carriage return or line feed became one ordinary space, and leading and trailing whitespace disappeared. RFC 3151 assumed this work had already happened whenever it discussed encoding.
The rule made comparison reliable, but it was not lossless. Two source captures that differed only by indentation, tabs or line breaks could yield the same normalized string. Once only the URN remained, their original whitespace layouts could not be reconstructed. The normalized name was therefore a new evidence artifact, not merely a prettier display of the source.
Spaces then became +. Because normalization collapsed runs first, adjacent plus signs generated from whitespace could not occur in a conforming output. A plus that genuinely existed in the source took another path: %2B. The difference is small on a page and decisive in an audit. One plus records a normalized space; the other records a literal character.
An implementation receipt should retain the original string, its character encoding, the normalized string, the rule version and the output bytes. A database that stores only the final URN can compare names but cannot explain which source whitespace was discarded or whether normalization preceded encoding.
Delimiters carried structure without validating it
SGML defined Formal Public Identifiers as a structured subset. A common FPI joined an owner identifier, public text class, description, language or designating sequence and optional display version. Double slashes separated many fields; double colons could appear inside structured material. Owners often began with -// or +//.
RFC 3151 preserved that visual structure mechanically. The sequence // became : and :: became ;. It did not require a translator to recognize the full FPI grammar or determine the semantic field boundaries. Identifying a valid FPI was outside the conversion algorithm.
That was a deliberately modest compatibility choice. Software could carry structured-looking names through URI-only interfaces without embedding an SGML authority engine. It also limits what the output proves. A colon in a publicid URN can be evidence that the source contained //; it is not proof that the source was a valid FPI, that its owner was registered or that its fields were meaningful.
Literal characters had to remain distinguishable from separators. A literal colon outside :: became %3A; a literal slash outside // became %2F; a literal semicolon became %3B. Apostrophe, question mark, number sign and percent sign also received percent encodings. The algorithm preserved a reversible distinction between syntax introduced by transcription and characters already present in the normalized name.
The evidence chain therefore includes positions, not merely values. A naive global replacement can consume overlapping pairs in the wrong order or mistake a literal separator for structure. A test should round-trip representative normalized inputs, but even a perfect round trip certifies only the transcription layer.
Exact lexical identity was the whole equivalence rule
RFC 3151 made lexical equivalence unusually plain: after the required source normalization, two URNs in the namespace were equivalent if and only if they were lexically identical. It did not offer case folding, owner aliases, semantic field comparison or same-target inference.
The narrowness prevented convenient guesses from becoming namespace law. An application could not silently decide that two spellings, escape styles or owner strings meant the same name merely because a local catalog mapped them to one file. Catalog policy was a later layer.
Nor did identical names make content identical. The RFC allowed a resource to have more than one public identifier. The reverse problem was also possible: one lexically identical name could meet different catalog stacks, base URIs, filesystems or caches and return different representations. Name equality, mapping equality, byte equality and behavioral equality were four separate tests.
Later URI and URN specifications changed the broader syntax and registration framework. They supply historical context for parsers and registries. They do not retroactively change what a 2001 catalog returned, validate an old owner or turn semantic equivalence into RFC 3151 lexical equivalence.
The namespace inherited its owner's weaknesses
The RFC did not create a central assignment service for every public identifier. Formal Public Identifiers with registered owner identifiers were required to be unique. Informal identifiers and FPIs with unregistered owners might or might not be unique, and the document asserted no enforcement policy.
Persistence followed the same inheritance. A registered owner generally offered a stronger basis than an informal string, but the namespace covered too many uses for one persistence policy. The IDN scheme, which derived a registered owner identifier from a domain name, inherited at least the persistence weaknesses of domain names.
This matters because the word URN can invite a false upgrade narrative. Encoding a weak public identifier does not make its owner durable. Registering an owner does not keep a catalog online. A policy does not prove that the issued name was unique in practice. A persistent name does not preserve every representation ever served beneath it.
A resource without a public identifier first needed one created under the applicable rules; only then could the conversion assign its publicid URN. A resource could also have several public identifiers. The name's provenance therefore needed an issuance record, owner policy and activation time in addition to its characters.
Resolution stayed deliberately plural
RFC 3151 described several ways public identifiers were already resolved. OASIS catalog files could map a public name to another identifier. A system could map components to local pathname components. Software could carry a fixed set of known public identifiers. URI-specific mechanisms such as caches might also participate.
This was not one global resolver hidden behind a common prefix. It was a portable name meeting contextual mechanisms. Catalog order, delegation, rewrite rules, base URIs, local mounts, network access and cache freshness could all decide the outcome.
A catalog match was one receipt: a rule selected a target. Retrieval was another: a file or response returned bytes. Content identity required a digest or equivalent observation. Parsing required the actual parser, entity policy and version. Application success required still another observation. Recording resolved=true compressed a chain of decisions into a conclusion.
The document specified no validation mechanism. Its security section added no considerations beyond ordinary URN use and resolution. Neither sentence authenticated an owner, catalog, cache or target. A deterministic encoder could coexist with a stale mapping, substituted local file, compromised response or vulnerable parser.
The useful design insight is that RFC 3151 resisted over-specification. It provided the smallest shared bridge needed to place established public names in URI fields while leaving existing catalogs and local practices able to continue. That encouraged compatibility, but it made resolver provenance essential.
Running behavior could correct a perfect name
Consider an external entity whose normalized public identifier transcribes perfectly. A parser consults the first catalog in its chain, rewrites the name to a local path and opens a file. Every syntax check can pass while the file belongs to an old package release. The lexical URN is correct; the mapping is valid under local policy; the bytes are wrong for the application.
Or a second machine can use the same URN and a different catalog, returning a newer DTD. The names compare equal while the parser behavior diverges. A cache can preserve an earlier mapping after the owner changes its policy. A built-in resolver can keep succeeding after the network resource disappears. No single one of those observations owns the full truth.
Running-code primacy does not make the specification optional. The transcription table is authoritative for whether the URN correctly carries the normalized name. Running behavior answers the later questions: which resolver ran, which rule matched, which bytes arrived and what the application did. Each layer can correct an overclaim made by the preceding one.
The historical achievement was therefore precise and bounded. An old public name could cross into URI architecture without pretending to be a location. But crossing the syntax boundary did not finish the journey to a resource.
Sources
- RFC 3151 text
- RFC 3151 record
- RFC 3151 HTML
- RFC 3151 document history
- RFC 2141 — URN syntax
- RFC 2396 — URI generic syntax
- RFC 2483 — URI resolution services
- RFC 3406 — URN namespace definition mechanisms
- RFC 3986 — URI generic syntax
- RFC 8141 — URNs
- XML 1.0 Second Edition
- OASIS XML Catalogs 1.0
- IANA Formal URN Namespaces
- Running-Code Primacy
- On Reality Layers
- Minimum Initial Specification
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
