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
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仕様のすべてのバージョンはRFC 2389 RFC 959にまとめ早いもので、いくつかの新しいコマンドを追加した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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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仕様のすべてのバージョンは、RFC 959 [RFC0959]にまとめ早いもので、いくつかの新しいコマンドを追加しました。 RFC 2389 [RFC2389]は拡張FTPサーバによってサポートされ、そして「FEAT」コマンドに応答して送信を識別する「FEAT文字列」によって、RFC 959で指定されたFTPプロトコルへの拡張を指定して交渉するためのメカニズムを確立しました。拡張子の数がすべてではないそれらの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 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.
FTPの仕様文書内のコマンド名を大文字にする長年の慣行に従い、コマンド名はすべて大文字で入力されます。コマンドの動作を修正拡張するために、プラス記号は、（「+」）コマンド名に付加されます。拡張は、全体的なコマンドパラメータ処理及び/又はトランザクション処理に影響を与える場合は、代わりに一つのコマンド（またはコマンドの少数）に結合され、文字列「 - 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.
FTPのRFC 2389 [RFC2389]をより以前の拡張機能、およびそれ以降に出版されたいくつかの拡張機能は、FEAT応答の拡張を識別するためのキーワードを指定していませんでした。いくつかの後の仕様は、そのキーワードとして、各コマンド名とFEATの文字列を設立します。そのような場合には将来の仕様のためのキーワードを提供するためには、この文書には、将来の標準化のための合理的な機能名を予約する「プレースホルダ」のキーワードを確立します。同様に、プレースホルダキーワードは、RFC 959 [RFC0959]とまだ使用中である前任者のものに指定された基本的なFTPコマンドのために使用されます。これらのプレースホルダキーワードは便宜上、レジストリに配置されています。彼らがFEAT応答で返されることを意図していません。この特異性を補償するために、レジストリの列は、「FEATコード」と題され、プレースホルダキーワード（以下、いわゆる「擬似FEATコードが」）であるのに対し、明らかに2例を区別するために、定義されたFEATは、コードが全て大文字で記載されているキーワード小文字に記載されています。将来の仕様は、それが特に下記の「不変」と宣言されていない限り、真のキーワードにプレースホルダを「アップグレード」することができ、それ以外はIANAは、大文字と小文字を区別しない比較に基づいて、機能名（FEATコード）の一意性を維持しています。
Description - A brief description of the extension and, where appropriate, the command.
説明 - 拡張と、適切な、コマンドの簡単な説明。
FEAT String - (optional in registration requests to IANA)
FEAT文字列 - （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.
多くの場合、拡張子を識別するために必要なFEATの文字列にのみ、この項目を冗長化、「FEATコード」で構成されています。 「FEATコード」そのものよりも、他の必須の要素が含まれていFEATの文字列を登録しようとする場合したがって、この項目は、必ず指定する必要があります。
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'.
アクセス制御、パラメータ{設定}を転送し、サービス{実行}：RFC 959 [RFC0959]のセクション4.1は、FTPの細分化は三種類にコマンドを導入しました。明確にするために、レジストリのユーザへのサービスとして、この細分化は '、「P」型の特性初期を使用して、すべての登録されたFTPコマンドに拡張され、または「S」、それぞれに提出「タイプ」と題されたレジストリ列。組み合わせは、例えば、 '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は、実装に必須のコマンドとオプションのコマンドを指定します。 「M」または「O」は、「必須」と「オプション」のいずれかで、それぞれ - この分類は、単一の文字を運ぶ「CONF」というタイトルのカラムを使用して、登録されたすべてのコマンドに引き継がれます。同様に、廃止または歴史的なエントリが展開実装との衝突を避けるために、レジストリに残されており、これらのエントリは、（「歴史」の場合）「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コード「塩基」とレジストリに記載されています。
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、HELP、LIST、MODE、NLST、NOOP、PASS、PASV、PORT、QUIT、REIN、REST、RETR、RNFR、RNTO、SITE、STAT、STOR、STRU、TYPE、ユーザー
Optional commands:
オプションのコマンド：
CDUP, MKD, PWD, RMD, SMNT, STOU, SYST
CDUP、MKD、PWD、RMD、SMNT、STOU、SYST
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
LIST、NLST、PASV、REST、SITE、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 [RFC0959]は彼らの標準後継者を指定するため、次のコマンドは、FTP仕様の初期バージョン[RFC0775]が、後にRFC 1123 [RFC1123]で非推奨に拡張して、実験として指定されました。これらは不変疑似FEATコード「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の努力の一部として指定され、廃止されました。これらは不変疑似FEATコード「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.
レジストリのユーザーと既存の仕様の作成者へのサービスとして、すべてのFTPコマンドと機能はSTD 3 [RFC1123]の後にRFCで出版され、この記事の執筆時点までの作成時に、レジストリに含まれていました。
The following pseudo FEAT codes have been assigned, according to Section 2:
以下の擬似FEATコードは、第2節によれば、割り当てられています：
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]
ベース - FTPの標準コマンド[RFC0959] HIST - 歴史的な実験のコマンド[RFC0775]、[RFC1639] SECU - FTPセキュリティ拡張[RFC2228]偉業 - FTP機能の交渉[RFC2389] nat6 - NAT / IPv6のFTP拡張[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 | | | |
| 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 |偉業|特集| | M＃1 | 2389 | | | |交渉| | | | | HELP |ベース|ヘルプ| S | M | 959 | | LANG | UTF8 |言語（用| P | O | 2640年| | | |サーバーメッセージ）| | | | | LIST |ベース|一覧| S | M | 959、1123 | | LPRT | HIST |データポート| P |時間| 1545年、1639 | | | | {FOOBAR} | | | | | LPSV | HIST |パッシブモード| P |時間| 1545年、1639 | | | | {FOOBAR} | | | | | MDTM | MDTM |ファイルの変更| S | O | 3659 | | | |時間| | | | | MIC | SECU |整合性| | O | 2228年、2773年、4217 | | | |保護されたコマンド| | | | | MKD |ベース|ディレクトリを作成します| S | O | 959 | | MLSD | MLST |リストディレクトリ| S | O | 3659 | | | | （機械用）| | | | | MLST | MLST |単一のリスト| S | O | 3659 | | | |オブジェクト| | | | | MODE |ベース|転送モード| P | M | 959 | | NLST |ベース|リストに名前を付け| S | M | 959、1123 | | NOOP |ベース|無操作なし| S | M | 959 | | OPTS |偉業|オプション| P | M＃1 | 2389 | | PASS |ベース|パスワード| | M | 959 | | PASV |ベース|パッシブモード| P | M | 959、1123 | | PBSZ | SECU |保護バッファ| P | O | 2228 | | | |サイズ| | | | | PBSZ + | PBSZ |保護バッファ| P | O | 4217 | | | |サイズ| | | | | PORT |ベース|データポート| P | M | 959 | | PROT | SECU |データチャネル| P | O | 2228 | | | |保護レベル| | | | | PROT + | PROT |データチャネル| P | O | 4217 | | | |保護レベル| | | | | PWD |ベース|ディレクトリを印刷| S | O | 959 | | QUIT |ベース|ログアウト| | M | 959 | | REIN |ベース|再初期化| | M | 959 | | REST |ベース|再起動してください| S / P | M | 959、1123 | | REST + | REST |再起動（するため| S / P | M | 3659＃3 | | | |ストリームモード）| | | | | RETR |ベース|取得| S | M | 959 | | RMD |ベース|ディレクトリを削除します| S | O | 959 | | RNFR |ベース| |から名前の変更S / P | M | 959 | | RNTO |ベース| |から名前の変更S | M | 959 | | SITE |ベース|サイトパラメータ| S | M | 959、1123 | | SIZE | SIZE |ファイルサイズ| S | O | 3659 | | SMNT |ベース|構造マウント| | O | 959 | | STAT |ベース|ステータス| 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 | | | |
+-------+------+-------------------+------+------+------------------+
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}
注：IETF標準化アクションがFEATメカニズム[RFC2389]を作るために必要なことだろうが＃1は必須、その拡張メカニズムの実装は明らかにそれに依存して、任意の拡張子や機能と併せて必要とされます。 [RFC2773]のためにAUTH TLSのFEAT文字列：AUTH KEA-SKIPJACK＃3 FEAT文字列：REST STREAM＃4 FEAT文字列：TYPE {サポートされるタイプのセミコロンで区切られたリスト} [RFC4217]のため＃2 FEATストリング
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.
バリー・レイバとアレクセイ・メルニコフが組み込まれているほとんどが、この文書の以前のバージョン、についていくつかの提案をしました。
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.4および2.5の本体を含む第2節に記載レジストリを確立しました。
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.
FTPへの拡張が承認またはRFCの場合や、すでに使用されていると十分に文書化の拡張機能が識別さで定義されているときに、新しいエントリはこのレジストリに追加する必要があります。言い換えれば、登録の要件は、専門家のレビューで「仕様が必要」の少しリラックスしたバージョン[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]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 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.エルツ、 "ファイル転送プロトコルの機能ネゴシエーションメカニズム"、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.、フランクリン、D.、およびA.オーウェン、 "ディレクトリ指向のFTPコマンド"、RFC 775、1980年12月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、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）"、RFC 1545、1993年11月。
[RFC1639] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994.
[RFC1639] Piscitello、D.、 "FTPオペレーションを超えるビッグアドレスレコード（FOOBAR）"、RFC 1639、1994年6月。
[RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, October 1997.
[RFC2228]ホロヴィッツ、M.、 "FTPセキュリティ拡張機能"、RFC 2228、1997年10月。
[RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998.
[RFC2428]オールマン、M.、Ostermann、S.、およびC.メッツ、 "IPv6とNATsのためのFTP拡張機能"、RFC 2428、1998年9月。
[RFC2773] Housley, R. and P. Yee, "Encryption using KEA and SKIPJACK", RFC 2773, February 2000.
[RFC2773] Housley氏、R.とP.イー、 "KEAとSKIPJACKを使用して暗号化"、RFC 2773、2000年2月。
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[RFC4217]フォード・ハッチンソン、P.、 "TLSでセキュアなFTP"、RFC 4217、2005年10月。
Authors' Addresses
著者のアドレス
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA
ジョン・S Clensin 1770マサチューセッツアベニュー、隣接する322ケンブリッジ、MA 02140彼
Phone: +1 617 245 1457 EMail: john+ietf@jck.com
電話：+1 617 245 1457 Eメール：john+ietf@jck.com
Alfred Hoenes TR-Sys Gerlinger Str. 12 Ditzingen D-71254 Germany
アルフレッドHoenes TR-SYS GerlingerのStr。 12 DitzingenのD-71254ドイツ
EMail: ah@TR-Sys.de
メールアドレス：ah@TR-Sys.de