Summary

  • RFC 9720 permits narrowly bounded reissuance of an RFC’s definitive XML and its rendered publication versions, while requiring that semantic content be preserved to the greatest extent possible and prior versions remain available.
  • That policy turns a standards archive into a chain of receipts: the current file is useful only alongside its version date, the earlier file, the stated reason for change and a review that distinguishes altered rendering from altered meaning.

The apparent contradiction

For decades, the comforting story about an RFC was simple: publication freezes it. That story protected implementers from a moving target, but it became too simple when the RFC Series moved from a single ASCII artefact toward RFCXML with HTML, plain-text and PDF renderings. A typo in XML, a changed schema, a better rendering tool or a consistency repair can be real maintenance work. Treating all of it as forbidden preserves defects; treating all of it as harmless converts an archive into an editor with no visible limit.

RFC 9720, published on the Editorial Stream in January 2025 and co-authored by Paul Hoffman and Heather Flanagan, refuses both shortcuts. It obsoletes RFC 7990 and updates the stability policy then found in RFC 9280. The document is informational rather than Standards Track, which matters: it describes an RFC Series publication policy, not a protocol implementation command or a guarantee about every document reader will ever retrieve.

Its useful move is linguistic before it is operational. The old label “canonical format” had been doing two incompatible jobs. It could mean the XML substrate from which files were rendered, and it could mean the authorized, archived document. RFC 9720 splits those roles into a definitive format—RFCXML—and a definitive version—a published RFC in that format. It separately names publication formats, currently HTML, text and PDF, and publication versions in each format.

The names are not editorial polish. They stop a render from impersonating the record and stop the record from escaping maintenance. A PDF layout change is not automatically a protocol revision. Nor does the fact that XML is maintained make it a freehand amendment channel.

What may move, and what may not

The RFC Production Center may reissue a definitive version. RFC 9720 gives bounded reasons: changes to the RFCXML schema, errors discovered in the XML and changes to tooling that generates publication versions. It says semantic content is to be preserved to the greatest extent possible. The qualifier is disciplined, not evasive. The RFC itself acknowledges that even a syntax-oriented change can introduce semantic risk. Its demand is not an impossible claim of zero risk; it is that the risk be understood, limited and made reviewable.

The corresponding limit on a publication version is equally important. Reissue is permitted, not mandatory. The production function must weigh consistency of the Series against the risk that the change alters meaning. It cannot call every aesthetic preference an archive repair, and readers cannot assume that an unchanged RFC number means every retrieved bit is identical to the copy used years ago.

This is minimum initial specification in a narrow but practical form. The shared rule fixes an invariant—do not casually change meaning—and specifies a small maintenance authority. It leaves particular storage systems, locator conventions and future tool choices open to the institution and technical community that will actually operate them. RFC 9720 explicitly does not prescribe how historical documents must be located. That restraint is not a missing feature. It prevents a document-format policy from pretending to own every archival implementation decision.

The archive is the counterweight

Permission without memory would be governance by replacement. RFC 9720 supplies the counterweight: the RPC must keep archived sets of earlier definitive and publication versions using the same access methods as current files, with a date for each creation or reissue. It must also keep a public record of each definitive-version reissue and a short explanation of why it occurred.

Those requirements make the archive part of the protocol of trust. The current HTML page does not settle a historical question by itself. A reader who needs to know whether an example, a reference, a diagram or non-ASCII text changed needs the earlier version, the newer version, a diff and the stated maintenance reason. The version trail makes a contradiction investigable instead of merely rhetorical.

There is a useful separation of powers here. The authoring and approval process gives an RFC its intended semantic content. The production function may maintain the representation within the stated boundary. An implementation team still decides which version it pins, how it validates an update and whether its own deployment changes. None can take over the other’s job merely because it has the newest file.

Heather Flanagan’s public IETF profile records that she served as RFC Series Editor from 2012 to 2019 and now chairs the SPICE working group and HotRFC. Her role in the RFC 9720 record gives the article a person-centred entry point. It does not make her sole author of the policy, the current operator of the RFC Production Center or the source of every future reissue decision.

A current version is not proof of a past dependency

The policy has a hard operational consequence. A current retrieval proves only what was served at the time of retrieval. It does not establish what an implementer read, what a procurement clause incorporated, which parser processed an example or whether a vendor’s documentation followed an older rendering. An RFC number is an important identifier; it is not a complete forensic receipt.

RFC 9920, published in February 2026, later obsoleted RFC 9280 and updates RFC 9720 among a wider set of RFC Series documents. That evolution reinforces rather than dissolves the lesson. Series policy can be updated through its own process. It does not turn every downstream file difference into either a catastrophe or a non-event. The question remains local and testable: which version was relied upon, what changed, and does the change affect the claim at stake?

For an operator, a standards-dependent supplier or a security reviewer, the proof packet should start with the RFC number but not end there. Retain the definitive and publication-version dates; retrieval URLs and checksums; the source-toolchain version where known; the public reissue reason; and a semantic as well as rendering diff. Record the dependent implementation, configuration and contract surface. Assign a reviewer and keep a reversible rollout boundary.

A broken link, changed line wrap or regenerated image may be immaterial. A changed normative keyword, code point, reference target, data model element or example consumed by a tool may not be. No styling change proves semantic safety; no release note proves it either. The evidence is the relationship between the actual difference and the system that relied on the old form.

Why frozen rhetoric fails

“Never change published text” can be a useful instinct when an institution is tempted to revise history. It becomes bad operational doctrine if it requires a public archive to retain correctable XML faults forever, leave accessibility defects unaddressed or make a document’s current display depend on obsolete production tooling. The opposite slogan—“it is only formatting”—is worse because it erases the reader’s right to inspect the boundary.

Flanagan and Hoffman’s policy makes neither slogan authoritative. It permits maintenance but makes maintenance answerable. That is the important inversion. A production body does not get credibility by declaring its change non-semantic. It earns it by retaining the predecessor, stating the reason, exposing the date and allowing others to inspect the difference.

This is consistent with the deeper distinction in Heng Lu’s notes between evidence, decision and mandate. A maintenance record is evidence that a change was made for a stated reason. It does not authorize every consumer to update automatically. The person who carries the operational risk—the implementer, operator or contracting party—must decide whether the particular dependency can move. The archive should make that decision cheaper and more reversible, not replace it.

Sources