摘要

  • RFC 1280 是一份协调用的定期快照，不是实时清点：它要求读者查找最新版本，并禁止在 1992 年 7 月 31 日后继续使用当期副本。
  • STATE 标示标准化成熟度，STATUS 标示实现要求。任一标签都不能单独证明部署范围或服务运行结果。

目录越有用，越容易被误当成永不过时的事实。需要判断某个协议在互联网标准体系里处于什么位置的人，需要一份共同参照，而不是逐本翻阅互不相连的 RFC。RFC 1280 集中列出协议，解释标准化阶段，给出要求级别，并指向相关规范。但它也为自己的权威画了期限：1992 年 3 月的版本计划大约每季度重发一次，且 7 月 31 日后不得再使用。

这不是说所有协议都会在 8 月 1 日改变。失效日限定的是这份目录能支持判断的时间范围。IAB 提醒读者向 Network Information Center 或 IANA 获取现行版本，并阅读每项的近期变更说明。同年 9 月，RFC 1360 已取代 RFC 1280。官方清单可以准确记录某个时点，却不保证在之后的决策中仍然新鲜。

清单把两个坐标拆开。STATE 描述规范成熟度：标准、草案标准、拟议标准、实验性、信息性或历史性。STATUS 描述对某类系统的实现要求：必须、推荐、可选、有限使用或不推荐。一个拟议标准可以只是可选；一个信息性规范也可能被推荐。前者回答规范处在什么流程阶段，后者回答具体系统应如何采用。

它们都不是部署普查。RFC 1280 提到，一些厂商协议没有 IESG 推荐或 IAB 批准，却已经得到广泛实现并对社区很重要。另一方面，“实验性”用于记录研究，不等于鼓励生产使用。因此，出现在 RFC 系列中不代表被部署，进入标准流程也不能代表普及。要证明这些事，需要另外的证据：独立实现、互操作测试和运营经验。

配套参考文档的更新时间也不同。Assigned Numbers、Gateway Requirements 与 Host Requirements 各自修订；彼此不一致时应以较新的文件为准。RFC 1280 帮读者找到协议的当前 RFC，却不会让所有下层说明同步更新。RFC 1310 把周期性标准清单描述为特定规范状态的权威记录；RFC 1280 同时写明这份记录何时到期。保留历史行并不能证明今天的协议行为、运营商的部署或服务是否响应。

来源：RFC 1280；RFC 1310；RFC 1360。