摘要

  • Verified 表示勘误已经审查并被认为准确；RFC Editor 仍不会把修正文直接写入通常提供的 TXT、PDF 或 XML 版本。
  • 勘误处理的是发布时已经存在的错误。新知识、新偏好或对原共识的重大改变，必须回到相应技术程序，通常需要发布更新或取代原文的新 RFC。

修正放在原文旁边

开发者读到两段互相冲突的规范文字，随后在 RFC 的勘误页发现一条 Verified 记录。记录列出原句、修正句、核验者和日期。依照修正句实现，很可能是正确的工程选择；声称修正句从一开始就在 RFC 里，则抹掉了一段重要历史。

RFC 固定了一次共同决定。勘误固定了稍后对该决定文本中某项错误的判断。前者回答“当时通过了什么”，后者回答“后来确认哪里写错了”。只有把两份记录都保留下来，实施者才能解释自己的选择，审计者才能还原权力链。

RFC Editor 以链接而不是覆盖来连接二者。Verified 记录对读者可见，却不混入常规发布版本。这个接缝迫使系统承认：纠错有权威，但纠错权威比重新制定规范更窄。

如果修正文直接替换档案，短期阅读会更顺畅，长期却无法区分原始批准、事后核验和本地采用。这种便利会透支标准的可追溯性。

四种状态是四种不同决定

Reported 只说明有人提交了一项主张。它可能准确，也可能误读了上下文，甚至可能试图借一个小表单重启旧争议。在完成分类前，它没有产生新的合规义务。

Verified 说明报告符合标准，应让实施和部署人员看到。它是最强的勘误状态，但作用仍是按照原意修复错误，不能凭此重新设计协议。

Rejected 说明这项主张不应沿勘误通道继续。原因可能是报告本身不成立，也可能是要求的变化太大，应由一份更新或取代旧文的新 RFC 承担。

Held for Document Update 表示当前 RFC 不必因此修改，但未来修订可以重新考虑。它保留问题，不宣布问题已经解决；它也不是一项延迟生效的规范命令。

因此，把四种状态压成一个“最新修正”字段，会同时丢失待审、认可、否定与保留之间的区别。机器得到一个简单值，治理却失去一整条判断记录。

谁核验，取决于 RFC 从哪里来

RFC Series 包含 IETF、IAB、IRTF、Independent Submission 与 Editorial 等不同发布流。它们的内容批准主体和目标不同，所以技术勘误的核验权也不能只归给数据库运营者。

IETF 流的技术勘误会通知作者、工作组主席和 Area Director。Area Director 对处理负责，可以自行评估，也可以委托他人。明显的编辑错误先由 RFC Editor 处理；一旦问题涉及技术含义，就需要相应技术责任人参与。

这种分工避免两种越权。出版团队不会因为掌握页面和工具就取得协议政策权；技术专家也不能绕过公开记录，直接把新的意思写成仿佛从未争议过的旧意思。

所以，审计时不能只读 Verified。还要读发布流、核验者、日期与理由。标签的可信度来自作出判断的具体权限，不来自数据库配色。

原始意图是勘误的上限

IESG 2021 年仍有效的声明给出关键界线：勘误针对 RFC 发布时已经存在的错误。后来出现的新能力、新思路，或者单纯不赞同既有内容，都不是勘误材料。

若技术问题有清晰解法，且解法与批准时的原意一致，可以标记 Verified。若解法仍需讨论，则应 Held。若变化会让协议以不同于原共识的方式运行，原则上应 Rejected。涉及 IANA 登记程序等流程变化时，也不能用勘误改写当时的社群选择。

字符数量不是权力大小。一处规范动词、一项默认值或一个代码点范围的改动，都可能改变互操作性、成本和风险归属。核验者需要查看工作组讨论、Last Call、IESG 评议、算法上下文与已知实现，而不能只比较两句话。

当这些材料不能证明唯一修法时，“仍待讨论”本身就是可靠结论。强行给出确定答案，只会把纠错通道变成一次缺少参与者的再立法。

重新发布文件，不等于改变语义

RFC 9720 允许在严格范围内重新发布 RFCXML 定稿及其渲染版本。原因可以是 XML 结构演进、源文件错误或生成工具变化。旧版本必须继续存档，每次重新发布都要留下公开日期和理由。

2026 年 2 月发布的 RFC 9920 已取代 RFC 9280。它把稳定性继续列为 RFC Series 的历史属性，同时承认展示形式可以重新生成。核心要求仍是尽最大可能保留原语义。

修复被截断的图形、错误字符或格式不一致，是维护出版载体。确认一处原有错误，是勘误判断。改变协议想要实现的行为，则需要有权作出新决定的标准程序。三者不能因为都表现为“文字变化”就混为一谈。

这个边界也方便事故调查：两套软件是执行了不同规则，还是仅仅阅读了同一语义的不同渲染？如果每项维护都覆盖旧档案，这个问题将无法回答。

工程引用必须带版本和日期

只写“遵循 RFC 1234”不足以重现一套实现。可靠记录应包括使用的发布版本、哪些后续 RFC 更新或废止了它、何时查询勘误，以及产品采纳了哪些 Verified 修正。

测试要把每条修正连接到可观察行为。若外部系统仍按原句运行，发行说明需要提示兼容性后果。安全错误可能要求立即缓解，即使档案文本保持原样。

Held 项可以进入未来设计复核，却不应自动成为合规失败。Rejected 项也有价值：它说明某种解释曾被正式考察，但没有取得纠错地位。删除拒绝历史，会诱使同一争议反复出现。

这种复合引用既不假设档案永不出错，也不假设勘误管理员可以制定新规范。运行系统可以进步，而每一层判断仍然可识别。

一份足够薄的共同账本

Heng Lu 的治理框架主张共同层只保存必要事实，把未来决定留给有能力的参与者，并通过自愿采用让运行代码检验改进。RFC 勘误在边界清楚时正符合这种结构。

共同记录可以准确陈述 RFC、章节、原文、建议修文、类型、状态、核验者、日期和理由。它不能由此推断所有厂商已经部署修正，不能把 Held 变成义务，也不能把一个已经休会的工作组的沉默解释为同意。

这些命题分别保存，反而让纠错更有力量。它的正当性来自如实记录“哪里错、谁判断、判断到什么程度”，而不是假装后来的注记已经把历史清除。

来源