摘要

  • RFC 9720 将 RFCXML 的“最终格式”、以该格式发布的“最终版本”、HTML/纯文本/PDF 等“发布格式”及其具体“发布版本”分开，允许在狭窄理由下重发，但要求尽可能保持语义内容。
  • 当前文件本身不是完整证据。只有旧版本、创建或重发日期、公开理由和可审阅的差异同时存在，读者才能区分修复显示与改变规范。

从单一文本到多种版本

过去把 RFC 想象成一个冻结的 ASCII 文件，直观而有保护性。它防止机构在实施者已经写进代码、合同已经引用之后再改写历史。但 RFC 系列转向 RFCXML 后，一份 RFC 有了承载完整发布信息的 XML，也有 HTML、纯文本和 PDF 等面向读者的输出。XML 可能发现错误，schema 会演进，生成工具也会变老。若一概禁止变化，公共档案被迫永久保留可修正的缺陷；若一概视为“只是格式”，生产环节就取得了不受约束的编辑权。

2025 年 1 月在 Editorial Stream 发布的 RFC 9720 没有选这两个极端。它取代 RFC 7990，并更新当时 RFC 9280 中的稳定性政策。它是信息性 RFC，不是 Standards Track 规范；它不命令某个网络如何部署，也不保证每一次重发都对每个依赖者无害。

它首先拆开一个容易被混用的词。“canonical format”过去既像是指可生成多个输出的 XML，又像是指被授权和归档的文件。RFC 9720 以最终格式指 RFCXML，以最终版本指该格式下已经发布的 RFC；HTML、文本、PDF 是发布格式，而各自的具体文件才是发布版本。名称的拆分是权限的拆分：PDF 外观不同，不能直接推出标准含义变了；XML 可以维护，也不能直接推出编辑者有权随意修改规范。

可以动的是什么，不能动的是什么

RFC Production Center 可以重新发布最终版本，但理由是有范围的：RFCXML schema 更新、在 XML 中发现错误，或生产发布版本的工具发生变化。规则要求“在最大可能范围内”保留语义内容。这个表述并没有假装零风险；RFC 明说即使面向语法的改动也可能意外造成语义变化。它要求的是识别风险、理解风险、降低风险，而不是把风险藏在“维护”这个词里。

发布版本的处理同样克制。重新发布是允许，不是强制。生产机构要同时衡量系列呈现的一致性和语义改变的风险。于是，不能为了维持“从不改变”的口号而把已知 XML 错误永久封存；也不能把每一个视觉偏好都说成必须替换历史文件的理由。

这是一种最小初始规范。共同层只规定必须共享的约束：语义不能被随意移动，维护权有明确边界。文件如何保存、历史版本如何定位、未来用什么工具，留给真正负责档案运行的机构和技术社群。RFC 9720 没有规定历史文件必须用哪一种方式寻找，恰恰避免把格式政策伪装成整个存储系统的总授权。

档案不是附属品，而是反向制衡

真正把维护权锁住的，是历史记录。RFC 9720 要求 RFC Production Center 保存所有较早的最终版本和发布版本，并且用与当前文件相同的访问方式提供。每一组归档都要记载创建或重新发布的日期。最终版本每次重发，还必须有公开记录和简短理由。

这使档案成为信任机制的一部分。今天打开的 HTML 页面不足以回答某个图、一个引用、一个非 ASCII 字符、一个规范性词语或被工具读取的示例是否曾改变。需要同时查看前后版本、重发理由和实际差异，再把差异与依赖它的代码、采购条款或审计流程相连。换行、字体或图像位置可能只有视觉影响；MUST、引用目标、数据模型元素或可执行示例的变化则可能不是。

责任也在此被分开。作者和审批程序对原本要表达的语义负责；生产环节在记录的边界内维护表示形式；实施者、供应商和网络运营者仍决定自己固定哪一个版本、如何验证、是否接受更新。谁提供最新文件，并不因此有权替承担运行风险的人作决定。

IETF Datatracker 的公开资料显示，Heather Flanagan 曾在 2012 至 2019 年担任 RFC Series Editor，目前是 Spherical Cow Consulting 的 Principal，并共同担任 SPICE 与 HotRFC 主席。这些事实说明她为何适合作为人物入口；它们不支持把 RFC 9720 写成她的单独创作，也不支持把她描述为当前 RFC Production Center 的操作者或一切重发决定的主人。

相同 RFC 编号不是完整回执

2026 年 2 月发布的 RFC 9920 取代 RFC 9280，并在一组 RFC 系列文件中更新 RFC 9720。政策本身也会在程序中演进。这一事实既不证明任何新文件都有害，也不证明任何变化可忽略。问题始终应落到具体依赖：当时使用的是哪个版本？差异是什么？哪个系统组件解释了这一部分？是否有可验证的回退？

运营者的证据包不应只留下 RFC 编号。它还应保存最终版本与发布版本的标识和日期、取回 URL 与哈希、公开的重发理由、语义差异与渲染差异、相关工具链版本、依赖组件、审阅者及可逆的发布边界。旧版本必须仍然能够取到。

这与 Heng Lu 对证据、决定和授权的区分一致。生产方公开说明一次重发，是关于它已执行动作的证据；它并不因此取得命令其他组织自动更新依赖的授权。承担停机、合规或合同后果的人，仍要拥有测试、接受或拒绝的决定权。

来源