Network Working Group P. Hoffman
Request for Comments: 4248 VPN Consortium
Obsoletes: 1738 October 2005
Category: Standards Track
Network Working Group P. Hoffman
Request for Comments: 4248 VPN Consortium
Obsoletes: 1738 October 2005
Category: Standards Track
The telnet URI Scheme
telnet URI方案
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.
本文档指定了最初在RFC 1738中指定的telnet统一资源标识符（URI）方案。本文件的目的是使RFC 1738过时，同时将有关方案的信息保持在标准轨道上。
URIs were previously defined in [RFC2396], which was updated by [RFC3986]. Those documents also specify how to define schemes for URIs.
URI先前在[RFC2396]中定义，并由[RFC3986]更新。这些文档还指定了如何定义URI的方案。
The first definition for many URI schemes appeared in [RFC1738]. Because that document has been made obsolete, this document copies the telnet URI scheme from it to allow that material to remain on standards track.
许多URI方案的第一个定义出现在[RFC1738]中。由于该文档已过时，因此本文档从中复制telnet URI方案，以允许该材料保持在标准轨道上。
The Telnet URL scheme is used to designate interactive services that may be accessed by the Telnet protocol [STD8].
Telnet URL方案用于指定可通过Telnet协议[STD8]访问的交互服务。
A telnet URL takes the form:
telnet URL的形式如下：
telnet://<user>:<password>@<host>:<port>/
telnet://<user>:<password>@<host>:<port>/
The final "/" character may be omitted. If :<port> is omitted, the port defaults to 23. The :<password> can be omitted, as well as the whole <user>:<password> part. Few implementations handle the user name and password very well, if at all.
最后的“/”字符可以省略。如果省略：<port>，则端口默认为23。可以省略：<password>，以及整个<user>：<password>部分。很少有实现能够很好地处理用户名和密码（如果有的话）。
This URL does not designate a data object, but rather an interactive service. Remote interactive services vary widely in the means by which they allow remote logins; in practice, the <user> and <password> supplied are advisory only: clients accessing a telnet URL merely advise the user of the suggested username and password.
此URL不指定数据对象，而是指定交互服务。远程交互服务在允许远程登录的方式上差别很大；实际上，提供的<user>和<password>只是建议：访问telnet URL的客户端仅建议用户使用建议的用户名和密码。
Many RFCs have added various services to the Telnet protocol for better authentication, encryption of traffic, or both. Those RFCs have not specified new URI schemes for Telnet to invoke those services (along the lines of "https" being a different URI scheme from "http"). Some modern telnet clients attempt to invoke those more-secure versions of Telnet when resolving a "telnet" URL.
许多RFC在Telnet协议中添加了各种服务，以实现更好的身份验证和/或流量加密。这些RFC没有为Telnet指定新的URI方案来调用这些服务（正如“https”是与“http”不同的URI方案一样）。一些现代telnet客户端在解析“telnet”URL时试图调用那些更安全的telnet版本。
There are many security considerations for URI schemes discussed in [RFC3986].
[RFC3986]中讨论了URI方案的许多安全注意事项。
The Telnet protocol normally uses passwords in the clear for authentication, and normally offers no privacy. In normal telnet, both the user's identity and their password are exposed without any protection; after that, the contents of the entire Telnet session is exposed without any protection.
Telnet协议通常使用clear中的密码进行身份验证，并且通常不提供隐私。在普通的telnet中，用户的身份和密码都被暴露，没有任何保护；之后，整个Telnet会话的内容将在没有任何保护的情况下公开。
Many extensions have been made to Telnet to make it more secure in different ways. In particular, [RFC2941] gives a framework based on a telnet option that many other security extensions have leveraged off of. These extensions are certainly worthwhile methods for reducing the obvious problems with exposing the user's name, password, and plaintext of the session in the clear.
为了使Telnet以不同的方式更加安全，已经对Telnet进行了许多扩展。特别是，[RFC2941]提供了一个基于telnet选项的框架，许多其他安全扩展都利用了该选项。这些扩展对于减少公开用户名、密码和会话明文的明显问题来说无疑是有价值的方法。
Although some modern telnet clients attempt to invoke those more-secure versions of Telnet when resolving a "telnet" URL, other telnet clients do not, so a user cannot rely on this type of security unless it is explicitly enabled and the results of the security negotiation are checked.
虽然一些现代telnet客户端在解析“telnet”URL时尝试调用那些更安全的telnet版本，但其他telnet客户端则不这样做，因此用户不能依赖这种类型的安全性，除非显式启用并检查安全协商的结果。
[STD8] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[STD8]Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]Berners Lee，T.，Masinter，L.，和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[RFC2941] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.
[RFC2941]Ts'o，T.和J.Altman，“Telnet认证选项”，RFC 29412000年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
Author's Address
作者地址
Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US
美国加利福尼亚州圣克鲁斯塞格雷广场127号保罗·霍夫曼私人有限公司，邮编95060
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。