摘要

  • 请远端主机传来文件，是搬运信息；请它运行程序，则是让另一台机器采取动作。RFC 114 曾在同一提案里探索这两种请求。
  • RFC 171 和 RFC 172 随后把通用数据传输与 FTP 文件命令分开；RFC 172 将远程执行留作可能的扩展，没有规定标准流程。

不妨想象给远端电脑发两种请求：把文件传来；运行这个程序并把结果返回。前者传递信息，后者触发另一台机器上的工作。若把两者放进一个协议，就得回答更大的问题：由哪一层定义这个动作？不同主机又该如何约定参数与结果？RFC 114 给出了一种有限尝试，后续文件则划出了不同边界。

RFC 114 所说的“文件”不只是等待复制的文档。提案页眉标注日期为 1971 年 4 月 16 日，RFC Editor 目录则记为 4 月 1 日；它描述的是协作进程如何通过事务使用另一台主机的文件系统。操作包括识别、取回、存储、追加、改名、删除、打开、关闭和查找，也包括 execute。

这并不是通用远程 Shell。RFC 114 描述的过程是发送输入，在服务主机上运行程序或子程序，再把输出返回。它也限制了这项设想：调用方进程必须知道参数与响应的约定。协议勾勒的是围绕程序文件的一次受控交互，并没有定义万能命令行，也没有给出安全模型。

提案所指向的实现环境具体而有限。RFC 114 说，该协议是为 MIT 的两台主机立即实现而开发的：GE 645/Multics 与 PDP-10/DM/CG-ITS，可能还包括哈佛的一台主机。当时，一个能力受限的临时版本正在调试。这能证明有一项特定的实现工作，却不能证明列出的每种事务都已可用，更不能说明协议已在网络中普及。

随后发布的设计文件把边界说得更清楚。1971 年 6 月的 RFC 171 提出一个可供多类应用共用的数据传输协议，包括文件传输、远程作业输入、网络邮件、图形和远程程序执行。其架构论点是：把传输功能与应用功能分开，可以让实现更灵活、降低复杂度，也减少协议数量不断膨胀。

配套的 RFC 172 定义了文件传输协议：由它使用 RFC 171 的 DTP 搬运数据，再在 FTP 应用中定义文件操作。各主机可以只实现部分命令。RFC 172 也说 FTP 可以扩展为支持远程程序执行，但没有建议一套标准流程。换言之，远程执行仍是一种可能性，却没有被纳入标准 FTP 操作程序。

这一差别很关键：规范把某项操作写进范围，不等于它已成为不同实现之间可靠、普遍的服务。同期的 RFC 141 评论讨论本地文件访问、命令子集，以及执行一个作业可能需要长时间等待。它们反映的是设计者正在追问的问题，不是使用情况普查。后来 FTP 的修订记录可以说明规范如何演进，却不能证明 RFC 114 的 execute 已经广泛使用。

更长远的变化在于概念划分。文件移动与承载数据的机制可以共用；远端应用如何处理这些数据，则是另一项决定。早期提案把两者靠得很近，试图一并探索；到 6 月，文件将可复用的传输层与特定应用的命令集区分得更明确。远程执行于是留作可能的扩展，而不是 FTP 的标准动作。

应把这段历史理解为规范范围的变化，而不是“危险功能先大规模部署、后来被移除”的故事。RFC 114 记录了一份雄心较大的初稿和有限的临时实现；RFC 171/172 记录了更清晰的职责划分。文献能说明作者选择写下了什么，却不能单独证明普及程度、实际运行安全，或每台主机的具体行为。

来源