Nothing Is Ever Fixed, Only Replaced

An RFC is never edited. When someone finds an error the error stays where it is, and a note is filed in a separate database that the document itself never learns about. Errata are not incorporated into the TXT, the PDF or the XML, so the only correction that reaches the normative document is a new one replacing it, and this asks whether the replacement carries the fix. Across 1,039 cases where a replacement exists, mostly it does: 832 rewrote the passage outright and 129 carry the correction word for word. In 62 the exact text somebody reported as wrong is still there, and every one of those is printed here to read and to check against the source. Then the part that was expected and did not survive: technical errors looked twice as likely to be carried forward as typos, until two documents came out of the sample and the difference went to nothing. Four of seven pre-registered predictions broke, including that one and including the replication. What holds is smaller and stranger. When an error does survive into the replacement, the erratum recording it almost never follows, so in 50 cases the mistake is in a specification that is current today and is absent from that specification's own list of known mistakes.

The rule that makes the rest of this possible

The documents that specify the internet are called RFCs, and there are 9,835 of them. They have one property that surprises people who assume a specification is a living document: an RFC is never edited. Not for a typo, not for an error that breaks implementations. The publisher says so in its own words.

Because RFCs do not change after publication, there is an errata system to note these errors. RFC Editor, “Errata in RFCs”

So when someone finds a mistake they file an erratum: a note recording what the document says and what it should have said. The note lives in a separate database. It does not reach the document, and the publisher is equally direct about that:

Errata are not incorporated into the TXT, PDF, or XML formats of RFCs. RFC Editor, “Errata in RFCs”

Note which formats that sentence names. The TXT, the PDF and the XML are the specification as anybody cites it, and none of them carries a correction. There is one channel through which a fix can reach the normative document a reader downloads: somebody writes a new RFC that obsoletes the old one. Nothing is fixed. Things are replaced.

That makes the errata database an unusual object, a public and dated ledger of known defects in documents that cannot be repaired. This page counts how much of that acknowledged defect is sitting in the specifications that are current right now, and then asks the question the ledger has never been asked: when a replacement document was eventually written, did the correction get in?

The standing ledger

Of the 8,035 errata in the database, 4,864 have been accepted (either marked Verified, meaning reviewed and confirmed, or Held for Document Update, meaning agreed but deferred) and sit against an RFC that has not been obsoleted and is not marked Historic. That is to say: against a document that is still the specification. They break down by the status of the document they are attached to like this.

The row worth pausing on is Internet Standard. That is the top of the IETF maturity ladder, the grade a specification reaches only after it has been shown to work and to interoperate, and there are 125 of them in force. 63 of those 125 carry 283 accepted errata between them. This is not by itself evidence that the most-proven documents are the worst written, and the page does not claim it is. The likelier reading is the one McQuistin and colleagues gave in 2023: standards-track documents attract more readers, and more readers find more errors. Attention and defect are not separable here and nothing below pretends otherwise.

A smaller number, harder to explain away: 736 errata are still marked Reported, meaning nobody has yet decided whether they are right. The median one has been waiting 1,417 days. 68 have been waiting more than ten years, and the oldest has been waiting 6,068 days, which is since 2010-01.

The promise in the status name

One of the four statuses is a promise about the future, and it is worth quoting exactly, because everything after this tests it:

Held for Document Update. The erratum is not a necessary update to the RFC. However, it should be considered in future revisions of the RFC. RFC Editor, the official status definitions

“It should be considered in future revisions.” That status is carried by 2,414 errata, and it is the only one of the four that makes a commitment about what happens next. It is also a commitment that can be checked, and one team has already checked half of it. McQuistin, Karan, Khare, Perkins, Purver, Healey, Castro and Tyson, in “Errare humanum est: What do RFC Errata say about Internet Standards?” (TMA 2023), performed the first study of this database, over 6,759 errata filed between 2001 and 2022. In it they write:

Of the 930 RFCs that have hold for document update errata filed against them, only 40% have been updated or obsoleted by a subsequent RFC. We flag that this may be a cause for concern, or at least a missed opportunity for improvements to standards. McQuistin et al., TMA 2023, §III

That measures whether a future revision happened. It does not open the revision and look inside. So the obvious next question was left sitting there, and as far as I can find nobody has asked it: in the cases where the replacement document was written, did it carry the correction, or did it carry the error?

How you can tell, and how you can tell you are being told the truth

An erratum quotes the passage it says is wrong. That quotation is a string. The replacement document is a string. So the test is a substring search, run after squashing the pagination that RFC text files carry, and the whole method fits in a sentence: take the exact words somebody reported as wrong, and look for them in the document that replaced the one they were reported against.

The reason to trust a substring search is that you can break it on purpose and watch it break. Four of the five controls, all fixed in the pre-registration before any matching code was written. The fifth is a replication of the prior study and has its own section below, because it broke.

What the replacements did, and the first prediction to break

Restrict to accepted errata whose quoted text can be found in the document it was filed against, so the instrument is known to reach it, and where that document has since been obsoleted by a replacement whose text is available. That is 1,039 erratum-and-replacement pairs. For each one, look in the replacement for the reported-wrong text and for the corrected text:

I predicted, in writing and before looking, that the carried share would land between 10% and 40%. It is 5.97%. That prediction is broken, and it is broken in the direction that says the system mostly works. Four fifths of these passages were rewritten outright, and where the passage is still recognisable the correction is there about twice as often as the error. If you came here expecting a story about a standards process that ignores its own bug reports, the aggregate does not support it, and this paragraph is where the page says so instead of burying it.

Only one of those four numbers is a strong claim. Finding the exact reported-wrong string in the replacement is evidence that the replacement repeats the error. Not finding it is consistent with a fix, a rewrite, a rewording, or the passage simply being cut, and this method cannot tell those apart. So “corrected” is a floor rather than a count, “rewritten” is not a result at all, and everything below is about the 62 that were carried.

The 62 that were carried, and where they actually live

Before any rate: these 62 cases come from only 26 document pairs, and 54.84% of them come from two.

Those two are big consolidating republications: RFC 8881 restates the NFS version 4.1 protocol from RFC 5661 under the same title, and RFC 7761 is the revised PIM sparse-mode specification replacing RFC 4601, which the prior study identified as the single most errata-attracting RFC in the series and which still is: 114 errata, ahead of the next document by 59. Carried error is not spread thinly across the corpus. It pools in the documents that were rewritten wholesale.

This matters more than a caveat usually does, because it decides what the number means. Take those two pairs out and the carried rate falls from 5.97% to 3.03% over the remaining 923 pairs. It also means these 62 observations are not independent of one another, which is the reason the significance tests further down come to nothing.

Read by hand, all of them

A substring match cannot tell whether the replacement is repeating the old text or quoting it in a section explaining what changed. Those are opposite findings. Every carried case was located to a section and screened for that automatically, and then every one was read. All 62 carried cases were read by hand against the rubric: 61 repeat the reported text as live content of the replacement, 1 is the replacement quoting the old wording in a 'Changes from' section, and none was a coincidental or boilerplate match. The automatic change-log screen flagged 2, of which the audit confirmed 1.

So the headline after the audit is 61, not 62: that many cases where the reported-wrong text is live content of the document that replaced the one it was reported against. The rubric permitted a 40-case random sample at this population size and all 62 were read instead, which is strictly less selective than the sample it allowed.

Read them yourself

This is the part that does not require trusting me. Below is every carried case: the erratum's own words, the passage as it stands in the replacement document, the two dates, and links to the erratum and to both RFCs on the RFC Editor's own site, so you can check any of it against the source in about thirty seconds. They are ordered by how long the correction had been on the record before the replacement was published.

The finding that survives: the erratum does not follow the error

An erratum is filed against a document. When that document is replaced and the replacement repeats the mistake, the erratum stays where it was, attached to the obsolete document. Nothing moves it. So the question is whether anybody re-filed it against the new one, and mostly nobody did.

Of the 62 carried cases, 56 were carried into a document that is itself still current, not obsoleted and not Historic. For 50 of those 56, no erratum quoting that passage has ever been filed against the replacement. The defect is in the specification a reader downloads today, and it is absent from that specification's own list of known defects. Only 7 of the 62 were re-filed.

The longest-standing is erratum 440, filed on 2002-01-06 against RFC2421. Its text is present in RFC3801, Voice Profile for Internet Mail - version 2 (VPIMv2), which replaced it and is today a draft standard. That is 24.7 years, and no erratum against RFC3801 records it.

This is exploratory: it was not part of the pre-registration, which asked only about the replacement's text. It is reported as an observation about 56 specific cases, all of them listed above, and not as a rate about the series. Matching is by quoted passage, so an erratum that reports the same defect in different words would not be found, which makes 50 an upper bound on the orphaning.

All seven predictions, and the four that broke

Prediction 7 is the interesting one, and it is the reason this section exists rather than a paragraph claiming a result. I expected technical errata, the ones the RFC Editor defines as errors in technical content, to be carried forward less often than typos, because someone rewriting a specification would attend to them first. The opposite showed up. Among errata filed before the replacement was published, technical ones are carried at 7.32% against 3.91% for editorial ones, which is a two-to-one difference with a two-sided Fisher exact p of 0.0335.

It does not survive contact with the concentration above. Remove the two document pairs that supply half the carried cases and the same comparison gives 3.31% against 2.73%, p = 0.7021. It would not survive a Bonferroni correction across the 7 comparisons on this page either, which needs p < 0.0071. So the honest report is: no difference is established, by type, by status, or by whether the correction was available in time. Here is every comparison run, including the ones that came to nothing, because listing only the one that nearly worked is how a result like this gets manufactured.

The status comparison in that table was not pre-registered. It is here because the name invites it: Held for Document Update promises consideration in a future revision and Verified promises nothing, so the two ought to part company if the promise means anything. Among errata filed before the replacement they run 7.45% against 4.49%, p = 0.0664, and that dies when the two documents come out as well. So the promise is not measurably broken more often than anything else here. It is also not measurably kept.

The replication that broke, and why that is the useful part

What this cannot tell you

• Absence proves nothing. Only the carried count is evidence. The 832 “rewritten” pairs may be fixes, rewordings, deletions or restructurings, and this method cannot distinguish them.
• Corrected is undercounted by construction. Submitters do not always write the corrected text as a drop-in replacement, and some describe the change in prose, so a document that genuinely fixed the error can fail to contain the erratum's corrected string.
• The carried cases are not independent. Half come from two documents. No rate here should be read as a property of the RFC series.
• Replacement only, not amendment. An RFC can also be updated by a later document that carries only the changed parts. The test does not apply there, and updates are excluded; only full obsoletion is measured.
• The reach is 75.36%, not 100%. Roughly a quarter of accepted errata quote their document loosely enough that this instrument cannot find the passage, and nothing is known about those.
• The database is not a complete record of what was submitted. Errata ids run to 9,163 with 8,035 rows present, so more than a thousand assigned numbers are not in the export. Spam screening and withdrawals, presumably, but the export does not say.
• One date in the database is not a date. Erratum 6534 against RFC2367 carries the submission date 9999-04-13. It is excluded from every date calculation and named here rather than quietly dropped.
• Scrutiny and defect are entangled throughout, as the prior study said. A document with more errata may be worse, or may simply be read more.

Run it yourself

Every number above comes from three public files and about six hundred lines of Node with no dependencies. The sources are the errata database, the RFC index, and the plain text of the individual RFCs. The check that tests the actual claim needs one file, Node, and a network connection: it picks carried cases at random, fetches the successor documents from rfc-editor.org, and confirms the reported-wrong text really is there.

curl -O https://artwaste.land/checks/verify-nothing-is-ever-fixed-only-replaced.mjs
node verify-nothing-is-ever-fixed-only-replaced.mjs --live 8

That is the whole recipe, in an empty directory, owning nothing you did not just download. It was tested that way rather than reasoned about, and the first attempt failed: the case list lives in the repository and a lone copy of the checker could not read it. The checker now falls back to the published copy, so the sentence above is something you can do rather than something that sounds like it would work.

• the verifier, which also asks git to prove the pre-registration was committed first
• the pre-registration, with the instrument, the controls and all seven predictions as they were written down
• the hand-audit rubric, fixed before the cases were read, and the 62 marks with a reason for each
• fetch.mjs, which collects the sources, one request at a time
• lib.mjs, which holds the normalisation, in one place
• match.mjs, which builds the table and runs the controls
• results.json, every aggregate this page quotes, and errata-table.jsonl, one row per accepted erratum: the whole working
• the lab notebook, including what is honest to say here and what is not

Read 2026-09-07. The errata database is live and these figures will move.