Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 5797
Updates: 959 A. Hoenes
Category: Standards Track TR-Sys
ISSN: 2070-1721 March 2010
Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 5797
Updates: 959 A. Hoenes
Category: Standards Track TR-Sys
ISSN: 2070-1721 March 2010
FTP Command and Extension Registry
FTP命令和扩展注册表
Abstract
摘要
Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both those supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command and Feature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry.
FTP规范的每个版本都添加了一些新命令，RFC959中总结了早期的命令。RFC 2389建立了指定和协商FTP扩展的机制。机制支持的扩展和不支持的扩展的数量继续增加。建立FTP命令和功能名称的IANA注册表，以减少名称冲突的可能性和由此产生的歧义。本规范建立了该注册表。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5797.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5797.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Registry Definition .............................................2
2.1. Registry Name ..............................................2
2.2. Registry Format ............................................2
2.3. Criteria for Registration ..................................4
2.4. Base FTP Commands ..........................................5
2.5. Obsolete Commands ..........................................5
3. Initial Contents of Registry ....................................6
4. Acknowledgments .................................................8
5. IANA Considerations .............................................9
6. Security Considerations .........................................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
1. Introduction ....................................................2
2. Registry Definition .............................................2
2.1. Registry Name ..............................................2
2.2. Registry Format ............................................2
2.3. Criteria for Registration ..................................4
2.4. Base FTP Commands ..........................................5
2.5. Obsolete Commands ..........................................5
3. Initial Contents of Registry ....................................6
4. Acknowledgments .................................................8
5. IANA Considerations .............................................9
6. Security Considerations .........................................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959 [RFC0959]. RFC 2389 [RFC2389] established a mechanism for specifying and negotiating extensions to the FTP protocol specified in RFC 959, by means of "FEAT Strings" identifying extensions supported by the FTP server, and sent in response to a "FEAT" command. The number of extensions continues to grow, not all of them supported by FEAT. An IANA registry is established to reduce the likelihood of a conflict of names and the consequent ambiguity and to encourage the sharing of information. This specification establishes that registry.
FTP规范的每个版本都添加了一些新命令，早期的命令在RFC959[RFC0959]中进行了总结。RFC 2389[RFC2389]建立了一种机制，用于指定和协商RFC 959中指定的FTP协议的扩展，通过“FEAT字符串”标识FTP服务器支持的扩展，并响应“FEAT”命令发送。扩展的数量继续增长，但并非所有扩展都得到了FEAT的支持。建立IANA登记册是为了减少名称冲突和由此产生的歧义的可能性，并鼓励信息共享。本规范建立了该注册表。
The name of this registry is "FTP Commands and Extensions".
此注册表的名称为“FTP命令和扩展”。
As specified in this RFC, IANA has established a registry for FTP commands and extensions. Registration requests and registry entries should include the following:
如本RFC中所述，IANA已为FTP命令和扩展建立了注册表。注册请求和注册条目应包括以下内容：
Command Name - The FTP command, either new or modified, used in the extension or with which the extension is used.
命令名—在扩展中使用或与扩展一起使用的新的或修改的FTP命令。
Following the long-standing practice to capitalize command names in specification documents for FTP, the command names are entered in all uppercase. For extensions amending the operation of a
按照FTP规范文档中命令名大写的长期做法，命令名以大写形式输入。有关修订
command, a plus sign ("+") is appended to the command name. However, if an extension affects the overall command parameter handling and/or transaction processing, instead of being bound to one command (or a small number of commands), the string "-N/A-" is entered.
命令，命令名后会附加一个加号（“+”）。但是，如果扩展影响整个命令参数处理和/或事务处理，而不是绑定到一个命令（或少量命令），则输入字符串“-N/a-”。
It is intended to have the registry entries ordered by ascending ASCII collation order of this column (including the "+" suffix if present).
它旨在使注册表项按此列的升序ASCII排序规则顺序排列（包括“+”后缀，如果存在）。
Extension name - The name of the extension.
扩展名—扩展名的名称。
FTP extensions predating RFC 2389 [RFC2389], and some extensions published after it, did not specify a keyword to identify the extension in a FEAT response. Some later specifications established FEAT strings with the respective command names as their keywords. In order to provide for keywords for future specifications in such cases, this document establishes 'placeholder' keywords to reserve reasonable feature names for future standardization. Similarly, placeholder keywords are used for the basic FTP commands specified in RFC 959 [RFC0959] and those of its predecessors that are still in use. These placeholder keywords are placed in the registry for convenience; it is not intended that they be returned in FEAT responses. To compensate for this idiosyncrasy, the column in the registry is entitled "FEAT Code", and to clearly distinguish between the two cases, defined FEAT keywords codes are listed in all uppercase, whereas placeholder keywords (henceforth called "pseudo FEAT codes") are listed in lowercase. Future specifications are allowed to "upgrade" a placeholder to a true keyword unless it is specifically declared 'immutable' below, but otherwise IANA maintains uniqueness of feature names (FEAT codes) based on case-insensitive comparison.
RFC 2389[RFC2389]之前的FTP扩展，以及它之后发布的一些扩展，没有在FEAT响应中指定关键字来标识扩展。后来的一些规范使用相应的命令名作为关键字建立了FEAT字符串。为了在这种情况下为将来的规范提供关键字，本文档建立了“占位符”关键字，以便为将来的标准化保留合理的特征名称。类似地，占位符关键字用于RFC 959[RFC0959]中指定的基本FTP命令以及仍在使用的先前命令。为了方便起见，这些占位符关键字被放置在注册表中；它们不打算以专长回应的形式返回。为了弥补这种特殊性，注册表中的列标题为“FEAT Code”，为了清楚区分这两种情况，定义的FEAT关键字代码以大写字母列出，而占位符关键字（此后称为“伪FEAT codes”）以小写字母列出。未来的规范允许将占位符“升级”为true关键字，除非下面明确声明为“不可变”，否则IANA将根据不区分大小写的比较保持功能名称（专长代码）的唯一性。
Description - A brief description of the extension and, where appropriate, the command.
描述-对扩展的简要描述，以及在适当的情况下对命令的简要描述。
FEAT String - (optional in registration requests to IANA)
专长字符串-（对IANA的注册请求中可选）
The string expected to be included in the response to the FEAT command [RFC2389] if the extension is supported.
如果支持扩展名，则预期将包含在对FEAT命令[RFC2389]的响应中的字符串。
In many cases, the FEAT string required to identify an extension only consists of the "FEAT Code", making this item redundant. Therefore, this item should only be specified if it is intended to register a FEAT string that contains mandatory elements other than the "FEAT Code" itself.
在许多情况下，标识扩展名所需的专长字符串只包含“专长代码”，这使得该项变得多余。因此，只有在注册包含除“专长代码”本身以外的必需元素的专长字符串时，才应指定此项。
Due to space restrictions, and to allow registrants to provide additional information, IANA should present these registration items (if given) in numbered footnotes to the table, not in an additional table column.
由于篇幅限制，为了允许注册人提供更多信息，IANA应在表格的编号脚注中提供这些注册项目（如有），而不是在额外的表格列中。
Command Type - The type (or 'kind') of the command.
命令类型-命令的类型（或“种类”）。
Section 4.1 of RFC 959 [RFC0959] introduced a subdivision of FTP commands into three types: Access control, transfer Parameter {setting}, and Service {execution}. For clarity, and as a service to the user of the registry, this subdivision is extended to all registered FTP commands, using the characteristic initial of the type, 'a', 'p', or 's', respectively, filed in the registry column titled "type"; combinations are allowed, e.g., 'p/s'.
RFC959[RFC0959]第4.1节将FTP命令细分为三种类型：访问控制、传输参数{设置}和服务{执行}。为清楚起见，作为对注册表用户的一项服务，此细分扩展到所有已注册的FTP命令，分别使用“a”、“p”或“s”类型的特征首字母，在注册表标题为“type”的列中存档；允许组合，例如“p/s”。
Conformance Requirements - The support expectation for the command.
一致性要求-对命令的支持期望。
RFC 959 specifies mandatory-to-implement commands and optional commands. This classification is carried over to all registered commands, using a column titled "conf" carrying a single character -- either 'm' or 'o', for "mandatory" and "optional", respectively. Similarly, obsoleted or historic entries are left in the registry to avoid conflicts with deployed implementations, and these entries are marked with 'h' (for "historic"). Beyond the initial registrations, Standards Action [RFC5226] is needed to register new "mandatory" entries or to move such entries to "historic".
RFC 959指定强制执行命令和可选命令。使用标题为“conf”的列携带单个字符，即“m”或“o”，分别表示“强制”和“可选”，将此分类传递到所有已注册的命令。类似地，过时的或历史性的条目保留在注册表中，以避免与已部署的实现发生冲突，并且这些条目标记为“h”（表示“历史”）。除了初始注册外，还需要标准行动[RFC5226]来注册新的“强制性”条目或将此类条目移至“历史性”条目。
Reference - A reference to an RFC or other definition of the extension and/or to implementations supporting it (see the next section).
引用-对RFC或扩展的其他定义和/或支持它的实现的引用（参见下一节）。
This registry is primarily intended to avoid conflicting uses of the same extension names and command keywords for different purposes, not to demonstrate that an extension is somehow "approved". The "Expert Review" method will be used, but the designated expert is expected to check only that at least one of the two criteria that follow are met.
此注册表的主要目的是避免为不同目的使用相同的扩展名和命令关键字时发生冲突，而不是证明某个扩展以某种方式被“批准”。将使用“专家审查”方法，但指定专家只需检查是否满足以下两个标准中的至少一个。
1. The extension is documented in a permanent and readily available public specification (this is the same as the "Specification Required" registration policy defined in RFC 5226 [RFC5226]).
1. 该扩展记录在一个永久且随时可用的公共规范中（这与RFC 5226[RFC5226]中定义的“所需规范”注册政策相同）。
2. The extension is actually implemented in FTP client and server systems that are generally available (not necessarily either free or unencumbered, but available).
2. 该扩展实际上是在FTP客户机和服务器系统中实现的，这些系统通常是可用的（不一定是免费的或无阻碍的，但可用）。
For an extension or command to be marked "mandatory" ('m' in the "conf" column), an IETF Standards Track specification is required. An IESG Standards Action is allowed to direct IANA to change the Conformance Requirements listed for any entry.
对于标记为“强制”的扩展或命令（“conf”列中的“m”），需要IETF标准跟踪规范。允许IESG标准行动指示IANA更改任何条目的合规性要求。
The following commands are part of the base FTP specification [RFC0959] and are listed in the registry with the immutable pseudo FEAT code "base".
以下命令是基本FTP规范[RFC0959]的一部分，在注册表中以不可变的伪FEAT代码“base”列出。
Mandatory commands:
强制命令：
ABOR, ACCT, ALLO, APPE, CWD, DELE, HELP, LIST, MODE, NLST, NOOP, PASS, PASV, PORT, QUIT, REIN, REST, RETR, RNFR, RNTO, SITE, STAT, STOR, STRU, TYPE, USER
ABOR、ACCT、ALLO、APPE、CWD、DELE、帮助、列表、模式、NLST、NOOP、PASV、端口、退出、REIN、REST、RETR、RNFR、RNTO、站点、STAT、STOR、STRU、类型、用户
Optional commands:
可选命令：
CDUP, MKD, PWD, RMD, SMNT, STOU, SYST
CDUP、MKD、PWD、RMD、SMNT、STOU、系统
Note: STD 3 [RFC1123] clarified and updated the status and implementation requirements of these standard FTP commands, and it contains important complementary information for the following commands:
注：STD 3[RFC1123]澄清并更新了这些标准FTP命令的状态和实施要求，其中包含以下命令的重要补充信息：
LIST, NLST, PASV, REST, SITE, STOU
列表、NLST、PASV、REST、站点、STOU
The following commands were specified as experimental in an extension to an early version of the FTP specification [RFC0775] but later deprecated by RFC 1123 [RFC1123], because Standard FTP [RFC0959] specifies their standard successors. They are listed in the registry with the immutable pseudo FEAT code "hist".
以下命令在FTP规范[RFC0775]早期版本的扩展中被指定为实验命令，但后来被RFC 1123[RFC1123]弃用，因为标准FTP[RFC0959]指定了它们的标准后续命令。它们与不可变的伪专长代码“hist”一起列在注册表中。
XCUP, XCWD, XMKD, XPWD, XRMD
XCUP、XCWD、XMKD、XPWD、XRMD
Implementation note: Deployed FTP clients still make use of the deprecated commands and most FTP servers support them as aliases for the standard commands.
实现说明：部署的FTP客户端仍然使用不推荐使用的命令，大多数FTP服务器支持将它们作为标准命令的别名。
The following commands were specified as part of the "FOOBAR" IPng effort in RFC 1545 [RFC1545] and, later, RFC 1639 [RFC1639] and are now obsolete. They are listed in the registry with the immutable pseudo FEAT code "hist".
以下命令在RFC 1545[RFC1545]和后来的RFC 1639[RFC1639]中被指定为“FOOBAR”IPng工作的一部分，现在已经过时。它们与不可变的伪专长代码“hist”一起列在注册表中。
LPRT, LPSV
LPRT，LPSV
As a service to users of the registry and the authors of existing specifications, all FTP commands and features published in RFCs after STD 3 [RFC1123] and up to the time of this writing were included in the registry upon creation.
作为对注册表用户和现有规范作者的服务，在STD 3[RFC1123]之后以及撰写本文之前在RFCs中发布的所有FTP命令和功能在创建时都包含在注册表中。
The following pseudo FEAT codes have been assigned, according to Section 2:
根据第2节，已分配以下伪FEAT代码：
base - FTP standard commands [RFC0959]
hist - Historic experimental commands [RFC0775], [RFC1639]
secu - FTP Security Extensions [RFC2228]
feat - FTP Feature Negotiation [RFC2389]
nat6 - FTP Extensions for NAT/IPv6 [RFC2428]
base - FTP standard commands [RFC0959]
hist - Historic experimental commands [RFC0775], [RFC1639]
secu - FTP Security Extensions [RFC2228]
feat - FTP Feature Negotiation [RFC2389]
nat6 - FTP Extensions for NAT/IPv6 [RFC2428]
+-------+------+-------------------+------+------+------------------+
| cmd | FEAT | description | type | conf | RFC#s/References |
| | Code | | | | and Notes |
+-------+------+-------------------+------+------+------------------+
| ABOR | base | Abort | s | m | 959 |
| ACCT | base | Account | a | m | 959 |
| ADAT | secu | Authentication/ | a | o | 2228, 2773, 4217 |
| | | Security Data | | | |
| ALLO | base | Allocate | s | m | 959 |
| APPE | base | Append (with | s | m | 959 |
| | | create) | | | |
| AUTH | secu | Authentication/ | a | o | 2228 |
| | | Security | | | |
| | | Mechanism | | | |
| AUTH+ | AUTH | Authentication/ | a | o | 2773, 4217 #2 |
| | | Security | | | |
| | | Mechanism | | | |
| CCC | secu | Clear Command | a | o | 2228 |
| | | Channel | | | |
| CDUP | base | Change to Parent | a | o | 959 |
| | | Directory | | | |
| CONF | secu | Confidentiality | a | o | 2228 |
| | | Protected Command | | | |
| CWD | base | Change Working | a | m | 959 |
| | | Directory | | | |
| DELE | base | Delete File | s | m | 959 |
| ENC | secu | Privacy Protected | a | o | 2228, 2773, 4217 |
| | | Command | | | |
| EPRT | nat6 | Extended Port | p | o | 2428 |
| EPSV | nat6 | Extended Passive | p | o | 2428 |
| | | Mode | | | |
+-------+------+-------------------+------+------+------------------+
| cmd | FEAT | description | type | conf | RFC#s/References |
| | Code | | | | and Notes |
+-------+------+-------------------+------+------+------------------+
| ABOR | base | Abort | s | m | 959 |
| ACCT | base | Account | a | m | 959 |
| ADAT | secu | Authentication/ | a | o | 2228, 2773, 4217 |
| | | Security Data | | | |
| ALLO | base | Allocate | s | m | 959 |
| APPE | base | Append (with | s | m | 959 |
| | | create) | | | |
| AUTH | secu | Authentication/ | a | o | 2228 |
| | | Security | | | |
| | | Mechanism | | | |
| AUTH+ | AUTH | Authentication/ | a | o | 2773, 4217 #2 |
| | | Security | | | |
| | | Mechanism | | | |
| CCC | secu | Clear Command | a | o | 2228 |
| | | Channel | | | |
| CDUP | base | Change to Parent | a | o | 959 |
| | | Directory | | | |
| CONF | secu | Confidentiality | a | o | 2228 |
| | | Protected Command | | | |
| CWD | base | Change Working | a | m | 959 |
| | | Directory | | | |
| DELE | base | Delete File | s | m | 959 |
| ENC | secu | Privacy Protected | a | o | 2228, 2773, 4217 |
| | | Command | | | |
| EPRT | nat6 | Extended Port | p | o | 2428 |
| EPSV | nat6 | Extended Passive | p | o | 2428 |
| | | Mode | | | |
| FEAT | feat | Feature | a | m #1 | 2389 |
| | | Negotiation | | | |
| HELP | base | Help | s | m | 959 |
| LANG | UTF8 | Language (for | p | o | 2640 |
| | | Server Messages) | | | |
| LIST | base | List | s | m | 959, 1123 |
| LPRT | hist | Data Port | p | h | 1545, 1639 |
| | | {FOOBAR} | | | |
| LPSV | hist | Passive Mode | p | h | 1545, 1639 |
| | | {FOOBAR} | | | |
| MDTM | MDTM | File Modification | s | o | 3659 |
| | | Time | | | |
| MIC | secu | Integrity | a | o | 2228, 2773, 4217 |
| | | Protected Command | | | |
| MKD | base | Make Directory | s | o | 959 |
| MLSD | MLST | List Directory | s | o | 3659 |
| | | (for machine) | | | |
| MLST | MLST | List Single | s | o | 3659 |
| | | Object | | | |
| MODE | base | Transfer Mode | p | m | 959 |
| NLST | base | Name List | s | m | 959, 1123 |
| NOOP | base | No-Op | s | m | 959 |
| OPTS | feat | Options | p | m #1 | 2389 |
| PASS | base | Password | a | m | 959 |
| PASV | base | Passive Mode | p | m | 959, 1123 |
| PBSZ | secu | Protection Buffer | p | o | 2228 |
| | | Size | | | |
| PBSZ+ | PBSZ | Protection Buffer | p | o | 4217 |
| | | Size | | | |
| PORT | base | Data Port | p | m | 959 |
| PROT | secu | Data Channel | p | o | 2228 |
| | | Protection Level | | | |
| PROT+ | PROT | Data Channel | p | o | 4217 |
| | | Protection Level | | | |
| PWD | base | Print Directory | s | o | 959 |
| QUIT | base | Logout | a | m | 959 |
| REIN | base | Reinitialize | a | m | 959 |
| REST | base | Restart | s/p | m | 959, 1123 |
| REST+ | REST | Restart (for | s/p | m | 3659 #3 |
| | | STREAM mode) | | | |
| RETR | base | Retrieve | s | m | 959 |
| RMD | base | Remove Directory | s | o | 959 |
| RNFR | base | Rename From | s/p | m | 959 |
| RNTO | base | Rename From | s | m | 959 |
| SITE | base | Site Parameters | s | m | 959, 1123 |
| SIZE | SIZE | File Size | s | o | 3659 |
| SMNT | base | Structure Mount | a | o | 959 |
| STAT | base | Status | s | m | 959 |
| FEAT | feat | Feature | a | m #1 | 2389 |
| | | Negotiation | | | |
| HELP | base | Help | s | m | 959 |
| LANG | UTF8 | Language (for | p | o | 2640 |
| | | Server Messages) | | | |
| LIST | base | List | s | m | 959, 1123 |
| LPRT | hist | Data Port | p | h | 1545, 1639 |
| | | {FOOBAR} | | | |
| LPSV | hist | Passive Mode | p | h | 1545, 1639 |
| | | {FOOBAR} | | | |
| MDTM | MDTM | File Modification | s | o | 3659 |
| | | Time | | | |
| MIC | secu | Integrity | a | o | 2228, 2773, 4217 |
| | | Protected Command | | | |
| MKD | base | Make Directory | s | o | 959 |
| MLSD | MLST | List Directory | s | o | 3659 |
| | | (for machine) | | | |
| MLST | MLST | List Single | s | o | 3659 |
| | | Object | | | |
| MODE | base | Transfer Mode | p | m | 959 |
| NLST | base | Name List | s | m | 959, 1123 |
| NOOP | base | No-Op | s | m | 959 |
| OPTS | feat | Options | p | m #1 | 2389 |
| PASS | base | Password | a | m | 959 |
| PASV | base | Passive Mode | p | m | 959, 1123 |
| PBSZ | secu | Protection Buffer | p | o | 2228 |
| | | Size | | | |
| PBSZ+ | PBSZ | Protection Buffer | p | o | 4217 |
| | | Size | | | |
| PORT | base | Data Port | p | m | 959 |
| PROT | secu | Data Channel | p | o | 2228 |
| | | Protection Level | | | |
| PROT+ | PROT | Data Channel | p | o | 4217 |
| | | Protection Level | | | |
| PWD | base | Print Directory | s | o | 959 |
| QUIT | base | Logout | a | m | 959 |
| REIN | base | Reinitialize | a | m | 959 |
| REST | base | Restart | s/p | m | 959, 1123 |
| REST+ | REST | Restart (for | s/p | m | 3659 #3 |
| | | STREAM mode) | | | |
| RETR | base | Retrieve | s | m | 959 |
| RMD | base | Remove Directory | s | o | 959 |
| RNFR | base | Rename From | s/p | m | 959 |
| RNTO | base | Rename From | s | m | 959 |
| SITE | base | Site Parameters | s | m | 959, 1123 |
| SIZE | SIZE | File Size | s | o | 3659 |
| SMNT | base | Structure Mount | a | o | 959 |
| STAT | base | Status | s | m | 959 |
| STOR | base | Store | s | m | 959 |
| STOU | base | Store Unique | a | o | 959, 1123 |
| STRU | base | File Structure | p | m | 959 |
| SYST | base | System | s | o | 959 |
| TYPE | base | Representation | p | m | 959 #4 |
| | | Type | | | |
| USER | base | User Name | a | m | 959 |
| XCUP | hist | {precursor for | s | h | 775, 1123 |
| | | CDUP} | | | |
| XCWD | hist | {precursor for | s | h | 775, 1123 |
| | | CWD} | | | |
| XMKD | hist | {precursor for | s | h | 775, 1123 |
| | | MKD} | | | |
| XPWD | hist | {precursor for | s | h | 775, 1123 |
| | | PWD} | | | |
| XRMD | hist | {precursor for | s | h | 775, 1123 |
| | | RMD} | | | |
| -N/A- | TVFS | Trivial Virtual | p | o | 3659 |
| | | File Store | | | |
+-------+------+-------------------+------+------+------------------+
| STOR | base | Store | s | m | 959 |
| STOU | base | Store Unique | a | o | 959, 1123 |
| STRU | base | File Structure | p | m | 959 |
| SYST | base | System | s | o | 959 |
| TYPE | base | Representation | p | m | 959 #4 |
| | | Type | | | |
| USER | base | User Name | a | m | 959 |
| XCUP | hist | {precursor for | s | h | 775, 1123 |
| | | CDUP} | | | |
| XCWD | hist | {precursor for | s | h | 775, 1123 |
| | | CWD} | | | |
| XMKD | hist | {precursor for | s | h | 775, 1123 |
| | | MKD} | | | |
| XPWD | hist | {precursor for | s | h | 775, 1123 |
| | | PWD} | | | |
| XRMD | hist | {precursor for | s | h | 775, 1123 |
| | | RMD} | | | |
| -N/A- | TVFS | Trivial Virtual | p | o | 3659 |
| | | File Store | | | |
+-------+------+-------------------+------+------+------------------+
Table 1
表1
Notes:
#1 While an IETF Standards Action would be required to make the FEAT
mechanism [RFC2389] mandatory, implementation of that extension
mechanism is clearly required in conjunction with any extension or
feature that depends on it.
#2 FEAT String for [RFC4217]: AUTH TLS
FEAT String for [RFC2773]: AUTH KEA-SKIPJACK
#3 FEAT String: REST STREAM
#4 FEAT String: TYPE {semicolon-separated list of supported types}
Notes:
#1 While an IETF Standards Action would be required to make the FEAT
mechanism [RFC2389] mandatory, implementation of that extension
mechanism is clearly required in conjunction with any extension or
feature that depends on it.
#2 FEAT String for [RFC4217]: AUTH TLS
FEAT String for [RFC2773]: AUTH KEA-SKIPJACK
#3 FEAT String: REST STREAM
#4 FEAT String: TYPE {semicolon-separated list of supported types}
Any work to update or extend FTP depends on the base specification in RFC 959. The contributions of its editors, Jon Postel and Joyce Reynolds, are gratefully acknowledged. The option-negotiation mechanism specified in RFC 2389 (and the accumulation of features that followed it) made this registry relevant; the authors of those documents are acknowledged as well.
更新或扩展FTP的任何工作都取决于RFC 959中的基本规范。该杂志编辑乔恩·波斯特尔和乔伊斯·雷诺兹的贡献得到了衷心的感谢。RFC 2389中规定的期权协商机制（以及随后的特征累积）使该登记册具有相关性；这些文件的作者也得到了承认。
Barry Leiba and Alexey Melnikov made several suggestions about earlier versions of this document, most of which have been incorporated.
巴里·莱巴（Barry Leiba）和阿列克谢·梅尔尼科夫（Alexey Melnikov）就本文件的早期版本提出了几点建议，其中大部分已被纳入。
Anthony Bryan spotted a few typographical errors.
安东尼·布莱恩发现了一些印刷错误。
Scott Bradner suggested a clarification to the "Expert Review" text.
斯科特·布拉德纳建议对“专家评论”文本进行澄清。
The authors appreciate the comments and support for this work received from FTP implementers and many IETF participants. Comments from the IESG helped to shape this document and registry to improve its utility.
作者感谢FTP实施者和许多IETF参与者对这项工作的评论和支持。IESG的评论有助于形成此文档和注册表，以提高其实用性。
IANA has established the registry described in Section 2 using the initial content specified in Section 3 and including the body of Sections 2.4 and 2.5 as explanatory text in the preface of the registry.
IANA已使用第3节规定的初始内容建立了第2节所述的登记册，并将第2.4节和第2.5节的正文作为登记册前言中的解释性文本。
New entries should be added to this registry when extensions to FTP are approved or defined in RFCs or when extensions that are already in use and well-documented are identified. In other words, the requirement for registration is a slightly relaxed version of "Specification Required" [RFC5226] with Expert Review. See Section 2.3 for specifics and exceptions.
当在RFC中批准或定义FTP扩展时，或当已在使用且有详细记录的扩展被识别时，应将新条目添加到此注册表。换句话说，注册要求是经过专家审查的“所需规范”[RFC5226]的稍微宽松版本。有关详细信息和例外情况，请参见第2.3节。
The creation of this registry provides improved documentation and protection against interoperability problems. It introduces no new security issues.
此注册表的创建提供了改进的文档和针对互操作性问题的保护。它没有引入新的安全问题。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998.
[RFC2389]Hethmon，P.和R.Elz，“文件传输协议的特征协商机制”，RFC 2389，1998年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC0775] Mankins, D., Franklin, D., and A. Owen, "Directory oriented FTP commands", RFC 775, December 1980.
[RFC0775]Mankins，D.，Franklin，D.，和A.Owen，“面向目录的FTP命令”，RFC 775，1980年12月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC1545] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1545, November 1993.
[RFC1545]Piscitello，D.，“大地址记录上的FTP操作（FOOBAR）”，RFC15451993年11月。
[RFC1639] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994.
[RFC1639]Piscitello，D.，“大地址记录上的FTP操作（FOOBAR）”，RFC1639，1994年6月。
[RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, October 1997.
[RFC2228]Horowitz，M.，“FTP安全扩展”，RFC2228，1997年10月。
[RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998.
[RFC2428]Allman，M.，Ostermann，S.，和C.Metz，“IPv6和NAT的FTP扩展”，RFC 24281998年9月。
[RFC2773] Housley, R. and P. Yee, "Encryption using KEA and SKIPJACK", RFC 2773, February 2000.
[RFC2773]Housley，R.和P.Yee，“使用KEA和SKIPJACK进行加密”，RFC 27732000年2月。
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[RFC4217]Ford Hutchinson，P.，“使用TLS保护FTP”，RFC 42172005年10月。
Authors' Addresses
作者地址
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA
美国马萨诸塞州剑桥322号马萨诸塞大道1770号约翰·C·克伦辛邮编：02140
Phone: +1 617 245 1457
EMail: john+ietf@jck.com
Phone: +1 617 245 1457
EMail: john+ietf@jck.com
Alfred Hoenes TR-Sys Gerlinger Str. 12 Ditzingen D-71254 Germany
Alfred Hoenes TR Sys Gerlinger Str.12 Ditzingen D-71254德国
EMail: ah@TR-Sys.de
EMail: ah@TR-Sys.de