Summary

  • An RFC Obsoletes relationship is authoritative about document lineage: the newer RFC becomes the general starting point for current specification or practice, while the older RFC remains in the permanent archive.
  • The relationship does not patch software, disable a feature, withdraw a product, terminate a negotiated protocol, or create a legal ban. Each of those effects belongs to a different actor and requires separate evidence.
  • HTTP/2 and TLS show why the distinction matters. A protocol identity can persist while its defining text changes, and a formally deprecated version can remain in service long enough to create a real choice between interoperability failure and security risk.
  • Operators should answer documentary obsolescence with a migration receipt: specification lineage, loaded-version proof, dependency mapping, tests, exception ownership, rollback conditions and telemetry showing what actually stopped running.

The line that moved no packets

The most revealing sentence on the first page of RFC 9113 is not a protocol instruction. It says the document “obsoletes” RFC 7540 and RFC 8740. That is consequential: the current account of HTTP/2 begins with the newer text, selected IANA references move, and a standards reviewer should cite the new record.

At publication, however, nothing necessarily changed in a rack. The Application-Layer Protocol Negotiation identifier remained h2. A shipped browser did not acquire new validation rules, and a server did not remove an older path because a document header changed. The standards record moved; the running fleet awaited maintainers and operators.

That boundary protects the credibility of standards. The IETF should state current requirements, the RFC Editor should preserve accurate lineage, and IANA should point to the right authority. None of those functions is improved when a policy register is allowed to testify for loaded code. A changed RFC number can identify the work; it cannot prove that the work reached the wire.

What Obsoletes actually governs

The RFC Editor’s explanation is precise. Published RFC text does not change. Revision produces a new RFC, and Obsoletes says that the newer document replaces the listed one as the general source for the current specification or practice. The older RFC remains in the permanent archive.

That permanence protects technical memory. An engineer can reconstruct what a component written in 2016 was expected to do; an incident reviewer can distinguish a rule inherited from RFC 7540 from one introduced in RFC 9113. RFC 7322 accordingly places Updates and Obsoletes in the header and recognises that an obsoleted RFC may still need to be cited beside its successor.

The relationship is neither weak nor decorative. Ignoring it can leave a reviewer applying rules that the standards process replaced. Yet its direct claim remains bounded: use the newer record to understand current specification or practice. It does not say that every old implementation is patched, every discouraged feature is disabled, every contract has changed or every operator has accepted the transition risk. Those propositions need their own evidence.

Six acts hidden inside one word

“Obsolete” compresses at least six acts. Document replacement identifies the current general reference. A status or applicability decision can move a specification to Historic or narrow acceptable use. Feature deprecation can retain a protocol while discouraging one mechanism. An implementation change turns the rule into source and release artifacts. A deployment decision loads or configures the change in identified systems. An external constraint may impose a deadline through contract, regulation or legal order.

These acts influence one another without becoming interchangeable. A new RFC may prompt a patch; a Best Current Practice may influence an insurer; end of support may force an operator’s timetable. But a merged patch is not loaded-state evidence, and a technical rationale is not automatically a legal mandate.

The distinction cuts both ways. An operator cannot dismiss a current requirement as “only a document” while claiming conformance to the newer specification. Standards establish real coordination commitments. They simply stop short of possessing the credentials, maintenance window and dependency map needed to alter a particular system.

HTTP/2: a new current document, the same h2

RFC 9113 changes both less and more than the word suggests. It becomes the current HTTP/2 specification, absorbs the TLS 1.3 treatment from RFC 8740, tightens validation, changes treatment of plaintext upgrade, revises priority signalling and clarifies Host and :authority. Appendix B records substantive differences.

It also preserves continuity. The h2 ALPN identifier still identifies HTTP/2, and the frame-type, settings and error-code registries continue. IANA updates references instead of inventing a second protocol identity. A peer negotiates an on-wire capability, not an RFC number.

Some earlier mechanisms receive narrower treatment. The HTTP2-Settings header field and h2c upgrade token are marked obsolete. The former priority scheme is deprecated, while RFC 9113 preserves enough reference to RFC 7540 to explain behaviour that can still appear. The archive supplies memory; the current RFC supplies direction.

A compliance entry saying “RFC 7540 obsolete; RFC 9113 adopted” therefore proves little about a fleet. The useful questions concern the reverse proxy, library, appliance firmware and compatibility branch. Which behaviour is loaded, and which telemetry would reveal it? The document number frames that inquiry but cannot answer it.

TLS: obsolescence, deprecation and coexistence

TLS makes the boundary harder to ignore. RFC 8446 specifies TLS 1.3 and obsoletes the TLS 1.2 specification, yet devotes an appendix to older clients, servers, middleboxes and mixed deployments. It was written for a world in which the new version would arrive gradually.

RFC 8996 takes a stronger step for TLS 1.0 and TLS 1.1: it formally deprecates them, moves their specifications to Historic and says implementations must not negotiate them. Its operational considerations nevertheless recognise that disabling them can break systems unable to use TLS 1.2 or higher. Preserving connectivity carries security risk; removing it can create interoperability failure.

That trade-off is not permission to retain TLS 1.0 indefinitely. It assigns the remaining work. The IETF can define unacceptable current practice; a system owner must find the dependency, isolate or replace it, accept any outage and prove that the old version is no longer available.

Scope also matters. RFC 9325 gives current guidance for TLS 1.2 and TLS 1.3 while prohibiting fallback to deprecated versions. RFC 9852 requires TLS 1.3 for new protocols using TLS. A reviewer who reads only “RFC 8446 obsoletes RFC 5246” misses the difference between an existing deployment, a deprecated version and the design floor for a new protocol.

Normative language is a condition, not a daemon

Capitalised requirements are real conditions of conformance. If an RFC says an implementation MUST NOT negotiate a version, maintainers should embody that rule in code, vendors should deliver it, and auditors should test it. But the words are not a background process with root access. Operators still load the artifact, change configuration and accept the failure mode.

This is the difference between normative and execution authority. Collapsing them weakens accountability. “The RFC required it” does not identify who chose the deadline, tested failover or approved an exception; “the RFC obsoleted it” does not identify which vendor withheld an update or which operator retained compatibility. The standard defines compatible behaviour. The operating record shows who made it real.

The installed base is evidence, not a veto

RFC 2026 recognises that a previous and a newer version may sometimes remain Internet Standards to honour an installed base, provided their relationship is explicit. Interoperability belongs to systems in relation, not to a document shelf.

The installed base is not a perpetual veto. Compatibility paths accumulate attack surface and testing cost, while an unmeasured dependency is easily labelled “critical”. The burden should shift: removal advocates first show that the replacement works; once risk evidence and migration experience accumulate, exception owners show why continued support is necessary, how it is isolated and when it expires.

Telemetry supplies the evidence. Inventory shows where an old capability may exist; negotiation data shows where it is exercised; dependency tests show what breaks; loaded-version proof shows whether a repair reached the traffic-handling process. The RFC header can make collecting these facts urgent, but it cannot supply them.

A migration receipt for documentary obsolescence

An operator needs a receipt strong enough to distinguish migration from a changed spreadsheet.

Record lineage: the new RFC, relevant updates or BCPs and the exact behaviour in scope. Record loaded state: the build or firmware handling traffic and the configuration that activates the rule. Record dependency evidence: clients, servers, middleboxes and counterparties using the older path, plus the observation window and blind spots.

Then record risk and authority: why removal is required, who owns the decision and whether the deadline comes from the operator, a customer, a vendor or a regulator. Add test and rollback: expected failure, staged rollout, abort condition and the authority required to re-enable a risky path. Add exception custody: named system, owner, compensating control, expiry and re-review trigger.

Finally, record removal evidence. Show that the capability stopped being negotiated or invoked, that alerts were not merely suppressed, and that the successor path carries the intended service. This receipt does not make the transition painless. It makes residual risk visible and completion testable.

Two ways to lie with the catalogue

The first lie is automatic completion: a new RFC exists, so exposure disappears from a register before behaviour disappears from the wire. Procurement asks for a document number instead of a tested capability. The second is permanent optionality: because publication cannot update a machine, every migration is treated as voluntary forever and compatibility is invoked without measuring who needs it.

The correct position is neither. The RFC relationship is authoritative evidence about the documentary baseline. The running system is authoritative evidence about deployed state. Accountable governance joins them through a decision and migration record; it never substitutes one for the other.

The test for honest obsolescence

When a dashboard says an RFC has been obsoleted, ask four questions. What changed in the current specification? Which old behaviour remains possible? Who controls the systems that must change? What evidence proves the change reached the wire?

Missing the first answer ignores the standards record. Missing the other three turns that record into theatre. The RFC Editor preserves the archive; the IETF states current requirements; IANA maintains references; maintainers ship code; operators decide and verify deployments; external authorities identify their own mandate. This is a chain of custody.

Obsoletes tells us where the current documentary chain begins. It becomes dangerous only when someone pretends the chain ends there.

Sources