Network Working Group E. Lear
Request for Comments: 3617 Cisco Systems
Category: Informational October 2003
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)
普通文件传输协议（TFTP）的统一资源标识符（URI）方案和适用性声明
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）是一种非常简单的普通协议，在互联网上已经使用了相当长的时间。虽然本文档主要出于安全考虑不鼓励继续使用，但我们确实定义了统一资源标识符（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）和统一资源定位器（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.
虽然我们定义了TFTP URI类型，但我们强烈建议不要继续使用TFTP，原因见第5节（除其他原因外）。URI的定义只允许当前使用协议（如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://" 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>
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;mode=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”。由于未指定其他模式，因此传输应以八位字节模式进行。
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[7]注册了附录A中的URL注册模板。
The author thanks Larry Masinter, Randy Presuhn, Phil Schafer, and Bill Fenner for their help in developing this document.
作者感谢Larry Masinter、Randy Presohn、Phil Schafer和Bill Fenner在编写本文档时提供的帮助。
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执行董事。
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 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
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] Crocker，D.，Ed.和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.，Carpenter，B.和L.Masinter，“URL中文字IPv6地址的格式”，RFC 2732，1999年12月。
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4] Berners Lee，T.，Fielding，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.，弗莱斯蒂克，H.，马斯特，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] Postel，J.和J.Reynolds，“文件传输协议”，标准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.King，“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
Phone: +1 (408) 527 4020
EMail: 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编辑功能的资金目前由互联网协会提供。