摘要

  • RFC 675 标注的日期为 1974 年 12 月，作者为 Vinton Cerf、Yogen Dalal 和 Carl Sunshine。共同署名是 Cerf 参与这份规范的直接记录，但不能据此分配每个人的设计份额。
  • 互联网协会的历史回顾 区分了 Cerf 与 Bob Kahn 希望支持的服务范围和初始 TCP 实现实际支持的虚电路服务。这一区别不能被简化为 Cerf 一个人的决定或责任。

先看文档留下的名字

讨论 Vint Cerf 的技术贡献，可以从一件具体的成果开始，而不是从声望倒推权限：题为《互联网传输控制程序规范》（Specification of Internet Transmission Control Program）的 RFC 675，日期为 1974 年 12 月，列出了 Vinton Cerf、Yogen Dalal 与 Carl Sunshine 三位作者。Cerf 在这里的身份明确而重要——他是这份技术规范的共同作者。这份署名记录 同时要求读者保留另外两位作者的位置。

共同署名并不意味着三个人的贡献恰好相等。它也没有提供一张逐条规则的分工表，说明谁提出了哪项设计、谁改写了哪些段落，或谁对争议拥有最后决定权。把全部成果归给 Cerf，超出了这项记录；反过来，因为无法计算个人份额就否认他的贡献，同样没有依据。

这里能够肯定的，是他参与形成了一份有具体技术内容的规范。要进一步评价个人作用，就应当追问：文档究竟规定了什么，又明确把哪些贡献记在了谁的名下？

进程、端口与套接字：贡献不是一个空泛标签

RFC 675 将网络通信视为进程之间的通信。按照它描述的方案，一个进程可以具有多个端口，用以区分与其他进程之间的通信流。为了形成唯一名称，文档提出把网络标识符、TCP 标识符和端口名称组合成一个套接字名称。这是规范中的命名安排，而不是从今天的网络术语反推出来的解释。

这套安排的意义，在于把“让进程通信”这个目标变成了需要明确回答的问题：通信流怎样区分，名称又由哪些部分组成？规定这些组成关系，使一个方案可以被具体讨论，也使实现者有了可据以工作的规则。这里的 TCP 标识符不应被悄悄改写成现代 IP 地址；1974 年这份文档的方案，也不应直接等同于今天完整的 TCP/IP 分层结构。

这提供了评价 Cerf 贡献的一条实在路径：他与 Dalal、Sunshine 共同署名的文档，不只是表达互联愿望，而是写下了通信对象与命名方式。然而，“规范写出了规则”与“某个人独自发明规则”仍是两种不同的判断。仅凭共同署名，不能把这一具体条款单独划到 Cerf 名下。

同样，写得足够明确不等于已经运行。命名规则能说明设计如何表达，不能单独证明软件实现了全部功能、实现之间已经互通，或网络运营者已选择采用。这不是贬低规范的价值，而是避免让一种成果替另一种成果作证。

致谢保留了署名之外的贡献

RFC 675 的致谢把三次握手与初始序列号选择的贡献记给了 R. Tomlinson，并提到 D. Belsnes、J. Burchfiel、M. Galland、R. Kahn、D. Lloyd、W. Plummer 和 J. Postel 对协议设计提供的想法与建议。这些明确的技术致谢 使贡献记录比三人的作者名单更丰富。

文档还感谢 R. Metcalfe、A. McKenzie、H. Zimmerman、G. LeLann 和 M. Elie，说明他们帮助澄清了早期设计工作中的问题。这部分致谢 同样应当保留，但不宜被扩写成材料没有交代的逐人决策故事。

两类记录应分别理解。作者名单确认共同作者；针对某项机制的致谢，说明文档如何承认相应贡献；较概括的感谢，则记录了讨论和建议的作用。它们不是一张完整的组织架构图，更不是可以直接换算成贡献百分比的账目。

因此，提及 Tomlinson 获得的具体致谢，不等于已经证明该机制只有他一位贡献者。列出更广泛的参与者，也不能据此认定他们对每条规则都有同等决定权。最稳妥的做法不是把所有人压缩为一个“团队”，而是保留文档所作的不同层次的归属：哪些人共同署名，哪些人得到具体技术致谢，哪些人被感谢提供想法或澄清问题。

设计希望提供什么，不等于代码已经提供什么

互联网协会的《互联网简史》从另一个角度呈现了这条边界。按照该历史回顾的描述，Cerf 与 Bob Kahn 希望 TCP 支持一系列服务：一端是可靠、有序的交付，另一端是数据报服务，使应用能够利用底层网络，即使数据可能丢失、损坏或改变顺序。这是该回顾对设计意图的叙述，不应被写成对两人私人动机的独立判定。

同一篇回顾指出，初始 TCP 实现只支持虚电路，适用于文件传输和远程登录，却不那么适合较高级的网络应用。它对初始实现的描述 说明，预期服务范围与已经实现的服务范围需要分别核对。

这项对比很有解释力，但也有边界。仅凭这里的描述，不能确定是哪支实现团队在何时作出了什么取舍，更不能把实现范围较窄归结为 Cerf 的单方面决定。它也不足以重建后续修改的完整过程，或证明某一次批评直接引发了某个人的架构调整。

本文讨论的两份材料承担着不同任务。RFC 675 提供一份当时的规范及其贡献记录；互联网协会的历史回顾提供设计意图与初始实现之间的对比。把二者放在一起，可以更准确地提出归属问题，却不能用后来的回顾填补文档没有写出的个人分工。

对 Cerf 的肯定，应当具体而有边界

这里可以给予 Cerf 明确的肯定：他是 RFC 675 的共同作者，这份规范提出了可供讨论和实现的具体规则。与此同时，Dalal、Sunshine 与受到致谢的人，不应在叙述中消失。

证据支持的是参与一项明确技术成果，而不是由此自动获得对全部实现、采用和网络发展结果的个人归属。若要判断某项具体选择由谁决定，需要更细的决策记录；若要判断谁完成了实现或促成采用，需要另外的实现和部署证据。把这些问题拆开，才能既不削弱已留下记录的贡献，也不让人物声望承担它无法完成的证明任务。