RFC2347 日本語訳
2347 TFTP Option Extension. G. Malkin, A. Harkin. May 1998. (Format: TXT=13060 bytes) (Obsoletes RFC1782) (Updates RFC1350) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Malkin Request for Commments: 2347 Bay Networks Updates: 1350 A. Harkin Obsoletes: 1782 Hewlett Packard Co. Category: Standards Track May 1998
Commmentsを求めるワーキンググループG.マルキンの要求をネットワークでつないでください: 2347のベイネットワークスアップデート: 1350 A.ハーキンは以下を時代遅れにします。 1782年のヒューレットパッカード社のカテゴリ: 標準化過程1998年5月
TFTP Option Extension
TFTPオプション拡張子
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.
トリビアル・ファイル転送プロトコル[1]はクライアントがリモートホストにファイルを届けるか、または置く簡単で、堅苦しいファイル転送プロトコルです。 このドキュメントは、ファイル転送の前にオプション交渉を許すために単純拡大についてTFTPに説明します。
Introduction
序論
The option negotiation mechanism proposed in this document is a backward-compatible extension to the TFTP protocol. It allows file transfer options to be negotiated prior to the transfer using a mechanism which is consistent with TFTP's Request Packet format. The mechanism is kept simple by enforcing a request-respond-acknowledge sequence, similar to the lock-step approach taken by TFTP itself.
本書では提案されたオプション交渉メカニズムはTFTPプロトコルへの後方コンパチブル拡大です。 それは、ファイル転送オプションが転送の前に交渉されるのをTFTPのRequest Packet形式と一致したメカニズムを使用することで許容します。 メカニズムがaを実施することによって簡単に保たれる、応じるよう要求してください、承認、TFTPによって取られた堅苦しいアプローチと同様の系列自体。
While the option negotiation mechanism is general purpose, in that many types of options may be negotiated, it was created to support the Blocksize option defined in [2]. Additional options are defined in [3].
オプション交渉メカニズムが汎用である間、多くのタイプのオプションが交渉されるかもしれないので、それはBlocksizeが[2]で定義されたオプションであるとサポートするために作成されました。 追加オプションは[3]で定義されます。
Packet Formats
パケット・フォーマット
TFTP options are appended to the Read Request and Write Request packets. A new type of TFTP packet, the Option Acknowledgment (OACK), is used to acknowledge a client's option negotiation request. A new error code, 8, is hereby defined to indicate that a transfer
Read RequestとWrite RequestパケットにTFTPオプションを追加します。 新しいタイプのTFTPパケット(Option Acknowledgment(OACK))は、クライアントのオプション交渉要求を承諾するのに使用されます。 新しいエラーコード(8)は、aが移されるのを示すためにこれにより定義されます。
Malkin & Harkin Standards Track [Page 1] RFC 2347 TFTP Option Extension May 1998
マルキンとハーキンStandardsはTFTPオプション拡大1998年5月にRFC2347を追跡します[1ページ]。
should be terminated due to option negotiation.
オプション交渉のため終えられるべきです。
Options are appended to a TFTP Read Request or Write Request packet as follows:
以下のTFTP Read RequestかWrite Requestパケットにオプションを追加します:
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
| opc |filename| 0 | mode | 0 | opt1 | 0 | value1 | 0 | <
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->。| opc|ファイル名| 0 | モード| 0 | opt1| 0 | value1| 0 | <+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->。
>-------+---+---~~---+---+
< optN | 0 | valueN | 0 |
>-------+---+---~~---+---+
>。-------+---+---~~---+---+ <optN| 0 | valueN| 0 | >、-、-、-、-、-、--+---+---~~---+---+
opc
The opcode field contains either a 1, for Read Requests, or 2,
for Write Requests, as defined in [1].
opcodeがさばくopcは[1]で定義されるようにRead RequestsのためのWrite Requestsのための1か2つの1を含んでいます。
filename
The name of the file to be read or written, as defined in [1].
This is a NULL-terminated field.
ファイル名、[1]で定義されるような読まれるか、または書かれているファイルの名前。 これはNULLによって終えられた分野です。
mode
The mode of the file transfer: "netascii", "octet", or "mail",
as defined in [1]. This is a NULL-terminated field.
モード、ファイル転送の方法: [1]の"netascii"、「八重奏」、または定義されるとしての「メール。」 これはNULLによって終えられた分野です。
opt1
The first option, in case-insensitive ASCII (e.g., blksize).
This is a NULL-terminated field.
1番目が大文字と小文字を区別しないASCII(例えば、blksizeする)でゆだねるopt1。 これはNULLによって終えられた分野です。
value1
The value associated with the first option, in case-
insensitive ASCII. This is a NULL-terminated field.
値がケース神経の鈍いASCIIにおける第1の選択に関連づけたvalue1。 これはNULLによって終えられた分野です。
optN, valueN
The final option/value pair. Each NULL-terminated field is
specified in case-insensitive ASCII.
optN、最終的なオプション/値の組のvalueN。 それぞれのNULLによって終えられた分野は大文字と小文字を区別しないASCIIで指定されます。
The options and values are all NULL-terminated, in keeping with the original request format. If multiple options are to be negotiated, they are appended to each other. The order in which options are specified is not significant. The maximum size of a request packet is 512 octets.
オプションと値は元の要求形式で保つ際にNULLによってすべて終えられます。 複数のオプションが交渉することであるなら、それらを互いに追加します。 オプションが指定されるオーダーは重要ではありません。 リクエスト・パケットの最大サイズは512の八重奏です。
The OACK packet has the following format:
OACKパケットには、以下の形式があります:
Malkin & Harkin Standards Track [Page 2] RFC 2347 TFTP Option Extension May 1998
マルキンとハーキンStandardsはTFTPオプション拡大1998年5月にRFC2347を追跡します[2ページ]。
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| opc | opt1 | 0 | value1 | 0 | optN | 0 | valueN | 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+ | opc| opt1| 0 | value1| 0 | optN| 0 | valueN| 0 | +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
opc
The opcode field contains a 6, for Option Acknowledgment.
opcodeがさばくopcはOption Acknowledgmentのための6を含んでいます。
opt1
The first option acknowledgment, copied from the original
request.
第1の選択承認であって、オリジナルの要求からコピーされたopt1。
value1
The acknowledged value associated with the first option. If
and how this value may differ from the original request is
detailed in the specification for the option.
承認された値が第1の選択に関連づけたvalue1。 そして、この値はオプションのための仕様でどう詳しく述べられたオリジナルの要求と異なるかもしれないか。
optN, valueN
The final option/value acknowledgment pair.
optN、最終的なオプション/値の承認組のvalueN。
Negotiation Protocol
交渉プロトコル
The client appends options at the end of the Read Request or Write request packet, as shown above. Any number of options may be specified; however, an option may only be specified once. The order of the options is not significant.
クライアントは上に示されるようにRead RequestかWriteリクエスト・パケットの端でオプションを追加します。 いろいろなオプションが指定されるかもしれません。 しかしながら、オプションは一度指定されるだけであるかもしれません。 オプションの注文は重要ではありません。
If the server supports option negotiation, and it recognizes one or more of the options specified in the request packet, the server may respond with an Options Acknowledgment (OACK). Each option the server recognizes, and accepts the value for, is included in the OACK. Some options may allow alternate values to be proposed, but this is an option specific feature. The server must not include in the OACK any option which had not been specifically requested by the client; that is, only the client may initiate option negotiation. Options which the server does not support should be omitted from the OACK; they should not cause an ERROR packet to be generated. If the value of a supported option is invalid, the specification for that option will indicate whether the server should simply omit the option from the OACK, respond with an alternate value, or send an ERROR packet, with error code 8, to terminate the transfer.
サーバが、オプションが交渉であるとサポートして、リクエスト・パケットで指定されたオプションの1つ以上を認めるなら、サーバはOptions Acknowledgment(OACK)と共に反応するかもしれません。 サーバが値を認識して、受け入れるそれぞれのオプションは含まれています。OACKで。 いくつかのオプションが、代替の値が提案されるのを許容するかもしれませんが、これはオプションの特定の機能です。 サーバはOACKにクライアントによって明確に要求されていなかった少しのオプションも含んではいけません。 すなわち、クライアントだけがオプション交渉を開始するかもしれません。 サーバがサポートしないオプションはOACKから省略されるべきです。 彼らはERRORパケットを生成させるべきではありません。 サーバがOACKからオプションを単に省略するべきであるか否かに関係なく、そのオプションのための仕様は、代替の値で応じるか、またはERRORパケットを送ってください、サポートしているオプションの値が無効であるなら転送を終えるためにエラーコード8で示すでしょう。
An option not acknowledged by the server must be ignored by the client and server as if it were never requested. If multiple options were requested, the client must use those options which were acknowledged by the server and must not use those options which were not acknowledged by the server.
まるでそれが決して要求されていないかのようにクライアントとサーバでサーバによって承諾されなかったオプションを無視しなければなりません。 複数のオプションが要求されたなら、クライアントは、サーバによって承諾されたそれらのオプションを使用しなければならなくて、サーバによって承諾されなかったそれらのオプションは使用してはいけません。
Malkin & Harkin Standards Track [Page 3] RFC 2347 TFTP Option Extension May 1998
マルキンとハーキンStandardsはTFTPオプション拡大1998年5月にRFC2347を追跡します[3ページ]。
When the client appends options to the end of a Read Request packet, three possible responses may be returned by the server:
クライアントがRead Requestパケットの端にオプションを追加するとき、サーバは3つの可能な応答を返すかもしれません:
OACK - acknowledge of Read Request and the options;
OACK--、承認、Read Requestとオプションについて。
DATA - acknowledge of Read Request, but not the options;
DATA--、承認、オプションではなく、Read Requestについて。
ERROR - the request has been denied.
ERROR--要求は否定されました。
When the client appends options to the end of a Write Request packet, three possible responses may be returned by the server:
クライアントがWrite Requestパケットの端にオプションを追加するとき、サーバは3つの可能な応答を返すかもしれません:
OACK - acknowledge of Write Request and the options;
OACK--、承認、Write Requestとオプションについて。
ACK - acknowledge of Write Request, but not the options;
ACK--、承認、オプションではなく、Write Requestについて。
ERROR - the request has been denied.
ERROR--要求は否定されました。
If a server implementation does not support option negotiation, it will likely ignore any options appended to the client's request. In this case, the server will return a DATA packet for a Read Request and an ACK packet for a Write Request establishing normal TFTP data transfer. In the event that a server returns an error for a request which carries an option, the client may attempt to repeat the request without appending any options. This implementation option would handle servers which consider extraneous data in the request packet to be erroneous.
サーバ実装が、オプションが交渉であるとサポートしないと、それはおそらくクライアントの要求に追加されたどんなオプションも無視するでしょう。 この場合、サーバはRead RequestのためのDATAパケットと正常なTFTPデータ転送を確立するWrite RequestのためのACKパケットを返すでしょう。 サーバがオプションを運ぶ要求のための誤りを返す場合、クライアントは、どんなオプションも追加しないで要求を繰り返すのを試みるかもしれません。 この実装オプションはリクエスト・パケットの異質なデータが誤ると考えるサーバを扱うでしょう。
Depending on the original transfer request there are two ways for a client to confirm acceptance of a server's OACK. If the transfer was initiated with a Read Request, then an ACK (with the data block number set to 0) is sent by the client to confirm the values in the server's OACK packet. If the transfer was initiated with a Write Request, then the client begins the transfer with the first DATA packet, using the negotiated values. If the client rejects the OACK, then it sends an ERROR packet, with error code 8, to the server and the transfer is terminated.
サーバのOACKの承認を確認するためにクライアントのために2つの方法であるオリジナルの転送要求によります。 転送がRead Requestと共に起こされたなら、ACK(数が0に設定するデータ・ブロックがある)は、サーバのOACKパケットで値を確認するためにクライアントによって送られます。 転送がWrite Requestと共に起こされたなら、クライアントは最初のDATAパケットによる転送を始めます、交渉された値を使用して。 クライアントがOACKを拒絶するなら、ERRORパケットを送ります、エラーコード8で、サーバと終えられた転送に。
Once a client acknowledges an OACK, with an appropriate non-error response, that client has agreed to use only the options and values returned by the server. Remember that the server cannot request an option; it can only respond to them. If the client receives an OACK containing an unrequested option, it should respond with an ERROR packet, with error code 8, and terminate the transfer.
クライアントがいったんOACKを承認すると、適切な非誤り応答に、そのクライアントは、オプションだけを使用するのを同意しました、そして、値はサーバで戻りました。サーバがオプションを要求できないのを覚えていてください。 それはそれらに応じることができるだけです。 クライアントが非要求されたオプションを含むOACKを受け取るなら、それは、ERRORパケット、エラーコード8で応じて、転送を終えるべきです。
Malkin & Harkin Standards Track [Page 4] RFC 2347 TFTP Option Extension May 1998
マルキンとハーキンStandardsはTFTPオプション拡大1998年5月にRFC2347を追跡します[4ページ]。
Examples
例
Read Request
読み出し要求
client server
-------------------------------------------------------
|1|foofile|0|octet|0|blksize|0|1432|0| --> RRQ
<-- |6|blksize|0|1432|0| OACK
|4|0| --> ACK
<-- |3|1| 1432 octets of data | DATA
|4|1| --> ACK
<-- |3|2| 1432 octets of data | DATA
|4|2| --> ACK
<-- |3|3|<1432 octets of data | DATA
|4|3| --> ACK
クライアントサーバ------------------------------------------------------- |1|foofile|0|八重奏|0|blksizeします。|0|1432|0| -->RRQ<--|6|blksizeします。|0|1432|0| OACK|4|0| -->ACK<--|3|1| データの1432の八重奏| データ|4|1| -->ACK<--|3|2| データの1432の八重奏| データ|4|2| -->ACK<--|3|3|データの<1432八重奏| データ|4|3| -->ACK
Write Request
要求を書いてください。
client server
-------------------------------------------------------
|2|barfile|0|octet|0|blksize|0|2048|0| --> RRQ
<-- |6|blksize|0|2048|0| OACK
|3|1| 2048 octets of data | --> DATA
<-- |4|1| ACK
|3|2| 2048 octets of data | --> DATA
<-- |4|2| ACK
|3|3|<2048 octets of data | --> DATA
<-- |4|3| ACK
クライアントサーバ------------------------------------------------------- |2|barfile|0|八重奏|0|blksizeします。|0|2048|0| -->RRQ<--|6|blksizeします。|0|2048|0| OACK|3|1| データの2048の八重奏| -->データ<--|4|1| ACK|3|2| データの2048の八重奏| -->データ<--|4|2| ACK|3|3|データの<2048八重奏| -->データ<--|4|3| ACK
Security Considerations
セキュリティ問題
The basic TFTP protocol has no security mechanism. This is why it has no rename, delete, or file overwrite capabilities. This document does not add any security to TFTP; however, the specified extensions do not add any additional security risks.
基本的なTFTPプロトコルには、セキュリティー対策が全くありません。 これはそれがいいえが重ね書き能力を改名するか、削除するか、またはファイルするのをさせる理由です。 このドキュメントは少しのセキュリティもTFTPに加えません。 しかしながら、指定された拡大は少しの追加担保危険も加えません。
References
参照
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
October 1992.
[1]Sollins、K.、「TFTPプロトコル(改正2)」、STD33、RFC1350、1992年10月。
[2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 2348,
May 1998.
[2] マルキン、G.、およびA.ハーキン、「TFTP Blocksizeオプション」、RFC2348は1998がそうするかもしれません。
[3] Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer
Size Options", RFC 2349, May 1998.
[3] マルキン、G.、およびA.ハーキン、「TFTPタイムアウト間隔と転送サイズオプション」(RFC2349)は1998がそうするかもしれません。
Malkin & Harkin Standards Track [Page 5] RFC 2347 TFTP Option Extension May 1998
マルキンとハーキンStandardsはTFTPオプション拡大1998年5月にRFC2347を追跡します[5ページ]。
Authors' Addresses
作者のアドレス
Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 01821
ビルリカ、ゲーリースコットマルキンベイネットワークス8の連邦政府の通りMA 01821
Phone: (978) 916-4237 EMail: gmalkin@baynetworks.com
以下に電話をしてください。 (978) 916-4237 メールしてください: gmalkin@baynetworks.com
Art Harkin Internet Services Project Information Networks Division 19420 Homestead Road MS 43LN Cupertino, CA 95014
芸術ハーキンインターネットのサービスは情報網を映し出します。事業部19420が道路MS43LNカルパチーノに入植する、カリフォルニア 95014
Phone: (408) 447-3755 EMail: ash@cup.hp.com
以下に電話をしてください。 (408) 447-3755 メールしてください: ash@cup.hp.com
Malkin & Harkin Standards Track [Page 6] RFC 2347 TFTP Option Extension May 1998
マルキンとハーキンStandardsはTFTPオプション拡大1998年5月にRFC2347を追跡します[6ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Malkin & Harkin Standards Track [Page 7]
マルキンとハーキン標準化過程[7ページ]
一覧
スポンサーリンク
