Network Working Group Internet Architecture Board (IAB)
Request for Comments: 2825 L. Daigle, Editor
Category: Informational May 2000
Network Working Group Internet Architecture Board (IAB)
Request for Comments: 2825 L. Daigle, Editor
Category: Informational May 2000
A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols
混乱的网络：I18N、域名和其他互联网协议的问题
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
The goals of the work to "internationalize" Internet protocols include providing all users of the Internet with the capability of using their own language and its standard character set to express themselves, write names, and to navigate the network. This impacts the domain names visible in e-mail addresses and so many of today's URLs used to locate information on the World Wide Web, etc. However, domain names are used by Internet protocols that are used across national boundaries. These services must interoperate worldwide, or we risk isolating components of the network from each other along locale boundaries. This type of isolation could impede not only communications among people, but opportunities of the areas involved to participate effectively in e-commerce, distance learning, and other activities at an international scale, thereby retarding economic development.
“国际化”互联网协议工作的目标包括为互联网的所有用户提供使用他们自己的语言和标准字符集来表达自己、写名字和浏览网络的能力。这会影响电子邮件地址中可见的域名，以及当今用于在万维网上定位信息的许多URL等。但是，域名由跨国界使用的互联网协议使用。这些服务必须在全球范围内互操作，否则我们就有可能沿着区域边界将网络组件彼此隔离。这种孤立不仅会阻碍人与人之间的交流，还会阻碍相关领域有效参与电子商务、远程学习和其他国际活动的机会，从而阻碍经济发展。
There are several proposals for internationalizing domain names, however it it is still to be determined whether any of them will ensure this interoperability and global reach while addressing visible-name representation. Some of them obviously do not. This document does not attempt to review any specific proposals, as that is the work of the Internationalized Domain Name (IDN) Working Group of the IETF, which is tasked with evaluating them in consideration of the continued global network interoperation that is the deserved expectation of all Internet users.
目前有几项关于域名国际化的建议，但仍有待确定其中是否有任何一项能够在解决可见名称表示的同时确保这种互操作性和全球范围。其中一些显然没有。本文件不试图审查任何具体提案，因为这是IETF国际域名（IDN）工作组的工作，其任务是在考虑到所有互联网用户应有的全球网络互操作的情况下对其进行评估。
This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces.
本文件是互联网体系结构委员会的声明。它不是一个协议规范，而是试图澄清域名国际化所面临的一系列体系结构问题。
The Internationalized Domain Names (IDN) Working Group is one component of the IETF's continuing comprehensive effort to internationalize language representation facilities in the protocols that support the global functioning of the Internet.
国际域名（IDN）工作组是IETF持续全面努力的一个组成部分，旨在将支持互联网全球功能的协议中的语言表示设施国际化。
In keeping with the principles of rough consensus, running code, architectural integrity, and in the interest of ensuring the global stability of the Internet, the IAB emphasizes that all solutions proposed to the (IDN) Working Group will have to be evaluated not only on their individual technical features, but also in terms of impact on existing standards and operations of the Internet and the total effect for end-users: solutions must not cause users to become more isolated from their global neighbors even if they appear to solve a local problem. In some cases, existing protocols have limitations on allowable characters, and in other cases implementations of protocols used in the core of the Internet (beyond individual organizations) have in practice not implemented all the requisite options of the standards.
为了遵循大致一致、运行代码、架构完整性的原则，并为了确保互联网的全球稳定性，IAB强调，向（IDN）工作组提出的所有解决方案都必须不仅根据各自的技术特征进行评估，但就对互联网现有标准和运营的影响以及对最终用户的总体影响而言：解决方案不得导致用户与其全球邻居变得更加孤立，即使他们似乎在解决本地问题。在某些情况下，现有协议对允许的字符有限制，而在另一些情况下，互联网核心使用的协议（除个别组织外）的实现实际上没有实现标准的所有必要选项。
In many technical respects, the IDN work is not different from any other effort to enable multiple character set representations in textual elements that were traditionally restricted to English language characters.
在许多技术方面，IDN工作与在传统上仅限于英语字符的文本元素中实现多个字符集表示的任何其他工作没有什么不同。
One aspect of the challenge is to decide how to represent the names users want in the DNS in a way that is clear, technically feasible, and ensures that a name always means the same thing. Several proposals have been suggested to address these issues.
挑战的一个方面是决定如何以一种清晰、技术上可行的方式在DNS中表示用户想要的名称，并确保名称始终具有相同的含义。为解决这些问题提出了若干建议。
These issues are being outlined in more detail in the IDN WG's evolving draft requirements document; further discussion is deferred to the WG and its documents.
这些问题在IDN工作组不断发展的需求文件草案中有更详细的概述；进一步讨论推迟到工作组及其文件。
Nevertheless, issues faced by the IDN working group are complex and intricately intertwined with other operational components of the Internet. A key challenge in evaluating any proposed solution is the analysis of the impact on existing critical operational standards
然而，IDN工作组面临的问题是复杂的，并且与互联网的其他运营组成部分错综复杂地交织在一起。评估任何拟议解决方案的关键挑战是分析对现有关键运营标准的影响
which use fully-qualified domain names [RFC1034], or simply host names [RFC1123]. Standards-changes can be effected, but the best path forward is one that takes into account current realities and (re)deployment latencies. In the Internet's global context, it is not enough to update a few isolated systems, or even most of the systems in a country or region. Deployment must be nearly universal in order to avoid the creation of "islands" of interoperation that provide users with less access to and connection from the rest of the world.
使用完全限定域名[RFC1034]或简单的主机名[RFC1123]。标准变更是可以实现的，但最好的前进道路是考虑当前现实和（重新）部署延迟。在互联网的全球背景下，仅仅更新一个国家或地区的几个孤立系统，甚至大部分系统是不够的。部署必须几乎是通用的，以避免创建互操作的“孤岛”，从而为用户提供较少的访问和与世界其他地区的连接。
These are not esoteric or ephemeral concerns. Some specific issues have already been identified as part of the IDN WG's efforts. These include (but are not limited to) the following examples.
这些都不是深奥或短暂的问题。一些具体问题已经确定为IDN工作组工作的一部分。这些包括（但不限于）以下示例。
As indicated in the IDN WG's draft requirements document, the issue goes beyond standardization of DNS usage. Electronic mail has long been one of the most-used and most important applications of the Internet. Internet e-mail is also used as the bridge that permits the users of a variety of local and proprietary mail systems to communicate. The standard protocols that define its use (e.g., SMTP [RFC821, RFC822] and MIME [RFC2045]) do not permit the full range of characters allowed in the DNS specification. Certain characters are not allowed in e-mail address domain portions of these specifications. Some mailers, built to adhere to these specifications, are known to fail when on mail having non-ASCII domain names in its address -- by discarding, misrouting or damaging the mail. Thus, it's not possible to simply switch to internationalized domain names and expect global e-mail to continue to work until most of the servers in the world are upgraded.
正如IDN工作组的需求文件草案所指出的，这个问题超出了DNS使用的标准化。电子邮件长期以来一直是互联网最常用和最重要的应用之一。互联网电子邮件也被用作桥梁，允许各种本地和专有邮件系统的用户进行通信。定义其使用的标准协议（例如SMTP[RFC821、RFC822]和MIME[RFC2045]）不允许DNS规范中允许的完整字符范围。这些规范的电子邮件地址域部分不允许使用某些字符。一些为遵守这些规范而构建的邮件程序，在处理地址中包含非ASCII域名的邮件时会失败——丢弃、错误路由或损坏邮件。因此，在世界上大多数服务器升级之前，不可能简单地切换到国际化域名并期望全局电子邮件继续工作。
At a lower level, the Routing Policy Specification Language (RPLS) [RFC2622] makes use of "named objects" -- and inherits object naming restrictions from older standards ([RFC822] for the same e-mail address restrictions, [RFC1034] for hostnames). This means that until routing registries and their protocols are updated, it is not possible to enter or retrieve network descriptions utilizing internationalized domain names.
在较低的级别上，路由策略规范语言（RPLS）[RFC2622]使用“命名对象”——并继承旧标准中的对象命名限制（[RFC822]用于相同的电子邮件地址限制，[RFC1034]用于主机名）。这意味着，在更新路由注册表及其协议之前，不可能使用国际化域名输入或检索网络描述。
Also, the Simple Network Management Protocol (SNMP) uses the textual representation defined in [RFC2579]. While that specification does allow for UTF-8-based domain names, an informal survey of deployed implementations of software libraries being used to build SNMP-compliant software uncovered the fact that few (if any) implement it.
此外，简单网络管理协议（SNMP）使用[RFC2579]中定义的文本表示。虽然该规范允许使用基于UTF-8的域名，但对用于构建符合SNMP的软件的软件库部署实现的非正式调查发现，很少（如果有的话）实现它。
This may cause inability to enter or display correct data in network management tools, if such names are internationalized domain names.
这可能会导致无法在网络管理工具中输入或显示正确的数据，如果这些名称是国际化域名。
Critical components of Internet public key technologies (PKIX, [RFC2459], IKE [RFC2409]) rely heavily on identification of servers (hostnames, or fully qualified domain names) and users (e-mail addresses). Failure to respect the character restrictions in these protocols will impact security tools built to use them -- Transport Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to name two.
Internet公钥技术（PKIX、[RFC2459]、IKE[RFC2409]）的关键组件在很大程度上依赖于服务器（主机名或完全限定的域名）和用户（电子邮件地址）的标识。不遵守这些协议中的字符限制将影响为使用它们而构建的安全工具——传输层安全协议（TLS，[RFC2246]）和IPsec[RFC2401]等等。
Failure may not be obvious. For example, in TLS, it is common usage for a server to display a certificate containing a domain name purporting to be the domain name of the server, which the client can then match with the server name he thought he used to reach the service.
失败可能并不明显。例如，在TLS中，服务器通常会显示一个证书，其中包含一个声称是服务器域名的域名，然后客户端可以将该域名与他认为用于访问该服务的服务器名称进行匹配。
Unless comparison of domain names is properly defined, the client may either fail to match the domain name of a legitimate server, or match incorrectly the domain name of a server performing a man-in-the-middle attack. Either failure could enable attacks on systems that are now impossible or at least far more difficult.
除非正确定义域名比较，否则客户端可能无法匹配合法服务器的域名，或者与执行中间人攻击的服务器的域名不正确匹配。任何一种故障都可能导致对系统的攻击，而这些攻击现在是不可能的，或者至少要困难得多。
It is therefore clear that, although there are many possible ways to assign internationalized names that are compatible with today's DNS (or a version that is easily-deployable in the near future), not all of them are compatible with the full range of necessary networking tools. When designing a solution for internationalization of domain names, the effects on the current Internet must be carefully evaluated. Some types of solutions proposed would, if put into effect immediately, cause Internet communications to fail in ways that would be hard to detect by and pose problems for those who deploy the new services, but also for those who do not; this would have the effect of cutting those who deploy them off from effective use of the Internet.
因此，很明显，尽管有许多可能的方法来分配与当今DNS兼容的国际化名称（或在不久的将来可以轻松部署的版本），但并非所有这些方法都与所有必要的网络工具兼容。在设计域名国际化解决方案时，必须仔细评估对当前互联网的影响。提出的某些类型的解决方案如果立即生效，将导致互联网通信以难以被部署新服务的人发现的方式出现故障，并给部署新服务的人以及没有部署新服务的人带来问题；这将导致部署它们的人无法有效使用互联网。
The IDN WG has been identified as the appropriate forum for identifying and discussing solutions for such potential interoperability issues.
IDN工作组已被确定为确定和讨论此类潜在互操作性问题解决方案的适当论坛。
Experience with deployment of other protocols has indicated that it will take years before a new protocol or enhancement is used all over the Internet. So far, the IDN WG has benefited from proposed solutions from all quarters, including organizations hoping to
部署其他协议的经验表明，新协议或增强功能在整个互联网上使用需要几年时间。到目前为止，IDN工作组已从各方面提出的解决方案中受益，包括希望
provide services that address visible-name representation and registration -- continuing this process with the aim of getting a single, scalable and deployable solution to this problem is the only way to ensure the continued global interoperation that is the deserved expectation of all Internet users.
提供解决可见名称表示和注册的服务——继续此过程，以获得解决此问题的单一、可扩展和可部署的解决方案，是确保全球持续互操作的唯一方法，这是所有Internet用户应得的期望。
In general, assignment and use of names does not raise any special security problems. However, as noted above, some existing security mechanisms are reliant on the current specification of domain names and may not be expected to work, as is, with Internationalized domain names. Additionally, deployment of non-standard systems (e.g., in response to current pressures to address national or regional characterset representation) might result in name strings that are not globally unique, thereby opening up the possibility of "spoofing" hosts from one domain in another, as described in [RFC2826].
一般来说，名称的分配和使用不会引起任何特殊的安全问题。然而，如上所述，一些现有的安全机制依赖于当前的域名规范，可能无法像国际化域名那样发挥作用。此外，非标准系统的部署（例如，响应当前解决国家或地区字符集表示的压力）可能会导致名称字符串不是全局唯一的，从而打开了从一个域到另一个域“欺骗”主机的可能性，如[RFC2826]所述。
This document is the outcome of the joint effort of the members of the IAB. Additionally, valuable remarks were provided by Randy Bush, Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters.
本文件是IAB成员共同努力的成果。此外，兰迪·布什、帕特里克·法茨特罗姆、特德·哈迪、保罗·霍夫曼和马克·科斯特斯发表了宝贵的评论。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, November 1989.
[RFC1123]Braden，R.，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年11月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[RFC2459]Housley，R.，Ford，W.，Polk，W.和D.Solo，“互联网X.509公钥基础设施证书和CRL配置文件”，RFC 2459，1999年1月。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J. and M. Rose, "Textual Conventions for SMIv2", RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.和M.Rose，“SMIv2的文本约定”，RFC 2579，1999年4月。
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.
[RFC2622]Alaettinoglu，C.，Villamizar，C.，Gerich，E.，Kessens，D.，Meyer，D.，Bates，T.，Karrenberg，D.和M.Terpstra，“路由策略规范语言（RPSL）”，RFC 26221999年6月。
[RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[RFC2826]IAB，“IAB对唯一DNS根的技术评论”，RFC 2826，2000年5月。
Internet Architecture Board
互联网架构委员会
EMail: iab@iab.org
EMail: iab@iab.org
Membership at time this document was completed:
本文件完成时的成员资格：
Harald Alvestrand Ran Atkinson Rob Austein Brian Carpenter Steve Bellovin Jon Crowcroft Leslie Daigle Steve Deering Tony Hain Geoff Huston John Klensin Henning Schulzrinne
哈拉尔·阿尔维斯特兰德（Harald Alvestrand）经营阿特金森（Atkinson）、罗布·奥斯汀（Rob Austein）、布莱恩（Brian）木匠史蒂夫·贝洛文（Steve Bellovin）、乔恩·克劳克罗夫特（Jon Crowcroft）、莱斯利·戴格尔（Leslie Daigle）、史蒂夫·迪林（Tony Hain Geoff Hu
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。