摘要

  • RFC 7942 允许 Internet-Draft 设置可选的 Implementation Status 章节，记录实现主体、名称、成熟度、功能覆盖、所对应的草案版本、许可、测试经验、联系人和更新时间。
  • 这些内容由贡献者提供，IETF 不负责核验，也不构成背书或完整产品目录。由于它们必然随时间变化，草案成为 RFC 前应删除整章及对 RFC 7942 的引用。
  • 删除不等于否定运行代码。它把“用于修改设计的临时证据”与“长期有效的规范文本”分开；实现、互操作、部署和运行结果仍需各自的可追溯回执。

一张从诞生起就有到期日的表

2016年7月，Yaron Sheffer 与 Adrian Farrel 共同署名的 RFC 7942 成为 BCP 205。它没有规定每一份 IETF 文档必须先有实现。相反，它承认一个现实：不少 Proposed Standard 在没有实现的情况下也会发布；不同工作组可以提出自己的要求，而这个流程本身是自愿的。

它提供的不是准入门槛，而是证据容器。草案作者可以在 Security Considerations 之前加入 Implementation Status 章节，把已经知道的实现逐项列出。工作组因而不必只听“应该能做出来”或“我们已经支持”这类无法复查的句子，而可以问：是哪套代码？对应草案第几版？做到哪些功能？谁维护？何时更新？有没有两端互通的测试记录？

这套机制本身也经历过试验。2013年的 RFC 6982 把它设为18个月的流程实验，观察四类结果：披露实现是否帮助比较竞争方案，运行经验是否推动协议修改，是否增加互操作测试，是否吸引非作者通过代码或实际交互参与评审。RFC 7942 后来取代 RFC 6982，把机制提升为最佳现行实践。换句话说，这项流程没有只凭理念永久化，它先限定试验期，再根据采用经验决定保留。

列名字没有意义，列边界才有意义

RFC 7942 给出的字段像一份最小审计表。它可以记录负责组织、实现名称或网页、总体说明、成熟度、规范覆盖范围、兼容的 Internet-Draft 版本、许可条款、实现经验、联系人和最后更新时间；若存在，还可附测试用例与互操作报告。

真正有用的是字段之间的联结。“生产级”若没有日期和版本，只是一句形容词。“实现协议”若没有覆盖范围，无法判断可选功能和异常路径是否存在。一个公开仓库若没有 commit、release 或对应草案版本，后来的人无法重现当时状态。两项实现若来自同一代码库，不能自动算作独立证据；两个产品名字若没有交换消息的测试记录，也不能证明互操作。

RFC 7942 对这些诱惑写得很直白。建议的章节说明必须提醒读者：出现某个实现不代表 IETF 背书；IETF 没有核验贡献者提交的材料；列表不是全部实现及功能的目录；没有列出的实现仍可能存在。工作组主席与领域主任还被要求阻止该章节沦为营销场地。

这不是对企业动机的道德判断。早期实现者自然希望其方案推进更快，开源项目希望获得开发者，作者希望证明方案已有动量。这些激励可以促成更好的工程工作，也可能把“先出现”包装成“更正确”。因此应比较的不是品牌数量，而是代码身份、所有权独立性、版本、覆盖、失败记录和测试条件。

为什么发布时要删

RFC 7942 的核心边界是时间。它明确说，实现状态信息必然具有时间依赖性，不适合进入已发布 RFC。作者应要求 RFC Editor 在发布前删除整章，也删除对 RFC 7942 的引用；RFC 勘误流程也不负责维护已经移走的快照。

假设某份草案在2019年写着“原型”，产品在2021年停止，许可在2022年变化，协议最终文字又在发布前调整。若原表永久留在 RFC 里，2026年的读者很容易把它误读为当前支持情况，甚至误读为标准组织对某供应商的认可。若当时只列出一个公开实现，遗漏的项目还会被永久塑造成“不存在”。

所以，删除不是销毁证据，而是防止过期自报继承规范的长期权威。若发布后仍需要实施状态，RFC 7942 建议将它放在可持续更新的外部公开资源，例如工作组 wiki；为了真正发挥作用，该资源不应要求认证、注册或访问权限。规范保持稳定，状态记录保持可改，二者各自承担适合的寿命。

运行代码优先，但代码不拥有主权

RFC 3935 把 IETF 的工程判断与实际实现和部署经验联系起来。RFC 7282 反对用投票代替技术问题的处理，也强调工程产物应当挑战纯理论设计。Heng Lu 的 Running-Code Primacy 把这条顺序推得更清楚：发布不是现实，协调规则必须由独立运行系统真正需要的最小功能来证明。

RFC 7942 展示了一个克制的落地方式。代码应在规范仍可改变时进入证据链，但它不能替代清晰规范。文档甚至明确拒绝规定工作组必须多大程度偏爱“已有代码”的方案。一套原型可以证明某个团队完成了某种解释，可以暴露歧义或不可实现的要求，也可以产生互操作测试输入；它不能仅凭存在证明安全、规模能力、独立实现数量、部署普及度或运行效果。

这正是运行代码优先与代码主权的分界。实现者有资格提供证据，没有资格把自己的实现状态强制转化成所有运营者的采用义务。工作组可以据此修改文稿，也可以在评估其他技术异议后拒绝其方案。发布后的运营者仍决定是否升级、何时启用、如何回滚。

不可压缩的九个时间点

一条可审计链至少要保留：草案名称与 revision；自报主体和提交时间；代码仓库、版本、commit、build 与许可；明确的功能覆盖；测试环境和用例；对端实现及其版本；成功与失败结果；工作组如何使用证据；发布后真实部署与观测。

其中任一阶段都不能替后一阶段作证。代码对应 draft-08，不自动覆盖 draft-12。两端完成一个必选消息交换，不自动证明全部可选功能。工作组因原型修改了文字，不代表最终 RFC 已被产品实现。RFC 号出现，不代表运营者已升级。配置打开，也不代表流量真的经过或结果符合预期。

截至2026年9月1日，IETF Datatracker 官方档案在 Adrian Farrel 的同一公开身份下列出82份 RFC 和多个当时角色。这能确认人物、长期参与和共同作者背景，不能把所有实现报告的核验责任归给他。RFC 7942 反而把权力拆开：实现者自报，作者整理，主席和领域主任防止营销，工作组判断证据权重，RFC Editor 移走临时文字，运营者决定运行什么。

因此，那张消失的表格不是标准史里的空白。它是一道时间边界：在设计仍可修改时，让运行代码说话；在规范成为长期公共记录时，让不断变化的实现事实进入另一份有日期、有责任人、可纠正的账本。

来源