摘要

  • RFC 880 为每个协议分别记录状态、规范、已知问题、参考资料、依赖和联系人；“列入官方清单”只说明它进入了这套记录。
  • 清单自身证明这些字段不能互换：TCP 被推荐但文档仍有缺陷，TFTP 可选却已在使用，GGP 处于实验状态却服务于核心网关。
  • 后来的标准流程进一步区分成熟度与实施要求，周期性总表最终也被在线清单替代；但任何清单都不能单独证明一段代码正在怎样运行。

如果把“实验性”理解成“尚未进入生产”，1983 年 10 月的 RFC 880 会让这种理解立即失效。它在 GGP 条目中一面标注 Experimental，一面说明这种网关协议当时正用于核心网关。

这份名为 Official Protocols 的 RFC 没有替两句话消除张力。它把张力保留下来，因为状态回答的是采用规则，使用说明回答的是观察到的现实。清单的权威，恰恰来自它不冒充现实本身。

“官方协议”并不住在一本永不变化的书里

RFC 880 说，官方协议“粗略地说”来自 1982 年 3 月的 Internet Protocol Transition Workbook。紧接着，它列出例外：有些正在使用的协议不在工作簿中；有些协议已经修订；邮件、Telnet 和实现指南分别进入了新册子；某些多年未改的资料仍在 1978 年 ARPANET 手册里。

因此，清单首先要做的不是宣布唯一文本，而是整理一组不同年代的文本。六个月前的 RFC 840 使用了相似框架，现在已被 RFC 880 取代。被取代说明目录视图有版本和日期，并不意味着所有读过旧表的机器同时改变。

每个条目把 STATUS、SPECIFICATION、COMMENTS、OTHER REFERENCES、DEPENDENCIES 与 CONTACT 分开。状态表达采用期待；规范指向定义文本；评论保存偏差和疑问；依赖揭示下层条件；联系人承接协调与解释。

这套结构拒绝让一个标签吞掉所有事实。正式文本可以存在，却仍不充分；实施可以存在，却偏离文本；协议可以被推荐，却尚未启用；上层功能可以可选，而它依赖的底层却是必需的。

五种状态不是五个质量等级

Required 表示所有主机必须实现，Recommended 表示鼓励所有主机实现，Elective 表示可以选择，Experimental 表示仅由参加并协调该实验的人实现，None 则表示这不是一个协议条目。

IP 和 ICMP 是 Required，UDP 与 TCP 是 Recommended，TFTP 是 Elective，EGP 和 GGP 是 Experimental。Catenet Model 标为 None，因为它描述架构而不是一套可直接实现的线上协议。

这些状态规定的是采用姿态，不是安全评分。Required 不能证明某台主机确实安装并启用；Recommended 不能证明两个实现互通；Elective 不能证明很少有人使用；Experimental 也不能证明没有生产流量。

TCP 的“推荐”旁边就是缺陷清单

RFC 880 指向 RFC 793，并把 TCP 标为 Recommended。它随后说明，许多修正意见已经收到，而且主要是“文档缺陷”而不是协议缺陷。

事件处理部分需要澄清；Push 的措辞仍容易让人误以为它是记录边界；最大报文段长度的默认值与作用范围不够清楚；监听服务器、空闲连接、关闭时尚未交给用户的数据、乱序报文段与用户超时也都有待说明。

这些评论没有取消 TCP 的推荐地位。它们使“推荐”变得可执行：实现者知道共识指向哪里，也知道文字在哪些位置不足以独立裁决。只抄下 Recommended 的合规表，反而删掉了官方条目最有价值的部分。

运行代码可以落在“实验性”格子里

EGP 被列为正在开发的实验协议。GGP 同样是 Experimental，却被说明正用于核心网关。RFC 880 没有给出网关数量、互操作率或可用性数据，所以不能把这句话扩写成部署普查。

它足以划清一个边界：Experimental 是制度状态，不是流量计。运行于关键位置的代码，不会因为它在运行就自动取得成熟标准地位；制度标签也不会让正在转发的代码停止转发。

Stream Protocol 显示另一种偏差。清单说它的实现已经演进，可能不再符合所列规范。此时“有运行代码”无法证明“符合该文档”。TFTP 则被列为 Elective，同时注明已经用于若干本地网络。可选择与已选择从来不是同一件事。

Telnet 选项必须另设“使用”一栏

RFC 880 的 Telnet 选项表不仅列 RFC 或 NIC 文档，还标出是否收入新的 Telnet 册子、是否留在旧 ARPANET 手册，以及 USE。Echo、Binary Transmission、Suppress Go Ahead 等选项被描述为经常实现，许多其他选项则没有普遍使用。

整个选项族仍是 Elective。清单没有据此推断每个 Telnet 实现都包含所有选项。“支持 Telnet”只能说明一个很宽的协议名称，无法证明某项功能会在两个端点之间完成协商。

USE 不是全球遥测，也没有提供测量方法与分母。它的价值在于承认：文档位置、制度可选性与现实采用必须分别陈述。

依赖与联系人限制了状态的作用范围

SMTP 和 Telnet 依赖 TCP，TFTP 依赖 UDP，网关协议依赖 IP。某个上层条目进入清单，不会让整条依赖链自动出现。要判断运行状态，仍须逐层验证。

联系人也不是装饰。实验性使用需要协调，规范疑问需要接收者。联系人没有因此获得支配所有实现的主权；这一字段只是承认，分类之后仍有维护和解释工作。

1986 年的 RFC 991 延续了这套方法，并称自己为官方状态报告。连续替换的版本说明：清单是一份需要维护的快照，而不是永久判决。

成熟度与实施要求后来被正式拆成两轴

到 1991 年，RFC 1200 明确区分标准化 STATE 与要求 STATUS。Standard、Draft Standard、Proposed Standard、Experimental、Informational、Historic 属于一轴；Required、Recommended、Elective、Limited Use、Not Recommended 属于另一轴。

RFC 2026 进一步规定标准轨道、适用性与要求级别。RFC 6410 后来把标准轨道从三个成熟度级别减少到两个。流程改变的，是文档如何取得地位；它仍没有替网络数出实现。

连周期性总表本身也会过时。RFC 7100 在 2013 年退役了最后一版总表和 STD 1，因为它们未能持续更新，已经让位于 RFC Editor 的在线清单。数据库比周期性重发的大文档更容易维护，但数据库记录仍不等于设备执行。

来源与边界

本文依据 RFC 840、RFC 880、RFC 991、RFC 1200、RFC 2026、RFC 6410 与 RFC 7100。它们证明目录与流程史，不证明当前部署份额、具名产品符合性、现时安全性、运营商政策或任何事故。