Errata, Revisions and the Exit Problem for a Standard

A specification is never finished. It is published, implemented, and then found wrong in particular places, and the process by which those findings become corrections is the part of standardization that implementers encounter most often and understand least. The process differs by body, but the problem is identical everywhere: a document that thousands of products conform to cannot be corrected by editing it in place.

Every correction mechanism is an answer to that constraint.

Four kinds of change and why they are kept separate

Published standards are corrected through at least four distinct channels, and conflating them is the most common source of confusion about what a specification currently says.

Errata are factual corrections that do not change the intended meaning. A wrong cross-reference, a table cell transposed, a field described as 8 bits in the text and 16 in the diagram. Errata are published as separate lists because the original document stays available and citable; a conformance report that cites a revision and an errata list is precise in a way that citing a revision alone is not.

Implementation notes or interpretations answer a question the text left open, without resolving it in the normative text. A note of this kind is advisory and is often the only artefact recording what the committee believed at a given moment.

Amendments and revisions change normative content and require the full process: a draft, a ballot, and a new edition. An amendment changes a bounded part of the document and leaves the rest citable as it stands; a revision replaces the edition wholesale. The choice between them is a documentation decision with a real cost, because an amendment leaves two documents whose combined meaning an implementer must assemble, and a revision leaves the previous edition as the only record of what changed.

Deprecations and withdrawals are the fourth channel, and they are the hardest to do honestly, because they must express a decision about the future without asserting anything false about the present.

Deprecation is not deletion

A deprecated feature stays in the specification. It remains normative in the sense that a conforming implementation must still interoperate with peers that use it, and it is typically annotated to indicate that new implementations should not adopt it and that it may be removed in a future revision.

The annotation is where the specification usually weakens its own guarantees. A feature marked “deprecated” without a statement of when support may be removed leaves a sender with no basis for deciding whether a peer still accepts it. A feature marked with a target removal edition gives a date that implementation schedules can be checked against, and is the more useful form.

From the receiving side, a deprecated feature is an obligation with no deadline. A product that stops accepting a deprecated message is not interoperable with every existing peer, and the specification’s own text supplies no defence for removing the behaviour. The result is a familiar deadlock: the feature is deprecated for a decade and stays mandatory in practice because the first product to drop it takes the blame for the failure.

The asymmetry that resolves it, when it is resolved, is a negotiated one. A protocol that gives the peer a way to declare which revision it implements lets each side opt out of the deprecated feature in an orderly way, at the cost of the negotiation machinery examined in the analysis of interoperability gaps.

Change control that is not a document

Formal bodies track editions with dated revisions and a change log. The Internet standards process does something different and unusual: it keeps a single canonical document per specification and republishes it as a new numbered document, with the new document declaring which documents it obsoletes and updates.

The mechanism has two named relations, and they matter operationally. A document that obsoletes another replaces it entirely: an implementer should read the newer one and treat the older as superseded. A document that updates another modifies part of it: the older document remains in force, with the named sections replaced by the newer text. A specification that has accumulated several updating documents requires the reader to apply them in order, and no single artefact states the resulting text.

This is the practical advantage of the obsoleting relation and the practical hazard of the updating one. An implementer who reads the base document and misses an updating document is reading text that has been superseded in part, without any marker in the base text to indicate it.

The maturity ladder established by RFC 2026 and later reduced by RFC 6410 to two levels is a separate axis, tracking how much confidence the community has in a specification rather than how current its text is. A mature specification can still be obsolete in content. The two statuses are frequently confused in discussions of whether a document is current.

The exit problem

Withdrawal is the hardest operation a body performs, because it is the only one that asserts a negative: that no new implementation should be made and that the specification’s authority is being retired.

The obstacle is that withdrawal does not undeploy anything. Products in the field continue to send the bytes, and peers continue to need to parse them. A withdrawn specification leaves implementers with behaviour they must support and no document to cite for it. The usual compromise is to withdraw the specification for new work while keeping it publicly available as a historic document, which preserves the citation and ends the maintenance.

The genuine failure case is when the authority itself disappears. A consortium that produced a specification, held the registry, and ran the conformance suite can dissolve, and there is often no successor with the legal standing to interpret the text. Implementations then persist with the behaviour frozen at the last published revision, and the only available authority is the accumulated behaviour of the installed base. That outcome is the de facto endpoint described in the comparison of de jure and de facto standards: the document becomes history, and the implementation becomes the document.

A related hazard is the abandoned registry. Where a numbering authority stops answering, assigned values remain allocated and unassigned values remain visible in the last published snapshot, but nothing prevents two parties from requesting the same value from different places. The collision is discovered when products meet.

Consensus decay and the cost of a late correction

A correction to a mature specification has a property that a specification at first publication does not: it must be agreed by parties who now have installed products and therefore positions. Where the original text was vague, each implementer resolved the ambiguity its own way, and the correction must choose among those resolutions. The party whose behaviour loses has a concrete reason to object, and the objection is technical rather than sectional.

The usual outcomes are three. The correction ratifies the behaviour of the largest installed base, which makes the errata list a record of market outcomes rather than of analysis. The correction ratifies the reference implementation, with the same effect reached more directly. Or the body declines to correct, marking the clause as ambiguous and leaving implementers to keep guessing, which is honest and leaves the specification permanently weaker.

The incentive to correct at all weakens with time. A defect found within a year of publication is corrected in a new edition that almost nobody has implemented and nobody has to migrate from. The same defect found after a decade requires implementers to change behaviour in products that already interoperate with each other, on the argument that they do not interoperate with something else. It is common for a body to record such an issue as a known erratum without changing normative text, which preserves the document and abandons the guarantee.

This is the sense in which early adoption has a cost that is not usually counted. The first implementers resolve the ambiguities, and the resolutions they chose are the ones the correction will later have to accept or overturn.

Reading a specification’s history as its current text

The working procedure that follows from all of this is short. For any specification, establish four facts before implementing: the revision in force, the list of errata applied to it, the set of documents that update or obsolete it, and whether any normative reference has been revised independently.

Each of the four is ordinary to check and none is stated in the document itself. The specification’s own front matter records the date of publication, which is the date the text was fixed, not the date its meaning was last adjusted. Reading the history is not an optional scholarly exercise appended to reading the standard; for a mature specification, the history is the standard.