[要約] RFC 5797はFTPコマンドと拡張機能の登録に関するものであり、FTPプロトコルの標準化と相互運用性を向上させることを目的としています。
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仕様のすべてのバージョンがいくつかの新しいコマンドを追加し、初期のコマンドはRFC 959に要約されています。RFC2389は、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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 strings」を使用して、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の仕様ドキュメントでコマンド名を大文字化するための長年のプラクティスに続いて、コマンド名はすべての大文字に入力されます。コマンドの操作を修正する拡張機能の場合、プラス記号（ ""）がコマンド名に追加されます。ただし、拡張機能が1つのコマンド（または少数のコマンド）にバインドされる代わりに、コマンドパラメーター処理および/またはトランザクション処理全体に影響する場合、文字列「-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応答で拡張機能を特定するためのキーワードを指定しませんでした。後の仕様では、それぞれのコマンド名がキーワードとして偉業文字列を確立しました。このような場合の将来の仕様のためにキーワードを提供するために、このドキュメントは、将来の標準化のための合理的な機能名を予約するための「プレースホルダー」キーワードを確立します。同様に、プレースホルダーキーワードは、RFC 959 [RFC0959]で指定された基本的なFTPコマンドと、まだ使用されている前任者のキーワードに使用されます。これらのプレースホルダーのキーワードは、利便性のためにレジストリに配置されます。feat応答で返されることを意図していません。この特異性を補うために、レジストリの列は「featコード」と題されており、2つのケースを明確に区別するために、定義されたfeatキーワードコードはすべての大文字にリストされていますが、プレースホルダーキーワード（以下「pseudo featコード」と呼ばれます）はあります）小文字にリストされています。将来の仕様は、以下で「不変」と宣言されている場合を除き、プレースホルダーを真のキーワードに「アップグレード」することができますが、そうでなければ、IANAはケースに依存しない比較に基づいて機能名（featコード）の一意性を維持しています。
Description - A brief description of the extension and, where appropriate, the command.
説明 - 拡張機能の簡単な説明と、必要に応じてコマンド。
FEAT String - (optional in registration requests to IANA)
feat string-（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 Code」自体以外の必須要素を含むfeat Stringを登録することを目的としている場合にのみ指定する必要があります。
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コマンドのサブディビジョンを3つのタイプに導入しました：アクセス制御、転送パラメーター{設定}、およびサービス{実行}の3つのタイプ。明確にし、レジストリのユーザーへのサービスとして、このサブディビジョンは、それぞれ「A」、「P」、または「S」というタイプの特徴的な初期を使用して、登録されたすべてのFTPコマンドに拡張されます。「タイプ」というタイトルのレジストリ列。たとえば、「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.
このレジストリは、主に、同じ拡張機能名とコマンドキーワードの矛盾する使用をさまざまな目的で回避することを目的としています。「エキスパートレビュー」方法が使用されますが、指定された専門家は、次の2つの基準のうち少なくとも1つが満たされていることのみを確認することが期待されます。
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]の一部であり、不変の擬似偉業コード「ベース」とともにレジストリにリストされています。
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、coit、rest、ret、rnfr、rnto、site、stat、stru、type、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
リスト、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仕様の初期バージョンの拡張[RFC0775]の拡張で実験として指定されましたが、標準のFTP [RFC0959]が標準の後継者を指定するため、後にRFC 1123 [RFC1123]によって非推奨されます。それらは、不変の擬似偉業コード「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、LPSG
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]の後にRFCSで公開され、この執筆の時代までは、作成時にレジストリに含まれていました。
The following pseudo FEAT codes have been assigned, according to Section 2:
セクション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]
+-------+------+-------------------+------+------+------------------+
| 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 |
| 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}
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の基本仕様に依存します。編集者であるJon PostelとJoyce Reynoldsの貢献は感謝されています。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.
FTPへの拡張がRFCSで承認または定義されている場合、または既に使用されている拡張機能が識別されている場合、新しいエントリをこのレジストリに追加する必要があります。言い換えれば、登録の要件は、専門家のレビューを備えた「仕様が必要」[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、「ファイル転送プロトコル」、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. 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]マンキンス、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] 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操作上のBig Address Records（Foobar）」、RFC 1545、1993年11月。
[RFC1639] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994.
[RFC1639] Piscitello、D。、「FTP操作上のFTP操作（Foobar）」、RFC 1639、1994年6月。
[RFC2228] Horowitz, M., "FTP Security Extensions", RFC 2228, October 1997.
[RFC2228] Horowitz、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] Allman、M.、Ostermann、S。、およびC. Metz、「IPv6およびNATのFTP拡張」、RFC 2428、1998年9月。
[RFC2773] Housley, R. and P. Yee, "Encryption using KEA and SKIPJACK", RFC 2773, February 2000.
[RFC2773] Housley、R。およびP. Yee、「Kea and Skipjackを使用した暗号化」、RFC 2773、2000年2月。
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October 2005.
[RFC4217] Ford-Hutchinson、P。、「TLSでFTPの保護」、RFC 4217、2005年10月。
Authors' Addresses
著者のアドレス
John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA
ジョンCクレンシン1770マサチューセッツアベニュー、STE 322ケンブリッジ、マサチューセッツ州02140 USA
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