Network Working Group P. Hethmon
Request for Comments: 2389 Hethmon Brothers
See Also: 959 R. Elz
Category: Standards Track University of Melbourne
August 1998
Network Working Group P. Hethmon
Request for Comments: 2389 Hethmon Brothers
See Also: 959 R. Elz
Category: Standards Track University of Melbourne
August 1998
Feature negotiation mechanism for the File Transfer Protocol
文件传输协议的特征协商机制
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
The File Transfer Protocol is, from time to time, extended with new commands, or facilities. Implementations of the FTP protocol cannot be assumed to all immediately implement all newly defined mechanisms. This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server.
文件传输协议不时通过新的命令或设施进行扩展。不能假设FTP协议的实现都会立即实现所有新定义的机制。本文档提供了一种机制，通过该机制，FTP协议的客户端可以发现特定FTP服务器支持哪些新功能。
Table of Contents
目录
Abstract ................................................ 1
1 Introduction ............................................ 2
2 Document Conventions .................................... 2
2.1 Basic Tokens ............................................ 3
2.2 Server Replies .......................................... 3
3 Knowledge of Extra Capabilities - the FEAT Command ...... 3
3.1 Feature (FEAT) Command Syntax ........................... 4
3.2 FEAT Command Responses .................................. 4
3.3 Rationale for FEAT ...................................... 6
4 The OPTS Command ........................................ 6
5 Security Considerations ................................. 7
6 References .............................................. 8
Acknowledgements ........................................ 8
Editors' Addresses ...................................... 8
Full Copyright Statement ................................ 9
Abstract ................................................ 1
1 Introduction ............................................ 2
2 Document Conventions .................................... 2
2.1 Basic Tokens ............................................ 3
2.2 Server Replies .......................................... 3
3 Knowledge of Extra Capabilities - the FEAT Command ...... 3
3.1 Feature (FEAT) Command Syntax ........................... 4
3.2 FEAT Command Responses .................................. 4
3.3 Rationale for FEAT ...................................... 6
4 The OPTS Command ........................................ 6
5 Security Considerations ................................. 7
6 References .............................................. 8
Acknowledgements ........................................ 8
Editors' Addresses ...................................... 8
Full Copyright Statement ................................ 9
This document amends the File Transfer Protocol (FTP) [1]. Two new commands are added: "FEAT" and "OPTS".
本文件修订了文件传输协议（FTP）[1]。添加了两个新命令：“专长”和“选择”。
These commands allow a client to discover which optional commands a server supports, and how they are supported, and to select among various options that any FTP command may support.
这些命令允许客户端发现服务器支持哪些可选命令，以及如何支持这些命令，并在任何FTP命令可能支持的各种选项中进行选择。
This document makes use of the document conventions defined in BCP14 [2]. That provides the interpretation of some capitalized words like MUST, SHOULD, etc.
本文件使用了BCP14[2]中定义的文件约定。这提供了一些大写单词的解释，如MUST、SHOULD等。
Terms defined in [1] will be used here as defined there. These include ASCII, reply, server-FTP process, user-FTP process, server-PI, user-PI, and user.
[1]中定义的术语将在此处使用。这些包括ASCII、应答、服务器FTP进程、用户FTP进程、服务器PI、用户PI和用户。
Syntax required is defined using the Augmented BNF defined in [3]. Some general ABNF definitions are required throughout the document, those will be defined here. At first reading, it may be wise to simply recall that these definitions exist here, and skip to the next section.
所需语法是使用[3]中定义的扩充BNF定义的。本文件中需要一些通用ABNF定义，这些定义将在此处定义。在第一次阅读时，明智的做法是简单地回忆一下这里存在这些定义，然后跳到下一节。
This document imports the definitions given in Appendix A of [3]. There definitions will be found for basic ABNF elements like ALPHA, DIGIT, VCHAR, SP, etc. To that, the following terms are added for use in this document.
本文件引入了[3]附录A中给出的定义。可以找到基本ABNF元素的定义，如ALPHA、DIGIT、VCHAR、SP等。除此之外，本文件中还添加了以下术语。
TCHAR = VCHAR / SP / HTAB ; visible plus white space
TCHAR = VCHAR / SP / HTAB ; visible plus white space
The TCHAR type, and VCHAR from [3], give basic character types from varying sub-sets of the ASCII character set for use in various commands and responses.
TCHAR类型和[3]中的VCHAR提供了ASCII字符集不同子集的基本字符类型，用于各种命令和响应。
error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT
error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT
Note that in ABNF, strings literals are case insensitive. That convention is preserved in this document. However note that ALPHA, in particular, is case sensitive, as are VCHAR and TCHAR.
请注意，在ABNF中，字符串和文本不区分大小写。该公约保留在本文件中。但是请注意，ALPHA尤其区分大小写，VCHAR和TCHAR也是如此。
Section 4.2 of [1] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change. Implementors should note that the ABNF syntax (which was not used in [1]) in this document, and other FTP related documents, sometimes shows replies using the one line format. Unless otherwise explicitly stated, that is not intended to imply that multi-line responses are not permitted. Implementors should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) may be of the multiline format described in [1].
[1]的第4.2节定义了服务器PI对来自用户PI的FTP命令的回复的格式和含义。这些回复约定在这里使用，没有任何更改。实施者应注意，本文档和其他FTP相关文档中的ABNF语法（在[1]中未使用）有时显示使用单行格式的回复。除非另有明确说明，否则这并不意味着不允许多行响应。实施者应假设，除非另有说明，否则对任何FTP命令（包括QUIT）的任何回复都可能是[1]中描述的多行格式。
Throughout this document, replies will be identified by the three digit code that is their first element. Thus the term "500 Reply" means a reply from the server-PI using the three digit code "500".
在本文件中，答复将以三位数代码标识，这是答复的第一个要素。因此，术语“500应答”是指来自服务器PI的使用三位数代码“500”的应答。
It is not to be expected that all servers will necessarily support all of the new commands defined in all future amendments to the FTP protocol. In order to permit clients to determine which new commands are supported by a particular server, without trying each possible command, one new command is added to the FTP command repertoire. This command requests the server to list all extension commands, or extended mechanisms, that it supports. That is, all defined and specified commands and features not defined in [1], or this document, must be included in the FEAT command output in the form specified in
并非所有服务器都必须支持FTP协议未来所有修订版中定义的所有新命令。为了允许客户端确定特定服务器支持哪些新命令，而无需尝试每个可能的命令，将向FTP命令库中添加一个新命令。此命令要求服务器列出其支持的所有扩展命令或扩展机制。也就是说，[1]或本文档中未定义的所有已定义和指定的命令和功能必须以中指定的形式包含在FEAT命令输出中
the document that defines the extension.
定义扩展名的文档。
User-FTP PIs must expect to see, in FEAT command responses, unknown features listed. This is not an error, and simply indicates that the server-FTP implementor has seen, and implemented, the specification of a new feature that is unknown to the user-FTP.
用户FTP PI必须期望在FEAT命令响应中看到列出的未知功能。这不是一个错误，只是表明服务器FTP实现者已经看到并实现了用户FTP未知的新功能的规范。
feat = "Feat" CRLF
feat=“feat”CRLF
The FEAT command consists solely of the word "FEAT". It has no parameters or arguments.
专长命令仅包含“专长”一词。它没有参数或参数。
Where a server-FTP process does not support the FEAT command, it will respond to the FEAT command with a 500 or 502 reply. This is simply the normal "unrecognized command" reply that any unknown command would elicit. Errors in the command syntax, such as giving parameters, will result in a 501 reply.
如果服务器FTP进程不支持FEAT命令，它将以500或502回复FEAT命令。这只是任何未知命令都会引发的正常“无法识别的命令”回复。命令语法中的错误（如给出参数）将导致501回复。
Server-FTP processes that recognize the FEAT command, but implement no extended features, and therefore have nothing to report, SHOULD respond with the "no-features" 211 reply. However, as this case is practically indistinguishable from a server-FTP that does not recognize the FEAT command, a 500 or 502 reply MAY also be used. The "no-features" reply MUST NOT use the multi-line response format, exactly one response line is required and permitted.
服务器FTP进程可以识别FEAT命令，但没有实现扩展功能，因此没有任何要报告的内容，应该以“无功能”211回复进行响应。但是，由于这种情况实际上无法与不识别FEAT命令的服务器FTP区分开来，因此也可以使用500或502回复。“无功能”回复不得使用多行回复格式，只需要并允许一行回复。
Replies to the FEAT command MUST comply with the following syntax. Text on the first line of the reply is free form, and not interpreted, and has no practical use, as this text is not expected to be revealed to end users. The syntax of other reply lines is precisely defined, and if present, MUST be exactly as specified.
对FEAT命令的回复必须符合以下语法。回复第一行的文本是自由形式的，没有解释，没有实际用途，因为该文本预计不会透露给最终用户。其他回复行的语法是精确定义的，如果存在，则必须与指定的完全相同。
feat-response = error-response / no-features / feature-listing
no-features = "211" SP *TCHAR CRLF
feature-listing = "211-" *TCHAR CRLF
1*( SP feature CRLF )
"211 End" CRLF
feature = feature-label [ SP feature-parms ]
feature-label = 1*VCHAR
feature-parms = 1*TCHAR
feat-response = error-response / no-features / feature-listing
no-features = "211" SP *TCHAR CRLF
feature-listing = "211-" *TCHAR CRLF
1*( SP feature CRLF )
"211 End" CRLF
feature = feature-label [ SP feature-parms ]
feature-label = 1*VCHAR
feature-parms = 1*TCHAR
Note that each feature line in the feature-listing begins with a single space. That space is not optional, nor does it indicate general white space. This space guarantees that the feature line can
请注意，要素列表中的每个要素行都以单个空格开头。该空格不是可选的，也不表示一般空白。此空间保证要素线可以
never be misinterpreted as the end of the feature-listing, but is required even where there is no possibility of ambiguity.
永远不要被误解为功能列表的结尾，但即使在不存在歧义的情况下也需要。
Each extension supported must be listed on a separate line to facilitate the possible inclusion of parameters supported by each extension command. The feature-label to be used in the response to the FEAT command will be specified as each new feature is added to the FTP command set. Often it will be the name of a new command added, however this is not required. In fact it is not required that a new feature actually add a new command. Any parameters included are to be specified with the definition of the command concerned. That specification shall also specify how any parameters present are to be interpreted.
支持的每个扩展必须在单独的行中列出，以便于可能包含每个扩展命令支持的参数。将每个新功能添加到FTP命令集中时，将指定在响应FEAT命令时使用的功能标签。通常是添加的新命令的名称，但这不是必需的。事实上，并不要求新功能实际添加新命令。包括的任何参数都应与相关命令的定义一起指定。该规范还应规定如何解释存在的任何参数。
The feature-label and feature-parms are nominally case sensitive, however the definitions of specific labels and parameters specify the precise interpretation, and it is to be expected that those definitions will usually specify the label and parameters in a case independent manner. Where this is done, implementations are recommended to use upper case letters when transmitting the feature response.
特征标签和特征参数名义上是区分大小写的，但是特定标签和参数的定义规定了精确的解释，预计这些定义通常会以独立于大小写的方式规定标签和参数。如果这样做了，建议在传输特性响应时使用大写字母。
The FEAT command itself is not included in the list of features supported, support for the FEAT command is indicated by return of a reply other than a 500 or 502 reply.
FEAT命令本身不包括在支持的功能列表中，对FEAT命令的支持通过返回500或502回复以外的回复来表示。
A typical example reply to the FEAT command might be a multiline reply of the form:
对FEAT命令的典型回复示例可能是以下形式的多行回复：
C> feat
S> 211-Extensions supported:
S> MLST size*;create;modify*;perm;media-type
S> SIZE
S> COMPRESSION
S> MDTM
S> 211 END
C> feat
S> 211-Extensions supported:
S> MLST size*;create;modify*;perm;media-type
S> SIZE
S> COMPRESSION
S> MDTM
S> 211 END
The particular extensions shown here are simply examples of what may be defined in other places, no particular meaning should be attributed to them. Recall also, that the feature names returned are not command names, as such, but simply indications that the server possesses some attribute or other.
此处所示的特定扩展只是其他地方可能定义的示例，不应赋予它们特定的含义。还记得，返回的功能名称本身并不是命令名，而是服务器拥有某些属性或其他属性的简单指示。
The order in which the features are returned is of no importance, server-FTP processes are not required to implement any particular order, or even to consistently return the same order when the command is repeated.
返回特性的顺序并不重要，服务器FTP进程不需要实现任何特定的顺序，甚至在重复命令时不需要一致地返回相同的顺序。
FTP implementations which support FEAT MUST include in the response to the FEAT command all properly documented FTP extensions beyond those commands and mechanisms described in RFC959 [1], including any which existed before the existence of FEAT. That is, when a client receives a FEAT response from an FTP server, it can assume that the only extensions the server supports are those that are listed in the FEAT response.
支持FEAT的FTP实现必须在对FEAT命令的响应中包括RFC959[1]中描述的命令和机制之外的所有正确记录的FTP扩展，包括FEAT存在之前存在的任何扩展。也就是说，当客户端从FTP服务器接收到FEAT响应时，它可以假定服务器支持的唯一扩展是FEAT响应中列出的扩展。
User-FTP processes should, however, be aware that there have been several FTP extensions developed, and in widespread use, prior to the adoption of this document and the FEAT command. The effect of this is that an error response to the FEAT command does not necessarily imply that those extensions are not supported by the server-FTP process. User-PIs should test for such extensions individually if an error response has been received to the FEAT command.
但是，用户FTP进程应该知道，在采用本文档和FEAT命令之前，已经开发了几个FTP扩展，并且已经广泛使用。这样做的结果是，对FEAT命令的错误响应并不一定意味着服务器FTP进程不支持这些扩展。如果收到FEAT命令的错误响应，用户PI应该单独测试这些扩展。
While not absolutely necessary, a standard mechanism for the server-PI to inform the user-PI of any features and extensions supported will help reduce unnecessary traffic between the user-PI and server-PI as more extensions may be introduced in the future. If no mechanism existed for this, a user-FTP process would have to try each extension in turn resulting in a series of exchanges between the user-PI and server-PI. Apart from being possibly wasteful, this procedure may not always be possible, as issuing of a command just to determine if it is supported or not may have some effect that is not desired.
虽然并非绝对必要，但服务器PI通知用户PI所支持的任何特性和扩展的标准机制将有助于减少用户PI和服务器PI之间不必要的通信量，因为将来可能会引入更多扩展。如果不存在这种机制，那么用户FTP进程必须依次尝试每个扩展，从而在用户PI和服务器PI之间进行一系列交换。除了可能造成浪费外，此过程可能并不总是可行的，因为仅发出命令以确定其是否受支持可能会产生一些不希望的效果。
The OPTS (options) command allows a user-PI to specify the desired behavior of a server-FTP process when another FTP command (the target command) is later issued. The exact behavior, and syntax, will vary with the target command indicated, and will be specified with the definition of that command. Where no OPTS behavior is defined for a particular command there are no options available for that command.
OPTS（options）命令允许用户PI在稍后发出另一个FTP命令（目标命令）时指定服务器FTP进程的所需行为。确切的行为和语法将随指示的目标命令而变化，并将随该命令的定义而指定。如果没有为特定命令定义OPTS行为，则该命令没有可用的选项。
Request Syntax:
opts = opts-cmd SP command-name
[ SP command-options ] CRLF
opts-cmd = "opts"
command-name = <any FTP command which allows option setting>
command-options = <format specified by individual FTP command>
Request Syntax:
opts = opts-cmd SP command-name
[ SP command-options ] CRLF
opts-cmd = "opts"
command-name = <any FTP command which allows option setting>
command-options = <format specified by individual FTP command>
Response Syntax:
opts-response = opts-good / opts-bad
opts-good = "200" SP response-message CRLF
opts-bad = "451" SP response-message CRLF /
"501" SP response-message CRLF
response-message = *TCHAR
Response Syntax:
opts-response = opts-good / opts-bad
opts-good = "200" SP response-message CRLF
opts-bad = "451" SP response-message CRLF /
"501" SP response-message CRLF
response-message = *TCHAR
An "opts-good" response (200 reply) MUST be sent when the command-name specified in the OPTS command is recognized, and the command-options, if any, are recognized, and appropriate. An "opts-bad" response is sent in other cases. A 501 reply is appropriate for any permanent error. That is, for any case where simply repeating the command at some later time, without other changes of state, will also be an error. A 451 reply should be sent where some temporary condition at the server, not related to the state of communications between user and server, prevents the command being accepted when issued, but where if repeated at some later time, a changed environment for the server-FTP process may permit the command to succeed. If the OPTS command itself is not recognized, a 500 or 502 reply will, of course, result.
当opts命令中指定的命令名被识别，并且命令选项（如果有的话）被识别且合适时，必须发送“opts良好”响应（200回复）。在其他情况下会发送“opts bad”响应。501回复适用于任何永久性错误。也就是说，在任何情况下，如果只是在以后某个时间重复该命令，而不进行其他状态更改，也将是一个错误。如果服务器上的某些临时条件（与用户和服务器之间的通信状态无关）阻止命令在发出时被接受，但如果在稍后某个时间重复，服务器FTP过程的更改环境可能允许命令成功，则应发送451回复。如果无法识别OPTS命令本身，当然会得到500或502回复。
The OPTS command MUST be implemented whenever the FEAT command is implemented. Because of that, there is no indication in the list of features returned by FEAT to indicate that the OPTS command itself is supported. Neither the FEAT command, nor the OPTS command, have any optional functionality, thus there are no "OPTS FEAT" or "OPTS OPTS" commands.
无论何时执行FEAT命令，都必须执行OPTS命令。因此，在FEAT返回的特性列表中，没有任何迹象表明OPTS命令本身是受支持的。FEAT命令和OPTS命令都没有任何可选功能，因此没有“OPTS FEAT”或“OPTS OPTS”命令。
No significant new security issues, not already present in the FTP protocol, are believed to have been created by this extension. However, this extension does provide a mechanism by which users can determine the capabilities of an FTP server, and from which additional information may be able to be deduced. While the same basic information could be obtained by probing the server for the various commands, if the FEAT command were not provided, that method may reveal an attacker by logging the attempts to access various extension commands. This possibility is not considered a serious enough threat to be worthy of any remedial action.
据信，此扩展不会造成FTP协议中尚未出现的重大新安全问题。但是，此扩展确实提供了一种机制，用户可以通过该机制确定FTP服务器的功能，并可以从中推断出其他信息。虽然通过探测服务器上的各种命令可以获得相同的基本信息，但如果未提供FEAT命令，该方法可能会通过记录访问各种扩展命令的尝试来发现攻击者。这种可能性被认为是不够严重的威胁，不值得采取任何补救行动。
The security of any additional features that might be reported by the FEAT command, and manipulated by the OPTS command, should be addressed where those features are defined.
任何可能由FEAT命令报告并由OPTS命令操作的附加功能的安全性，都应该在定义这些功能的地方加以解决。
[1] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[1] Postel，J.和J.Reynolds，“文件传输协议（FTP）”，标准9，RFC 959，1985年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[3] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
Acknowledgements
致谢
This protocol extension was developed in the FTPEXT Working Group of the IETF, and the members of that group are all acknowledged as its creators.
该协议扩展是在IETF的FTPEXT工作组中开发的，该工作组的成员都被公认为其创建者。
Editors' Addresses
编辑地址
Paul Hethmon Hethmon Brothers 2305 Chukar Road Knoxville, TN 37923 USA
保罗·赫特蒙·赫特蒙兄弟美国田纳西州诺克斯维尔丘卡尔路2305号，邮编：37923
Phone: +1 423 690 8990
Email: phethmon@hethmon.com
Phone: +1 423 690 8990
Email: phethmon@hethmon.com
Robert Elz University of Melbourne Department of Computer Science Parkville, Vic 3052 Australia
罗伯特·埃尔兹墨尔本大学计算机科学系帕克维尔，澳大利亚VIC 3052
Email: kre@munnari.OZ.AU
Email: kre@munnari.OZ.AU
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。