Summary

  • RFC 1011把协议规范与状态、评注、依赖关系和联系人分开列示，让庞大且持续变化的技术体系更容易协调。
  • “必需”表示主机应当实现某项协议；它并未说明任何一台主机安装或运行了什么代码。

一份需要定期失效的清单

Joyce Reynolds与Jon Postel在1987年5月发布的备忘录名为Official Internet Protocols。它自称是一份状态报告：列出互联网所用协议的规范文档，并注明计划中的修订或变化。与其说它是描述每台机器现状的总手册，不如说它是一张有日期、描绘移动系统的地图。

文档自己就提示了这一局限：读者应使用最近三个月内发布的版本。每个条目可以指向规范，列明依赖关系，记录实现问题，并给出联系人。读者因此不仅能知道某协议由哪份文件描述，也能看见描述中仍待解决的地方，以及后续协调该找谁。

每个协议有五种状态之一。“必需”表示所有主机都必须实现；“推荐”表示鼓励实现；“可选”由主机自行决定；“实验性”限定在经过协调的实验中使用；“无”则说明该条目本身并非协议。这些标签描述不同的预期，并不是对机器运行状况的五种测量。

状态标签不会安装软件

具体条目把区别说得很清楚。IP列为必需；TCP和UDP列为推荐。“Graphics Protocol”列为可选，但评注同时写明，没有已知的活跃实现。评注并未删掉这个条目，状态也不会凭空造出一份实现。编者记录了分类，也记录了知识边界。

这个并列关系很关键。目录可以权威地说明某份规范被赋予了什么状态，却仍无法认证所有主机的行为。“必需”是一种兼容性要求。若要描述真实运行情况，还需要实现和观察。RFC 1011没有完整主机普查，没有已安装版本清单，也没有测试回执证明每台主机都正确运行了每项必需协议。

规范与实现是在时间中衔接的

RFC 1011属于持续更新的发布序列：新报告取代旧报告，并重列各协议状态。到1989年4月，RFC 1100进一步说明了标准化程序：任何人都可以提出协议，技术工作组的建议会进入审议，而一般政策是在有实现经验之后才把协议定为正式互联网标准。它也说明RFC编号不会重发；协议可以改进，再由后续RFC重新描述。

这并不意味着标准文件不重要。共同规范让不同团队能够对准相同的行为。但从提案到服务，过程不止是发布：有人实现某个版本，和其他系统测试互通，依据经验修订，再由主机采纳。1989年的主机要求文件把通用互联网主机的许多期待写得更具体。即便如此，规范措辞描述的仍是合规主机应当做什么，而不是所有在网设备都已做到什么。

清单的更新节奏因此很有意义。季度状态报告能帮助运营者和实现者找到当前文档，但日期本身也是其有效性的一部分。发布时准确的一行，可能随着规范、评注和实践变化而过时。提醒读者不要使用旧版本，正说明协调需要持续维护。

有用的记录，不是正在运行的网络

RFC 1011最好被看作协调工具。它让状态更清楚，把协议条目连到文档和联系人，也没有掩盖不确定性。这些作用确实可能影响决策；要求或推荐并非空话。但报告无法进入每一台主机，让它自动执行某项决定。

这条界线仍有助于理解互联网史。文档编号不是实现，标准状态不是数据包捕获，推荐也不是部署数量。共同规则能缩小彼此兼容的选择范围，但互联网是由运营者选择运行并持续保持互通的系统构成的。

来源