Source freshness path from errata check to archive decision

When citing RFC or W3C errata, keep the original document and the correction record visible so readers know what text was published and what later correction applies.

The RFC Editor explains that verified errata are reviewed and considered accurate, but errata are not incorporated into the RFC text formats themselves. That means a reader who opens only the RFC may not see the correction in the body. W3C errata pages similarly record known errors for recommendations and classify the nature of changes. A source note should not blur these layers.

A practical citation has four parts: the base document link, the exact section or sentence being used, the errata link or identifier, and the errata status checked on a specific date. For example, a developer note might say that the implementation follows RFC X section Y as read with verified erratum Z. That wording is clearer than rewriting the original as if it had already changed.

The status line is important. Reported errata can be useful warnings, but they are not the same as verified corrections. Held-for-document-update items can indicate a future clarification without requiring readers to treat the original sentence as replaced. Rejected items may explain why a tempting correction should not be used.

The goal is not to make citations heavier. It is to prevent a common failure: one reader quotes the original text, another quotes the correction, and the team thinks they are disagreeing about the standard when they are really reading different layers of the same source.

How to cite RFC and W3C errata without pretending the original document changed

// COMMENTS

ON THIS PAGE