Network Working Group E. Lear
Request for Comments: 3617 Cisco Systems
Category: Informational October 2003
Uniform Resource Identifier (URI) Scheme and
Applicability Statement for the
Trivial File Transfer Protocol (TFTP)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time. While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.
簡易ファイル転送プロトコル（TFTP）は、非常に長い時間のためにインターネット上で使用されている非常に単純なTRIVIALプロトコルです。この文書は主にセキュリティ上の問題に、その継続的な使用を推奨していますが、私たちは、統一資源識別子（URI）スキームを定義だけでなく、プロトコルの適用可能性を議論します。
The Trivial File Transfer Protocol (TFTP) has been around for quite some time. Its common uses are to initially configure devices or to load new versions of operating system code [1]. As devices begin to adopt use of Uniform Resource Identifiers (URIs) and Uniform Resource Locators (URLs), for completeness we specify a way to reference files that is still quite common. Use of a URI is a convenient way to indicate underlying mechanism, server name or address, and file name.
簡易ファイル転送プロトコル（TFTP）は、かなり長く使われています。その一般的な用途は、最初にデバイスを構成するか、オペレーティング・システム・コード[1]の新しいバージョンをロードすることです。デバイスは、ユニフォームリソース識別子（URI）とUniform Resource Locator（URL）の使用を採用し始めると、完全を期すために、我々はまだ非常に一般的ですファイルを参照する方法を指定します。 URIの使用は、基礎となるメカニズム、サーバー名またはアドレス、およびファイル名を指定する便利な方法です。
WHILE WE DEFINE THE TFTP URI TYPE, WE STRONGLY RECOMMEND AGAINST THE CONTINUED USE OF TFTP, FOR REASONS LISTED IN SECTION 5 (amongst others). The definition of a URI merely allows tools that currently use protocols such as TFTP to have a standard name space and structure where one can understand the process used to resolve that name. Indeed it is hoped that the definition of this URI will ease transition to modern file transfer mechanisms.
WEがTFTP URIタイプを定義しているが、私たちは強く（とりわけ）セクション5に記載されている理由のために、TFTPの継続使用に対するお勧めします。 URIの定義は、単に現在、TFTPなどのプロトコルを使用するツールは、1がその名前を解決するために使用されるプロセスを理解することができ、標準の名前空間と構造を持つことができます。実際、このURIの定義は、近代的なファイル転送メカニズムへの移行を容易にすることが期待されます。
A TFTP URI has the following ABNF syntax [2]:
TFTP URIは以下のABNF構文を持っている[2]：
tftpURI = "tftp://" host "/" file [ mode ] mode = ";" "mode=" ( "netascii" / "octet" ) file = *( unreserved / escaped ) host = <as specified by RFC 2732 [3]> unreserved = <as specified in RFC 2396 [4]> escaped = <as specified in RFC 2396>
tftpURI = "TFTP：//" ホスト "/" ファイルの[モード]モード= ";" "モード="（ "NETASCII" / "オクテット"）ファイル= * <RFC 2732で指定された[3]> <RFC 2396に指定されている[4]>指定されたホストは=予約されていない= <=エスケープ（予約されていない/エスケープ） RFC 2396で>
A TFTP URI specifies a file that is to be found or placed on a TFTP server. The "mode" option is an option indicating how the file is to be transferred. If left unspecified, the mode is assumed to be "octet". A third "mail" mode was deprecated at the time RFC 1350 was adopted, and is not specified.
TFTP URIが見つからないか、またはTFTPサーバに配置するファイルを指定します。 「モード」オプションは、ファイルを転送するかを示すオプションです。指定しない場合、モードは「オクテット」とします。第三の「メール」モードを採用し、そして指定されていない時間RFC 1350で廃止されました。
Aside from syntax as described above, the TFTP protocol does not specify length limits to either file names or file sizes. In the case of file names, they may contain any character so long as those characters are properly escaped as described above.
上記のように脇構文から、TFTPプロトコルは、ファイル名やファイルサイズいずれかの長さの制限が指定されていません。ファイル名の場合、彼らは限り上記のように、それらの文字が適切にエスケープされているとして、任意の文字を含めることができます。
As previously stated the TFTP URI is a reference to a file. The allowed operations on a TFTP URI are read and write. When a TFTP URI is read the underlying mechanisms retrieve the named file via the TFTP protocol from the specified host with the optionally specified mode. When a TFTP URI is written the underlying mechanisms transmit a file via TFTP to a specified server to either the specified file using the optionally specified mode. No other operations are supported.
先に述べたようにTFTP URIは、ファイルへの参照です。 TFTP URIに許可される操作は、読み取りおよび書き込みされています。 TFTP URIが読み込まれると、基礎となるメカニズムは、必要に応じて指定されたモードで指定されたホストからTFTPプロトコルを介しという名前のファイルを取り出します。 TFTP URIが書かれている場合、基礎となるメカニズムは、任意に指定されたモードを使用して、指定されたファイルのいずれかに指定されたサーバにTFTPを介してファイルを送信します。他の操作はサポートされていません。
Note that it is not possible to retrieve file size information prior to retrieval, nor is it possible to determine file existence or permissions prior to transfer. Files transferred may or may not arrive intact, as there is no guarantee of reliability or even completeness. See the TFTP standard for more details. For more robust file transfer, consider using either FTP or HTTP [5, 6].
検索する前にファイルサイズ情報を取得することはできません、またそれを転送する前にファイルの存在または許可を決定することが可能であることに注意してください。信頼性あるいは完全性の保証がないとして転送されたファイルは、または、無傷で到着しない場合があります。詳細は、TFTP標準を参照してください。より堅牢なファイル転送のために、FTPまたはHTTP [5、6]のいずれかを使用することを検討してください。
tftp://example.com/myconfigurationfile;mode=netascii
TFTP：//example.com/myconfigurationfile;モード= NETASCII
This example references file "myconfigurationfile" on server "example.com" and requests that the transfer occur in netascii mode.
この例の参照は、サーバー上の「myconfigurationfile」を「example.com」ファイルと転送がNETASCIIモードで発生することを要求します。
tftp://example.com/mystartupfile
TFTP：//example.com/mystartupfile
This file references file "mystartupfile" on server "example.com". The transfer should occur in octet mode, since no other mode was specified.
このファイルの参照は、サーバー上の「mystartupfile」を「example.com」ファイル。他のモードが指定されていないため、転送は、オクテットモードで発生する必要があります。
Use of TFTP has been historically limited to those devices where a more full protocol stack is impractical due to either memory or CPU constraints. While this still may be the case with a toaster, it is unlikely to be the case for even the simplest piece of network support hardware, such as simple routers or switches. There are a myriad of reasons to use some protocol other than TFTP, only a few of which are listed below.
TFTPの使用は歴史的に、より完全なプロトコルスタックが原因メモリやCPUの制約のいずれかに非現実的であるこれらのデバイスに限定されてきました。これはまだトースターの場合であってもよいが、単純なルータやスイッチなどのネットワークサポートハードウェアの最も単純な片の場合でにくいです。下記にリストされているのほんの数TFTP、以外のいくつかのプロトコルを使用する理由は無数にあります。
TFTP has no mechanism for access control within the protocol, and there is no protection from a man in the middle attack. Implementations are left to their own devices in this area. Because TFTP has no way to determine file sizes in advance, implementations should be prepared to properly check the bounds of transfers so that neither memory nor disk limitations are exceeded.
TFTPは、プロトコル内のアクセス制御のための機構がないと、中間者攻撃からの保護はありません。実装は、この分野で自分のデバイスに残っています。 TFTPは、事前にファイルサイズを決定する方法がないので、実装は、メモリやディスクの制限もないが超過しているように、適切に転送の境界を確認するために準備する必要があります。
TFTP is not well suited to large files for the following reasons. TFTP has no inherent integrity check. There is no way to determine what one side sent is what the other received. There is no way to restart TFTP transfers from anywhere other than the beginning. TFTP is a lock step protocol. Only one packet may be in flight at any one time. There is no slow start or smart backoff mechanism in TFTP, but very simple timeouts.
TFTPは、次の理由から、大容量のファイルには適していません。 TFTPには、固有の整合性チェックを持っていません。送信された一方が他方を受信するものであるかを判断する方法はありません。先頭以外の任意の場所からTFTP転送を再起動する方法はありません。 TFTPは、ロックステッププロトコルです。一つだけのパケットは、任意の時点での飛行であってもよいです。何のスロースタートまたはTFTPでのスマートバックオフメカニズムが、非常にシンプルなタイムアウトはありません。
TFTP is not well suited to file transfers across administrative domains. For one thing, TFTP utilizes UDP, and many NATs will not either support or allow TFTP transfers. More likely firewalls will prohibit transfers.
TFTPは、管理ドメイン間でファイルを転送するには適していません。一つには、TFTPは、UDPを利用し、多くのNATはTFTP転送をサポートかのいずれかを許可しません。より多くの可能性が高いのファイアウォールは、転送を禁止します。
There are no caching semantics within TFTP. There is no safe way to cache information using the TFTP protocol.
TFTP内には、キャッシングのセマンティクスはありません。 TFTPプロトコルを使用して情報をキャッシュする安全な方法はありません。
In summary, use of TFTP is strongly discouraged except in the most limited of circumstances where memory and CPU are at the highest premium.
要約すると、TFTPの使用が強く、メモリとCPUが最高のプレミアムにある状況の中で最も制限された以外はお勧めしません。
The IANA has registered the URL registration template found in Appendix A in accordance with RFC 2717 [7].
IANAはRFC 2717に合わせて付録Aで見つかったURLの登録テンプレートを登録している[7]。
The author thanks Larry Masinter, Randy Presuhn, Phil Schafer, and Bill Fenner for their help in developing this document.
このドキュメントの開発に彼らの助けのための著者のおかげでラリーMasinter、ランディPresuhn、フィル・シェーファー、ビルフェナー。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Appendix A. Registration Template
付録A.登録テンプレート
URL scheme name: tftp URL scheme syntax: Section 2 Character encoding considerations: Section 2 Intended usage: Section 1 Applications and/or protocols which use this scheme: [1] Interoperability considerations: None Security considerations: Section 5 Relevant publications: [1] Contact: The author, Section 8 Author/Change Controller: IESG
URLのスキーム名：TFTP URLスキームの構文：セクション2つの文字エンコーディングの考慮事項：第2節意図している用法：セクション1つのアプリケーションおよび/またはこの方式を使用するプロトコル：[1]相互運用性に関する注意事項：なしセキュリティに関する注意事項：第5章関連資料：[1]連絡先：著者、セクション8著者/変更コントローラ：IESG
References
リファレンス
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[1] Sollins、K.、 "TFTPプロトコル（改訂第2版）"、STD 33、RFC 1350、1992年7月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[3] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[3] HindenとR.、大工、B.およびL. Masinterを、 "リテラルIPv6アドレスのフォーマットURLの中に"、RFC 2732、1999年12月。
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、RFC 2396、1998年8月。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[5]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[6] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[6]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[7] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[7] Petke、R.とI.キング、 "URLスキーム名の登録手順"、BCP 35、RFC 2717、1999年11月に。
Author's Address
著者のアドレス
Eliot Lear Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134-1706
エリオット・リアシスコシステムズ社170 W.タスマン博士はカリフォルニア州サンノゼ95134-1706
Phone: +1 (408) 527 4020 EMail: lear@cisco.com
電話：+1（408）527 4020 Eメール：lear@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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 assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。