摘要

  • Obsoletes 对文档谱系具有明确权威：新 RFC 成为理解现行规范或实践的一般起点，旧 RFC 仍保留在永久档案中。
  • 这条关系不会自动修补软件、关闭功能、撤回产品、终止协议协商或产生法律禁令；每一种结果都需要不同主体另行行动并提供证据。
  • HTTP/2 表明，协议在网络上的身份可以延续，而定义它的文档已经更换；TLS 则表明，即使旧版本被正式弃用，现实系统仍会把安全风险与互操作损失摆到运营者面前。
  • 合规的结论不能只看最新编号，而应形成一张迁移回执：规范关系、实际装载版本、依赖对象、试验结果、例外负责人、回退条件，以及旧行为确已停止的遥测。

一行字改变了什么

RFC 9113 首页有一项简短元数据：它取代 RFC 7540 与 RFC 8740。对 RFC 系列而言，这不是装饰。读者今天理解 HTTP/2，应当从 RFC 9113 开始；RFC Editor 会在旧文档页面标出新的继任者；IANA 按照新文档更新部分登记项的引用；声称符合现行规范的实现，也必须面对新文本中的实质变化。

可是，这一出版动作没有取得任何服务器的管理员权限。它不会把早已交付的二进制文件重新编译，不会替设备安装固件，也不会替运营者关闭明文升级路径。一个仍按旧优先级语义工作的中间设备，不会因为目录多了一条关系就立刻改变。

规范事件是真实的，直接作用对象却首先是文档记录。承认这一点并不是贬低 IETF。相反，只有不夸大权限，标准机构的决定才可验证、可归责。IETF 负责形成技术规范，RFC Editor 负责保存不可变档案和关系，IANA 负责维护协议参数记录。它们都不需要假装能够远程控制别人的机器，才能完成协调职责。

组织之所以容易混淆，是因为文档完成成本很低，运行完成成本很高。在合规表格里把 7540 改成 9113，只需几分钟；确认哪些代理、终端、嵌入式设备和外部伙伴仍依赖旧行为，可能需要数月。若目录更新可以直接被报告为“已经采用”，机构就能得到一幅整洁的治理图景，而无需面对杂乱的真实基础设施。

问题不是目录不重要，而是目录被要求替机器作证。

“取代”仍然保留旧文档

RFC Editor 对关系的解释十分克制：已发布 RFC 的正文不再改写。修订或替代必须获得新编号。Obsoletes 表示新 RFC 取代所列旧 RFC，读者通常应以新文档理解现行规范或实践；旧文档仍属于 RFC 系列的永久档案。

永久保留不是情怀。它让工程师可以重建一款旧产品开发时面对的要求，让事故调查者分辨某项行为源于哪一版文本，也让审计者看清规范究竟在何时改变。若把旧文本删除，目录看起来更纯净，证据链反而断裂。

RFC 7322 把 Updates 与 Obsoletes 放在文档头部。它也承认，引用已经被取代的 RFC 仍可能有必要，通常需要同时指向较新的版本。这正是不可变文献体系的工作方式：新决定通过显式关系改变阅读路径，而不是偷偷重写历史。

因此，Obsoletes 绝非可有可无。实现者若声称符合 RFC 9113，不能任意保留 RFC 7540 中对自己有利的规则。架构评审若忽略替代关系，也可能继续依赖已经改变的要求。文档谱系具有真实约束力。

但它直接证明的只有谱系。它不证明补丁已经装载，不证明某项配置已经关闭，不证明厂商已停止支持，也不证明监管者作出禁令。把这些命题一起塞进“过时”二字，就是把多个控制面伪装成一个权力中心。

被一个词压扁的六种行动

第一种是文档替代。标准流程确认新的现行文本，档案系统记录新旧关系，同时保留两个文档。

第二种是状态或适用范围改变。规范可能转为 Historic；Best Current Practice 可能提高安全要求；适用性声明可能只针对新协议、特定行业或特定使用环境。

第三种是功能弃用。协议名称和大部分线缆行为可以继续存在，其中某一条路径却被删除、降级或不再推荐。协议身份延续，不等于所有旧功能仍被认可。

第四种是实现变化。维护者修改源代码、制作发布包、选择支持分支并决定是否回移修复。代码已经合并，只能证明某个版本可用，不能证明客户正在运行它。

第五种是部署决定。运营者发现受影响系统，测试依赖，安排批次，修改配置，观察失败，批准或拒绝例外。服务中断与残余风险在这里被实际承担。

第六种是外部约束。客户、合同、保险人、采购规则、监管机关或法院可能要求停止使用。它们的权限来自自身法律或契约基础，不是从 RFC 页眉借来。

六种行动会互相影响。新 RFC 可以促使维护者改代码，BCP 可以改变保险人的风险看法，厂商停止支持可以逼迫运营者提前迁移。但影响不等于同一。标准机构触发了变化，不代表它执行了后续所有动作，更不代表它承担每个本地系统的损失。

反过来，运营者也不能以“RFC 只是文档”为由，一边忽略新要求，一边宣称符合新规范。标准定义选择加入共同协调的系统应当如何行为。这里要限制的是执行权外推，而不是把规范义务说成没有意义。

HTTP/2 没有因为新编号改名

RFC 9113 既有连续，也有改变。它吸收 RFC 8740 对 TLS 1.3 与 HTTP/2 的处理，收紧若干验证规则，调整明文升级和优先级机制，并澄清 Host 与 :authority 的关系。附录 B 专门列出实质与编辑变化，说明它不是仅换封面的重印。

与此同时，ALPN 标识仍然是 h2。帧类型、设置项和错误码登记继续有效。IANA 把若干引用更新到 RFC 9113，并未为修订后的 HTTP/2 创造另一个协议身份。连接双方协商的是线上能力，不是文档编号。

一些具体机制获得了更明确的退出安排。HTTP2-Settings 字段与 h2c 升级令牌被标为过时；RFC 7540 的优先级方案被弃用。可是，RFC 9113 仍保留相关格式，并指出旧优先级语义只能在 RFC 7540 中理解。

这不是规范自相矛盾。被取代文档不再是现行规范的一般入口，却仍可解释现实中可见的旧行为。永久档案保存记忆，现行 RFC 指示方向，软件维护者与运营者决定方向何时进入生产。

所以，一张写着“已从 RFC 7540 迁移到 RFC 9113”的表，几乎不能独立证明什么。代理是否拒绝已删除的明文路径？库是否还发送旧信号？托管设备是否收到固件？老客户端是否走兼容分支？只有运行证据能回答。

TLS 把时间差写进了标准

RFC 8446 规定 TLS 1.3，并取代 TLS 1.2 的规范 RFC 5246。可是，它在兼容性附录中详细讨论如何与较旧服务器和客户端协商，如何在多服务器环境中逐步部署 TLS 1.3，以及旧中间设备面对陌生扩展或版本时可能出现的故障。

新标准的作者没有假设页眉会消灭旧安装基础。他们把新协议写成能够进入混合环境的方案。

RFC 8996 随后对 TLS 1.0 与 TLS 1.1 采取更强行动：正式弃用，将相关文档转为 Historic，并要求实现不得协商这些版本。这比一般文档替代更进一步，因为它给出了明确的安全结论和现行实践边界。

即使如此，RFC 8996 的运营部分仍指出，有些系统可能无法支持 TLS 1.2 或更高版本。执行新要求会与这些系统失去互操作；继续兼容则承担安全风险。决策者需要结合风险、缓解措施和升级本身的危险，判断迁移速度。

这不是为 TLS 1.0 提供永久豁免，而是在分配责任。IETF 可以界定符合现行实践的行为。系统所有者仍要找到依赖，选择替换、隔离或中断，并证明旧版本确实不再协商。

RFC 9325 对 TLS 1.2 与 TLS 1.3 分别给出当时的安全建议，同时禁止回退到更早的弃用版本。RFC 9852 后来又要求采用 TLS 的新协议必须要求 TLS 1.3。现行实践由替代、更新、适用范围和时间共同组成，不能用“8446 取代 5246”一句话全部压平。

MUST NOT 不是后台进程

规范中的大写关键词当然有分量。在相应范围内，MUST NOT 定义了声称符合该规范的实现不得出现的行为。它为测试、采购和安全审查提供了明确基准。

但它不是拥有全球 root 权限的后台程序。维护者要把要求写入代码，厂商要交付可用制品，运营者要装载并配置，对端要能承受结果，审计者要检查实际进程。

这就是规范权威与执行权威的区别。前者可以定义合规系统的共同表现，后者必须拥有设备、维护窗口与风险责任。互联网协调可以让两者相互作用，不必把它们合成一条命令链。

一旦合并，责任反而消失。迁移失败后，“RFC 要求如此”无法回答谁选择日期、谁批准例外、谁验证回退。旧功能继续存在时，“它已经过时”也不能说明是维护者没有实现、厂商没有交付，还是运营者保留了配置。

好的标准描述应有行为；好的回执描述实际行动。

安装基础是证据，不是永久否决权

RFC 2026 有一个重要限定：既有 Internet Standard 出现新版本后，旧版本通常被取代并转为 Historic；但为照顾安装基础的需要，某些情况下新旧版本可以同时保留为标准，只要关系被明确说明。

这不是向旧技术无条件投降，而是承认互操作发生在真实系统之间。无视现有对端的规范，文字上可能整齐，协调上可能失败。

安装基础也可能被滥用。一个从未测量的依赖被永久称为“关键”；少数旧客户成为整个服务保留攻击面的理由；临时例外失去负责人和到期日。兼容成本、测试分支与安全模糊随时间累积。

证明责任应当移动。迁移初期，主张关闭旧行为的人要证明替代方案可用、失败模式已知。随着安全证据、受支持版本和迁移经验增加，保留例外的一方应说明必要性、隔离措施和结束时间。

资产清单告诉我们旧能力可能在哪里；协商遥测告诉我们实际在哪里使用；断开试验告诉我们会损失什么；装载版本证明哪段代码正在处理流量。这些答案不在 RFC 页眉中，但页眉可以是启动调查的可靠信号。

一张可以审计的迁移回执

第一项是规范谱系：新 RFC、所有 Updates 与 Obsoletes 关系、后续 BCP，以及实际受影响的具体行为。“采用 RFC 9113”过于宽泛，必须说明究竟要停止哪条路径。

第二项是装载状态：正在承载流量的版本、构建、固件和配置。补丁在仓库、更新已下载、厂商公告已发布，都不等于运行进程已经改变。

第三项是依赖证据：仍使用旧行为的客户端、服务器、中间设备、嵌入系统与外部伙伴。无法全面盘点时，要说明观察窗口与盲区，不能把没有看到当成零。

第四项是风险与权限：为什么退役，谁作决定，期限来自运营者、客户合同、厂商支持政策还是监管要求。RFC 可以提供技术理由，外部强制力必须另有来源。

第五项是试验与回退：预期的互操作故障、分批顺序、停止阈值和允许的回退时间。若回退会重新开放脆弱版本，就必须重新批准风险，而非自动恢复。

第六项是例外托管：明确系统、负责人、补偿控制、到期时间与复查触发器。没有主体和时钟的“遗留需要”，不是例外，而是默认政策。

最后是退出证据：旧能力不再被协商或调用，告警并非只是隐藏，替代路径确实承载原服务。完成迁移是一个关于运行状态的命题。

两种对称的自欺

第一种是自动完成：新 RFC 已发布，于是旧行为被报告为已经消失。风险先从报表消失，再等待有一天从网络消失。采购检查编号，审计检查政策库，没人检查握手或进程。

第二种是永久可选：既然 RFC 不能自动改机器，任何迁移都被视为可以无限拖延。规范要求变成意见，兼容性变成没有到期日的挡箭牌。

诚实治理必须同时保留两类权威。文档关系证明什么是现行技术基线，运行系统证明实际部署了什么。中间需要有可归责、可限制、可测试的决定链。

看到“已过时”时，应继续问：具体规则改变了什么？旧行为还可能在哪里出现？谁控制相关设备？什么测量能够证明它已经退出？

RFC Editor 应保存历史，IETF 应说明现行规范，IANA 应维护准确引用，维护者应交付代码，运营者应部署并验证，外部机构应说明自身权限。这不是权力碎片化，而是迁移的证据保管链。

Obsoletes 告诉我们今天从哪份文档开始读。它从未声称昨天的代码已经停止运行。

来源