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
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
TFTP Option Extension
TFTP选项扩展
Status of this 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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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的请求包格式一致的机制协商文件传输选项。该机制通过强制执行请求-响应-确认序列保持简单，类似于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].
虽然期权协商机制是通用的，但由于可以协商多种类型的期权，因此创建该机制是为了支持[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
TFTP选项附加到读请求和写请求数据包。一种新类型的TFTP数据包，选项确认（OACK），用于确认客户端的选项协商请求。特此定义一个新的错误代码8，以指示传输
should be terminated due to option negotiation.
应因期权谈判而终止。
Options are appended to a TFTP Read Request or Write Request packet as follows:
选项附加到TFTP读取请求或写入请求数据包，如下所示：
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
| opc |filename| 0 | mode | 0 | opt1 | 0 | value1 | 0 | <
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
| opc |filename| 0 | mode | 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].
opc操作码字段包含1（用于读取请求）或2（用于写入请求），如[1]中所定义。
filename The name of the file to be read or written, as defined in [1]. This is a NULL-terminated field.
filename要读取或写入的文件名，如[1]中所定义。这是以NULL结尾的字段。
mode The mode of the file transfer: "netascii", "octet", or "mail", as defined in [1]. This is a NULL-terminated field.
模式文件传输模式：“netascii”、“八位字节”或“邮件”，如[1]中所定义。这是以NULL结尾的字段。
opt1 The first option, in case-insensitive ASCII (e.g., blksize). This is a NULL-terminated field.
opt1第一个选项，不区分大小写的ASCII（例如blksize）。这是以NULL结尾的字段。
value1 The value associated with the first option, in case-insensitive ASCII. This is a NULL-terminated field.
值1与第一个选项关联的值，不区分大小写。这是以NULL结尾的字段。
optN, valueN The final option/value pair. Each NULL-terminated field is specified in case-insensitive ASCII.
optN，最后一个选项/值对中的值。每个以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数据包具有以下格式：
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| 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.
opc操作码字段包含一个6，用于选项确认。
opt1 The first option acknowledgment, copied from the original request.
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与第一个选项关联的已确认值。该值是否与原始请求不同以及如何与原始请求不同，详见选项规范。
optN, valueN The final option/value acknowledgment pair.
optN，值最终选项/值确认对。
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.
客户端在读请求或写请求数据包的末尾追加选项，如上所示。可以指定任意数量的选项；但是，一个选项只能指定一次。期权的顺序并不重要。
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.
如果服务器支持选项协商，并且它识别请求数据包中指定的一个或多个选项，则服务器可以使用选项确认（OACK）进行响应。服务器识别并接受其值的每个选项都包含在OACK中。某些选项可能允许提出备选值，但这是选项特有的功能。服务器不得在OACK中包含客户端未特别请求的任何选项；也就是说，只有客户可以发起期权谈判。应该从OACK中省略服务器不支持的选项；它们不应导致生成错误数据包。如果受支持选项的值无效，则该选项的规范将指示服务器是否应该从OACK中省略该选项、使用替代值进行响应或发送错误数据包（错误代码为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.
客户端和服务器必须忽略服务器未确认的选项，就像从未请求过一样。如果请求了多个选项，则客户端必须使用服务器已确认的选项，而不能使用服务器未确认的选项。
When the client appends options to the end of a Read Request packet, three possible responses may be returned by the server:
当客户端将选项附加到读取请求数据包的末尾时，服务器可能会返回三种可能的响应：
OACK - acknowledge of Read Request and the options;
OACK-确认读取请求和选项；
DATA - acknowledge of Read Request, but not the options;
数据-确认读取请求，但不确认选项；
ERROR - the request has been denied.
错误-请求已被拒绝。
When the client appends options to the end of a Write Request packet, three possible responses may be returned by the server:
当客户端将选项附加到写入请求数据包的末尾时，服务器可能会返回三种可能的响应：
OACK - acknowledge of Write Request and the options;
OACK-确认写入请求和选项；
ACK - acknowledge of Write Request, but not the options;
确认-确认写入请求，但不确认选项；
ERROR - the request has been denied.
错误-请求已被拒绝。
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.
如果服务器实现不支持选项协商，它可能会忽略附加到客户端请求中的任何选项。在这种情况下，服务器将返回用于读取请求的数据包和用于建立正常TFTP数据传输的写入请求的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。如果传输是通过读取请求启动的，那么客户端将发送ACK（数据块编号设置为0），以确认服务器的OACK数据包中的值。如果传输是通过写入请求启动的，则客户端使用协商的值以第一个数据包开始传输。如果客户机拒绝OACK，那么它将向服务器发送一个错误数据包，错误代码为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，则应使用错误包（错误代码为8）进行响应，并终止传输。
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
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
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
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
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版）”，STD 33，RFC 1350，1992年10月。
[2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 2348, May 1998.
[2] Malkin，G.和A.Harkin，“TFTP块大小选项”，RFC 2348，1998年5月。
[3] Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size Options", RFC 2349, May 1998.
[3] Malkin，G.和A.Harkin，“TFTP超时间隔和传输大小选项”，RFC 2349，1998年5月。
Authors' Addresses
作者地址
Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 01821
加里·斯科特·马尔金湾网络8号联邦街马里兰州比尔里卡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
Art Harkin互联网服务项目信息网络部加利福尼亚州库珀蒂诺市霍姆斯特德路19420号，邮编95014，邮编43LN
Phone: (408) 447-3755 EMail: ash@cup.hp.com
电话：（408）447-3755电子邮件：ash@cup.hp.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。