RFC3617 日本語訳

Network Working Group                                            E. Lear
Request for Comments: 3617                                 Cisco Systems
Category: Informational                                     October 2003

コメントを求めるワーキンググループE.リア要求をネットワークでつないでください: 3617年のシスコシステムズカテゴリ: 情報の2003年10月

              Uniform Resource Identifier (URI) Scheme and
                    Applicability Statement for the
                 Trivial File Transfer Protocol (TFTP)

Uniform Resource Identifier(URI)体系とトリビアル・ファイル転送プロトコルのための適用性証明(TFTP)

Status of this Memo

この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.

Copyright(C)インターネット協会(2003)。 All rights reserved。

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プロトコルです。 このドキュメントが継続的な使用に水をさしている間、私たちは、主に安全上の配慮のため、Uniform Resource Identifier(URI)体系を定義して、プロトコルの適用性について議論します。

1.  Introduction

1. 序論

   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]の新しいバージョンをロードすることになっているために用途です。 デバイスがUniform Resource Identifier(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.

WHILE WE DEFINE THE TFTP URI TYPE、WE STRONGLY RECOMMEND AGAINST THE CONTINUED USE OF TFTP、FOR REASONS LISTED IN SECTION5(他のものの)。 URIの定義で、現在TFTPなどのプロトコルを使用するツールは単に、1つが、プロセスが以前はよくその名前を決議していたのを理解できる標準の名前スペースと構造を持つことができます。 本当に、このURIの定義が現代のファイル転送メカニズムへの変遷を緩和することが望まれています。

Lear                         Informational                      [Page 1]

RFC 3617                  URI Scheme for TFTP               October 2003

TFTP2003年10月のリア情報[1ページ]のRFC3617URI体系

2.  Syntax of a TFTP URI

2. TFTP 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://」は」 /を接待する」というファイル[モード]モードが等しい、」、;、」 指定されるとしてのRFC2396[4]>の指定されるとしてのRFC2732[3]>予約していない=<による「モード=」("netascii"/「八重奏」)ファイル=*(無遠慮であるか逃げられた)ホスト=<はRFC2396>の指定されるとしての=<から逃げました。

   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サーバに関して課されることになっているファイルを指定します。「モード」オプションはファイルがどのようにわたるかことであることを示すオプションです。 不特定のままにされるなら、モードは「八重奏」であると思われます。 RFC1350が採用されて、指定されないとき、3番目の「メール」モードは推奨しなかったです。

2.1.  Encoding Rules

2.1. 符号化規則

   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プロトコルは、名前をファイルするか、またはサイズをファイルするために長さの限界を指定しません。 ファイル名の場合では、それらのキャラクタ上で説明されるように適切に逃げられる限り、それらはどんなキャラクタも含むかもしれません。

3.  Semantics and Operations

3. 意味論と操作

   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]を使用すると考えてください。

Lear                         Informational                      [Page 2]

RFC 3617                  URI Scheme for TFTP               October 2003

TFTP2003年10月のリア情報[2ページ]のRFC3617URI体系

4. Examples

4. 例

      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.

"example.com"というサーバのこの例の参照ファイル"myconfigurationfile"と転送が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.

"example.com"というサーバのこのファイル・リファレンスファイル"mystartupfile"。 他のモードが全く指定されなかったので、転送は八重奏モードで起こるべきです。

5.  Security Considerations and Concerns about TFTP's use

5. TFTPの使用の周りのセキュリティConsiderationsとConcerns

   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はロックステッププロトコルです。 いかなる時も、1つのパケットしか飛行でないかもしれません。 TFTPの、しかし、非常に簡単なタイムアウトにはどんな遅れた出発も賢いbackoffメカニズムもありません。

   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を利用して、多くのNATsはTFTPに転送をサポートもしませんし、許容もしないでしょう。 おそらく、ファイアウォールは転送を禁止するでしょう。

   There are no caching semantics within TFTP.  There is no safe way to
   cache information using the TFTP protocol.

TFTPの中で意味論をキャッシュしてはいけません。 TFTPプロトコルを使用することで情報をキャッシュするどんな安全な方法もありません。

Lear                         Informational                      [Page 3]

RFC 3617                  URI Scheme for TFTP               October 2003

TFTP2003年10月のリア情報[3ページ]のRFC3617URI体系

   In summary, use of TFTP is strongly discouraged except in the most
   limited of circumstances where memory and CPU are at the highest
   premium.

概要では、最も高いプレミアムにはメモリとCPUがある事情が最も制限されるのを除いて、TFTPの使用は強くお勧めできないです。

6.  IANA Considerations

6. IANA問題

   The IANA has registered the URL registration template found in
   Appendix A in accordance with RFC 2717 [7].

IANAはRFC2717[7]によると、Appendix Aで見つけられたURL登録テンプレートを登録しました。

7.  Acknowledgments

7. 承認

   The author thanks Larry Masinter, Randy Presuhn, Phil Schafer, and
   Bill Fenner for their help in developing this document.

作者は彼らの助けについてこのドキュメントを開発する際にラリーMasinter、ランディPresuhn、フィル・シェッフル、およびビル・フェナーに感謝します。

8.  Intellectual Property Statement

8. 知的所有権声明

   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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。

Lear                         Informational                      [Page 4]

RFC 3617                  URI Scheme for TFTP               October 2003

TFTP2003年10月のリア情報[4ページ]のRFC3617URI体系

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 Intended用法: セクション1 この体系を使用するApplications、そして/または、プロトコル: [1] 相互運用性問題: なにも、Security問題: セクション5 Relevant刊行物: [1] 以下に連絡してください。 作者、セクション8 Author/変化Controller: IESG

Lear                         Informational                      [Page 5]

RFC 3617                  URI Scheme for TFTP               October 2003

TFTP2003年10月のリア情報[5ページ]のRFC3617URI体系

References

参照

   [1]  Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
        July 1992.

[1]Sollins、K.、「TFTPプロトコル(改正2)」、STD33、RFC1350、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"、1997年11月のRFC2234。

   [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、「URLの文字通りのIPv6アドレスのための形式」、RFC2732、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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。

   [6]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
        RFC 959, October 1985.

[6] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、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体系名のための登録手順」BCP35、1999年11月のRFC2717。

Author's Address

作者のアドレス

   Eliot Lear
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134-1706

エリオットリアシスコシステムズInc.170W.タスマン博士サンノゼ、カリフォルニア95134-1706

   Phone: +1 (408) 527 4020
   EMail: lear@cisco.com

以下に電話をしてください。 +1(408) 527 4020はメールされます: lear@cisco.com

Lear                         Informational                      [Page 6]

RFC 3617                  URI Scheme for TFTP               October 2003

TFTP2003年10月のリア情報[6ページ]のRFC3617URI体系

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Lear                         Informational                      [Page 7]

リアInformationalです。[7ページ]