RFC959：FILE TRANSFER PROTOCOL (FTP)，October 1985
本备忘录的状态
本备忘录是文件传输协议 (File Transfer Protocol，FTP) 的官方规范。本备忘录的分发不受限制。
此版本的规范中包含以下新的可选命令：
CDUP（Change to Parent Directory，更改到父目录）、SMNT（Structure Mount，结构挂载）、STOU（Store Unique，唯一存储）、RMD（Remove Directory，删除目录）、MKD（Make Directory，制作目录）、PWD（Print Directory，打印目录）和 SYST（System，系统）。
请注意，此规范与以前的版本兼容。
1、 介绍
FTP 的目标是：
1) 促进文件（计算机程序和/或数据）的共享，
2) 鼓励间接或隐式（通过程序）使用远程计算机，
3) 保护用户免受文件存储系统的变化影响主机，以及
4) 可靠、高效地传输数据。 FTP 虽然可由用户在终端直接使用，但主要设计为供程序使用。
本规范的尝试是通过简单、易于实现的协议设计来满足maxi-hosts、mini-hosts、个人工作站和TACs用户的多样化需求。
本文假设您了解传输控制协议 (Transmission Control Protocol，TCP) [2] 和 Telnet 协议 [TELNET协议规范]。这些文档包含在 ARPA-Internet 协议手册 [1] 中。
2、 概述
在本节中，将讨论历史、术语和 FTP 模型。本节中定义的术语只是那些在 FTP 中具有特殊意义的术语。某些术语非常特定于 FTP 模型；一些读者可能希望在查看术语时转向有关 FTP 模型的部分。
2.1、 历史
多年来，FTP 经历了漫长的发展。附录3 是与 FTP 相关的征求意见文档的时间顺序汇编。其中包括 1971 年首次提出的文件传输机制，该机制是为在麻省理工学院的主机上实现而开发的。（RFC 114），以及 RFC 141 中的评论和讨论。
RFC 172 为主机（包括终端 IMP）之间的文件传输提供了一个面向用户的协议。将此修订为 RFC 265，重申 FTP 以进行额外审查，而 RFC 281 建议进一步更改。 1982 年 1 月在 RFC 294 中提议使用“设置数据类型”事务。
RFC 354 废弃了 RFC 264 和 265。文件传输协议现在被定义为 ARPANET 上主机之间文件传输的协议，FTP 的主要功能定义为在主机之间高效可靠地传输文件，并允许方便地使用远程文件存储能力。 RFC 385 进一步评论了错误、重点和协议的补充，而 RFC 414 提供了关于工作服务器和用户 FTP 的状态报告。 1973 年发布的 RFC 430（在其他 RFC 中不胜枚举）对 FTP 提出了进一步的评论。最后，一个“官方”的 FTP 文档被发布为 RFC 454。
到 1973 年 7 月，与 FTP 的最后一个版本相比，发生了相当大的变化，但总体结构保持不变。 RFC 542 作为新的“官方”规范发布以反映这些更改。但是，许多基于旧规范的实现并未更新。
1974 年，RFC 607 和 614 继续对 FTP 进行评论。 RFC 624 提出了进一步的设计更改和小的修改。 1975 年，名为“Leaving Well Enough Alone”的 RFC 686 讨论了所有早期和晚期 FTP 版本之间的差异。 RFC 691 提出了 RFC 686 的小修订版，涉及打印文件的主题。
在从 NCP 过渡到作为底层协议的 TCP 的推动下，在 RFC 765 作为用于 TCP 的 FTP 规范的所有上述努力中诞生了凤凰。
FTP 规范的当前版本旨在更正一些小的文档错误，改进对某些协议功能的解释，并添加一些新的可选命令。
特别是，此版本的规范中包含了以下新的可选命令：
CDUP - Change to Parent Directory，更改为父目录
SMNT - Structure Mount，结构挂载
STOU - Store Unique，唯一存储
RMD - Remove Directory，删除目录
MKD - Make Directory，制作目录
PWD - Print Directory，打印目录
SYST – System，系统
该规范与以前的版本兼容。符合先前规范的程序应该自动符合本规范。
2.2、 术语
ASCII
ASCII 字符集在 ARPA-Internet 协议手册中定义。在 FTP 中，ASCII 字符被定义为八位代码集的下半部分（即最高有效位为零）。
访问控制
访问控制（access controls）定义了用户对系统使用和该系统中文件的访问权限。访问控制是必要的，以防止未经授权或意外使用文件。调用访问控制是服务器 FTP 进程的特权。
字节大小
FTP 中有两种感兴趣的字节大小（byte size）：文件的逻辑字节大小和用于传输数据的传输字节大小。传输字节大小始终为 8 位。传输字节大小不一定是系统中要存储数据的字节大小，也不一定是用于解释数据结构的逻辑字节大小。
控制连接
USER-PI 和 SERVER-PI 之间用于交换命令和回复的通信路径。此连接遵循 Telnet 协议。
数据连接
以指定的模式和类型传输数据的全双工连接。传输的数据可以是文件的一部分、整个文件或多个文件。该路径可以在服务器-DTP 和用户-DTP 之间，或在两个服务器-DTP 之间。
数据端口
被动数据传输过程在数据端口（data port）上“侦听”来自主动传输过程的连接，以便打开数据连接。
DTP
数据传输过程（data transfer process）建立和管理数据连接。 DTP 可以是被动的或主动的。
end-of-file
行尾（end-of-file）顺序定义了打印行的分隔。顺序是回车，然后是换行。
EOF
文件结束条件，用于定义正在传输的文件的结尾。
EOR
记录结束（end-of-record）条件，定义正在传输的记录的结束。
错误恢复
允许用户从某些错误中恢复的过程，例如主机系统或传输过程的故障。在 FTP 中，错误恢复（error recovery）可能涉及在给定检查点重新启动文件传输。
FTP命令
一组命令，包含从用户 FTP 流向服务器 FTP 进程的控制信息。
文件
一组任意长度的有序计算机数据（包括程序），由路径名唯一标识。
模式
通过数据连接传输数据的模式（mode）。该模式定义了传输过程中的数据格式，包括 EOR 和 EOF。 FTP 中定义的传输模式在传输模式部分中描述。
NVT
Telnet 协议中定义的网络虚拟终端（Network Virtual Terminal）。
NVFS
网络虚拟文件系统（Network Virtual File System）。使用标准命令和路径名约定定义标准网络文件系统的概念。
页
一个文件可以被构造为一组称为页面（page）的独立部分。 FTP 支持将不连续文件作为独立索引页面进行传输。
路径名
路径名（pathname）被定义为必须由用户输入文件系统以识别文件的字符串。路径名通常包含设备和/或目录名称，以及文件名规范。 FTP 尚未指定标准路径名约定。每个用户都必须遵循传输中涉及的文件系统的文件命名约定。
PI
协议解释器（protocol interpreter）。协议的用户端和服务器端在用户 PI 和服务器 PI 中实现了不同的角色。
记录
一个顺序文件可以被构造为许多称为记录（record）的连续部分。 FTP 支持记录结构，但文件不需要具有记录结构。
回复
回复（reply）是响应 FTP 命令从服务器通过控制连接发送给用户的确认（肯定或否定）。回复的一般形式是完成代码（包括错误代码）后跟文本字符串。代码供程序使用，文本通常供人类用户使用。
服务器-DTP
数据传输过程在其正常的“活动”状态下，与“侦听”数据端口建立数据连接。它设置传输和存储参数，并根据来自其 PI 的命令传输数据。 DTP 可以置于“被动”状态以进行侦听，而不是在数据端口上发起连接。
服务器-FTP进程
一个进程或一组进程，与用户 FTP 进程以及可能的另一个服务器协作执行文件传输功能。这些功能包括协议解释器 (protocol interpreter，PI) 和数据传输过程 (data transfer process，DTP)。
服务器PI
服务器协议解释器（protocol interpreter）在端口 L 上“侦听”来自用户 PI 的连接并建立控制通信连接。它从用户 PI 接收标准 FTP 命令，发送回复，并管理服务器 DTP。
类型
用于数据传输和存储的数据表示类型（type）。类型意味着数据存储时间和数据传输时间之间的某些转换。 FTP 中定义的表示类型在“建立数据连接”部分中描述。
用户
希望获得文件传输服务的个人或代表个人的进程。人类用户（user）可以直接与服务器 FTP 进程交互，但首选使用用户 FTP 进程，因为协议设计侧重于自动机。
用户-DTP
数据传输进程在数据端口上“侦听”来自服务器 FTP 进程的连接。如果两台服务器在它们之间传输数据，则用户 DTP 处于非活动状态。
用户FTP进程
一组功能，包括协议解释器、数据传输过程和用户界面，它们与一个或多个服务器-FTP 过程共同执行文件传输功能。用户界面允许在与用户的命令-回复对话中使用本地语言。
用户PI
用户协议解释器启动从它的端口 U 到服务器 FTP 进程的控制连接，启动 FTP 命令，并在该进程是文件传输的一部分时管理用户 DTP。
2.3、 FTP模型
考虑到上述定义，可以为 FTP 服务绘制以下模型（如图 1 所示）。
图 1 FTP 使用模型
注意： 1. 数据连接可用于任一方向。
2. 数据连接不必一直存在。
在图 1 描述的模型中，用户协议解释器启动控制连接。控制连接遵循 Telnet 协议。在用户启动时，标准的 FTP 命令由用户 PI 生成并通过控制连接传输到服务器进程。 （用户可以建立到服务器-FTP 的直接控制连接，例如从 TAC 终端，并独立生成标准 FTP 命令，绕过用户-FTP 过程。）标准回复从服务器-PI 发送到用户- PI 通过控制连接响应命令。
FTP 命令指定数据连接的参数（数据端口、传输模式、表示类型和结构）和文件系统操作的性质（存储、检索、追加、删除等）。用户-DTP 或其指定者应“监听”指定的数据端口，服务器根据指定的参数发起数据连接和数据传输。需要注意的是，数据端口不必在通过控制连接发起 FTP 命令的同一台主机上，但用户或用户 FTP 进程必须确保在指定的数据端口上“监听”。还应注意，数据连接可用于同时发送和接收。
在另一种情况下，用户可能希望在两个主机之间传输文件，这两个主机都不是本地主机。用户建立到两台服务器的控制连接，然后安排它们之间的数据连接。以这种方式，控制信息被传递给用户 PI，但数据在服务器数据传输过程之间传输。以下是此服务器-服务器交互的模型。
图2
该协议要求在进行数据传输时打开控制连接。用户有责任在使用完 FTP 服务后请求关闭控制连接，而采取行动的是服务器。如果在没有命令的情况下关闭控制连接，服务器可能会中止数据传输。
FTP和Telnet的关系：
FTP 在控制连接上使用 Telnet 协议。这可以通过两种方式实现：
第一，用户PI或服务器PI可以直接在自己的程序中实现Telnet协议的规则；或者，第二，用户PI或服务器PI可以利用系统中现有的Telnet模块。
易于实现、共享代码和模块化编程支持第二种方法。效率和独立性支持第一种方法。实际上，FTP 对 Telnet 协议的依赖很少，因此第一种方法不一定涉及大量代码。
3、 数据传输功能
文件仅通过数据连接传输。控制连接用于传输命令，这些命令描述了要执行的功能以及对这些命令的回复（参见 FTP 回复部分）。几个命令与主机之间的数据传输有关。这些数据传输命令包括指定如何传输数据位的 MODE 命令，以及用于定义数据表示方式的 STRUcture 和 TYPE 命令。传输和表示基本独立，但“Stream”传输模式取决于文件结构属性，如果使用“压缩”传输模式，则填充字节的性质取决于表示类型。
3.1、 数据表示和存储
数据从发送主机中的存储设备传输到接收主机中的存储设备。通常需要对数据执行某些转换，因为两个系统中的数据存储表示不同。例如，NVT-ASCII 在不同的系统中有不同的数据存储表示。 DEC TOPS-20s 通常将 NVT-ASCII 存储为五个 7 位 ASCII 字符，在 36 位字中左对齐。 IBM 大型机将 NVT-ASCII 存储为 8 位 EBCDIC 代码。 Multics 将 NVT-ASCII 存储为 36 位字中的四个 9 位字符。在不同系统之间传输文本时，最好将字符转换为标准 NVT-ASCII 表示。发送站点和接收站点必须在标准表示与其内部表示之间执行必要的转换。
在具有不同字长的主机系统之间传输二进制数据（不是字符代码）时，会出现不同的表示问题。发送方应该如何发送数据以及接收方如何存储数据并不总是很清楚。例如，当将 32 位字节从 32 位字长系统传输到 36 位字长系统时，可能需要（出于效率和实用性的原因）将 32 位字节右对齐存储在后一种系统中的 36 位字中。在任何情况下，用户都应该可以选择指定数据表示和转换函数。应该注意的是，FTP 提供了非常有限的数据类型表示。超出此有限能力所需的转换应由用户直接执行。
3.1.1、 数据类型
数据表示由用户指定表示类型在 FTP 中处理。这种类型可以隐式（如在 ASCII 或 EBCDIC 中）或显式（如在本地字节中）定义用于解释的字节大小，称为“逻辑字节大小”。请注意，这与用于通过数据连接传输的字节大小无关，称为“传输字节大小”，不应将两者混淆。例如，NVT-ASCII 的逻辑字节大小为 8 位。如果类型是本地字节，则 TYPE 命令具有指定逻辑字节大小的强制性第二个参数。传输字节大小始终为 8 位。
3.1.1.1、 ASCII 类型
这是默认类型，必须被所有 FTP 实现接受。它主要用于传输文本文件，除非两个主机都发现 EBCDIC 类型更方便。
发送方将数据从内部字符表示转换为标准的 8 位 NVT-ASCII 表示（请参阅 Telnet 规范）。接收者将数据从标准格式转换为他自己的内部格式。
根据 NVT 标准， 序列应在必要时用于表示一行文本的结尾。 （请参阅数据表示和存储部分末尾的文件结构讨论。）
使用标准 NVT-ASCII 表示意味着数据必须被解释为 8 位字节。
下面讨论 ASCII 和 EBCDIC 类型的格式参数。
3.1.1.2、 EBCDIC 类型
此类型用于在使用 EBCDIC 作为其内部字符表示的主机之间进行有效传输。
对于传输，数据表示为 8 位 EBCDIC 字符。字符代码是 EBCDIC 和 ASCII 类型的功能规范之间的唯一区别。
出于表示结构的目的，行尾（与记录尾相反——参见结构的讨论）可能很少与 EBCDIC 类型一起使用，但在必要时应使用 字符。
3.1.1.3、 IMAGE类型
数据作为连续位发送，为了传输，这些位被打包成 8 位传输字节。接收站点必须将数据存储为连续位。存储系统的结构可能需要将文件（或每个记录，对于记录结构的文件）填充到某个方便的边界（字节、字或块）。这种填充必须全为零，只能出现在文件的末尾（或每条记录的末尾），并且必须有一种方法来识别填充位，以便在检索文件时可以将它们剥离。应该很好地宣传填充转换，以使用户能够在存储站点处理文件。
图像类型用于文件的高效存储和检索以及二进制数据的传输。建议所有 FTP 实现都接受此类型。
3.1.1.4、 LOCAL类型
数据以逻辑字节传输，其大小由强制性的第二个参数字节大小指定。 Byte size 的值必须是十进制整数；没有默认值。逻辑字节大小不一定与传输字节大小相同。如果字节大小不同，则逻辑字节应连续打包，不考虑传输字节边界并在末尾添加任何必要的填充。
当数据到达接收主机时，它将以依赖于逻辑字节大小和特定主机的方式进行转换。这种转换必须是可逆的（即，如果使用相同的参数，则可以检索到相同的文件）并且应该由 FTP 实现者很好地宣传。
例如，用户向具有 32 位字的主机发送 36 位浮点数可以将该数据作为逻辑字节大小为 36 的本地字节发送。然后接收主机将需要存储逻辑字节，以便他们可以很容易地被操纵；在本例中，将 36 位逻辑字节放入 64 位双字就足够了。
在另一个例子中，一对 36 位字长的主机可以使用 TYPE L 36 以字的形式相互发送数据。 数据将以 8 位传输字节打包发送，以便 9 个传输字节携带两个主机字。
3.1.1.5、 格式控制
ASCII 和 EBCDIC 类型也采用第二个（可选）参数；这是为了指示哪种垂直格式控件（如果有）与文件相关联。 FTP 中定义了以下数据表示类型：
字符文件可以出于以下三个目的之一传输到主机：用于打印、存储和以后检索，或用于处理。如果发送文件进行打印，接收主机必须知道垂直格式控件是如何表示的。在第二种情况下，必须可以将文件存储在主机上，然后以完全相同的形式检索它。最后，应该可以将文件从一台主机移动到另一台主机并在第二台主机上处理该文件而不会出现不必要的麻烦。单一的 ASCII 或 EBCDIC 格式不能满足所有这些条件。因此，这些类型具有指定以下三种格式之一的第二个参数：
3.1.1.5.1、 NON PRINT
如果省略第二个（格式）参数，这是要使用的默认格式。所有 FTP 实现都必须接受非输出格式。
该文件不需要包含垂直格式信息。如果将其传递给输出进程，则该进程可能会假定间距和边距的标准值。
通常，这种格式将用于处理或仅用于存储的文件。
3.1.1.5.2、 Telnet 格式控制
该文件包含 ASCII/EBCDIC 垂直格式控件（即 、、、、），输出进程将对其进行适当解释。 ，在这个序列中，也表示行尾。
3.1.1.5.3、 传输控制 (ASA)
该文件包含 ASA (FORTRAN) 垂直格式控制字符。 （参见 RFC 740 附录 C；和 ACM 通信，第 7 卷，第 10 期，第 606 页，1964 年 10 月。）在根据 ASA 标准格式化的行或记录中，第一个字符不打印.相反，它应该用于确定在打印记录的其余部分之前应该发生的纸张的垂直移动。
ASA 标准规定了以下控制字符：
显然，输出进程必须有某种方式来区分结构实体的结尾。如果文件有记录结构（见下文），这没问题；记录将在传输和存储过程中明确标记。如果文件没有记录结构， 行尾序列用于分隔打印行，但这些格式效应器会被 ASA 控件覆盖。
3.1.2、 数据结构
除了不同的表示类型外，FTP 还允许指定文件的结构。 FTP中定义了三种文件结构：
文件结构，这里没有内部结构，文件被认为是一个连续的数据字节序列，
记录结构，其中文件由顺序记录组成，
和页面结构，其中文件由独立的索引页面组成。
如果未使用 STRUcture 命令，则默认采用文件结构，但所有 FTP 实现都必须接受“文本”文件（即具有 TYPE ASCII 或 EBCDIC 的文件）的文件和记录结构。文件的结构将影响文件的传输模式（参见传输模式部分）以及文件的解释和存储。
文件的“自然”结构将取决于存储文件的主机。源代码文件通常以固定长度记录的形式存储在 IBM 大型机上，但在 DEC TOPS-20 上作为分隔为行的字符流（例如通过 ）存储。如果要在此类不同站点之间传输文件有用，则一个站点必须有某种方式来识别另一个站点对文件的假设。
由于一些站点天生面向文件，而另一些网站天生面向记录，如果将具有一种结构的文件发送到面向另一种结构的主机，则可能会出现问题。如果将带有记录结构的文本文件发送到面向文件的主机，则该主机应根据记录结构对文件应用内部转换。显然，这种转换应该是有用的，但它也必须是可逆的，以便可以使用记录结构检索相同的文件。
在将具有文件结构的文件发送到面向记录的主机的情况下，存在主机应使用什么标准将文件划分为可在本地处理的记录的问题。如果此划分是必要的，则 FTP 实现应使用行尾序列， 用于 ASCII，或 用于 EBCDIC 文本文件，作为分隔符。如果 FTP 实现采用此技术，则必须准备好在使用文件结构检索文件时反转转换。
3.1.2.1、 DATA结构
如果未使用 STRUCture 命令，则默认采用文件结构（DATA STRUCTURES）。
在文件结构中，没有内部结构，文件被认为是一个连续的数据字节序列。
3.1.2.2、 记录结构
所有 FTP 实现都必须接受“文本”文件（即具有 TYPE ASCII 或 EBCDIC 的文件）的记录结构（RECORD STRUCTURE）。
在记录结构中，文件由顺序记录组成。
3.1.2.3、 页面结构
为了传输不连续的文件，FTP 定义了页面结构。这种类型的文件有时被称为“随机访问文件/random access files”，甚至被称为“多孔文件/holey files”。在这些文件中，有时还有与整个文件相关联的其他信息（例如，文件描述符），或与文件的一部分（例如，页面访问控制），或两者都有。在 FTP 中，文件的部分称为页面。
为了提供各种页面大小和相关信息，每个页面都带有一个页面标题。页眉具有以下定义的字段：
标题长度
页头中包含该字节的逻辑字节数。最小标题长度为 4。
页面索引
文件此部分的逻辑页码。这不是本页的传输序号，而是用于标识文件本页的索引。
数据长度
页数据中的逻辑字节数。最小数据长度为 0。
页面类型
这是页面的类型。定义了以下页面类型：
0 = 最后一页
这用于指示分页结构化传输的结束。头部长度必须为4，数据长度必须为0。
1 = 简单页面
这是没有页面级关联控制信息的简单分页文件的正常类型。标头长度必须为 4。
2 = 描述符页
该类型用于传输文件整体的描述信息。
3 = 访问控制页面
此类型包括带有页面级访问控制信息的分页文件的附加头字段。标头长度必须为 5。
可选字段
更多的报头字段可用于提供每页控制信息，例如每页访问控制。
所有字段的长度都是一个逻辑字节。逻辑字节大小由 TYPE 命令指定。有关更多详细信息和页面结构中的特定案例，请参阅附录1。
关于参数的注意事项：如果检索的版本与最初传输的版本相同，则必须使用相同的参数存储和检索文件。相反，如果用于存储和检索文件的参数相同，则 FTP 实现必须返回与原始文件相同的文件。
3.2、 建立数据连接
传输数据的机制包括建立到适当端口的数据连接和选择传输参数。用户和服务器 DTP 都有一个默认数据端口。用户进程默认数据端口与控制连接端口（即 U）相同。服务器进程默认数据端口是与控制连接端口（即 L-1）相邻的端口。
传输字节大小为 8 位字节。此字节大小仅与数据的实际传输相关；它与主机文件系统中的数据表示无关。
被动数据传输过程（这可能是用户 DTP 或第二个服务器 DTP）应在发送传输请求命令之前“侦听”数据端口。 FTP 请求命令确定数据传输的方向。服务器在收到传输请求后，将启动与端口的数据连接。建立连接后，DTP 之间的数据传输开始，服务器 PI 向用户 PI 发送确认回复。
每个 FTP 实现都必须支持使用默认数据端口，并且只有 USER-PI 可以发起对非默认端口的更改。
用户可以使用 PORT 命令指定备用数据端口。用户可能希望将文件转储到 TAC 行式输出或从第三方主机检索。在后一种情况下，用户 PI 与两个服务器 PI 建立控制连接。然后（通过 FTP 命令）告诉一台服务器“侦听”另一台将启动的连接。用户 PI 向一个服务器 PI 发送一个 PORT 命令，指示另一个服务器的数据端口。最后，两者都被发送适当的传输命令。在用户控制器和服务器之间发送的命令和回复的确切顺序在 FTP 回复部分定义。
通常，服务器负责维护数据连接——启动和关闭它。例外情况是当用户 DTP 以需要关闭连接以指示 EOF 的传输模式下发送数据时。服务器必须在以下条件下关闭数据连接：
1、服务器已经完成发送数据的传输模式，需要close表示EOF。
2、服务器收到用户的 ABORT 命令。
3、端口规格由用户的命令更改。
4、控制连接被合法或以其他方式关闭。
5、发生不可恢复的错误情况。
否则关闭是一个服务器选项，服务器必须仅通过 250 或 226 回复向用户进程指示执行该选项。
3.3、 数据连接管理
默认数据连接端口：所有 FTP 实现都必须支持使用默认数据连接端口，并且只有 User-PI 可以启动非默认端口的使用。
协商非默认数据端口：用户 PI 可以使用 PORT 命令指定非默认用户端数据端口。 User-PI 可以通过 PASV 命令请求服务器端识别一个非默认的服务器端数据端口。由于连接是由地址对定义的，这些操作中的任何一个都足以获得不同的数据连接，但仍然允许执行这两个命令以在数据连接的两端使用新端口。
数据连接的重用：当使用数据传输的流模式时，必须通过关闭连接来指示文件的结尾。如果要在会话中传输多个文件，这会导致问题，因为 TCP 需要将连接记录保留一段时间以保证可靠通信。因此无法立即重新打开连接。
这个问题有两种解决方案：第一个是协商一个非默认端口。二是使用另一种传输方式。
关于传输模式的评论。流传输模式本质上是不可靠的，因为人们无法确定连接是否过早关闭。其他传输模式（块、压缩）不会关闭连接以指示文件结束。它们具有足够的 FTP 编码，可以解析数据连接以确定文件的结尾。因此，使用这些模式可以让数据连接保持打开状态以进行多个文件传输。
3.4、 传输模式
传输数据的下一个考虑因素是选择合适的传输模式。共有三种模式：一种是格式化数据并允许重新启动程序；一种还压缩数据以实现高效传输；以及一种在很少或不进行处理的情况下传递数据的方法。在最后一种情况下，模式与结构属性交互以确定处理类型。在压缩模式下，表示类型决定了填充字节。
所有数据传输都必须以文件结束符 (EOF) 完成，该文件结束符可以通过关闭数据连接来明确说明或暗示。对于具有记录结构的文件，所有记录结束标记 (EOR) 都是明确的，包括最后一个。对于以页面结构传输的文件，使用“最后一页”页面类型。
注意：在本节的其余部分，字节表示“传输字节”，除非另有明确说明。
为了标准化传输的目的，发送主机将其内部的行尾或记录结束表示转换为传输模式和文件结构规定的表示，而接收主机将对其内部表示进行逆转换。 IBM 大型机记录计数字段在另一台主机上可能无法识别，因此记录结束信息可能在流模式下作为两字节控制代码传输，或者作为块或压缩模式描述符中的标志位传输。没有记录结构的 ASCII 或 EBCDIC 文件中的行尾应分别由 或 指示。由于这些转换意味着某些系统需要额外的工作，因此传输非记录结构化文本文件的相同系统可能希望使用二进制表示和流模式进行传输。
FTP中定义了以下传输模式：
3.4.1、 流模式
数据以字节流的形式传输。对使用的表示类型没有限制；记录结构是允许的。
在记录结构文件中，EOR 和 EOF 将分别由一个两字节的控制代码表示。控制代码的第一个字节全是 1，即转义字符。对于 EOR，第二个字节的低位将打开，其他位置为零，而 EOF 的第二个低位将打开；也就是说，该字节的 EOR 值为 1，EOF 值为 2。 EOR 和 EOF 可以通过打开两个低位（即值 3）在传输的最后一个字节上一起指示。如果打算将全 1 的一个字节作为数据发送，则应在控制代码的第二个字节中重复该字节。
如果结构是文件结构，EOF由发送主机关闭数据连接指示，所有字节都是数据字节。
3.4.2、 块模式
该文件作为一系列数据块传输，前面有一个或多个报头字节。头字节包含计数字段和描述符代码。计数字段以字节为单位指示数据块的总长度，从而标记下一个数据块的开始（没有填充位）。描述符代码定义：文件中的最后一个块 (EOF) 记录中的最后一个块 (EOR)、重新启动标记（请参阅错误恢复和重新启动部分）或可疑数据（即，正在传输的数据被怀疑有错误并且是不可靠的）。最后一个代码不是用于 FTP 中的错误控制。它的动机是交换某些类型的数据（例如地震或天气数据）的站点希望发送和接收所有数据，尽管本地错误（例如“磁带读取错误”），但在传输中表明某些部分是可疑的）。在这种模式下允许记录结构，并且可以使用任何表示类型。
头部由三个字节组成。头信息的24位中，低16位代表字节数，高8位代表描述符代码，如下所示。
区块头
描述符代码由描述符字节中的位标志指示。分配了四个代码，其中每个代码编号是字节中相应位的十进制值。
通过这种编码，对于特定块可能存在不止一个描述符编码条件。 可以标记尽可能多的位。
重新启动标记作为整数个 8 位字节嵌入数据流中，表示控制连接上使用的语言（例如，默认值--NVT-ASCII）中的可打印字符。 （空格，在适当的语言中）不得在重新启动标记内使用。
例如，要传输一个 6 个字符的标记，将发送以下内容：
3.4.3、 压缩模式
要发送的信息有三种：常规数据，以字节串形式发送； 压缩数据，包括复制或填充； 和控制信息，以两字节的转义序列发送。 如果发送了 n>0 个字节（最多 127 个）的常规数据，则这 n 个字节前面是一个字节，其中最左边的位设置为 0，最右边的 7 位包含数字 n。
字节串：
n 个数据字节的字符串 d(1),..., d(n)
计数 n 必须为正。
为了压缩数据字节 d 的 n 个复制的字符串，发送以下 2 个字节：
复制字节：
一串n个填充字节可以压缩成一个字节，填充字节随表示类型不同而不同。 如果类型为 ASCII 或 EBCDIC，则填充字节为 （空格，ASCII 代码 32，EBCDIC 代码 64）。 如果类型是图像或本地字节，则填充符为零字节。
填充字符串：
转义序列是一个双字节，第一个是转义字节（全为零），第二个包含块模式中定义的描述符代码。描述符代码与块模式中的含义相同，适用于后续的字节串。
压缩模式对于在非常大的网络传输中以一点额外的 CPU 成本获得增加的带宽很有用。它可以最有效地用于减小输出文件的大小，例如由 RJE 主机生成的文件。
3.5、 错误恢复和重启
没有检测数据传输中丢失或加扰的位的规定；这一级别的错误控制由 TCP 处理。但是，提供了重新启动程序来保护用户免受严重的系统故障（包括主机、FTP 进程或底层网络的故障）。
重启程序仅针对数据传输的块和压缩模式定义。它要求数据的发送方在带有一些标记信息的数据流中插入一个特殊的标记代码。标记信息仅对发送方有意义，但必须由控制连接的默认或协商语言（ASCII 或 EBCDIC）的可打印字符组成。标记可以表示位计数、记录计数或系统可以用来识别数据检查点的任何其他信息。数据接收方如果执行了重启程序，就会在接收系统中标记该标记的对应位置，并将该信息返回给用户。
在系统出现故障的情况下，用户可以通过 FTP 重新启动程序识别标记点来重新启动数据传输。以下示例说明了重新启动过程的使用。
数据的发送方在数据流中的方便点插入适当的标记块。接收主机在其文件系统中标记相应的数据点，并将最后已知的发送者和接收者标记信息直接或通过 110 回复中的控制连接（取决于谁是发送者）传送给用户。在系统故障的情况下，用户或控制器进程通过发送带有服务器标记代码作为参数的重新启动命令，在最后一个服务器标记处重新启动服务器。重启命令通过控制连接传输，紧随其后的是发生系统故障时正在执行的命令（如 RETR、STOR 或 LIST）。
4、 文件传输功能
从用户 PI 到服务器 PI 的通信通道建立为从用户到标准服务器端口的 TCP 连接。用户协议解释器负责发送FTP命令并解释收到的回复；服务器 PI 解释命令、发送回复并指示其 DTP 建立数据连接并传输数据。如果数据传输的第二方（被动传输过程）是user-DTP，那么它是通过user-FTP主机的内部协议进行管理的；如果它是第二个服务器 DTP，则它由来自用户 PI 的 PI on 命令控制。 FTP 回复将在下一节讨论。在本节中一些命令的描述中，明确说明可能的回复是有帮助的。
4.1、 FTP 命令
4.1.1、 访问控制命令
以下命令指定访问控制标识符（命令代码显示在括号中）。
用户名（USER）
参数字段是标识用户的 Telnet 字符串。用户标识是服务器访问其文件系统所需的标识。此命令通常是用户在建立控制连接后发送的第一个命令（某些服务器可能需要此命令）。某些服务器也可能需要密码和/或帐户命令形式的附加标识信息。服务器可以允许在任何时候输入新的 USER 命令以更改访问控制和/或记帐信息。这具有刷新已提供的任何用户、密码和帐户信息并再次开始登录序列的效果。所有传输参数都保持不变，任何正在进行的文件传输都在旧的访问控制参数下完成。
密码 (PASS)
参数字段是指定用户密码的 Telnet 字符串。此命令必须紧跟在用户名命令之后，并且对于某些站点，完成用户的识别以进行访问控制。由于密码信息非常敏感，因此通常需要“屏蔽”它或禁止输入。服务器似乎没有万无一失的方法来实现这一点。因此，用户 FTP 进程有责任隐藏敏感的密码信息。
帐户 (ACCT)
参数字段是标识用户帐户的 Telnet 字符串。该命令不一定与 USER 命令相关，因为某些站点可能需要帐户才能登录，而其他站点仅用于特定访问，例如存储文件。在后一种情况下，命令可能随时到达。
有回复代码来区分这些情况的自动化：当登录需要帐户信息时，对成功的 PASSword 命令的响应是回复代码 332。另一方面，如果登录不需要帐户信息，则回复 a成功的 PASSword 命令是 230；如果在对话中稍后发出的命令需要帐户信息，则服务器应分别返回 332 或 532 回复，具体取决于它是存储（等待接收 ACCounT 命令）还是丢弃该命令。
更改工作目录 (CWD)
此命令允许用户使用不同的目录或数据集进行文件存储或检索，而无需更改其登录或记帐信息。传输参数同样不变。参数是指定目录或其他系统相关文件组指示符的路径名。
更改到父目录 (CDUP)
此命令是 CWD 的一个特例，包含该命令是为了简化在具有不同命名父目录语法的操作系统之间传输目录树的程序的实现。回复码应与CWD 的回复码相同。有关详细信息，请参阅附录2。
结构挂载 (SMNT)
此命令允许用户挂载不同的文件系统数据结构，而无需更改其登录或记帐信息。传输参数同样不变。参数是指定目录或其他系统相关文件组指示符的路径名。
重新初始化（REIN）
此命令会终止 USER，刷新所有 I/O 和帐户信息，但允许完成正在进行的任何传输。所有参数都重置为默认设置，控制连接保持打开状态。这与用户在打开控制连接后立即发现自己的状态相同。可能会出现 USER 命令。
退出（QUIT）
此命令终止用户，如果文件传输不在进行中，服务器将关闭控制连接。如果文件传输正在进行，连接将保持打开状态以响应结果，然后服务器将关闭它。如果用户进程正在为多个用户传输文件，但不希望为每个用户关闭然后重新打开连接，则应使用 REIN 命令而不是 QUIT。
控制连接的意外关闭将导致服务器采取有效的中止 (ABOR) 和注销 (QUIT) 操作。
4.1.2、 传输参数命令
所有数据传输参数都有默认值，只有当默认参数值需要改变时，才需要指定数据传输参数的命令。默认值是最后指定的值，或者如果未指定值，则标准默认值如此处所述。这意味着服务器必须“记住”适用的默认值。命令可以按任何顺序排列，但它们必须在 FTP 服务请求之前。以下命令指定数据传输参数：
数据端口（PORT）
参数是用于数据连接的数据端口的 HOST-PORT 规范。用户和服务器数据端口都有默认值，一般情况下不需要此命令及其回复。如果使用此命令，则参数是 32 位 Internet 主机地址和 16 位 TCP 端口地址的串联。该地址信息被分成 8 位字段，每个字段的值作为十进制数（以字符串表示）传输。字段以逗号分隔。端口命令将是：
PORT h1,h2,h3,h4,p1,p2
其中 h1 是 Internet 主机地址的高 8 位。
被动 (PASV)
此命令请求服务器 DTP 在数据端口（不是其默认数据端口）上“侦听”并等待连接而不是在接收到传输命令时启动连接。 对此命令的响应包括此服务器正在侦听的主机和端口地址。
表示类型（TYPE）
参数指定数据表示和存储部分中描述的表示类型。 几种类型采用第二个参数。 第一个参数由单个 Telnet 字符表示，ASCII 和 EBCDIC 的第二个 Format 参数也是如此； 本地字节的第二个参数是一个十进制整数，表示字节大小。 参数由 （空格，ASCII 代码 32）分隔。
为类型分配了以下代码：
默认表示类型是 ASCII 非打印。 如果更改了 Format 参数，并且稍后仅更改了第一个参数，则 Format 将返回到非打印默认值。
文件结构 (STRU)
参数是一个单独的 Telnet 字符代码，指定了数据表示和存储部分中描述的文件结构。
为结构分配了以下代码：
F - File (no record structure) R - Record structure P - Page structure
默认结构是文件。
传输模式（MODE）
参数是单个 Telnet 字符代码，指定传输模式部分中描述的数据传输模式。
为传输模式分配了以下代码：
S - Stream B - Block C - Compressed
默认传输模式为 Stream。
4.1.3、 FTP 服务命令
FTP 服务命令定义了用户请求的文件传输或文件系统功能。 FTP 服务命令的参数通常是路径名。路径名的语法必须符合服务器站点约定（适用标准默认值）和控制连接的语言约定。建议的默认处理是使用最后指定的设备、目录或文件名，或为本地用户定义的标准默认值。除了“rename from”命令后面必须跟“rename to”命令并且重启命令后面必须跟中断的服务命令（例如，STOR或RETR）之外，命令可以是任何顺序。响应 FTP 服务命令传输的数据应始终通过数据连接发送，某些信息性回复除外。以下命令指定 FTP 服务请求：
检索 (RETR)
此命令使服务器 DTP 将路径名中指定的文件副本传输到数据连接另一端的服务器或用户 DTP。服务器站点上文件的状态和内容不受影响。
存储 (STOR)
该命令使服务器-DTP 接受通过数据连接传输的数据并将数据作为文件存储在服务器站点。如果路径名中指定的文件存在于服务器站点，则其内容应由正在传输的数据替换。如果路径名中指定的文件不存在，则会在服务器站点上创建一个新文件。
唯一存储 (STOU)
此命令的行为与 STOR 类似，不同之处在于将在当前目录中以对该目录唯一的名称创建结果文件。 250 Transfer Started 响应必须包含生成的名称。
APPEND（带创建）（APPE）
该命令使服务器-DTP 接受通过数据连接传输的数据并将数据存储在服务器站点的文件中。如果路径名中指定的文件存在于服务器站点，则数据应附加到该文件中；否则将在服务器站点创建路径名中指定的文件。
分配（ALLO）
某些服务器可能需要此命令来保留足够的存储空间以容纳要传输的新文件。参数应是一个十进制整数，表示要为文件保留的存储的字节数（使用逻辑字节大小）。对于使用记录或页面结构发送的文件，可能还需要最大记录或页面大小（以逻辑字节为单位）；这由命令的第二个参数字段中的十进制整数表示。第二个参数是可选的，但是当出现时应该用三个 Telnet 字符 R 与第一个参数分开。该命令后面应跟有 STORe 或 APPEnd 命令。 ALLO 命令应该被那些不需要事先声明文件最大大小的服务器视为 NOOP（无操作），那些只对最大记录或页面大小感兴趣的服务器应该接受第一个参数并忽略它。
重启（REST）
参数字段表示要重新启动文件传输的服务器标记。此命令不会导致文件传输，而是跳过文件到指定的数据检查点。该命令应紧跟在适当的 FTP 服务命令之后，该命令将使文件传输恢复。
重命名自 (RNFR)
此命令指定要重命名的文件的旧路径名。此命令必须紧跟在指定新文件路径名的“重命名为”命令之后。
重命名为（RNTO）
此命令指定在紧接在前面的“rename from”命令中指定的文件的新路径名。这两个命令一起导致文件被重命名。
中止（ABOR）
此命令告诉服务器中止先前的 FTP 服务命令和任何相关的数据传输。 abort 命令可能需要“特殊操作”，如 FTP 命令部分所述，以强制服务器识别。如果之前的命令已经完成（包括数据传输），则不会采取任何行动。服务器不关闭控制连接，但必须关闭数据连接。
服务器收到该命令有两种情况：（1）FTP服务命令已经完成，或者（2）FTP服务命令还在进行中。
在第一种情况下，服务器关闭数据连接（如果它是打开的）并以 226 回复响应，表示成功处理了 abort 命令。
第二种情况，服务器中止正在进行的FTP服务并关闭数据连接，返回426回复，表示服务请求异常终止。然后服务器发送 226 回复，表示成功处理了 abort 命令。
删除（DELE）
此命令会导致在服务器站点删除路径名中指定的文件。如果需要额外的保护级别（例如查询“您真的要删除吗？”），则应由用户 FTP 进程提供。
删除目录 (RMD)
此命令会导致将路径名中指定的目录作为目录（如果路径名是绝对的）或作为当前工作目录的子目录（如果路径名是相对的）删除。见附录二。
创建目录 (MKD)
此命令使路径名中指定的目录创建为目录（如果路径名是绝对的）或当前工作目录的子目录（如果路径名是相对的）。见附录二。
打印工作目录 (PWD)
此命令导致在回复中返回当前工作目录的名称。见附录二。
列表（LIST）
此命令会导致从服务器向被动 DTP 发送一个列表。如果路径名指定了一个目录或其他文件组，则服务器应传输指定目录中的文件列表。如果路径名指定了一个文件，那么服务器应该发送有关该文件的当前信息。空参数表示用户当前的工作目录或默认目录。数据传输通过 ASCII 类型或 EBCDIC 类型的数据连接进行。 （用户必须确保 TYPE 是适当的 ASCII 或 EBCDIC）。由于文件上的信息可能因系统而异，因此该信息可能难以在程序中自动使用，但对人类用户可能非常有用。
名称列表 (NLST)
此命令导致目录列表从服务器发送到用户站点。路径名应指定目录或其他特定于系统的文件组描述符；空参数意味着当前目录。服务器将返回文件名称流，不返回其他信息。数据将以 ASCII 或 EBCDIC 类型作为由 或 分隔的有效路径名字符串通过数据连接传输。 （同样，用户必须确保 TYPE 正确。）此命令旨在返回信息，程序可以使用这些信息来自动进一步处理文件。例如，在执行“多次获取”功能时。
站点参数（SITE）
服务器使用此命令来提供特定于其系统的服务，这些服务对于文件传输必不可少，但不够通用，无法作为命令包含在协议中。这些服务的性质和它们的语法规范可以在对 HELP SITE 命令的回复中说明。
系统 (SYST)
此命令用于查找服务器上的操作系统类型。答复应将当前版本的指定编号文档 [4] 中列出的系统名称作为其第一个单词。
状态 (STAT)
该命令将导致状态响应以回复的形式通过控制连接发送。该命令可以在文件传输期间发送（连同 Telnet IP 和同步信号 - 请参阅有关 FTP 命令的部分）在这种情况下，服务器将以正在进行的操作状态进行响应，或者它可以在文件之间发送转让。在后一种情况下，命令可能有一个参数字段。如果参数是路径名，则该命令类似于“list”命令，不同之处在于数据应通过控制连接传输。如果给出了部分路径名，服务器可能会以与该规范相关联的文件名或属性列表进行响应。如果没有给出参数，服务器应该返回关于服务器 FTP 进程的一般状态信息。这应该包括所有传输参数的当前值和连接状态。
帮助（HELP）
该命令将使服务器通过控制连接向用户发送有关其实现状态的有用信息。命令可以接受一个参数（例如，任何命令名称）并返回更具体的信息作为响应。回复类型为 211 或 214。建议在输入 USER 命令之前允许 HELP。服务器可以使用此回复来指定与站点相关的参数，例如，响应 HELP SITE。
NOOP (NOOP)
此命令不影响任何参数或以前输入的命令。除了服务器发送 OK 回复之外，它没有指定任何动作。
对于控制连接上的所有通信，文件传输协议遵循 Telnet 协议的规范。由于用于 Telnet 通信的语言可能是协商选项，因此接下来两节中的所有引用都将指向“Telnet 语言”和相应的“Telnet 行尾代码”。目前，人们可能会将这些理解为 NVT-ASCII 和 。不会引用 Telnet 协议的其他规范。
FTP 命令是由“Telnet 行尾代码”终止的“Telnet 字符串”。命令代码本身是由字符 （空格）终止的字母字符，如果参数跟在后面，否则为 Telnet-EOL。本节描述了命令代码和命令的语义；命令的详细语法在命令部分指定，回复序列在命令和回复排序部分讨论，说明命令使用的场景在典型 FTP 场景部分提供。
FTP 命令可以划分为指定访问控制标识符、数据传输参数或 FTP 服务请求的命令。某些命令（例如 ABOR、STAT、QUIT）可以在数据传输过程中通过控制连接发送。有些服务器可能无法同时监控控制和数据连接，在这种情况下，需要采取一些特殊措施来引起服务器的注意。暂时推荐以下有序格式：
1. 用户系统在Telnet流中插入Telnet“中断进程”(IP)信号。
2. 用户系统发送Telnet“Synch”信号。
3. 用户系统在 Telnet 流中插入命令（例如，ABOR）。
4. 服务器 PI 在接收到“IP”后，扫描 Telnet 流以查找 EXACTLY ONE FTP 命令。
（对于其他服务器，这可能不是必需的，但上面列出的操作应该没有异常影响。）
4.2、 FTP 回复
文件传输协议命令的回复旨在确保文件传输过程中请求和动作的同步，并保证用户进程始终知道服务器的状态。每个命令必须至少生成一个回复，尽管可能不止一个；在后一种情况下，必须很容易地区分多个答复。此外，一些命令出现在顺序组中，例如 USER、PASS 和 ACCT，或 RNFR 和 RNTO。如果所有前面的命令都成功，则回复显示中间状态的存在。序列中任何一点的失败都需要从头开始重复整个序列。
命令-回复序列的细节在下面的一组状态图中得到了明确的说明。
FTP 回复由一个三位数字（作为三个字母数字字符传输）和一些文本组成。该数字旨在供自动机使用以确定接下来要进入的状态；该文本适用于人类用户。这三个数字包含足够的编码信息，用户进程（User-PI）不需要检查文本，并且可能会丢弃它或将其传递给用户，视情况而定。特别是，文本可能依赖于服务器，因此每个回复代码可能有不同的文本。
回复被定义为包含 3 位代码，后跟空格 ，后跟一行文本（已指定某些最大行长度），并以 Telnet 行尾代码终止。但是，在某些情况下，文本比一行还长。在这些情况下，完整的文本必须用括号括起来，以便用户进程知道何时可以停止读取回复（即停止处理控制连接上的输入）并去做其他事情。这需要在第一行使用特殊格式来指示多行即将到来，并在最后一行使用另一个格式将其指定为最后一行。其中至少有一个必须包含适当的回复代码以指示事务的状态。为了满足所有派系，决定第一行和最后一行代码应该相同。
因此，多行回复的格式是第一行以确切所需的回复代码开头，紧接着是连字符“-”（也称为减号），然后是文本。最后一行将以相同的代码开头，紧接着是空格 、可选的一些文本和 Telnet 行尾代码。
例如：
123-First line Second line 234 A line beginning with numbers 123 The last line
然后，用户进程只需要在一行的开头搜索第二次出现的相同回复代码，后跟 （空格），并忽略所有中间行。如果中间线以 3 位数字开头，则服务器必须填充前面以避免混淆。
该方案允许将标准系统例程用于回复信息（例如用于 STAT 回复），并附加“人工”第一行和最后一行。在极少数情况下，这些例程能够在任何行的开头生成三个数字和一个空格，每个文本行的开头应该被一些中性文本偏移，例如空格。
该方案假设多行回复可能不会嵌套。
回复的三位数字各有特殊意义。这旨在允许用户进程进行一系列非常简单到非常复杂的响应。第一个数字表示响应是好、坏还是不完整。（参见状态图），一个简单的用户进程将能够通过简单地检查第一个数字来确定其下一步操作（按计划进行、重做、裁员等）。想要知道发生了什么样的错误（例如文件系统错误、命令语法错误）的用户进程可以检查第二个数字，保留第三个数字用于信息的最佳分级（例如，没有前面的 RNFR 的 RNTO 命令） .
回复代码的第一位数字有五个值：
1yz：正面初步答复
正在启动请求的操作；在继续执行新命令之前期待另一个答复。 （用户进程在完成回复之前发送另一个命令将违反协议；但服务器 FTP 进程应该将任何到达的命令排队，而前一个命令正在进行中。）这种类型的回复可用于指示命令已被接受，用户进程现在可能会关注数据连接，以实现同时监控是困难的。服务器-FTP 进程最多可以发送每个命令一个 1yz 回复。
2yz：主动完成回复
请求的操作已成功完成。可以发起新的请求。
3yz：正面中级回复
命令已被接受，但请求的操作被搁置，等待收到进一步的信息。用户应发送另一个指定此信息的命令。该回复用于命令序列组。
4yz：瞬态否定完成回复
未接受命令且未执行请求的操作，但错误情况是暂时的，可能会再次请求操作。用户应返回到命令序列的开头（如果有）。很难为“瞬态”赋予含义，尤其是当两个不同的站点（服务器进程和用户进程）必须就解释达成一致时。 4yz 类别中的每个回复的时间值可能略有不同，但其目的是鼓励用户进程重试。确定回复是否适合 4yz 或 5yz（永久否定）类别的经验法则是，如果命令可以重复而无需更改命令形式或用户或服务器的属性（例如，命令的拼写与使用的参数相同；用户不会更改其文件访问权限或用户名；服务器不会提供新的实现。）
5yz：永久否定完成回复
未接受该命令且未执行请求的操作。不鼓励用户进程重复确切的请求（以相同的顺序）。甚至一些“永久性”错误条件也可以被纠正，因此人类用户可能希望在未来的某个时刻（例如，在拼写改变后，或者用户已经改变了他的目录状态。）
以下功能分组编码在第二位：
x0z
语法 - 这些回复指的是语法错误、不适合任何功能类别的语法正确命令、未实现或多余的命令。
x1z
信息 - 这些是对信息请求的回复，例如状态或帮助。
x2z
连接 - 参考控制和数据连接的回复。
x3z
身份验证和记帐 - 对登录过程和记帐程序的答复。
x4z
至今未明。
x5z
文件系统 - 这些回复指示服务器文件系统相对于请求的传输或其他文件系统操作的状态。
第三个数字在每个功能类别中给出了更精细的含义等级，由第二个数字指定。下面的答复列表将说明这一点。请注意，与每个回复关联的文本是推荐的，而不是强制性的，甚至可能会根据与之关联的命令而改变。另一方面，回复代码必须严格遵循上一节中的规范；也就是说，服务器实现不应该为与这里描述的情况略有不同的情况发明新的代码，而应该调整已经定义的代码。
诸如 TYPE 或 ALLO 之类的命令如果成功执行并没有为用户进程提供任何新信息，将导致返回 200 回复。如果该命令没有由特定的 Server-FTP 进程执行，因为它与该计算机系统无关，例如在 TOPS20 站点上的 ALLO，仍然需要肯定完成答复，以便简单的用户进程知道它可以继续它的行动方针。在这种情况下使用 202 回复，例如回复文本：“无需分配存储空间”。另一方面，如果该命令请求非特定于站点的操作并且未实施，则响应为 502。对此的改进是对已实施但请求未实施参数的命令的 504 回复。
4.2.1 功能组回复码
200 命令完成。
500 语法错误，命令无法识别。这可能包括命令行太长等错误。
501 参数或参数中的语法错误。
202 命令未执行，在此站点上是多余的。
502 命令未执行。
503 错误的命令序列。
504 该参数未执行命令。
110 重新启动标记回复。 在这种情况下，文本是准确的，而不是留给特定的实现； 它必须是：
MARK yyyy = mmmm
其中 yyyy 是用户进程数据流标记，以及 mmmm 服务器的等效标记（注意标记和“=”之间的空格）。
211 系统状态，或系统帮助回复。
212 目录状态。
213 文件状态。
214 帮助信息。关于如何使用服务器或特定非标准命令的含义。此回复仅对人类用户有用。
215 命名系统类型。其中 NAME 是 Assigned Numbers 文档中列表中的正式系统名称。
120 服务在 nnn 分钟内准备就绪。
220 为新用户准备好服务。
221 服务关闭控制连接。适当时注销。
421 服务不可用，正在关闭控制连接。如果服务知道它必须关闭，这可能是对任何命令的回复。
125 数据连接已打开；转移开始。
225 数据连接打开；没有正在进行的转移。
425 无法打开数据连接。
226 关闭数据连接。请求的文件操作成功（例如，文件传输或文件中止）。
426 连接关闭；传输中止。
227 进入被动模式 (h1,h2,h3,h4,p1,p2)。
230 用户登录，继续。
530 未登录。
331 用户名好，需要密码。
332 需要账号登录。
532 需要帐户来存储文件。
150 文件状态正常； 即将打开数据连接。
250 请求的文件操作正常，已完成。
257 “路径名”已创建。
350 请求的文件操作等待进一步的信息。
450 未采取请求的文件操作。 文件不可用（例如，文件忙）。
550 未采取请求的操作。 文件不可用（例如，未找到文件、无法访问）。
451 请求的操作已中止。 处理中的局部错误。
551 请求的操作已中止。 页面类型未知。
452 未采取请求的操作。 系统存储空间不足。
552 请求的文件操作已中止。 超出存储分配（对于当前目录或数据集）。
553 未采取请求的操作。 不允许使用文件名。
4.2.2 回复码数字顺序表
110 重新启动标记回复。 在这种情况下，文本是准确的，而不是留给特定的实现； 它必须是：
MARK yyyy = mmmm
其中 yyyy 是用户进程数据流标记，以及 mmmm 服务器的等效标记（注意标记和“=”之间的空格）。
120 服务在 nnn 分钟内准备就绪。
125 数据连接已打开；转移开始。
150 文件状态正常；即将打开数据连接。
200 命令没问题。
202 命令未执行，在此站点上是多余的。
211 系统状态，或系统帮助回复。
212 目录状态。
213 文件状态。
214 帮助信息。关于如何使用服务器或特定非标准命令的含义。此回复仅对人类用户有用。
215 命名系统类型。其中 NAME 是 Assigned Numbers 文档中列表中的正式系统名称。
220 为新用户准备好服务。
221 服务关闭控制连接。适当时注销。
225 数据连接打开；没有正在进行的转移。
226 关闭数据连接。请求的文件操作成功（例如，文件传输或文件中止）。
227 进入被动模式 (h1,h2,h3,h4,p1,p2)。
230 用户登录，继续。
250 请求的文件操作正常，已完成。
257 “路径名”已创建。
331 用户名好，需要密码。
332 需要账号登录。
350 请求的文件操作等待进一步的信息。
421 服务不可用，正在关闭控制连接。如果服务知道它必须关闭，这可能是对任何命令的回复。
425 无法打开数据连接。
426 连接关闭；传输中止。
450 未采取请求的文件操作。文件不可用（例如，文件忙）。
451 请求的操作中止：处理中的本地错误。
452 未采取请求的操作。系统存储空间不足。
500 语法错误，命令无法识别。这可能包括命令行太长等错误。
501 参数或参数中的语法错误。
502 命令未执行。
503 错误的命令序列。
504 该参数未执行命令。
530 未登录。
532 需要帐户来存储文件。
550 未采取请求的操作。文件不可用（例如，未找到文件、无法访问）。
551 请求的操作中止：页面类型未知。
552 请求的文件操作已中止。超出存储分配（对于当前目录或数据集）。
553 未采取请求的操作。不允许使用文件名。
5. 声明性规范
5.1. 最低执行
为了使 FTP 能够正常工作而没有不必要的错误消息，所有服务器都需要以下最低限度的实现：
TYPE - ASCII Non-print MODE - Stream STRUCTURE - File, Record COMMANDS - USER, QUIT, PORT,TYPE, MODE, STRU, 对于默认值 RETR, STOR,NOOP.
传输参数的默认值为：
TYPE - ASCII Non-print MODE - Stream STRU - File
所有主机都必须接受上述作为标准默认值。
5.2.连接
服务器协议解释器应“监听”端口 L。用户或用户协议解释器应启动全双工控制连接。服务器和用户进程应遵循 ARPA-Internet 协议手册 [1] 中指定的 Telnet 协议约定。服务器没有义务提供命令行的编辑，并且可能要求在用户主机中完成。在所有传输和回复完成后，服务器应用户请求关闭控制连接。
用户-DTP 必须“监听”指定的数据端口；这可能是默认用户端口 (U) 或 PORT 命令中指定的端口。服务器应使用指定的用户数据端口从他自己的默认数据端口 (L-1) 启动数据连接。传输的方向和使用的端口将由 FTP 服务命令决定。
请注意，所有 FTP 实现都必须支持使用默认端口的数据传输，并且只有 USER-PI 可以启动非默认端口的使用。
当数据要在两台服务器 A 和 B（参见图 2）之间传输时，用户 PI C 与两个服务器 PI 建立控制连接。其中一个服务器，比如说 A，然后会收到一个 PASV 命令，告诉他在他收到传输服务命令时“监听”他的数据端口而不是启动连接。当用户 PI 收到对 PASV 命令的确认时，其中包括主机的身份和正在侦听的端口，然后用户 PI 在 PORT 命令中将 A 的端口 a 发送到 B；返回回复。然后，用户 PI 可以向 A 和 B 发送相应的服务命令。服务器 B 启动连接并继续传输。下面列出了命令-回复序列，其中消息垂直同步但水平异步：
图 3
数据连接应在建立数据连接部分所述的条件下由服务器关闭。如果在不需要关闭连接来指示文件结束的数据传输之后关闭数据连接，则服务器必须立即这样做。不允许等到新的传输命令之后，因为用户进程已经测试了数据连接以查看它是否需要进行“监听”； （请记住，用户必须在发送传输请求之前“监听”关闭的数据端口）。为了防止这里的竞争条件，服务器在关闭数据连接后发送回复（226）（或者如果连接保持打开，“文件传输完成”回复（250）并且用户 PI 应该等待其中之一在发出新的传输命令之前回复）。
任何时候用户或服务器看到另一端正在关闭连接，它应该立即读取连接上排队的任何剩余数据并在自己端发出关闭。
5.3.命令
这些命令是通过控制连接传输的 Telnet 字符串，如 FTP 命令部分所述。命令功能和语义在访问控制命令、传输参数命令、FTP 服务命令和杂项命令一节中描述。命令语法在此处指定。
命令以命令代码开头，后跟参数字段。命令代码是四个或更少的字母字符。大写和小写字母字符将被同等对待。因此，以下任何一项都可能代表检索命令：
RETR Retr retr ReTr rETr
这也适用于表示参数值的任何符号，例如 A 或 ASCII 类型的 a。 命令代码和参数字段由一个或多个空格分隔。
参数字段由可变长度字符串组成，以字符序列 （回车，换行）结尾，用于 NVT-ASCII 表示； 对于其他协商语言，可能会使用不同的行尾字符。 需要注意的是，服务器在收到行尾代码之前不采取任何行动。
下面在 NVT-ASCII 中指定了语法。 参数字段中的所有字符都是 ASCII 字符，包括任何 ASCII 表示的十进制整数。 方括号表示可选参数字段。 如果不采用该选项，则隐含适当的默认值。
5.3.1. FTP 命令
以下是FTP命令：
USER <SP> <username> <CRLF> PASS <SP> <password> <CRLF> ACCT <SP> <account-information> <CRLF> CWD <SP> <pathname> <CRLF> CDUP <CRLF> SMNT <SP> <pathname> <CRLF> QUIT <CRLF> REIN <CRLF> PORT <SP> <host-port> <CRLF> PASV <CRLF> TYPE <SP> <type-code> <CRLF> STRU <SP> <structure-code> <CRLF> MODE <SP> <mode-code> <CRLF> RETR <SP> <pathname> <CRLF> STOR <SP> <pathname> <CRLF> STOU <CRLF> APPE <SP> <pathname> <CRLF> ALLO <SP> <decimal-integer> [<SP> R <SP> <decimal-integer>] <CRLF> REST <SP> <marker> <CRLF> RNFR <SP> <pathname> <CRLF> RNTO <SP> <pathname> <CRLF> ABOR <CRLF> DELE <SP> <pathname> <CRLF> RMD <SP> <pathname> <CRLF> MKD <SP> <pathname> <CRLF> PWD <CRLF> LIST [<SP> <pathname>] <CRLF> NLST [<SP> <pathname>] <CRLF> SITE <SP> <string> <CRLF> SYST <CRLF> STAT [<SP> <pathname>] <CRLF> HELP [<SP> <string>] <CRLF> NOOP <CRLF>
5.3.2. FTP 命令参数
上述参数字段的语法（在适用的情况下使用 BNF 表示法）是：
<username> ::= <string> <password> ::= <string> <account-information> ::= <string> <string> ::= <char> | <char><string> <char> ::= any of the 128 ASCII characters except <CR> and <LF> <marker> ::= <pr-string> <pr-string> ::= <pr-char> | <pr-char><pr-string> <pr-char> ::= printable characters, any ASCII code 33 through 126 <byte-size> ::= <number> <host-port> ::= <host-number>,<port-number> <host-number> ::= <number>,<number>,<number>,<number> <port-number> ::= <number>,<number> <number> ::= any decimal integer 1 through 255 <form-code> ::= N | T | C <type-code> ::= A [<sp> <form-code>] | E [<sp> <form-code>] | I | L <sp> <byte-size> <structure-code> ::= F | R | P <mode-code> ::= S | B | C <pathname> ::= <string> <decimal-integer> ::= any decimal integer
5.4.命令和回复的排序
用户和服务器之间的通信旨在进行交替对话。因此，用户发出 FTP 命令，服务器以提示的主要回复进行响应。用户应该在发送进一步的命令之前等待这个初始的主要成功或失败响应。
某些命令需要用户也应该等待的第二个答复。例如，这些回复可能会报告文件传输的进度或完成情况或数据连接的关闭情况。它们是对文件传输命令的辅助回复。
一组重要的信息回复是连接问候语。在正常情况下，服务器会在连接完成时发送 220 回复“等待输入”。在发送任何命令之前，用户应该等待此问候消息。如果服务器无法立即接受输入，则应立即发送 120“预期延迟”回复，并在准备好时发送 220 回复。如果有延迟，用户将知道不要挂断。
自发回复
有时“系统”自发地有一条消息要发送给用户（通常是所有用户）。例如，“系统将在 15 分钟内停机”。 FTP 中没有规定从服务器向用户发送此类自发信息。建议将此类信息在服务器 PI 中排队，并在下一个回复中传递给用户 PI（可能使其成为多行回复）。
下表列出了每个命令的替代成功和失败回复。这些必须严格遵守；服务器可以替换回复中的文本，但不能更改代码编号和特定命令回复序列所隐含的含义和动作。
命令-回复序列
在本节中，将介绍命令-应答序列。列出了每个命令及其可能的回复；命令组一起列出。首先列出初步答复（其后续答复缩进并在其下方），然后是肯定和否定完成，最后是中间答复，其中包含以下序列中的其余命令。此列表构成了状态图的基础，状态图将单独呈现。
Connection Establishment 120 220 220 421
Login
USER 230 530 500, 501, 421 331, 332 PASS 230 202 530 500, 501, 503, 421 332 ACCT 230 202 530 500, 501, 503, 421 CWD 250 500, 501, 502, 421, 530, 550 CDUP 200 500, 501, 502, 421, 530, 550 SMNT 202, 250 500, 501, 502, 421, 530, 550
Logout
REIN 120 220 220 421 500, 502 QUIT 221 500
Transfer parameters
PORT 200 500, 501, 421, 530 PASV 227 500, 501, 502, 421, 530 MODE 200 500, 501, 504, 421, 530 TYPE 200 500, 501, 504, 421, 530 STRU 200 500, 501, 504, 421, 530
File action commands
ALLO 200 202 500, 501, 504, 421, 530 REST 500, 501, 502, 421, 530 350 STOR 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 452, 553 500, 501, 421, 530 STOU 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 452, 553 500, 501, 421, 530 RETR 125, 150 (110) 226, 250 425, 426, 451 450, 550 500, 501, 421, 530 LIST 125, 150 226, 250 425, 426, 451 450 500, 501, 502, 421, 530 NLST 125, 150 226, 250 425, 426, 451 450 500, 501, 502, 421, 530 APPE 125, 150 (110) 226, 250 425, 426, 451, 551, 552 532, 450, 550, 452, 553 500, 501, 502, 421, 530 RNFR 450, 550 500, 501, 502, 421, 530 350 RNTO 250 532, 553 500, 501, 502, 503, 421, 530 DELE 250 450, 550 500, 501, 502, 421, 530 RMD 250 500, 501, 502, 421, 530, 550 MKD 257 500, 501, 502, 421, 530, 550 PWD 257 500, 501, 502, 421, 550 ABOR 225, 226 500, 501, 502, 421
Informational commands
SYST 215 500, 501, 502, 421 STAT 211, 212, 213 450 500, 501, 502, 421, 530 HELP 211, 214 500, 501, 502, 421
Miscellaneous commands
SITE 200 202 500, 501, 530 NOOP 200 500 421
6. 状态图
在这里，我们展示了一个非常简单的 FTP 实现的状态图。 仅使用回复代码的第一位数字。 每组 FTP 命令或命令序列都有一个状态图。
命令分组是通过为每个命令构建一个模型然后将具有结构相同模型的命令收集在一起来确定的。
对于每个命令或命令序列，存在三种可能的结果：成功 (S)、失败 (F) 和错误 (E)。 在下面的状态图中，我们使用符号 B 表示“开始”，使用符号 W 表示“等待回复”。
我们首先展示代表最大组 FTP 命令的图表：
此图为命令建模：
ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV, QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, 和 TYPE.
另一大组命令由非常相似的图表表示：
此图为命令建模：
APPE, LIST, NLST, REIN, RETR, STOR, 和 STOU.
请注意，第二个模型也可以用于表示第一组命令，唯一的区别是在第一组中 100 系列回复是意外的，因此被视为错误，而第二组期望（有些可能需要）100 系列 回复。 请记住，每个命令最多允许一个 100 系列回复。
其余的图表模型命令序列，其中最简单的可能是重命名序列：
下图是 Restart 命令的简单模型：
其中“cmd”是 APPE、STOR 或 RETR。
我们注意到上述三个模型是相似的。 Restart 与 Rename two 的区别仅在于第二阶段对 100 系列回复的处理，而第二组期望（有些可能需要）100 系列回复。 请记住，每个命令最多允许一个 100 系列回复。
最复杂的图是登录序列：
最后，我们展示了一个通用图，可用于对命令和回复交换进行建模：
7. 典型的 FTP 场景
主机 U 上的用户想要向主机 S 传输文件/从主机 S 传输文件：
通常，用户将通过中介用户 FTP 进程与服务器通信。 以下可能是一个典型的场景。 user-FTP 提示显示在括号中，'---->' 代表主机 U 到主机 S 的命令，'<----' 代表主机 S 到主机 U 的回复。
8. 连接建立
FTP控制连接是通过TCP在用户进程端口U和服务器进程端口L之间建立的。该协议被分配了服务端口21（25八进制），即L=21。
附录1 - 页结构
FTP 支持页面结构的需要主要源于支持在 TOPS-20 系统之间有效传输文件的需要，尤其是 NLS 使用的文件。
TOPS-20 的文件系统基于页的概念。操作系统在将文件作为页面进行操作方面效率最高。操作系统为文件系统提供了一个接口，因此许多应用程序将文件视为连续的字符流。但是，一些应用程序直接使用底层页面结构，其中一些会创建有孔文件。
TOPS-20 磁盘文件由四部分组成：路径名、页表、（可能为空的）页集和属性集。
路径名在 RETR 或 STOR 命令中指定。它包括目录名、文件名、文件扩展名和代号。
页表最多包含 2^18 个条目。每个条目可能是空的，也可能指向一个页面。如果不为空，也有一些页面特定的访问位；并非文件的所有页面都需要相同的访问保护。
页是一组连续的 512 个字，每个字 36 位。
文件的属性，在文件描述符块 (FDB) 中，包含诸如创建时间、写入时间、读取时间、写入器的字节大小、文件结束指针、读取和写入计数、备份系统磁带编号等内容， 等等。
请注意，没有要求页表中的条目是连续的。在被占用的页表插槽之间可能有空的页表插槽。此外，文件指针的结尾只是一个数字。不要求它实际上指向文件中的“最后一个”数据。 TOPS-20 中的普通顺序 I/O 调用将导致文件尾指针在最后写入的数据之后被留下，但如果特定的编程系统需要，其他操作可能会导致它不是这样。
事实上，在这两种特殊情况下，“有洞”文件和不在文件末尾的文件尾指针出现在 NLS 数据文件中。
可以使用 FTP 传输参数发送 TOPS-20 分页文件：TYPE L 36、STRU P 和 MODE S（实际上，可以使用任何模式）。
每页信息都有一个标题。每个作为逻辑字节的标头字段是一个 TOPS-20 字，因为 TYPE 是 L 36。
标题字段是：
Word 0: Header Length.
标头长度为 5。
Word 1: Page Index.
如果数据是磁盘文件页面，则这是文件页面映射中该页面的编号。 文件中的空页（空洞）不会被发送。 请注意，一个洞与一页零不同。
Word 2: Data Length.
此页中的数据字数，跟在标题后面。 因此，传输单元的总长度是报头长度加上数据长度。
Word 3: Page Type.
这是什么类型的块的代码。 数据页是类型 3，FDB 页是类型 2。
Word 4: Page Access Control.
与文件页面映射中的页面相关联的访问位。 （这个完整的字数被程序从网络读取到磁盘放入一个 SPACS 的 AC2 中。）
头部之后是数据长度数据字。 数据长度当前要么是数据页的 512，要么是 FDB 的 31。 磁盘文件页中的尾随零可能会被丢弃，在这种情况下使数据长度小于 512。
附录2 - 目录命令
由于 UNIX 具有树状目录结构，其中目录与普通文件一样易于操作，因此扩展这些机器上的 FTP 服务器以包含处理目录创建的命令非常有用。 由于ARPA-Internet 上还有其他主机具有树状目录（包括TOPS-20 和Multics），因此这些命令尽可能通用。
FTP 添加了四个目录命令：
MKD pathname
创建一个名为“pathname”的目录。
RMD pathname
删除名为“pathname”的目录。
PWD
打印当前工作目录名称。
CDUP
切换到当前工作目录的父目录。
“路径名”参数应该作为当前工作目录的子目录创建（删除），除非“路径名”字符串包含足够的信息来指定服务器，例如，“路径名”是一个绝对路径名（在 UNIX 和 Multics 中） )，或者路径名类似于 TOPS-20 的“<abso.lute.path>”。
REPLY CODES
CDUP 命令是 CWD 的一个特例，包含它是为了简化用于在具有不同命名父目录语法的操作系统之间传输目录树的程序的实现。 CDUP 的回复代码与 CWD 的回复代码相同。
RMD 的回复代码与其类似文件 DELE 的回复代码相同。
但是，MKD 的回复代码稍微复杂一些。 新创建的目录可能是未来 CWD 命令的对象。 不幸的是，MKD 的论据可能并不总是适合 CWD 的论据。 例如，当仅通过提供子目录名称创建 TOPS-20 子目录时，就是这种情况。 也就是说，用一个TOPS-20服务器FTP，命令序列
MKD MYDIR CWD MYDIR
将失败。 新目录只能以其“绝对”名称引用； 例如，如果上面的 MKD 命令是在连接到目录 <DFRANKLIN> 时发出的，则新的子目录只能由名称 <DFRANKLIN.MYDIR> 引用。
然而，即使在 UNIX 和 Multics 上，给 MKD 的参数也可能不合适。 如果它是“相对”路径名（即相对于当前目录解释的路径名），则用户需要位于同一当前目录中才能到达子目录。 根据应用程序，这可能不方便。 在任何情况下它都不是很健壮。
为了解决这些问题，在成功完成 MKD 命令后，服务器应返回以下形式的一行：
257<space>"<directory-name>"<space><commentary>
也就是说，服务器会告诉用户在引用创建的目录时使用什么字符串。 目录名可以包含任何字符； 嵌入的双引号应该被双引号转义（“双引号”约定）。
例如，用户连接到目录 /usr/dm，并创建一个名为 pathname 的子目录：
CWD /usr/dm 200 directory changed to /usr/dm MKD pathname 257 "/usr/dm/pathname" directory created
带有嵌入式双引号的示例：
MKD foo"bar 257 "/usr/dm/foo""bar" directory created CWD /usr/dm/foo"bar 200 directory changed to /usr/dm/foo"bar
同名子目录的先前存在是一个错误，在这种情况下，服务器必须返回“访问被拒绝”错误回复。
CWD /usr/dm 200 directory changed to /usr/dm MKD pathname 521-"/usr/dm/pathname" directory already exists; 521 taking no action.
MKD 的失败回复类似于它的文件创建表亲 STOR。 此外，如果与子目录同名的文件名将与子目录的创建冲突（这在 UNIX 上是一个问题，但在 TOPS-20 上不应该是一个问题），则会给出“拒绝访问”返回。
本质上，因为 PWD 命令返回与成功的 MKD 命令相同类型的信息，成功的 PWD 命令也使用 257 回复代码。
SUBTLETIES
因为这些命令在将子树从一台机器传输到另一台机器时最有用，所以仔细观察 MKD 的参数将被解释为当前工作目录的子目录，除非它包含足够的信息让目标主机以其他方式告知 . 在 TOPS-20 世界中使用它的一个假设示例：
CWD <some.where> 200 Working directory changed MKD overrainbow 257 "<some.where.overrainbow>" directory created CWD overrainbow 431 No such directory CWD <some.where.overrainbow> 200 Working directory changed CWD <some.where> 200 Working directory changed to <some.where> MKD <unambiguous> 257 "<unambiguous>" directory created CWD <unambiguous>
请注意，第一个示例生成连接目录的子目录。 相比之下，第二个示例中的参数包含足够的信息，TOPS-20 可以判断 <unambiguous> 目录是顶级目录。 另请注意，在第一个示例中，用户通过尝试访问新创建的目录而不是 TOPS-20 返回的名称来“违反”协议。 如果存在 <overrainbow> 目录，则在这种情况下可能会导致问题； 这是某些 TOPS-20 实现中固有的歧义。 类似的考虑适用于 RMD 命令。 关键是：除非这样做会违反主机用于表示相对路径名和绝对路径名的约定，否则主机应该将 MKD 和 RMD 命令的操作数视为子目录。 MKD 命令的 257 回复必须始终包含创建的目录的绝对路径名。
附录3 – 关于FTP的 RFC
Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823), MIT-Project MAC, 16 April 1971. Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971. Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172 (NIC 6794), MIT-Project MAC, 23 June 1971. Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663), UCLA/CCN, 29 September 1971. Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265 (NIC 7813), MIT-Project MAC, 17 November 1971. McKenzie, Alex, "A Suggested Addition to File Transfer Protocol", RFC 281 (NIC 8163), BBN, 8 December 1971. Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC, 25 January 1972. Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596), MIT-Project MAC, 8 July 1972. Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)", RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972. Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah, 27 November 1972. Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972. Braden, Bob, "Comments on File Transfer Protocol", RFC 430 (NIC 13299), UCLA/CCN, 7 February 1973. Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction", RFC 438 (NIC 13770), BBN, 15 January 1973. Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN, 27 February 1973. McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN, 16 February 1973. Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458 (NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973. Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN, 12 July 1973. Krilanovich, Mark, and George Gregg, "Comments on the File Transfer Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974. Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974. Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White, "Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB, Ames Research Center, SRI-ARC, 28 February 1974. Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463 (NIC 14573), MIT-DMCG, 21 February 1973. Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN, 8 March 1973. Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919), MIT-DMCG, 6 March 1973. Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II", RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973. White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948), SRI-ARC, 8 March 1973. White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949), SRI-ARC, 8 March 1973. Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506 (NIC 16157), MIT-Multics, 26 June 1973. Day, John, "Memo to FTP Group (Proposal for File Access Protocol)", RFC 520 (NIC 16819), Illinois, 25 June 1973. Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532 (NIC 17451), UCSD-CC, 22 June 1973. Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN, 15 November 1973. McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation - Schedule Change", RFC 593 (NIC 20615), BBN and MITRE, 29 November 1973. Sussman, Julie, "FTP Error Code Usage for More Reliable Mail Service", RFC 630 (NIC 30237), BBN, 10 April 1974. Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843), UCLA/NMC, 5 June 1974. Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481), SU-AI, 10 May 1975. Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI, 28 May 1975. Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975. Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL, 31 October 1977. Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758), SRI-KL, 30 December 1977. Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT, 10 December 1978. Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI, June 1980. Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP Commands", RFC 776, BBN, December 1980. Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE, July 1985.
参考文档
[1] Feinler, Elizabeth, "Internet Protocol Transition Workbook", Network Information Center, SRI International, March 1982. [2] Postel, Jon, "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol Specification", RFC 854, ISI, May 1983. [4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943, ISI, April 1985.
