Summary

  • RFC 3553 created urn:ietf:params for persistent names of registered protocol parameters, but it expressly defined neither a resolver nor a validator. Registration identifies; it does not prove discovery, implementation support or execution.
  • Its most durable rule was negative: a name must not contain a value whose meaning changes. The stable identifier may name the slot or concept that holds the changing value, while the repository location may move independently.

Imagine that an XML schema needs to refer to an IETF protocol parameter. In 2003, its author could paste the URL of the file that happened to contain the registry. That looked concrete. It also made the identity depend on a web server, directory layout and filename that an operator might later need to change. The alternative was to invent a URI. That avoided one dependency by creating another problem: different authors could invent different strings for the same registered object.

RFC 3553 addressed that small but consequential gap. Published in June 2003 as BCP 73, it created the params branch beneath the ietf URN namespace established by RFC 2648. The goal was not to turn IANA's registry website into a universal name service. It was to give standards a common, persistent way to identify registered protocol items while allowing the machinery that stores and displays their records to change.

The sharpest rule appears under persistence. Once allocated, a name must not be reassigned to a different purpose. More subtly, a sub-namespace must be designed so an assigned value's meaning cannot change. If foo is a parameter whose current contents vary, the URN may identify the stable slot that contains foo; it must not encode today's contents as though they were permanent. A version number can appear when the version itself is persistent and unique. A mutable setting cannot borrow permanence from the identifier syntax.

This was a separation of identity from state. The name answers, “Which registered concept is this?” A current registry row can answer, “What does the authoritative record say now?” A resolver might answer, “Where can I retrieve a representation?” An implementation can answer, “Do I recognize it?” Only observed execution can answer, “What did the system do?” RFC 3553 deliberately stopped at the first of these and the rules needed to keep it stable.

The document says the namespace is primarily opaque. Colons provide a limited hierarchy, but punctuation is not a universal semantic tree. urn:ietf:params:xml:... is meaningful because RFC 3688 and the XML registry define the branch, not because a generic parser can infer governance from each colon. The same is true of the later oauth branch registered by RFC 6755. A parser can split a string and still know nothing about the assignment's protocol meaning.

RFC 3553 also says that no resolution mechanism and no validation mechanism were defined. That omission is part of the architecture, not a defect to be silently filled by assumptions. Global scope does not mean every machine can dereference the name. Registry presence does not certify that a product implements it. Exact lexical equality can establish that two strings are the same identifier under the governing rules; it cannot prove that two programs apply the same semantics.

The registration template reinforced the boundary. It required the registry name, defining specification, authoritative repository and the index value used in the URN. But the repository was described as the current location, a hint that could change as files and servers moved. The persistent name was not a disguised filename. Continuity depended on preserving the assignment and meaning, not on freezing an operational host.

The current record shows the design's long tail. The IANA snapshot frozen for this Article was updated on 2 February 2026. It lists seven second-level ietf branches and 23 registered identifiers below params, including xml, oauth, netconf, scim, acme, jmap, whip and unit. That is evidence that the registry remains active. It is not an adoption survey. Twenty-three rows do not disclose how many implementations recognize them, how securely they do so or whether any particular exchange succeeded.

RFC 6924 later made the hierarchy easier to inspect by creating a registry of all second-level ietf URN branches and by using the newer “IETF Review” policy label. RFC 8141 later replaced RFC 2141 as the general URN syntax. These changes matter, but neither collapses the distinctions that made RFC 3553 useful. An identifier can survive a syntax document's succession and a repository's reorganization because it is not the current file, server or value.

The institutional lesson is narrow. IANA's legitimate role here is to prevent collision, preserve the assignment and expose the record. That custodial function is essential, but it does not make the registry the owner of every implementation that cites a name. Running code remains the place where recognition and behavior become facts. The registry supplies a stable coordinate from which those facts can be examined.

An operator auditing a protocol therefore needs separate receipts: the exact identifier received; the IANA branch and cited specification; the version of the registry record consulted; the implementation and release that recognized it; the policy applied; and the observable result. If only the URN is retained, the audit has identity without execution. If only a moving repository URL is retained, the audit has a location without durable identity.

RFC 3553's achievement was restraint. It made names persistent by refusing to let them claim the changing value, the current repository or the eventual outcome. The name survived because it was allowed to mean one stable thing—and nothing more.

Sources