摘要

  • RFC 1 划分了问题边界：BBN 负责规定 Interface Message Processor（IMP）的软件，接入网络的主机团队则需要就各自计算机如何使用网络达成协议。
  • Steve Crocker 把内容称为暂定方案并期待反馈。RFC 3 随后解释，读者容易把书面发布的文字当成权威决定；RFC 系列正是要为尚未定型的想法留出讨论空间。
  • RFC 6 中的修改、RFC 11 所述 UCLA GORDO 实现，以及 RFC 33 记录的后续调整，共同呈现了一个持续推进的过程，却无法证明所有主机都未经修改地采用了 RFC 1。

分组网络之上，仍缺一套主机间约定

ARPA Network 的早期设计有一条明确的技术边界。Bolt, Beranek and Newman 规定了 IMP 的软件，由这些机器在站点之间转发消息。连接在 IMP 上的计算机还需要彼此理解的软件约定，才能建立连接、分配逻辑链路，并决定远端主机如何处理收到的数据。

Steve Crocker 于 1969 年 4 月 7 日发表的 RFC 1，试图把这个主机到主机的问题放进一份共同文件。它概述了 IMP 消息格式，并讨论主机软件可能需要的功能：连接请求、类似电传打字机的会话、大文件传输、错误检查和交互式操作。它还提出一种本地前端设想，让终端的即时响应尽可能在用户附近处理，而不是把每次按键都送过网络。

这不是一个由单一决定覆盖所有层次的问题。IMP 的转发方式和主机操作系统的软件行为，涉及不同的责任和故障模式。消息抵达目标 IMP，并不意味着两台主机已经知道如何建立会话或解释对方的下一条消息。

Crocker 在引言中并未掩饰这种不确定性：小组形成了一些暂定协议，也遇到尚未解决的问题；文中很少有内容已经定论。这份文件的重要性之一，恰恰在于保留了问题尚未收束时的状态。若把它读成完整规格，便会抹去它真正记录的工作阶段。

第一份备忘录究竟提出了什么

RFC 1 把主机通信描述为成对主机之间的逻辑链路。它设想留出一条链路供操作系统间控制使用，其余链路用于用户会话。一种连接可以模拟拨号电传终端；另一条并行的文件式连接，则可承载更大数据量，并避开面向终端的缓冲和中断处理方式。

文件还试图处理远程交互中的时延问题。一个设想是把小型本地前端程序送到用户所在一端，以当时称为 DEL 的语言描述终端如何响应，从而在本地处理常规交互。作者说明相关规格仍在讨论中，因此这并非已经部署到所有网络主机的能力。

最初实验的描述同样有边界。Crocker 记录了 SRI 对检索系统和 DEL 前端的修改工作，以及 UCLA、Utah 使用 NLS 的计划。这些记录能说明参与者在尝试建设什么，却不是逐站点的安装台账，也不能证明最初四台主机都实现了全部提议。

所以，第一份 RFC 并非标准组织下发的命令。它更像共同讨论的载体：把设计选项摆出来，邀请他人纠正，也让分布在不同地点的工程师围绕同一份材料交换意见。

编号让异议和修订更容易留下记录

RFC 1 两天后，Bill Duvall 写下了 RFC 2，标题同样是“Host Software”。RFC 3 接着说明了早期文档约定：任何站点的任何人都可以提交备忘录；及时性比润色更重要；标题不要求唯一。RFC 编号由 SRI 的 Bill Duvall 分配。

RFC 3 还点出一个至今仍常见的治理难题：读者容易因为一句话已经写成并公开发布，就把它视为权威。早期宽松的格式，反而希望促成尚未具备权威性的观点之间的交流。编号解决的是如何找到一份备忘录，不是如何裁定它提出的问题。

这并不是一个缩小版的成熟标准制定流程。早期 RFC 混合了建议、问题、实现细节和征求回复的请求。它们共同的价值，在于让不同站点之间的技术推理变得可见；这些站点需要互操作，却仍各自运行不同的计算机和操作系统。

修订与实现，是两类不同的证据

Crocker 于 4 月 10 日整理的 RFC 6，记下了与 Bob Kahn 交谈后对 Host–IMP 链路字段的修改：字段变为五位，并增设一位表示转换。细节虽然不大，时间顺序却很说明问题。RFC 1 发表几天后，其中一个设计点仍在讨论和调整。

同年 8 月，Gerard Deloche 的 RFC 11 说明了主机间过程，以及这些过程在 UCLA 的 SDS Sigma 7 分时系统 GORDO 中如何实现。文件描述了连接类型、控制消息、校验和、缓冲区，以及在用户与 IMP 接口之间传递消息的程序。也是在 8 月，RFC 13 引用 RFC 11，并提出用零长度消息标示辅助连接上的文件传输结束。

这些记录表明，想法在一个明确命名的实现中变得具体，随后又引出针对具体需求的提议。它们没有证明所有主机都采用 GORDO 的过程，也没有表明网络从此停止变化。一个本地实现比一份抽象提案更能证明该站点确实运行过某种方案，但仍无法提供全网采用比例。

RFC 33 把这一区别写得很清楚。1970 年 2 月，它指出，相比 RFC 11，主机间协议已经发生许多变化；这些变化来自前一年 12 月的网络会议。RFC 33 还坦言，随附文稿的信息不足以据此编写 Network Control Program，并继续征求反馈。此时网络已具备可用连接并开始承担真实使用，但主机协议仍处于修改和文档化过程中。

RFC 1 的历史意义，不是它说了最后一句

RFC 1 的历史价值，不在于每个字段或操作步骤都永久保留下来，而在于它让一个跨主机的共同设计问题能够被讨论，而当时所有主机尚未拥有统一而成熟的实现。它指出责任范围、提出可选方案，也把不确定之处留在纸面上。

这种成绩不同于协议部署。一份文件可以定义共同问题；后续修改可以收窄分歧；代码可以证明某个系统能运行；反复的互通测试才能说明彼此独立的系统对消息有兼容理解。这些环节前后相连，但一个环节不能自动替下一个环节作证。

早期档案因此支持一种更精确的协调史。BBN 规定 IMP 这一层，主机团队处理其上的软件问题，RFC 提供可编号、可携带的讨论空间。后续实现和备忘录，才记录了哪些方案被尝试、又在哪里修改。第一个编号开启了过程，却没有替过程画上句号。

来源

RFC 1 是 Crocker 暂定主机软件提案的原始来源。RFC 2 收录 Bill Duvall 的“Host Software”备忘录，RFC 3 说明最初的文档约定。Crocker 的 RFC 6 记录其后一次 Host–IMP 讨论。Deloche 的 RFC 11 讲述 GORDO 的过程和实现；Cerf 的 RFC 13 提出辅助传输的文件结束标记。Crocker 等人的 RFC 33 记录后续变化和仍未解决的问题。1971 年的 RFC 170 索引 则列出早期备忘录及其日期。