摘要

  • Abhay Bhushan 早期设计的 FTP 统一的是跨主机操作，而不是强迫所有主机采用同一种文件系统。
  • 从主机问卷到 1972 年研讨会，设计过程先暴露真实能力与分歧，再决定哪些内容进入共同协议。
  • 服务器明确说明“不支持”，往往比悄悄接受并改变语义更有利于互操作；路径名正是本地权力仍然存在的边界。

一串路径名背后的主机

路径名从来不只是字符。它携带着一台机器对存储的理解：目录是否分层，账户如何写入名称，版本是否属于文件标识，省略部分会采用什么默认值，以及谁有权读取。今天许多约定已经变得熟悉，人们容易把它们误认为网络天然拥有的语法。1971 年的 ARPANET 没有这种幻觉。

这也是 Abhay Bhushan 工作中最值得重看的部分。他并非只为后来被称为 FTP 的协议列出命令，而是在彼此陌生的操作系统之间划定一条可以合作的线。线的一侧是能够共同理解的动作；另一侧是远端主机仍然掌握的命名、权限和内部结构。协议越过网络，却没有冒充每个站点的文件系统管理员。

Internet Hall of Fame 的人物资料将 Abhay Bhushan 记为最初 FTP 规范的作者，并称他在 1967 至 1974 年间任职于 MIT Project MAC，撰写了二十多份 RFC。这些履历可以说明他的角色范围，而早期文件则显示出具体工作方式：他既写协议，也收集需求、组织讨论，还把未解决的意见分歧如实写进记录。

“第一刀”之后先做调查

1971 年 4 月的 RFC 114 同时设想了直接和间接两种远程使用方式。用户可以亲自面对远端系统，也可以通过一个中间进程，由后者遮蔽部分远端命令与习惯。后一种方式已经指向统一界面的价值，但 Bhushan 仍把这份方案称作初步尝试。下一步不是宣布问题解决，而是调查网络主机的需求与能力。

这个先后顺序十分关键。效率、可扩展性、适应性、错误恢复，以及不依附于某一个应用，都是设计目标；但目标不能替代主机事实。协议团队没有先画出一套完美抽象，再把所有现存系统标为偏差，而是先问：这些机器究竟能做什么，它们之间哪些差异可以被接口吸收？

RFC 180 把这种态度变成一份文件系统问卷。文中明确说，当时的小组没有打算统一命名约定和访问控制约定。用户访问远端主机，仍需了解远端的命名方式。应 Bhushan 的请求，Alex McKenzie 向各主机代表征集资料，问题涉及合法文件名、默认值、目录操作、访问限制、文件表示和系统功能。

问卷看起来不像协议，却承担着协议设计最难的一环：把本地人习以为常、外部人看不见的假设暴露出来。只有差异能够比较，团队才可能判断哪些应成为共同基线，哪些需要协商，哪些只能由服务器明确拒绝。

一场允许“不达成共识”的研讨会

进入 1972 年，RFC 309 发出数据与文件传输研讨会邀请，向参与者征求立场文件，并安排工作会议依据当下和预期需求修订协议。Bhushan 要做的不是让小圈子为成稿盖章，而是让不同应用、不同主机把初稿遗漏的压力带进现场。

RFC 327 的会议记录之所以重要，恰恰因为它没有把讨论改写成一路胜利。与会者研究过“网络虚拟文件映像”，希望用共同概念承载更多文件结构，但没有形成一致意见，于是暂时放弃。记录保留下来的目标更克制：维护数据完整性，说明字符如何表示和解释，在方便可行的范围内保存结构信息，并把更完整的虚拟文件系统留作长期方向。

会议也作出可以执行的决定：命令应当可打印；控制连接与数据连接分开；一组基本表示类型必须具备；服务器若不能接收请求的文件结构，就应拒绝并通知用户。Bhushan 负责整理记录和继续起草。

没有通过的虚拟方案并非需要掩盖的失败。它恰好界定了现实共识的外沿。协议因此可以先交付可靠的较小承诺，而不必把一个仍有争议的文件本体伪装成全网标准。

共同的动词，本地的名词

RFC 171 将通用数据传输机制与具体应用功能分开，目的是减少为每个应用重复造传输系统。RFC 172 则把承诺限定为“在实际可行范围内”遮蔽主机差异，允许实现协议子集，也允许相互同意的各方扩展；路径名的命名仍由站点决定。

于是，共同接口可以统一“取回”“存入”“列出”这样的动词，也可以协商表示、结构和传输模式。动词所指向的名词却属于远端：它可能包含某种目录分隔方式、账户前缀、代数编号，或者只有该主机才理解的默认规则。协议同样不能取代站点关于谁能触及这个对象的决定。

1972 年的 RFC 354 将这种有限互通写得更具体。控制会话选择表示、类型和模式。服务器不必接受所有组合或所有字节尺寸，但必须把不支持的情况告诉用户。“不行”因此也成为可供软件处理的协议信息。

明确拒绝并不削弱互操作。客户端知道原因，就能改变请求、选择别的表示，或把有意义的错误交给使用者。相反，服务器若表面接受、暗中转换，文件可能在“成功”之后丢失结构或改变含义。边界可见，本身就是可靠性的一部分。

统一接口为何需要停止

1985 年的 RFC 959 记录了 FTP 多年演进后的成熟形态，不能倒过来证明 1971 或 1972 年已经确定了后来的全部设计。早期材料最有价值的地方正是它的时间顺序：初稿、调查、公开研讨、缩小承诺、再修订。成熟来自持续判断，而非一次性发明。

这种方法让高度不同的主机不必先放弃内部模型，就能开始交换数据。代价也真实存在：客户端需要掌握远端命名习惯，能力组合不断增加，扩展逐渐变成兼容负担。但若先追求完整的全网文件系统，结果可能是迟迟无法部署，或把少数强势主机的习惯冻结成所谓普遍规则。

路径名因此成了最清楚的界标。网络可以携带一个动作，目标主机仍决定对象叫什么、如何解释以及谁能访问。Abhay Bhushan 的设计价值不在于消灭这条边界，而在于让所有参与者知道它在哪里。真正耐用的标准，不仅要说明共同部分，还要准确交代它不替谁作主。

资料来源