摘要

  • RFC 1410 是 IAB 1993 年 3 月的官方协议标准目录。它明示读者：1993 年 7 月 31 日之后不要再用这一版。
  • 每次标准成熟度升级都需要 IESG 建议、IAB 批准；若 IAB 不批准，工作退回 IETF。最短等待期和不同团队写出的实现也是门槛。

一份自称“官方”的名单，开头却劝你几个月后别再信这一版。这不是客套话，而是对目录自身权力的一次限期。RFC 1410 要求读者确认手上的副本是最新版，并把 1993 年 7 月 31 日写成这版的停止使用日。协议状态会变，发布状态的纸也必须跟着变。

目录背后有一条多关节的流程。协议开发主要在 IETF 工作组进行，标准成熟度依次为 Proposed Standard、Draft Standard、Standard。每升一级，IESG 先提出建议，IAB 再批准。如果 IAB 没有批准，提案就回到 IETF 继续工作。两个机构各做一个决定，不能把前一个意见当作后一个盖章。

时间也不能省。IAB 规定从 Proposed 到 Draft 至少等六个月，从 Draft 到 Standard 至少再等四个月，让社区有机会观察和反对。文件另说，进入 Draft 后，若没有重大异议或缺陷，六个月内很可能升到 Standard。那是对走向的预期，并非到点自动升级。

更难伪装的是代码。按 IAB 当时的一般做法，Proposed 要升 Draft，至少得有两个独立实现。Draft 升 Standard 通常还要有运行经验，并证明两个或更多实现能够互通。写出一份描述和让不同团队的程序真正说同一种话，是相邻却不同的成绩。

拿不准时，IAB 还能召集来自 IETF、IRTF 和 IAB 的专家委员会，要求它对具体行动提出建议。这个额外审视环节没有抹去原先的批准链。目录甚至保留被替代或不再使用的协议，标作 Historic；星号则表示条目较上一版新增、迁移或改变。所谓官方清单，自己就标出了变化的痕迹。

RFC Editor 记录 如今把这版列为 Historic，并注明后来由 RFC 1500 取代。既有的 RFC 1311 文章解释 RFC 编号和 STD 编号为何不是一回事。RFC 1410 追问另一件事：谁能让协议升级，谁能退回，升级时要拿出什么程序运行的证据？

1993 年的答案很具体：IESG 建议，IAB 可以叫停并退回，社区按等待期观察，两个独立实现检验文字是否真能互通。连记录这个答案的目录都给自己设了失效日。机构的章有重量，也有日期。