摘要

  • RFC 3967 要求在 IETF 最后呼叫中显明较低成熟度的规范性依赖，而不是把例外藏起来。
  • RFC 4897 和 RFC 8067 后来将部分等待改为附注与 IESG 裁量；它们都没有提高被引用文档本身的成熟度。

一项标准可能需要引用一份有用、但成熟度尚不足以与它并列的文档。实现者也许必须依照一份 Informational RFC 中描述的算法；迁移规范可能要说明怎样与旧协议共存；IETF 文档还可能依赖外部标准或专有系统，而这些材料并非 IETF 能直接重新发布并提升等级的对象。真正棘手的不是引用存在，而是一个被称为标准的文档，在规范意义上依赖了状态所显示的审查或稳定程度较低的材料。

RFC 2026 的通常规则试图保留这种区分：标准轨道规范一般不应依赖成熟度更低的标准轨道文档，也不应依赖非标准轨道规范；其他标准组织的规范是例外。2004 年 12 月发布的 RFC 3967 属于 BCP 97，它解释了背后的制度顾虑：不能让读者误以为一项标准比实际更成熟。成熟度标签不是技术质量分数，但规范性引用可能包含完整实现所必需的信息。如果依赖文档不稳定、难以取得或容易被误解，引用它的规范就可能无法自洽。

RFC 3967 承认有些向下引用无法避免，并给出了可见的例外路径。标准轨道或 BCP 文档仍可经过正常的 IETF 最后呼叫，但通知必须明确列出该向下引用。社区对其适当性的意见要进入 IESG 的审议。只有在同一文档、同一版本已多次向社区公开，而且负责领域总监认为该用法已为技术领域所接受时，才可以免去后续通知。

这是一种披露机制，而非自动认可。RFC 3967 提醒：如果正确做法是把被引用文档移入合适的类别，就不应把此程序当作捷径。例外也不会改变目标文档的状态；它仍保留自己的成熟度。目的在于让社区看见依赖、并能在发布前提出异议，而不是把成熟度差异包装成共识。

三年后，RFC 4897 把另一种成本写进了规则讨论。它的引言称，旧规则有时造成很长的发布延迟，也有人认为这严重妨碍文档升至更高成熟度。但证据需要谨慎阅读：致谢部分同样写道，作者并不确定某些抱怨是否成立，提案在一定程度上也是为了检验这些说法。这是流程争论的记录，不是测量延迟规模的研究。

RFC 4897 改变了对已发布、但成熟度较低的标准轨道或 BCP 文档的规范性引用处理方式。引用方不必一律等到目标文档升级，可以在参考项中加注：该文档可能较不稳定，并可说明为何这样的依赖是合适的。IESG 仍能制定何时应延迟的指引；社区也可在文档生命周期中提出异议，不另设脱离正文的专项审查。目标不是标准轨道文档时，仍适用 RFC 3967。RFC 4897 还明确表示，如果可以合理升级目标文档，升级依旧更可取；“注明后继续”并非普遍替代规则。

2017 年的 RFC 8067 又调整了通知要求：最后呼叫消息明确列出向下引用，变成“强烈建议”，而非必须。负责的领域总监仍须主动检查；若在最后呼叫或 IESG 审查阶段才发现漏项，是否重开社区征询由 IESG 判断。不重复最后呼叫不会改变目标文档的成熟度；未来再次使用时仍受向下引用流程约束。遗漏还应记入 Datatracker。

把这三份 BCP 97 文件放在一起看，变化的是制度承担成本的方式。RFC 3967 让社区先看到成熟度差异，再由 IESG 决定；RFC 4897 允许部分引用带着明确警告继续推进，而不总是等待目标升级；RFC 8067 则允许 IESG 决定未被及时发现的引用是否值得再次征询，同时保留成熟度信号和决策记录。流程从主要依靠程序性等待，逐渐转向明确分配披露、审查、注释与裁量责任。

这些 RFC 并不能证明发布在实践中变快了、安全性提高了，或例外究竟用了多少次。它们给出规则和作者的理由，却没有提供前后对比数据。较稳妥的历史结论是：标准体系可以承认依赖关系与文档状态不会同步推进，同时仍要求引用不能悄悄继承自己尚未获得的权威。

来源：RFC 2026、RFC 3967、RFC 4897、RFC 8067、RFC 7841。