[要約] RFC 2389は、FTPのための機能交渉メカニズムについての要約です。このRFCの目的は、クライアントとサーバーが使用可能な機能を交渉し、最適なファイル転送を実現することです。
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
This document amends the File Transfer Protocol (FTP) [1]. Two new commands are added: "FEAT" and "OPTS".
このドキュメントは、ファイル転送プロトコル（FTP）[1]を修正します。 「FEAT」と「OPTS」の2つの新しいコマンドが追加されました。
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で与えられた定義をインポートします。 ALPHA、DIGIT、VCHAR、SPなどの基本的なABNF要素の定義があります。それに加えて、このドキュメントで使用するために次の用語が追加されています。
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
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からFTPコマンドへのサーバーPIによる応答の形式と意味を定義しています。ここでは、これらの返信規則をそのまま使用します。実装者は、このドキュメントおよび他のFTP関連ドキュメントのABNF構文（[1]では使用されなかった）が、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".
このドキュメント全体で、返信は最初の要素である3桁のコードで識別されます。したがって、「500応答」という用語は、3桁のコード「500」を使用したサーバーPIからの応答を意味します。
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 the document that defines the extension.
すべてのサーバーがFTPプロトコルの将来のすべての修正で定義されたすべての新しいコマンドを必ずしもサポートすることは期待されていません。クライアントが特定のサーバーでサポートされている新しいコマンドを判別できるようにするには、考えられる各コマンドを試行せずに、FTPコマンドのレパートリーに1つの新しいコマンドを追加します。このコマンドは、サーバーがサポートするすべての拡張コマンドまたは拡張メカニズムをリストするようサーバーに要求します。つまり、[1]またはこのドキュメントで定義されていないすべての定義および指定されたコマンドと機能は、拡張機能を定義するドキュメントで指定された形式でFEATコマンドの出力に含める必要があります。
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.
FEATコマンドは、「FEAT」という単語のみで構成されています。パラメータや引数はありません。
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コマンドをサポートしていない場合、FEATコマンドに500または502応答で応答します。これは、不明なコマンドが引き出す通常の「認識されないコマンド」の応答です。パラメータの指定などのコマンド構文のエラーは、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.
FEATコマンドを認識するサーバーFTPプロセスは、拡張機能を実装していないため、レポートするものは何もないため、「no-features」211応答で応答する必要があります（SHOULD）。ただし、このケースはFEATコマンドを認識しないサーバーFTPと事実上区別がつかないため、500または502の応答も使用される場合があります。 "no-features"応答は、複数行の応答形式を使用してはなりません。厳密に1行の応答行が必要であり、許可されます。
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
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.
feature-labelとfeature-parmsは、名目上は大文字と小文字を区別しますが、特定のラベルとパラメーターの定義は正確な解釈を指定します。これらの定義は通常、ラベルとパラメーターを大文字と小文字を区別せずに指定することが予想されます。これが行われる場合、機能の応答を送信するときに大文字を使用するように実装することをお勧めします。
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
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プロセスでサポートされていないことを必ずしも意味しないということです。ユーザーPIは、FEATコマンドに対するエラー応答が受信された場合、そのような拡張を個別にテストする必要があります。
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（オプション）コマンドを使用すると、後で別のFTPコマンド（ターゲットコマンド）が発行されたときに、ユーザーPIがサーバー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>
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-good」応答（200応答）は、OPTSコマンドで指定されたコマンド名が認識され、コマンドオプション（ある場合）が認識され、適切である場合に送信する必要があります。その他の場合は、「opts-bad」応答が送信されます。 501応答は、永続的なエラーに適しています。つまり、後で他の状態を変更せずに単にコマンドを繰り返すだけの場合も、エラーになります。 451応答は、ユーザーとサーバー間の通信状態に関係のないサーバーの一時的な状態により、コマンドが発行されたときにコマンドが受け入れられない場合に送信する必要がありますが、後で繰り返すと、サーバーの環境が変更されます。 FTPプロセスがコマンドの成功を許可する場合があります。もちろん、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.
OPTSコマンドは、FEATコマンドを実装する場合は必ず実装する必要があります。そのため、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、「File Transfer Protocol（FTP）」、STD 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
Paul Hethmon Hethmon Brothers 2305 Chukar Road Knoxville、TN 37923 USA
Phone: +1 423 690 8990
Email: phethmon@hethmon.com
Robert Elz University of Melbourne Department of Computer Science Parkville, Vic 3052 Australia
ロバートエルツメルボルン大学コンピュータサイエンス学科パークビルビクトリア3052オーストラリア
Email: kre@munnari.OZ.AU
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。