Network Working Group J. Klensin
Request for Comments: 3467 February 2003
Category: Informational
Network Working Group J. Klensin
Request for Comments: 3467 February 2003
Category: Informational
Role of the Domain Name System (DNS)
域名系统（DNS）的角色
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
摘要
This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them.
本文档回顾了域名系统（DNS）的原始功能和用途。它将这一历史与DNS最近应用的一些目的以及对其提出的或建议的一些新要求进行了对比。然后概述了在DNS上施加这些附加应力的替代方案框架。本文件和该框架不是一个拟议的解决方案，只是一个强有力的建议，表明现在是开始更广泛地思考我们所遇到的问题以及解决这些问题的可能途径的时候了。
Table of Contents
目录
1. Introduction and History ..................................... 2
1.1 Context for DNS Development ............................... 3
1.2 Review of the DNS and Its Role as Designed ................ 4
1.3 The Web and User-visible Domain Names ..................... 6
1.4 Internet Applications Protocols and Their Evolution ....... 7
2. Signs of DNS Overloading ..................................... 8
3. Searching, Directories, and the DNS .......................... 12
3.1 Overview ................................................. 12
3.2 Some Details and Comments ................................. 14
4. Internationalization ......................................... 15
4.1 ASCII Isn't Just Because of English ....................... 16
4.2 The "ASCII Encoding" Approaches ........................... 17
4.3 "Stringprep" and Its Complexities ......................... 17
4.4 The Unicode Stability Problem ............................. 19
4.5 Audiences, End Users, and the User Interface Problem ...... 20
4.6 Business Cards and Other Natural Uses of Natural Languages. 22
4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22
1. Introduction and History ..................................... 2
1.1 Context for DNS Development ............................... 3
1.2 Review of the DNS and Its Role as Designed ................ 4
1.3 The Web and User-visible Domain Names ..................... 6
1.4 Internet Applications Protocols and Their Evolution ....... 7
2. Signs of DNS Overloading ..................................... 8
3. Searching, Directories, and the DNS .......................... 12
3.1 Overview ................................................. 12
3.2 Some Details and Comments ................................. 14
4. Internationalization ......................................... 15
4.1 ASCII Isn't Just Because of English ....................... 16
4.2 The "ASCII Encoding" Approaches ........................... 17
4.3 "Stringprep" and Its Complexities ......................... 17
4.4 The Unicode Stability Problem ............................. 19
4.5 Audiences, End Users, and the User Interface Problem ...... 20
4.6 Business Cards and Other Natural Uses of Natural Languages. 22
4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22
4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
5. Search-based Systems: The Key Controversies .................. 23
6. Security Considerations ...................................... 24
7. References ................................................... 25
7.1 Normative References ...................................... 25
7.2 Explanatory and Informative References .................... 25
8. Acknowledgements ............................................. 30
9. Author's Address ............................................. 30
10. Full Copyright Statement ..................................... 31
4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
5. Search-based Systems: The Key Controversies .................. 23
6. Security Considerations ...................................... 24
7. References ................................................... 25
7.1 Normative References ...................................... 25
7.2 Explanatory and Informative References .................... 25
8. Acknowledgements ............................................. 30
9. Author's Address ............................................. 30
10. Full Copyright Statement ..................................... 31
The DNS was designed as a replacement for the older "host table" system. Both were intended to provide names for network resources at a more abstract level than network (IP) addresses (see, e.g., [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]). In recent years, the DNS has become a database of convenience for the Internet, with many proposals to add new features. Only some of these proposals have been successful. Often the main (or only) motivation for using the DNS is because it exists and is widely deployed, not because its existing structure, facilities, and content are appropriate for the particular application of data involved. This document reviews the history of the DNS, including examination of some of those newer applications. It then argues that the overloading process is often inappropriate. Instead, it suggests that the DNS should be supplemented by systems better matched to the intended applications and outlines a framework and rationale for one such system.
DNS被设计为旧的“主机表”系统的替代品。两者都旨在提供比网络（IP）地址更抽象的网络资源名称（参见，例如，[RFC625]、[RFC811]、[RFC819]、[RFC830]、[RFC882]）。近年来，DNS已成为一个方便互联网的数据库，并提出了许多增加新功能的建议。这些建议中只有一部分是成功的。通常，使用DNS的主要（或唯一）动机是因为它存在并且被广泛部署，而不是因为它的现有结构、设施和内容适合所涉及数据的特定应用。本文档回顾了DNS的历史，包括对一些较新应用程序的检查。然后，它认为过载过程通常是不合适的。相反，它建议DNS应该由更适合预期应用的系统来补充，并概述了此类系统的框架和基本原理。
Several of the comments that follow are somewhat revisionist. Good design and engineering often requires a level of intuition by the designers about things that will be necessary in the future; the reasons for some of these design decisions are not made explicit at the time because no one is able to articulate them. The discussion below reconstructs some of the decisions about the Internet's primary namespace (the "Class=IN" DNS) in the light of subsequent development and experience. In addition, the historical reasons for particular decisions about the Internet were often severely underdocumented contemporaneously and, not surprisingly, different participants have different recollections about what happened and what was considered important. Consequently, the quasi-historical story below is just one story. There may be (indeed, almost certainly are) other stories about how the DNS evolved to its present state, but those variants do not invalidate the inferences and conclusions.
下面的一些评论有点修正主义。好的设计和工程通常需要设计师对未来需要的东西有一定程度的直觉；一些设计决策的原因当时没有明确说明，因为没有人能够清楚地表达出来。下面的讨论根据后续的发展和经验，重新构建了有关Internet主名称空间（“Class=IN”DNS）的一些决策。此外，关于互联网的特定决定的历史原因往往在同一时期被严重低估，而且，毫不奇怪，不同的参与者对发生的事情和被认为重要的事情有不同的回忆。因此，下面的准历史故事只是一个故事。关于DNS如何发展到现在的状态，可能有（事实上，几乎肯定有）其他故事，但这些变体并不会使推论和结论无效。
This document presumes a general understanding of the terminology of RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]).
本文件假定对RFC 1034[RFC1034]或任何良好DNS教程的术语有一般理解（参见，例如[Albitz]）。
During the entire post-startup-period life of the ARPANET and nearly the first decade or so of operation of the Internet, the list of host names and their mapping to and from addresses was maintained in a frequently-updated "host table" [RFC625], [RFC811], [RFC952]. The names themselves were restricted to a subset of ASCII [ASCII] chosen to avoid ambiguities in printed form, to permit interoperation with systems using other character codings (notably EBCDIC), and to avoid the "national use" code positions of ISO 646 [IS646]. These restrictions later became collectively known as the "LDH" rules for "letter-digit-hyphen", the permitted characters. The table was just a list with a common format that was eventually agreed upon; sites were expected to frequently obtain copies of, and install, new versions. The host tables themselves were introduced to:
在ARPANET启动后的整个生命周期以及互联网运行的前十年左右，主机名列表及其与地址之间的映射被保存在频繁更新的“主机表”[RFC625]、[RFC811]、[RFC952]中。名称本身被限制为ASCII[ASCII]的子集，以避免打印形式的歧义，允许与使用其他字符编码（尤其是EBCDIC）的系统进行互操作，并避免ISO 646[IS646]的“国家使用”代码位置。这些限制后来统称为“字母-数字连字符”的“LDH”规则，即允许的字符。该表格只是一份最终商定的通用格式清单；网站应经常获取并安装新版本的副本。主机表本身被介绍为：
o Eliminate the requirement for people to remember host numbers (addresses). Despite apparent experience to the contrary in the conventional telephone system, numeric numbering systems, including the numeric host number strategy, did not (and do not) work well for more than a (large) handful of hosts.
o 消除了人们记忆主机号码（地址）的要求。尽管在传统电话系统中有明显相反的经验，但数字编号系统，包括数字主机编号策略，在（大量）少数主机上不能（也不能）很好地工作。
o Provide stability when addresses changed. Since addresses -- to some degree in the ARPANET and more importantly in the contemporary Internet -- are a function of network topology and routing, they often had to be changed when connectivity or topology changed. The names could be kept stable even as addresses changed.
o 在地址更改时提供稳定性。由于地址——在某种程度上在ARPANET中，更重要的是在当代互联网中——是网络拓扑和路由的函数，因此当连接或拓扑发生变化时，地址常常必须改变。即使地址发生变化，这些名称也可以保持稳定。
o Provide the capability to have multiple addresses associated with a given host to reflect different types of connectivity and topology. Use of names, rather than explicit addresses, avoided the requirement that would otherwise exist for users and other hosts to track these multiple host numbers and addresses and the topological considerations for selecting one over others.
o 提供与给定主机关联的多个地址的功能，以反映不同类型的连接和拓扑。使用名称，而不是显式地址，避免了用户和其他主机跟踪这些多个主机号和地址的要求，以及选择一个主机而不是其他主机的拓扑考虑。
After several years of using the host table approach, the community concluded that model did not scale adequately and that it would not adequately support new service variations. A number of discussions and meetings were held which drew several ideas and incomplete proposals together. The DNS was the result of that effort. It continued to evolve during the design and initial implementation period, with a number of documents recording the changes (see [RFC819], [RFC830], and [RFC1034]).
在使用主机表方法数年后，社区得出结论，该模型没有充分扩展，不能充分支持新的服务变化。举行了一些讨论和会议，汇集了一些想法和不完整的提案。DNS就是这一努力的结果。它在设计和初始实施期间继续发展，许多文件记录了这些变化（参见[RFC819]、[RFC830]和[RFC1034]）。
The goals for the DNS included:
DNS的目标包括：
o Preservation of the capabilities of the host table arrangements (especially unique, unambiguous, host names),
o 保留主机表安排的功能（特别是唯一、明确的主机名），
o Provision for addition of additional services (e.g., the special record types for electronic mail routing which quickly followed introduction of the DNS), and
o 增加额外服务的规定（例如，DNS引入后很快出现的电子邮件路由的特殊记录类型），以及
o Creation of a robust, hierarchical, distributed, name lookup system to accomplish the other goals.
o 创建一个健壮的、分层的、分布式的名称查找系统，以实现其他目标。
The DNS design also permitted distribution of name administration, rather than requiring that each host be entered into a single, central, table by a central administration.
DNS设计还允许分发名称管理，而不是要求中央管理将每个主机输入到一个单一的中央表中。
The DNS was designed to identify network resources. Although there was speculation about including, e.g., personal names and email addresses, it was not designed primarily to identify people, brands, etc. At the same time, the system was designed with the flexibility to accommodate new data types and structures, both through the addition of new record types to the initial "INternet" class, and, potentially, through the introduction of new classes. Since the appropriate identifiers and content of those future extensions could not be anticipated, the design provided that these fields could contain any (binary) information, not just the restricted text forms of the host table.
DNS设计用于识别网络资源。虽然有人猜测包括（例如）个人姓名和电子邮件地址，但其设计主要不是为了识别人员、品牌等。同时，该系统的设计具有灵活性，能够适应新的数据类型和结构，包括通过在最初的“互联网”类别中添加新的记录类型，潜在地，通过引入新类。由于无法预期这些未来扩展的适当标识符和内容，因此设计规定这些字段可以包含任何（二进制）信息，而不仅仅是主机表的受限文本形式。
However, the DNS, as it is actually used, is intimately tied to the applications and application protocols that utilize it, often at a fairly low level.
然而，实际使用的DNS与使用它的应用程序和应用程序协议密切相关，通常处于相当低的级别。
In particular, despite the ability of the protocols and data structures themselves to accommodate any binary representation, DNS names as used were historically not even unrestricted ASCII, but a very restricted subset of it, a subset that derives from the original host table naming rules. Selection of that subset was driven in part by human factors considerations, including a desire to eliminate possible ambiguities in an international context. Hence character codes that had international variations in interpretation were excluded, the underscore character and case distinctions were eliminated as being confusing (in the underscore's case, with the hyphen character) when written or read by people, and so on. These considerations appear to be very similar to those that resulted in similarly restricted character sets being used as protocol elements in many ITU and ISO protocols (cf. [X29]).
特别是，尽管协议和数据结构本身能够容纳任何二进制表示，但历史上使用的DNS名称甚至不是不受限制的ASCII，而是它的一个非常受限制的子集，一个源自原始主机表命名规则的子集。选择这一子集部分是出于人为因素的考虑，包括希望消除国际环境中可能存在的歧义。因此，在解释上具有国际差异的字符代码被排除在外，下划线字符和大小写的区别被消除，因为人们在书写或阅读时容易混淆（在下划线的情况下，使用连字符），等等。这些考虑因素似乎与导致在许多ITU和ISO协议（参见[X29]）中使用类似受限字符集作为协议元素的考虑因素非常相似。
Another assumption was that there would be a high ratio of physical hosts to second level domains and, more generally, that the system would be deeply hierarchical, with most systems (and names) at the third level or below and a very large percentage of the total names representing physical hosts. There are domains that follow this model: many university and corporate domains use fairly deep hierarchies, as do a few country-oriented top level domains ("ccTLDs"). Historically, the "US." domain has been an excellent example of the deeply hierarchical approach. However, by 1998, comparison of several efforts to survey the DNS showed a count of SOA records that approached (and may have passed) the number of distinct hosts. Looked at differently, we appear to be moving toward a situation in which the number of delegated domains on the Internet is approaching or exceeding the number of hosts, or at least the number of hosts able to provide services to others on the network. This presumably results from synonyms or aliases that map a great many names onto a smaller number of hosts. While experience up to this time has shown that the DNS is robust enough -- given contemporary machines as servers and current bandwidth norms -- to be able to continue to operate reasonably well when those historical assumptions are not met (e.g., with a flat, structure under ".COM" containing well over ten million delegated subdomains [COMSIZE]), it is still useful to remember that the system could have been designed to work optimally with a flat structure (and very large zones) rather than a deeply hierarchical one, and was not.
另一个假设是，物理主机与二级域的比例很高，而且更一般地说，系统的层次结构很深，大多数系统（和名称）处于三级或三级以下，并且总名称中有很大一部分代表物理主机。有一些领域遵循这种模式：许多大学和公司领域使用相当深的层次结构，一些面向国家的顶级领域（“CCTLD”）也是如此。从历史上看，“US.”域一直是深入分层方法的一个很好的例子。然而，到1998年，对调查DNS的几项工作的比较显示，SOA记录的数量接近（并且可能已经超过）不同主机的数量。从不同的角度来看，我们似乎正朝着这样一种情况发展：互联网上的委派域数量接近或超过主机数量，或者至少是能够向网络上的其他人提供服务的主机数量。这可能是因为同义词或别名将大量名称映射到较少主机上。尽管迄今为止的经验表明，DNS足够强大——考虑到作为服务器的当代机器和当前的带宽规范——能够在不满足这些历史假设的情况下（例如，“.COM”下的扁平结构包含超过1000万个委托子域[COMSIZE]）继续合理运行，记住，系统可以设计为在平面结构（以及非常大的区域）而不是深层次的层次结构下以最佳方式工作，这一点仍然很有用，但事实并非如此。
Similarly, despite some early speculation about entering people's names and email addresses into the DNS directly (e.g., see [RFC1034]), electronic mail addresses in the Internet have preserved the original, pre-DNS, "user (or mailbox) at location" conceptual format rather than a flatter or strictly dot-separated one. Location, in that instance, is a reference to a host. The sole exception, at least in the "IN" class, has been one field of the SOA record.
类似地，尽管早期有人猜测将人的姓名和电子邮件地址直接输入DNS（例如，请参见[RFC1034]），但互联网上的电子邮件地址保留了原始的DNS前的“位置处的用户（或邮箱）”概念格式，而不是更平坦或严格的点分隔格式。在该实例中，位置是对主机的引用。唯一的例外，至少在“in”类中是SOA记录的一个字段。
Both the DNS architecture itself and the two-level (host name and mailbox name) provisions for email and similar functions (e.g., see the finger protocol [FINGER]), also anticipated a relatively high ratio of users to actual hosts. Despite the observation in RFC 1034 that the DNS was expected to grow to be proportional to the number of users (section 2.3), it has never been clear that the DNS was seriously designed for, or could, scale to the order of magnitude of number of users (or, more recently, products or document objects), rather than that of physical hosts.
DNS体系结构本身以及电子邮件和类似功能的两级（主机名和邮箱名）规定（例如，参见finger协议[finger]）也预计用户与实际主机的比例相对较高。尽管在RFC 1034中观察到DNS预计将与用户数量成比例增长（第2.3节），但始终不清楚DNS是否是为用户数量（或最近的产品或文档对象）而不是物理主机数量的数量级而认真设计的，或者是否可以扩展到用户数量的数量级。
Just as was the case for the host table before it, the DNS provided critical uniqueness for names, and universal accessibility to them, as part of overall "single internet" and "end to end" models (cf.
与之前的主机表一样，DNS为名称提供了关键的唯一性和通用的可访问性，作为整体“单一互联网”和“端到端”模型的一部分（参见。
[RFC2826]). However, there are many signs that, as new uses evolved and original assumptions were abused (if not violated outright), the system was being stretched to, or beyond, its practical limits.
[RFC2826]）。然而，有许多迹象表明，随着新用途的发展和原始假设的滥用（如果不是彻底违反的话），该系统正被扩展到或超出其实际极限。
The original design effort that led to the DNS included examination of the directory technologies available at the time. The design group concluded that the DNS design, with its simplifying assumptions and restricted capabilities, would be feasible to deploy and make adequately robust, which the more comprehensive directory approaches were not. At the same time, some of the participants feared that the limitations might cause future problems; this document essentially takes the position that they were probably correct. On the other hand, directory technology and implementations have evolved significantly in the ensuing years: it may be time to revisit the assumptions, either in the context of the two- (or more) level mechanism contemplated by the rest of this document or, even more radically, as a path toward a DNS replacement.
导致DNS的最初设计工作包括检查当时可用的目录技术。设计小组的结论是，DNS设计由于其简化的假设和有限的功能，将是可行的部署，并使其具有足够的健壮性，而更全面的目录方法则不具备这一点。同时，一些与会者担心这些限制可能会导致未来的问题；本文件的基本立场是，它们可能是正确的。另一方面，目录技术和实现在随后的几年中有了显著的发展：现在可能是重新审视这些假设的时候了，无论是在本文档其余部分所设想的两（或更多）级机制的背景下，还是更根本的，作为DNS替代的途径。
From the standpoint of the integrity of the domain name system -- and scaling of the Internet, including optimal accessibility to content -- the web design decision to use "A record" domain names directly in URLs, rather than some system of indirection, has proven to be a serious mistake in several respects. Convenience of typing, and the desire to make domain names out of easily-remembered product names, has led to a flattening of the DNS, with many people now perceiving that second-level names under COM (or in some countries, second- or third-level names under the relevant ccTLD) are all that is meaningful. This perception has been reinforced by some domain name registrars [REGISTRAR] who have been anxious to "sell" additional names. And, of course, the perception that one needed a second-level (or even top-level) domain per product, rather than having names associated with a (usually organizational) collection of network resources, has led to a rapid acceleration in the number of names being registered. That acceleration has, in turn, clearly benefited registrars charging on a per-name basis, "cybersquatters", and others in the business of "selling" names, but it has not obviously benefited the Internet as a whole.
从域名系统的完整性和互联网的可扩展性（包括内容的最佳可访问性）的角度来看，在URL中直接使用“记录”域名而不是某种间接系统的web设计决策在几个方面被证明是一个严重错误。打字的便利性，以及用容易记住的产品名制作域名的愿望，导致了DNS的扁平化，许多人现在认为COM下的二级名称（或在某些国家，相关ccTLD下的二级或三级名称）才是有意义的。一些域名注册商（registrator）也强化了这种看法，他们急于“出售”更多的域名。当然，人们认为每个产品都需要一个二级（甚至是顶级）域名，而不是将名称与网络资源（通常是组织性的）集合相关联，这导致注册的名称数量迅速增加。反过来，这种加速明显有利于按姓名收费的注册商、“网络抢注者”和其他从事“出售”姓名业务的人，但这显然没有使整个互联网受益。
This emphasis on second-level domain names has also created a problem for the trademark community. Since the Internet is international, and names are being populated in a flat and unqualified space, similarly-named entities are in conflict even if there would ordinarily be no chance of confusing them in the marketplace. The problem appears to be unsolvable except by a choice between draconian measures. These might include significant changes to the legislation and conventions that govern disputes over "names" and "marks". Or
这种对二级域名的强调也给商标界带来了问题。由于互联网是国际性的，而且名字都是在一个扁平且不合格的空间中填充的，因此类似的命名实体存在冲突，即使在市场上通常不会混淆它们。除非在严厉措施之间做出选择，否则这个问题似乎无法解决。这些可能包括对管辖“名称”和“标志”争端的立法和公约进行重大修改。或
they might result in a situation in which the "rights" to a name are typically not settled using the subtle and traditional product (or industry) type and geopolitical scope rules of the trademark system. Instead they have depended largely on political or economic power, e.g., the organization with the greatest resources to invest in defending (or attacking) names will ultimately win out. The latter raises not only important issues of equity, but also the risk of backlash as the numerous small players are forced to relinquish names they find attractive and to adopt less-desirable naming conventions.
它们可能会导致一种情况，即对一个名称的“权利”通常不会使用商标制度中微妙的传统产品（或行业）类型和地缘政治范围规则来解决。相反，他们在很大程度上依赖于政治或经济实力，例如，拥有最大资源投资于捍卫（或攻击）名字的组织最终会胜出。后者不仅带来了重要的公平问题，而且还带来了遭到抵制的风险，因为众多小公司被迫放弃他们认为有吸引力的名字，并采用不太理想的命名惯例。
Independent of these sociopolitical problems, content distribution issues have made it clear that it should be possible for an organization to have copies of data it wishes to make available distributed around the network, with a user who asks for the information by name getting the topologically-closest copy. This is not possible with simple, as-designed, use of the DNS: DNS names identify target resources or, in the case of email "MX" records, a preferentially-ordered list of resources "closest" to a target (not to the source/user). Several technologies (and, in some cases, corresponding business models) have arisen to work around these problems, including intercepting and altering DNS requests so as to point to other locations.
与这些社会政治问题无关，内容分发问题清楚地表明，一个组织应该可以将其希望提供的数据副本分发到整个网络中，通过名称请求信息的用户可以获得拓扑上最接近的副本。简单地使用DNS是不可能做到这一点的：DNS名称标识目标资源，或者在电子邮件“MX”记录的情况下，优先排序的“最接近”目标（而不是源/用户）的资源列表。一些技术（在某些情况下，还有相应的业务模型）已经出现，以解决这些问题，包括拦截和更改DNS请求以指向其他位置。
Additional implications are still being discovered and evaluated.
其他影响仍在发现和评估之中。
Approaches that involve interception of DNS queries and rewriting of DNS names (or otherwise altering the resolution process based on the topological location of the user) seem, however, to risk disrupting end-to-end applications in the general case and raise many of the issues discussed by the IAB in [IAB-OPES]. These problems occur even if the rewriting machinery is accompanied by additional workarounds for particular applications. For example, security associations and applications that need to identify "the same host" often run into problems if DNS names or other references are changed in the network without participation of the applications that are trying to invoke the associated services.
然而，涉及截取DNS查询和重写DNS名称（或根据用户的拓扑位置改变解析过程）的方法在一般情况下似乎有可能中断端到端应用程序，并引发IAB在[IAB-OPES]中讨论的许多问题。即使重写机制伴随着针对特定应用的额外解决方法，也会出现这些问题。例如，如果在网络中更改DNS名称或其他引用而没有尝试调用关联服务的应用程序的参与，则需要标识“同一主机”的安全关联和应用程序通常会遇到问题。
At the applications level, few of the protocols in active, widespread, use on the Internet reflect either contemporary knowledge in computer science or human factors or experience accumulated through deployment and use. Instead, protocols tend to be deployed at a just-past-prototype level, typically including the types of expedient compromises typical with prototypes. If they prove useful, the nature of the network permits very rapid dissemination (i.e., they fill a vacuum, even if a vacuum that no one previously knew existed). But, once the vacuum is filled, the installed base
在应用层面，互联网上活跃、广泛使用的协议很少反映计算机科学的当代知识或人的因素或通过部署和使用积累的经验。相反，协议倾向于在刚刚过去的原型级别上部署，通常包括原型典型的权宜之计。如果它们被证明是有用的，网络的性质允许非常迅速的传播（即，它们填补了一个真空，即使以前没有人知道存在一个真空）。但是，一旦真空被填满，安装的基础
provides its own inertia: unless the design is so seriously faulty as to prevent effective use (or there is a widely-perceived sense of impending disaster unless the protocol is replaced), future developments must maintain backward compatibility and workarounds for problematic characteristics rather than benefiting from redesign in the light of experience. Applications that are "almost good enough" prevent development and deployment of high-quality replacements.
提供其自身的惯性：除非设计存在严重缺陷，无法有效使用（或者除非协议被替换，否则人们普遍认为灾难即将来临），未来的开发必须为有问题的特性保持向后兼容性和变通方法，而不是根据经验从重新设计中获益。“几乎足够好”的应用程序会阻止高质量替换的开发和部署。
The DNS is both an illustration of, and an exception to, parts of this pessimistic interpretation. It was a second-generation development, with the host table system being seen as at the end of its useful life. There was a serious attempt made to reflect the computing state of the art at the time. However, deployment was much slower than expected (and very painful for many sites) and some fixed (although relaxed several times) deadlines from a central network administration were necessary for deployment to occur at all. Replacing it now, in order to add functionality, while it continues to perform its core functions at least reasonably well, would presumably be extremely difficult.
DNS既是这种悲观解释的一个例证，也是一个例外。这是第二代开发，主机表系统被视为在其使用寿命结束时。有一个认真的尝试，以反映当时的计算技术水平。但是，部署速度比预期慢得多（对许多站点来说，这是非常痛苦的），而且中央网络管理部门的一些固定（尽管放宽了好几次）期限对于部署来说是必需的。为了增加功能，在它继续至少相当好地执行其核心功能的同时，现在替换它可能非常困难。
There are many, perhaps obvious, examples of this. Despite many known deficiencies and weaknesses of definition, the "finger" and "whois" [WHOIS] protocols have not been replaced (despite many efforts to update or replace the latter [WHOIS-UPDATE]). The Telnet protocol and its many options drove out the SUPDUP [RFC734] one, which was arguably much better designed for a diverse collection of network hosts. A number of efforts to replace the email or file transfer protocols with models which their advocates considered much better have failed. And, more recently and below the applications level, there is some reason to believe that this resistance to change has been one of the factors impeding IPv6 deployment.
这方面的例子很多，也许很明显。尽管定义存在许多已知的缺陷和弱点，“finger”和“whois”[whois]协议尚未被替换（尽管有许多努力更新或替换后者[whois-update]）。Telnet协议及其众多选项淘汰了SUPDUP[RFC734]协议，该协议可以说更适合于各种网络主机。用他们的拥护者认为更好的模型取代电子邮件或文件传输协议的许多努力都失败了。而且，最近在应用程序级别以下，有理由相信这种对变化的抵制已经成为阻碍IPv6部署的因素之一。
Parts of the historical discussion above identify areas in which the DNS has become overloaded (semantically if not in the mechanical ability to resolve names). Despite this overloading, it appears that DNS performance and reliability are still within an acceptable range: there is little evidence of serious performance degradation. Recent proposals and mechanisms to better respond to overloading and scaling issues have all focused on patching or working around limitations that develop when the DNS is utilized for out-of-design functions, rather than on dramatic rethinking of either DNS design or those uses. The number of these issues that have arisen at much the same time may argue for just that type of rethinking, and not just for adding complexity and attempting to incrementally alter the design (see, for example, the discussion of simplicity in section 2 of [RFC3439]).
上述历史讨论的部分内容确定了DNS过载的区域（如果不是在解析名称的机械能力方面，则在语义上）。尽管存在这种过载，但DNS性能和可靠性似乎仍在可接受的范围内：几乎没有证据表明性能严重下降。为了更好地应对过载和扩展问题，最近的提案和机制都集中在修补或解决DNS用于设计外功能时产生的限制，而不是对DNS设计或这些使用进行戏剧性的重新思考。同时出现的这些问题的数量可能会支持这种类型的重新思考，而不仅仅是增加复杂性和试图逐步改变设计（例如，参见[RFC3439]第2节中关于简单性的讨论）。
For example:
例如：
o While technical approaches such as larger and higher-powered servers and more bandwidth, and legal/political mechanisms such as dispute resolution policies, have arguably kept the problems from becoming critical, the DNS has not proven adequately responsive to business and individual needs to describe or identify things (such as product names and names of individuals) other than strict network resources.
o 虽然技术方法（如更大、更高功率的服务器和更多带宽）以及法律/政治机制（如争议解决政策）可以说阻止了问题的严重性，但事实证明DNS并没有充分响应企业和个人描述或识别事物的需要（如产品名称和个人姓名）而非严格的网络资源。
o While stacks have been modified to better handle multiple addresses on a physical interface and some protocols have been extended to include DNS names for determining context, the DNS does not deal especially well with many names associated with a given host (e.g., web hosting facilities with multiple domains on a server).
o 虽然堆栈已被修改以更好地处理物理接口上的多个地址，并且一些协议已被扩展以包括用于确定上下文的DNS名称，但DNS不能很好地处理与给定主机相关联的许多名称（例如，服务器上具有多个域的web托管设施）。
o Efforts to add names deriving from languages or character sets based on other than simple ASCII and English-like names (see below), or even to utilize complex company or product names without the use of hierarchy, have created apparent requirements for names (labels) that are over 63 octets long. This requirement will undoubtedly increase over time; while there are workarounds to accommodate longer names, they impose their own restrictions and cause their own problems.
o 添加源自非简单ASCII和类似英语名称（见下文）的语言或字符集的名称，甚至使用复杂的公司或产品名称而不使用层次结构的努力，对长度超过63个八位字节的名称（标签）产生了明显的要求。这一要求无疑将随着时间的推移而增加；虽然有一些变通方法可以容纳较长的名称，但它们会施加自己的限制并导致自己的问题。
o Increasing commercialization of the Internet, and visibility of domain names that are assumed to match names of companies or products, has turned the DNS and DNS names into a trademark battleground. The traditional trademark system in (at least) most countries makes careful distinctions about fields of applicability. When the space is flattened, without differentiation by either geography or industry sector, not only are there likely conflicts between "Joe's Pizza" (of Boston) and "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto Repair" (of Los Angeles). All three would like to control "Joes.com" (and would prefer, if it were permitted by DNS naming rules, to also spell it as "Joe's.com" and have both resolve the same way) and may claim trademark rights to do so, even though conflict or confusion would not occur with traditional trademark principles.
o 随着互联网商业化程度的提高，以及被认为与公司或产品名称相匹配的域名的可见度不断提高，DNS和DNS名称已成为一个商标战场。（至少）大多数国家的传统商标制度对适用范围进行了仔细区分。当空间变得平坦，没有地域或行业区分时，不仅“乔的比萨饼”（波士顿）和“乔的比萨饼”（旧金山）之间可能存在冲突，而且“乔的汽车修理”（洛杉矶）与“乔的汽车修理”之间也可能存在冲突。这三家公司都希望控制“Joes.com”（如果DNS命名规则允许的话，他们更愿意将其拼写为“Joe's.com”，并以相同的方式进行解析），并且可以主张商标权，即使与传统商标原则不会发生冲突或混淆。
o Many organizations wish to have different web sites under the same URL and domain name. Sometimes this is to create local variations -- the Widget Company might want to present different material to a UK user relative to a US one -- and sometimes it is to provide higher performance by supplying information from the server topologically closest to the user. If the name resolution
o 许多组织希望在同一URL和域名下有不同的网站。有时这是为了创建本地变体——Widget公司可能希望向英国用户提供与美国用户不同的材料——有时是通过从拓扑上最接近用户的服务器提供信息来提供更高的性能。如果名称解析
mechanism is expected to provide this functionality, there are three possible models (which might be combined):
预计该机制将提供此功能，有三种可能的模型（可以组合）：
- supply information about multiple sites (or locations or references). Those sites would, in turn, provide information associated with the name and sufficient site-specific attributes to permit the application to make a sensible choice of destination, or
- 提供有关多个站点（或位置或参考）的信息。这些站点反过来将提供与名称相关的信息和足够的站点特定属性，以允许应用程序明智地选择目的地，或
- accept client-site attributes and utilize them in the search process, or
- 接受客户端站点属性并在搜索过程中使用它们，或
- return different answers based on the location or identity of the requestor.
- 根据请求者的位置或身份返回不同的答案。
While there are some tricks that can provide partial simulations of these types of function, DNS responses cannot be reliably conditioned in this way.
虽然有一些技巧可以提供这些类型功能的部分模拟，但DNS响应不能以这种方式进行可靠调节。
These, and similar, issues of performance or content choices can, of course, be thought of as not involving the DNS at all. For example, the commonly-cited alternate approach of coupling these issues to HTTP content negotiation (cf. [RFC2295]), requires that an HTTP connection first be opened to some "common" or "primary" host so that preferences can be negotiated and then the client redirected or sent alternate data. At least from the standpoint of improving performance by accessing a "closer" location, both initially and thereafter, this approach sacrifices the desired result before the client initiates any action. It could even be argued that some of the characteristics of common content negotiation approaches are workarounds for the non-optimal use of the DNS in web URLs.
当然，这些以及类似的性能或内容选择问题可以被认为根本不涉及DNS。例如，通常引用的将这些问题耦合到HTTP内容协商的替代方法（参见[RFC2295]）要求首先打开到某个“公共”或“主”主机的HTTP连接，以便可以协商首选项，然后客户端重定向或发送替代数据。至少从通过访问“更近”的位置（最初和之后）来提高性能的角度来看，这种方法在客户机启动任何操作之前牺牲了期望的结果。甚至可以说，常见内容协商方法的一些特征是在web URL中非最佳使用DNS的变通方法。
o Many existing and proposed systems for "finding things on the Internet" require a true search capability in which near matches can be reported to the user (or to some user agent with an appropriate rule-set) and to which queries may be ambiguous or fuzzy. The DNS, by contrast, can accommodate only one set of (quite rigid) matching rules. Proposals to permit different rules in different localities (e.g., matching rules that are TLD- or zone-specific) help to identify the problem. But they cannot be applied directly to the DNS without either abandoning the desired level of flexibility or isolating different parts of the Internet from each other (or both). Fuzzy or ambiguous searches are desirable for resolution of names that might have spelling variations and for names that can be resolved into different sets of glyphs depending on context. Especially when internationalization is considered, variant name problems go beyond simple differences in representation of a character or
o 许多现有和拟议的“在互联网上查找东西”系统需要真正的搜索能力，在这种能力中，可以向用户（或具有适当规则集的某个用户代理）报告接近匹配的内容，并且查询可能是模糊的或模糊的。相比之下，DNS只能容纳一组（相当严格的）匹配规则。允许在不同地方实施不同规则的建议（例如，针对TLD或区域的匹配规则）有助于确定问题。但如果不放弃所需的灵活性或将互联网的不同部分彼此隔离（或两者都隔离），它们就无法直接应用于DNS。模糊或模棱两可的搜索适用于解析可能存在拼写变化的名称，以及可根据上下文解析为不同字形集的名称。特别是在考虑国际化时，变体名称问题超出了字符或名称表示的简单差异
ordering of a string. Instead, avoiding user astonishment and confusion requires consideration of relationships such as languages that can be written with different alphabets, Kanji-Hiragana relationships, Simplified and Traditional Chinese, etc. See [Seng] for a discussion and suggestions for addressing a subset of these issues in the context of characters based on Chinese ones. But that document essentially illustrates the difficulty of providing the type of flexible matching that would be anticipated by users; instead, it tries to protect against the worst types of confusion (and opportunities for fraud).
字符串的排序。相反，为了避免用户的惊讶和困惑，需要考虑各种关系，例如可以用不同字母书写的语言、汉字-平假名关系、简体中文和繁体中文等。参见[Seng]讨论并建议如何在基于汉字的汉字背景下解决这些问题的子集。但该文件从本质上说明了提供用户预期的灵活匹配类型的困难；相反，它试图防止最严重的混乱（以及欺诈的机会）。
o The historical DNS, and applications that make assumptions about how it works, impose significant risk (or forces technical kludges and consequent odd restrictions), when one considers adding mechanisms for use with various multi-character-set and multilingual "internationalization" systems. See the IAB's discussion of some of these issues [RFC2825] for more information.
o 当人们考虑添加用于各种多字符集和多语言“国际化”系统的机制时，历史DNS和对其工作方式进行假设的应用程序会带来重大风险（或强制技术混乱和随后的奇怪限制）。有关更多信息，请参见IAB对其中一些问题的讨论[RFC2825]。
o In order to provide proper functionality to the Internet, the DNS must have a single unique root (the IAB provides more discussion of this issue [RFC2826]). There are many desires for local treatment of names or character sets that cannot be accommodated without either multiple roots (e.g., a separate root for multilingual names, proposed at various times by MINC [MINC] and others), or mechanisms that would have similar effects in terms of Internet fragmentation and isolation.
o 为了向互联网提供适当的功能，DNS必须有一个唯一的根（IAB提供了关于这个问题的更多讨论[RFC2826]）。许多人希望对名称或字符集进行局部处理，如果没有多个词根（例如，多语言名称的单独词根，由MINC[MINC]和其他人在不同时间提出），或者没有在互联网碎片化和隔离方面具有类似效果的机制，这些名称或字符集将无法适应。
o For some purposes, it is desirable to be able to search not only an index entry (labels or fully-qualified names in the DNS case), but their values or targets (DNS data). One might, for example, want to locate all of the host (and virtual host) names which cause mail to be directed to a given server via MX records. The DNS does not support this capability (see the discussion in [IQUERY]) and it can be simulated only by extracting all of the relevant records (perhaps by zone transfer if the source permits doing so, but that permission is becoming less frequently available) and then searching a file built from those records.
o 出于某些目的，不仅希望能够搜索索引项（DNS中的标签或完全限定名），而且还希望能够搜索其值或目标（DNS数据）。例如，您可能希望找到所有导致邮件通过MX记录定向到给定服务器的主机（和虚拟主机）名称。DNS不支持此功能（请参见[IQUERY]中的讨论），只能通过提取所有相关记录（如果源允许，可能通过区域传输，但该权限越来越不常用）然后搜索根据这些记录生成的文件来模拟此功能。
o Finally, as additional types of personal or identifying information are added to the DNS, issues arise with protection of that information. There are increasing calls to make different information available based on the credentials and authorization of the source of the inquiry. As with information keyed to site locations or proximity (as discussed above), the DNS protocols make providing these differentiated services quite difficult if not impossible.
o 最后，由于DNS中添加了其他类型的个人或身份信息，因此会出现保护该信息的问题。根据查询来源的凭证和授权，越来越多的人要求提供不同的信息。与键入站点位置或邻近性的信息（如上所述）一样，DNS协议使得提供这些差异化服务非常困难（如果不是不可能的话）。
In each of these cases, it is, or might be, possible to devise ways to trick the DNS system into supporting mechanisms that were not designed into it. Several ingenious solutions have been proposed in many of these areas already, and some have been deployed into the marketplace with some success. But the price of each of these changes is added complexity and, with it, added risk of unexpected and destabilizing problems.
在每一种情况下，都有可能或可能有办法欺骗DNS系统，使其支持未设计的机制。在其中许多领域已经提出了一些独创性的解决方案，其中一些已经部署到市场上并取得了一些成功。但这些变化的代价是增加了复杂性，同时也增加了意外和不稳定问题的风险。
Several of the above problems are addressed well by a good directory system (supported by the LDAP protocol or some protocol more precisely suited to these specific applications) or searching environment (such as common web search engines) although not by the DNS. Given the difficulty of deploying new applications discussed above, an important question is whether the tricks and kludges are bad enough, or will become bad enough as usage grows, that new solutions are needed and can be deployed.
上面的几个问题可以通过良好的目录系统（由LDAP协议或更适合于这些特定应用程序的某些协议支持）或搜索环境（如通用web搜索引擎）得到很好的解决，尽管DNS不支持这些问题。鉴于上面讨论的部署新应用程序的困难，一个重要的问题是，这些技巧和难题是否已经足够糟糕，或者随着使用量的增加，它们是否会变得足够糟糕，是否需要并可以部署新的解决方案。
The constraints of the DNS and the discussion above suggest the introduction of an intermediate protocol mechanism, referred to below as a "search layer" or "searchable system". The terms "directory" and "directory system" are used interchangeably with "searchable system" in this document, although the latter is far more precise. Search layer proposals would use a two (or more) stage lookup, not unlike several of the proposals for internationalized names in the DNS (see section 4), but all operations but the final one would involve searching other systems, rather than looking up identifiers in the DNS itself. As explained below, this would permit relaxation of several constraints, leading to a more capable and comprehensive overall system.
DNS的限制和上述讨论建议引入中间协议机制，以下称为“搜索层”或“可搜索系统”。在本文件中，术语“目录”和“目录系统”可与“可搜索系统”互换使用，尽管后者更为精确。搜索层建议将使用两个（或更多）阶段的查找，与DNS中国际化名称的几个建议不同（参见第4节），但除最后一个操作外，所有操作都将涉及搜索其他系统，而不是在DNS中查找标识符。如下文所述，这将允许放宽若干限制，从而形成一个能力更强、更全面的整体系统。
Ultimately, many of the issues with domain names arise as the result of efforts to use the DNS as a directory. While, at the time this document was written, sufficient pressure or demand had not occurred to justify a change, it was already quite clear that, as a directory system, the DNS is a good deal less than ideal. This document suggests that there actually is a requirement for a directory system, and that the right solution to a searchable system requirement is a searchable system, not a series of DNS patches, kludges, or workarounds.
最终，域名的许多问题都是使用DNS作为目录的结果。虽然在编写本文档时，还没有出现足够的压力或需求来证明更改的合理性，但很明显，作为一个目录系统，DNS远远不够理想。本文档表明，实际上需要一个目录系统，可搜索系统需求的正确解决方案是一个可搜索系统，而不是一系列DNS补丁、乱码或解决方法。
The following points illustrate particular aspects of this conclusion.
以下几点说明了这一结论的具体方面。
o A directory system would not require imposition of particular length limits on names.
o 目录系统不需要对名称施加特定的长度限制。
o A directory system could permit explicit association of attributes, e.g., language and country, with a name, without having to utilize trick encodings to incorporate that information in DNS labels (or creating artificial hierarchy for doing so).
o 目录系统可以允许将属性（例如语言和国家）与名称显式关联，而无需使用技巧编码将该信息合并到DNS标签中（或为此创建人工层次结构）。
o There is considerable experience (albeit not much of it very successful) in doing fuzzy and "sonex" (similar-sounding) matching in directory systems. Moreover, it is plausible to think about different matching rules for different areas and sets of names so that these can be adapted to local cultural requirements. Specifically, it might be possible to have a single form of a name in a directory, but to have great flexibility about what queries matched that name (and even have different variations in different areas). Of course, the more flexibility that a system provides, the greater the possibility of real or imagined trademark conflicts. But the opportunity would exist to design a directory structure that dealt with those issues in an intelligent way, while DNS constraints almost certainly make a general and equitable DNS-only solution impossible.
o 在目录系统中进行模糊匹配和“sonex”（类似的声音）匹配有相当多的经验（尽管不是很成功）。此外，考虑不同地区和名称集合的不同匹配规则是合理的，以便这些规则能够适应当地的文化要求。具体地说，在目录中可能有一个单一形式的名称，但是对于哪些查询匹配该名称（甚至在不同的区域有不同的变体）有很大的灵活性。当然，系统提供的灵活性越大，真实或想象的商标冲突的可能性就越大。但设计一个以智能方式处理这些问题的目录结构的机会是存在的，而DNS约束几乎肯定会使通用和公平的仅DNS解决方案成为不可能。
o If a directory system is used to translate to DNS names, and then DNS names are looked up in the normal fashion, it may be possible to relax several of the constraints that have been traditional (and perhaps necessary) with the DNS. For example, reverse-mapping of addresses to directory names may not be a requirement even if mapping of addresses to DNS names continues to be, since the DNS name(s) would (continue to) uniquely identify the host.
o 如果使用目录系统转换为DNS名称，然后以正常方式查找DNS名称，则可能会放宽DNS的一些传统约束（可能是必要的）。例如，即使地址到DNS名称的映射继续存在，地址到目录名称的反向映射也可能不是必需的，因为DNS名称将（继续）唯一地标识主机。
o Solutions to multilingual transcription problems that are common in "normal life" (e.g., two-sided business cards to be sure that recipients trying to contact a person can access romanized spellings and numbers if the original language is not comprehensible to them) can be easily handled in a directory system by inserting both sets of entries.
o 在“正常生活”中常见的多语言转录问题的解决方案（例如，双面名片，以确保试图联系某人的收件人在无法理解原始语言的情况下可以访问罗马拼法和数字）可以通过插入两组条目在目录系统中轻松处理。
o A directory system could be designed that would return, not a single name, but a set of names paired with network-locational information or other context-establishing attributes. This type of information might be of considerable use in resolving the "nearest (or best) server for a particular named resource"
o 可以设计一个目录系统，返回的不是单个名称，而是一组与网络位置信息或其他上下文建立属性成对的名称。在解析“特定命名资源的最近（或最好）服务器”时，此类信息可能非常有用
problems that are a significant concern for organizations hosting web and other sites that are accessed from a wide range of locations and subnets.
托管从广泛位置和子网访问的网站和其他网站的组织非常关注的问题。
o Names bound to countries and languages might help to manage trademark realities, while, as discussed in section 1.3 above, use of the DNS in trademark-significant contexts tends to require worldwide "flattening" of the trademark system.
o 与国家和语言绑定的名称可能有助于管理商标现实，而如上文第1.3节所述，在商标重要上下文中使用域名系统往往需要在全球范围内“扁平化”商标系统。
Many of these issues are a consequence of another property of the DNS: names must be unique across the Internet. The need to have a system of unique identifiers is fairly obvious (see [RFC2826]). However, if that requirement were to be eliminated in a search or directory system that was visible to users instead of the DNS, many difficult problems -- of both an engineering and a policy nature -- would be likely to vanish.
这些问题中的许多是DNS的另一个属性的结果：名称在Internet上必须是唯一的。需要一个唯一标识符系统是相当明显的（见[RFC2826]）。然而，如果在用户可见的搜索或目录系统（而不是DNS）中消除这一要求，许多工程和政策性质的难题可能会消失。
Almost any internationalization proposal for names that are in, or map into, the DNS will require changing DNS resolver API calls ("gethostbyname" or equivalent), or adding some pre-resolution preparation mechanism, in almost all Internet applications -- whether to cause the API to take a different character set (no matter how it is then mapped into the bits used in the DNS or another system), to accept or return more arguments with qualifying or identifying information, or otherwise. Once applications must be opened to make such changes, it is a relatively small matter to switch from calling into the DNS to calling a directory service and then the DNS (in many situations, both actions could be accomplished in a single API call).
对于DNS中的名称或映射到DNS的名称，几乎所有的国际化建议都需要在几乎所有的Internet应用程序中更改DNS解析程序API调用（“gethostbyname”或等效名称），或添加一些预解析准备机制——是否使API采用不同的字符集（无论它随后如何映射到DNS或其他系统中使用的位），接受或返回更多具有限定或标识信息的参数，或其他。一旦必须打开应用程序进行此类更改，则从调用DNS切换到调用目录服务，然后再调用DNS，这是一件相对较小的事情（在许多情况下，这两个操作都可以在单个API调用中完成）。
A directory approach can be consistent both with "flat" models and multi-attribute ones. The DNS requires strict hierarchies, limiting its ability to differentiate among names by their properties. By contrast, modern directories can utilize independently-searched attributes and other structured schema to provide flexibilities not present in a strictly hierarchical system.
目录方法可以与“平面”模型和多属性模型保持一致。DNS需要严格的层次结构，限制了其根据名称属性区分名称的能力。相比之下，现代目录可以利用独立搜索的属性和其他结构化模式来提供严格分层系统所不具备的灵活性。
There is a strong historical argument for a single directory structure (implying a need for mechanisms for registration, delegation, etc.). But a single structure is not a strict requirement, especially if in-depth case analysis and design work leads to the conclusion that reverse-mapping to directory names is not a requirement (see section 5). If a single structure is not needed, then, unlike the DNS, there would be no requirement for a global organization to authorize or delegate operation of portions of the structure.
对于单一目录结构（意味着需要注册、委派等机制），有一个强有力的历史论据。但单一结构并不是严格的要求，特别是如果深入的案例分析和设计工作得出结论，即不需要反向映射到目录名（参见第5节）。如果不需要单一结构，则与DNS不同，全球组织不需要授权或委派结构部分的操作。
The "no single structure" concept could be taken further by moving away from simple "names" in favor of, e.g., multiattribute, multihierarchical, faceted systems in which most of the facets use restricted vocabularies. (These terms are fairly standard in the information retrieval and classification system literature, see, e.g., [IS5127].) Such systems could be designed to avoid the need for procedures to ensure uniqueness across, or even within, providers and databases of the faceted entities for which the search is to be performed. (See [DNS-Search] for further discussion.)
“没有单一结构”的概念可以进一步从简单的“名称”转移到多属性、多层次、多方面的系统，其中大多数方面使用受限词汇。（这些术语在信息检索和分类系统文献中是相当标准的，参见，例如[IS5127]）此类系统的设计可以避免需要程序来确保要对其执行搜索的分面实体的提供者和数据库之间的唯一性，甚至在其内的唯一性。（有关进一步讨论，请参阅[DNS搜索]。）
While the discussion above includes very general comments about attributes, it appears that only a very small number of attributes would be needed. The list would almost certainly include country and language for internationalization purposes. It might require "charset" if we cannot agree on a character set and encoding, although there are strong arguments for simply using ISO 10646 (also known as Unicode or "UCS" (for Universal Character Set) [UNICODE], [IS10646] coding in interchange. Trademark issues might motivate "commercial" and "non-commercial" (or other) attributes if they would be helpful in bypassing trademark problems. And applications to resource location, such as those contemplated for Uniform Resource Identifiers (URIs) [RFC2396, RFC3305] or the Service Location Protocol [RFC2608], might argue for a few other attributes (as outlined above).
虽然上面的讨论包括关于属性的非常一般性的评论，但似乎只需要非常少的属性。出于国际化的目的，这份清单几乎肯定会包括国家和语言。如果我们不能就字符集和编码达成一致意见，则可能需要“字符集”，尽管在交换中简单地使用ISO10646（也称为Unicode或“UCS”（通用字符集）[Unicode]、[IS10646]编码有很强的理由。商标问题可能会激发“商业”和“非商业”（或其他）的动机属性，如果它们有助于绕过商标问题。和资源位置的应用程序，如统一资源标识符（URI）[RFC2396，RFC3305]或服务位置协议[RFC2608]的预期应用程序，可能需要一些其他属性（如上所述）。
Much of the thinking underlying this document was driven by considerations of internationalizing the DNS or, more specifically, providing access to the functions of the DNS from languages and naming systems that cannot be accurately expressed in the traditional DNS subset of ASCII. Much of the relevant work was done in the IETF's "Internationalized Domain Names" Working Group (IDN-WG), although this document also draws on extensive parallel discussions in other forums. This section contains an evaluation of what was learned as an "internationalized DNS" or "multilingual DNS" was explored and suggests future steps based on that evaluation.
本文件背后的许多想法都是出于DNS国际化的考虑，或者更具体地说，提供从语言和命名系统对DNS功能的访问，这些语言和命名系统不能准确地用传统的ASCII DNS子集表示。IETF的“国际化域名”工作组（IDN-WG）完成了大部分相关工作，尽管本文件还借鉴了其他论坛上广泛的平行讨论。本节包含对“国际化DNS”或“多语言DNS”所学内容的评估，并根据该评估建议未来的步骤。
When the IDN-WG was initiated, it was obvious to several of the participants that its first important task was an undocumented one: to increase the understanding of the complexities of the problem sufficiently that naive solutions could be rejected and people could go to work on the harder problems. The IDN-WG clearly accomplished that task. The beliefs that the problems were simple, and in the corresponding simplistic approaches and their promises of quick and painless deployment, effectively disappeared as the WG's efforts matured.
当IDN-WG启动时，对一些参与者来说，它的第一项重要任务显然是一项未经记录的任务：充分提高对问题复杂性的理解，以拒绝幼稚的解决方案，人们可以着手解决更难的问题。IDN-WG显然完成了这项任务。随着工作组努力的成熟，认为问题很简单的信念以及相应的简单化方法及其快速、无痛部署的承诺实际上消失了。
Some of the lessons learned from increased understanding and the dissipation of naive beliefs should be taken as cautions by the wider community: the problems are not simple. Specifically, extracting small elements for solution rather than looking at whole systems, may result in obscuring the problems but not solving any problem that is worth the trouble.
更广泛的社区应将从增进理解和消除天真信念中吸取的一些教训作为警示：问题并不简单。具体地说，提取小元素来解决问题，而不是查看整个系统，可能会导致模糊问题，但无法解决任何值得费心的问题。
The hostname rules chosen in the mid-70s weren't just "ASCII because English uses ASCII", although that was a starting point. We have discovered that almost every other script (and even ASCII if we permit the rest of the characters specified in the ISO 646 International Reference Version) is more complex than hostname-restricted-ASCII (the "LDH" form, see section 1.1). And ASCII isn't sufficient to completely represent English -- there are several words in the language that are correctly spelled only with characters or diacritical marks that do not appear in ASCII. With a broader selection of scripts, in some examples, case mapping works from one case to the other but is not reversible. In others, there are conventions about alternate ways to represent characters (in the language, not [only] in character coding) that work most of the time, but not always. And there are issues in coding, with Unicode/10646 providing different ways to represent the same character ("character", rather than "glyph", is used deliberately here). And, in still others, there are questions as to whether two glyphs "match", which may be a distance-function question, not one with a binary answer. The IETF approach to these problems is to require pre-matching canonicalization (see the "stringprep" discussion below).
70年代中期选择的主机名规则不仅仅是“ASCII，因为英语使用ASCII”，尽管这是一个起点。我们发现，几乎所有其他脚本（即使允许ISO 646国际参考版本中指定的其余字符，也包括ASCII）都比主机名受限ASCII（LDH格式，见第1.1节）更复杂。ASCII还不足以完全代表英语——该语言中有几个单词的拼写是正确的，只有字符或变音符号没有出现在ASCII中。对于更广泛的脚本选择，在某些示例中，案例映射可以从一个案例映射到另一个案例，但不可逆。在另一些情况下，关于表示字符的替代方法（在语言中，而不仅仅是在字符编码中）有一些约定，这些约定大部分时间都有效，但并不总是有效。在编码方面也存在一些问题，Unicode/10646提供了不同的方式来表示相同的字符（这里故意使用字符而不是“字形”）。还有一些问题是关于两个字形是否“匹配”，这可能是一个距离函数问题，而不是一个具有二进制答案的问题。IETF解决这些问题的方法是要求预匹配规范化（参见下面的“stringprep”讨论）。
The IETF has resisted the temptations to either try to specify an entirely new coded character set, or to pick and choose Unicode/10646 characters on a per-character basis rather than by using well-defined blocks. While it may appear that a character set designed to meet Internet-specific needs would be very attractive, the IETF has never had the expertise, resources, and representation from critically-important communities to actually take on that job. Perhaps more important, a new effort might have chosen to make some of the many complex tradeoffs differently than the Unicode committee did, producing a code with somewhat different characteristics. But there is no evidence that doing so would produce a code with fewer problems and side-effects. It is much more likely that making tradeoffs differently would simply result in a different set of problems, which would be equally or more difficult.
IETF抵制了尝试指定一个全新的编码字符集，或者在每个字符的基础上挑选Unicode/10646字符，而不是使用定义良好的块的诱惑。虽然看起来，一个旨在满足互联网特定需求的角色集非常有吸引力，但IETF从未拥有来自至关重要的社区的专业知识、资源和代表来实际承担这项工作。也许更重要的是，一项新的努力可能会选择以不同于Unicode委员会的方式进行一些复杂的权衡，从而产生具有某种不同特征的代码。但没有证据表明这样做会产生问题和副作用更少的代码。更可能的情况是，做出不同的权衡只会导致不同的问题集，这同样或更困难。
While the DNS can handle arbitrary binary strings without known internal problems (see [RFC2181]), some restrictions are imposed by the requirement that text be interpreted in a case-independent way ([RFC1034], [RFC1035]). More important, most internet applications assume the hostname-restricted "LDH" syntax that is specified in the host table RFCs and as "prudent" in RFC 1035. If those assumptions are not met, many conforming implementations of those applications may exhibit behavior that would surprise implementors and users. To avoid these potential problems, IETF internationalization work has focused on "ASCII-Compatible Encodings" (ACE). These encodings preserve the LDH conventions in the DNS itself. Implementations of applications that have not been upgraded utilize the encoded forms, while newer ones can be written to recognize the special codings and map them into non-ASCII characters. These approaches are, however, not problem-free even if human interface issues are ignored. Among other issues, they rely on what is ultimately a heuristic to determine whether a DNS label is to be considered as an internationalized name (i.e., encoded Unicode) or interpreted as an actual LDH name in its own right. And, while all determinations of whether a particular query matches a stored object are traditionally made by DNS servers, the ACE systems, when combined with the complexities of international scripts and names, require that much of the matching work be separated into a separate, client-side, canonicalization or "preparation" process before the DNS matching mechanisms are invoked [STRINGPREP].
虽然DNS可以处理任意二进制字符串，而不存在已知的内部问题（请参见[RFC2181]），但文本必须以独立于大小写的方式进行解释（[RFC1034]、[RFC1035]）的要求施加了一些限制。更重要的是，大多数internet应用程序采用主机名受限的“LDH”语法，该语法在主机表RFCs中指定，在RFC1035中指定为“审慎”。如果不满足这些假设，这些应用程序的许多一致性实现可能会表现出令实现者和用户吃惊的行为。为了避免这些潜在问题，IETF国际化工作的重点是“ASCII兼容编码”（ACE）。这些编码在DNS本身中保留LDH约定。未升级的应用程序的实现使用编码形式，而较新的应用程序可以编写以识别特殊编码并将其映射为非ASCII字符。然而，即使忽略了人机界面问题，这些方法也不是没有问题的。在其他问题中，它们依赖于最终的启发式方法来确定DNS标签是被视为国际化名称（即编码的Unicode）还是被解释为实际的LDH名称。而且，尽管传统上DNS服务器会对特定查询是否与存储对象匹配进行所有确定，但ACE系统在与复杂的国际脚本和名称相结合时，要求将大部分匹配工作分为单独的客户端规范化或“准备”在调用DNS匹配机制之前处理[STRINGPREP]。
As outlined above, the model for avoiding problems associated with putting non-ASCII names in the DNS and elsewhere evolved into the principle that strings are to be placed into the DNS only after being passed through a string preparation function that eliminates or rejects spurious character codes, maps some characters onto others, performs some sequence canonicalization, and generally creates forms that can be accurately compared. The impact of this process on hostname-restricted ASCII (i.e., "LDH") strings is trivial and essentially adds only overhead. For other scripts, the impact is, of necessity, quite significant.
如上所述，用于避免将非ASCII名称放入DNS和其他地方的相关问题的模型演变为以下原则：字符串只有在通过字符串准备功能后才能放入DNS，该功能消除或拒绝伪字符代码，将一些字符映射到其他字符，执行一些序列规范化，通常创建可以精确比较的表单。此过程对主机名受限ASCII（即“LDH”）字符串的影响很小，本质上只会增加开销。对于其他脚本来说，影响必然是相当大的。
Although the general notion underlying stringprep is simple, the many details are quite subtle and the associated tradeoffs are complex. A design team worked on it for months, with considerable effort placed into clarifying and fine-tuning the protocol and tables. Despite general agreement that the IETF would avoid getting into the business of defining character sets, character codings, and the associated conventions, the group several times considered and rejected special
尽管stringprep的基本概念很简单，但许多细节都相当微妙，相关的权衡也很复杂。一个设计团队为此工作了数月，花了大量精力澄清和微调协议和表格。尽管普遍认为IETF将避免介入定义字符集、字符编码和相关约定的业务，但该组织多次考虑并拒绝了特殊要求
treatment of code positions to more nearly match the distinctions made by Unicode with user perceptions about similarities and differences between characters. But there were intense temptations (and pressures) to incorporate language-specific or country-specific rules. Those temptations, even when resisted, were indicative of parts of the ongoing controversy or of the basic unsuitability of the DNS for fully internationalized names that are visible, comprehensible, and predictable for end users.
处理代码位置，使其更接近于Unicode与用户对字符之间的相似性和差异的感知相匹配。但有强烈的诱惑（和压力）来纳入特定语言或特定国家的规则。这些诱惑，即使遭到抵制，也表明了正在进行的争论的一部分，或者DNS对于最终用户可见、可理解和可预测的完全国际化名称基本上是不合适的。
There have also been controversies about how far one should go in these processes of preparation and transformation and, ultimately, about the validity of various analogies. For example, each of the following operations has been claimed to be similar to case-mapping in ASCII:
关于在这些准备和转化过程中应该走多远，以及最终关于各种类比的有效性，也存在争议。例如，以下每个操作都声称类似于ASCII中的大小写映射：
o stripping of vowels in Arabic or Hebrew
o 阿拉伯语或希伯来语中元音的剥离
o matching of "look-alike" characters such as upper-case Alpha in Greek and upper-case A in Roman-based alphabets
o 匹配“相似”字符，如希腊字母大写字母和罗马字母大写A
o matching of Traditional and Simplified Chinese characters that represent the same words,
o 匹配表示相同单词的繁体字和简体字，
o matching of Serbo-Croatian words whether written in Roman-derived or Cyrillic characters
o 塞尔维亚-克罗地亚语单词的匹配，无论是用罗马衍生字符还是西里尔字母书写
A decision to support any of these operations would have implications for other scripts or languages and would increase the overall complexity of the process. For example, unless language-specific information is somehow available, performing matching between Traditional and Simplified Chinese has impacts on Japanese and Korean uses of the same "traditional" characters (e.g., it would not be appropriate to map Kanji into Simplified Chinese).
支持这些操作的决定将对其他脚本或语言产生影响，并将增加整个过程的复杂性。例如，除非以某种方式获得特定于语言的信息，否则在繁体中文和简体中文之间进行匹配会影响日语和韩语对相同“繁体”字符的使用（例如，将汉字映射为简体中文是不合适的）。
Even were the IDN-WG's other work to have been abandoned completely or if it were to fail in the marketplace, the stringprep and nameprep work will continue to be extremely useful, both in identifying issues and problem code points and in providing a reasonable set of basic rules. Where problems remain, they are arguably not with nameprep, but with the DNS-imposed requirement that its results, as with all other parts of the matching and comparison process, yield a binary "match or no match" answer, rather than, e.g., a value on a similarity scale that can be evaluated by the user or by user-driven heuristic functions.
即使IDN-WG的其他工作被完全放弃，或者在市场上失败，stringprep和nameprep工作仍将非常有用，无论是在确定问题和问题代码点，还是在提供一套合理的基本规则方面。问题仍然存在的地方，可以说不是nameprep的问题，而是DNS强加的要求，即其结果与匹配和比较过程的所有其他部分一样，产生二进制“匹配或不匹配”答案，而不是可以由用户或由用户驱动的启发式函数评估的相似性尺度上的值。
ISO 10646 basically defines only code points, and not rules for using or comparing the characters. This is part of a long-standing tradition with the work of what is now ISO/IEC JTC1/SC2: they have performed code point assignments and have typically treated the ways in which characters are used as beyond their scope. Consequently, they have not dealt effectively with the broader range of internationalization issues. By contrast, the Unicode Technical Committee (UTC) has defined, in annexes and technical reports (see, e.g., [UTR15]), some additional rules for canonicalization and comparison. Many of those rules and conventions have been factored into the "stringprep" and "nameprep" work, but it is not straightforward to make or define them in a fashion that is sufficiently precise and permanent to be relied on by the DNS.
ISO10646基本上只定义代码点，而不是使用或比较字符的规则。这是ISO/IEC JTC1/SC2工作的一个长期传统的一部分：他们执行代码点分配，通常将字符的使用方式视为超出其范围。因此，它们没有有效地处理更广泛的国际化问题。相比之下，Unicode技术委员会（UTC）在附件和技术报告（参见[UTR15]）中定义了一些规范化和比较的附加规则。这些规则和约定中的许多已被纳入“stringprep”和“nameprep”工作中，但以DNS所依赖的足够精确和永久的方式来制定或定义它们并不容易。
Perhaps more important, the discussions leading to nameprep also identified several areas in which the UTC definitions are inadequate, at least without additional information, to make matching precise and unambiguous. In some of these cases, the Unicode Standard permits several alternate approaches, none of which are an exact and obvious match to DNS needs. That has left these sensitive choices up to IETF, which lacks sufficient in-depth expertise, much less any mechanism for deciding to optimize one language at the expense of another.
也许更重要的是，导致nameprep的讨论还确定了UTC定义不充分的几个领域，至少在没有额外信息的情况下，无法使匹配准确无误。在某些情况下，Unicode标准允许几种替代方法，但没有一种方法与DNS需求完全匹配。这就让IETF做出了这些敏感的选择，IETF缺乏足够深入的专业知识，更不用说任何以牺牲另一种语言为代价优化一种语言的机制了。
For example, it is tempting to define some rules on the basis of membership in particular scripts, or for punctuation characters, but there is no precise definition of what characters belong to which script or which ones are, or are not, punctuation. The existence of these areas of vagueness raises two issues: whether trying to do precise matching at the character set level is actually possible (addressed below) and whether driving toward more precision could create issues that cause instability in the implementation and resolution models for the DNS.
例如，很容易根据特定脚本的成员资格或标点符号来定义某些规则，但对于哪些字符属于哪个脚本、哪些字符是标点符号或哪些字符不是标点符号，却没有精确的定义。这些模糊区域的存在引发了两个问题：是否尝试在字符集级别进行精确匹配实际上是可能的（如下所述），以及向更精确的方向发展是否会导致DNS的实现和解析模型不稳定的问题。
The Unicode definition also evolves. Version 3.2 appeared shortly after work on this document was initiated. It added some characters and functionality and included a few minor incompatible code point changes. IETF has secured an agreement about constraints on future changes, but it remains to be seen how that agreement will work out in practice. The prognosis actually appears poor at this stage, since UTC chose to ballot a recent possible change which should have been prohibited by the agreement (the outcome of the ballot is not relevant, only that the ballot was issued rather than having the result be a foregone conclusion). However, some members of the community consider some of the changes between Unicode 3.0 and 3.1 and between 3.1 and 3.2, as well as this recent ballot, to be
Unicode定义也在发展。3.2版在本文件工作启动后不久出现。它添加了一些字符和功能，并包括一些不兼容的代码点小改动。IETF已就未来变化的限制达成协议，但该协议在实践中的效果仍有待观察。在这一阶段，预测结果实际上似乎很差，因为UTC选择了投票表决协议本应禁止的最近可能发生的变化（投票结果不相关，只是投票结果已发布，而不是结果已成定局）。然而，一些社区成员考虑Unicode 3和3.1之间的一些变化，以及3.1到3.2之间的变化，以及最近的投票。
evidence of instability and that these instabilities are better handled in a system that can be more flexible about handling of characters, scripts, and ancillary information than the DNS.
不稳定的证据，以及这些不稳定在比DNS更灵活地处理字符、脚本和辅助信息的系统中得到更好的处理。
In addition, because the systems implications of internationalization are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of those issues to its SC22/WG20 (the Internationalization working group within the subcommittee that deals with programming languages, systems, and environments). WG20 has historically dealt with internationalization issues thoughtfully and in depth, but its status has several times been in doubt in recent years. However, assignment of these matters to WG20 increases the risk of eventual ISO internationalization standards that specify different behavior than the UTC specifications.
此外，由于国际化的系统影响被认为超出了SC2的范围，ISO/IEC JTC1将其中一些问题分配给了其SC22/WG20（小组委员会中负责处理编程语言、系统和环境的国际化工作组）。20国工作组历来以深思熟虑和深入的方式处理国际化问题，但近年来其地位多次受到质疑。但是，将这些事项分配给WG20会增加最终ISO国际化标准的风险，这些标准规定了与UTC规范不同的行为。
Part of what has "caused" the DNS internationalization problem, as well as the DNS trademark problem and several others, is that we have stopped thinking about "identifiers for objects" -- which normal people are not expected to see -- and started thinking about "names" -- strings that are expected not only to be readable, but to have linguistically-sensible and culturally-dependent meaning to non-specialist users.
“导致”DNS国际化问题以及DNS商标问题和其他几个问题的部分原因是，我们已经不再考虑“对象标识符”——普通人不希望看到的——并开始考虑“名称”——不仅希望可读的字符串，但对于非专业用户来说，这意味着语言上的合理和文化上的依赖。
Within the IETF, the IDN-WG, and sometimes other groups, avoided addressing the implications of that transition by taking "outside our scope -- someone else's problem" approaches or by suggesting that people will just become accustomed to whatever conventions are adopted. The realities of user and vendor behavior suggest that these approaches will not serve the Internet community well in the long term:
在IETF中，IDN-WG，有时还有其他团体，通过采取“超出我们的范围——其他人的问题”的方法，或建议人们习惯于采用任何公约，来避免解决这种过渡的影响。用户和供应商行为的现实表明，从长远来看，这些方法不会很好地服务于互联网社区：
o If we want to make it a problem in a different part of the user interface structure, we need to figure out where it goes in order to have proof of concept of our solution. Unlike vendors whose sole [business] model is the selling or registering of names, the IETF must produce solutions that actually work, in the applications context as seen by the end user.
o 如果我们想让它成为用户界面结构不同部分的一个问题，我们需要弄清楚它的去向，以便对我们的解决方案进行概念验证。与唯一[业务]模式是销售或注册名称的供应商不同，IETF必须在最终用户看到的应用程序上下文中产生实际工作的解决方案。
o The principle that "they will get used to our conventions and adapt" is fine if we are writing rules for programming languages or an API. But the conventions under discussion are not part of a semi-mathematical system, they are deeply ingrained in culture. No matter how often an English-speaking American is told that the Internet requires that the correct spelling of "colour" be used, he or she isn't going to be convinced. Getting a French-speaker in Lyon to use exactly the same lexical conventions as a French-
o 如果我们正在为编程语言或API编写规则，那么“他们将习惯于我们的约定并进行调整”的原则是可以接受的。但讨论中的惯例并不是半数学体系的一部分，它们在文化中根深蒂固。无论一个说英语的美国人被告知互联网要求使用“color”的正确拼写，他或她都不会被说服。让里昂的法语使用者使用与法语完全相同的词汇惯例-
speaker in Quebec in order to accommodate the decisions of the IETF or of a registrar or registry is just not likely. "Montreal" is either a misspelling or an anglicization of a similar word with an acute accent mark over the "e" (i.e., using the Unicode character U+00E9 or one of its equivalents). But global agreement on a rule that will determine whether the two forms should match -- and that won't astonish end users and speakers of one language or the other -- is as unlikely as agreement on whether "misspelling" or "anglicization" is the greater travesty.
魁北克省的发言人为了适应IETF或注册处或注册处的决定是不可能的。“Montreal”是一个类似单词的拼写错误或英语化，在“e”上有一个尖锐的重音符号（即使用Unicode字符U+00E9或其等价物之一）。但是，就一项规则达成全球一致将决定这两种形式是否匹配——这不会让最终用户和使用一种或另一种语言的人感到惊讶——就“拼写错误”或“英语化”是否是更大的讽刺达成一致也是不可能的。
More generally, it is not clear that the outcome of any conceivable nameprep-like process is going to be good enough for practical, user-level, use. In the use of human languages by humans, there are many cases in which things that do not match are nonetheless interpreted as matching. The Norwegian/Danish character that appears in U+00F8 (visually, a lower case 'o' overstruck with a forward slash) and the "o-umlaut" German character that appears in U+00F6 (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly different and no matching program should yield an "equal" comparison. But they are more similar to each other than either of them is to, e.g., "e". Humans are able to mentally make the correction in context, and do so easily, and they can be surprised if computers cannot do so. Worse, there is a Swedish character whose appearance is identical to the German o-umlaut, and which shares code point U+00F6, but that, if the languages are known and the sounds of the letters or meanings of words including the character are considered, actually should match the Norwegian/Danish use of U+00F8.
更一般地说，尚不清楚任何可想象的类似nameprep的过程的结果是否足以用于实际的用户级应用。在人类使用人类语言的过程中，有许多情况下，不匹配的东西仍然被解释为匹配。U+00F8中出现的挪威/丹麦字符（视觉上，小写字母“o”加上正斜杠）和U+00F6中出现的“o-umlaut”德语字符（视觉上，小写字母“o”加上分音符（或umlaut））明显不同，任何匹配程序都不应产生“相等”的比较。但它们之间的相似性比它们中的任何一个都要大，例如“e”。人类能够在心理上根据上下文进行纠正，而且很容易做到，如果计算机不能做到这一点，他们会感到惊讶。更糟糕的是，有一个瑞典字符，其外观与德语o-umlaut相同，代码点为U+00F6，但如果已知语言，并且考虑了字母的发音或单词（包括该字符）的含义，实际上应该与挪威/丹麦使用的U+00F8相匹配。
This text uses examples in Roman scripts because it is being written in English and those examples are relatively easy to render. But one of the important lessons of the discussions about domain name internationalization in recent years is that problems similar to those described above exist in almost every language and script. Each one has its idiosyncrasies, and each set of idiosyncracies is tied to common usage and cultural issues that are very familiar in the relevant group, and often deeply held as cultural values. As long as a schoolchild in the US can get a bad grade on a spelling test for using a perfectly valid British spelling, or one in France or Germany can get a poor grade for leaving off a diacritical mark, there are issues with the relevant language. Similarly, if children in Egypt or Israel are taught that it is acceptable to write a word with or without vowels or stress marks, but that, if those marks are included, they must be the correct ones, or a user in Korea is potentially offended or astonished by out-of-order sequences of Jamo, systems based on character-at-a-time processing and simplistic matching, with no contextual information, are not going to satisfy user needs.
本文使用罗马脚本中的示例，因为它是用英语编写的，并且这些示例相对容易呈现。但近年来关于域名国际化讨论的一个重要教训是，几乎每种语言和脚本都存在类似上述问题。每个人都有自己的特质，而每一组特质都与相关群体中非常熟悉的常见用法和文化问题联系在一起，通常被视为文化价值观。只要美国的学童在拼写测试中使用完全有效的英国拼写而得不到好成绩，或者法国或德国的学童在拼写测试中漏掉发音符号而得不到好成绩，那么相关语言就存在问题。类似地，如果埃及或以色列的儿童被教导可以书写带有或不带有元音或重音符号的单词，但如果包含这些符号，则这些符号必须是正确的，否则韩国的用户可能会对Jamo的无序顺序感到冒犯或惊讶，基于一次字符处理和简单匹配的系统，没有上下文信息，无法满足用户需求。
Users are demanding solutions that deal with language and culture. Systems of identifier symbol-strings that serve specialists or computers are, at best, a solution to a rather different (and, at the time this document was written, somewhat ill-defined), problem. The recent efforts have made it ever more clear that, if we ignore the distinction between the user requirements and narrowly-defined identifiers, we are solving an insufficient problem. And, conversely, the approaches that have been proposed to approximate solutions to the user requirement may be far more complex than simple identifiers require.
用户要求解决语言和文化问题。为专家或计算机服务的标识符符号字符串系统充其量只能解决一个完全不同的问题（在编写本文档时，定义有些不明确）。最近的努力更加清楚地表明，如果我们忽视用户需求和狭义标识符之间的区别，我们就解决了一个不足的问题。并且，相反地，已经提出的用于近似用户需求的解决方案的方法可能比简单标识符所要求的复杂得多。
Over the last few centuries, local conventions have been established in various parts of the world for dealing with multilingual situations. It may be helpful to examine some of these. For example, if one visits a country where the language is different from ones own, business cards are often printed on two sides, one side in each language. The conventions are not completely consistent and the technique assumes that recipients will be tolerant. Translations of names or places are attempted in some situations and transliterations in others. Since it is widely understood that exact translations or transliterations are often not possible, people typically smile at errors, appreciate the effort, and move on.
在过去几个世纪里，世界各地都建立了处理多种语言情况的地方公约。检查其中一些可能会有所帮助。例如，如果一个人访问一个语言不同于他自己的国家，名片通常印在两面，每种语言印在一面。这些约定并不完全一致，该技术假设接收者会容忍。在某些情况下会尝试翻译姓名或地名，而在另一些情况下会尝试进行音译。由于人们普遍认为，准确的翻译或音译通常是不可能的，人们通常会对错误微笑，欣赏所做的努力，然后继续前进。
The DNS situation differs from these practices in at least two ways. Since a global solution is required, the business card would need a number of sides approximating the number of languages in the world, which is probably impossible without violating laws of physics. More important, the opportunities for tolerance don't exist: the DNS requires a exact match or the lookup fails.
DNS情况与这些实践至少在两个方面不同。由于需要一个全球性的解决方案，名片将需要多个接近世界语言数量的侧面，如果不违反物理定律，这可能是不可能的。更重要的是，不存在容忍的机会：DNS需要精确匹配，否则查找失败。
Part of the argument for ACE-based solutions is that they provide an escape for multilingual environments when applications have not been upgraded. When an older application encounters an ACE-based name, the assumption is that the (admittedly ugly) ASCII-coded string will be displayed and can be typed in. This argument is reasonable from the standpoint of mixtures of Roman-based alphabets, but may not be relevant if user-level systems and devices are involved that do not support the entry of Roman-based characters or which cannot conveniently render such characters. Such systems are few in the world today, but the number can reasonably be expected to rise as the Internet is increasingly used by populations whose primary concern is with local issues, local information, and local languages. It is,
基于ACE的解决方案的部分理由是，当应用程序尚未升级时，它们为多语言环境提供了一种逃避。当较旧的应用程序遇到基于ACE的名称时，假设将显示（公认难看的）ASCII编码字符串，并且可以键入该字符串。从混合使用罗马字母的角度来看，这一论点是合理的，但如果涉及的用户级系统和设备不支持输入罗马字符或无法方便地呈现此类字符，则可能不相关。这样的系统在当今世界上为数不多，但随着互联网越来越多地被主要关注当地问题、当地信息和当地语言的人群所使用，这个数字可以合理地预期会上升。它是，
for example, fairly easy to imagine populations who use Arabic or Thai scripts and who do not have routine access to scripts or input devices based on Roman-derived alphabets.
例如，很容易想象使用阿拉伯语或泰语脚本的人群，他们无法常规访问基于罗马字母表的脚本或输入设备。
It appears, from the cases above and others, that none of the intra-DNS-based solutions for "multilingual names" are workable. They rest on too many assumptions that do not appear to be feasible -- that people will adapt deeply-entrenched language habits to conventions laid down to make the lives of computers easy; that we can make "freeze it now, no need for changes in these areas" decisions about Unicode and nameprep; that ACE will smooth over applications problems, even in environments without the ability to key or render Roman-based glyphs (or where user experience is such that such glyphs cannot easily be distinguished from each other); that the Unicode Consortium will never decide to repair an error in a way that creates a risk of DNS incompatibility; that we can either deploy EDNS [RFC2671] or that long names are not really important; that Japanese and Chinese computer users (and others) will either give up their local or IS 2022-based character coding solutions (for which addition of a large fraction of a million new code points to Unicode is almost certainly a necessary, but probably not sufficient, condition) or build leakproof and completely accurate boundary conversion mechanisms; that out of band or contextual information will always be sufficient for the "map glyph onto script" problem; and so on. In each case, it is likely that about 80% or 90% of cases will work satisfactorily, but it is unlikely that such partial solutions will be good enough. For example, suppose someone can spell her name 90% correctly, or a company name is matched correctly 80% of the time but the other 20% of attempts identify a competitor: are either likely to be considered adequate?
从上述案例和其他案例来看，似乎没有一种基于DNS内部的“多语言名称”解决方案是可行的。它们建立在太多似乎不可行的假设之上——人们将使根深蒂固的语言习惯适应为使计算机的生活变得简单而制定的惯例；我们可以就Unicode和nameprep做出“现在就冻结它，不需要在这些领域进行更改”的决定；ACE将解决应用程序的问题，即使在没有键控或渲染基于罗马符号的环境中（或者在用户体验导致此类符号无法轻易彼此区分的情况下）；Unicode联盟决不会决定以造成DNS不兼容风险的方式修复错误；我们可以部署EDN[RFC2671]，或者长名称并不重要；日本和中国的计算机用户（以及其他人）要么放弃本地或基于IS 2022的字符编码解决方案（为此，在Unicode中添加一百万个新代码点中的很大一部分几乎肯定是必要的，但可能不是充分的条件）或建立防漏和完全精确的边界转换机制；带外或上下文信息始终足以解决“将字形映射到脚本”问题；等等在每种情况下，大约80%或90%的案例都能令人满意地工作，但这种局部解决方案不太可能足够好。例如，假设某个人的名字拼写正确率为90%，或者某个公司的名字在80%的时间内匹配正确，但在其他20%的尝试中，识别出了竞争对手：这两种情况是否都被认为是足够的？
For many years, a common response to requirements to locate people or resources on the Internet has been to invoke the term "directory". While an in-depth analysis of the reasons would require a separate document, the history of failure of these invocations has given "directory" efforts a bad reputation. The effort proposed here is different from those predecessors for several reasons, perhaps the most important of which is that it focuses on a fairly-well-understood set of problems and needs, rather than on finding uses for a particular technology.
多年来，对于在互联网上查找人员或资源的要求，一种常见的回应是使用术语“目录”。虽然深入分析原因需要单独的文档，但这些调用失败的历史给“目录”工作带来了坏名声。这里提出的努力不同于以前的努力，原因有几个，也许最重要的是，它侧重于一组相当好理解的问题和需求，而不是寻找特定技术的用途。
As suggested in some of the text above, it is an open question as to whether the needs of the community would be best served by a single (even if functionally, and perhaps administratively, distributed)
正如上文某些文本所建议的，一个单一的（即使是功能上的，也许是行政上的）分配方案是否能最好地满足社区的需求，这是一个悬而未决的问题
directory with universal applicability, a single directory that supports locally-tailored search (and, most important, matching) functions, or multiple, locally-determined, directories. Each has its attractions. Any but the first would essentially prevent reverse-mapping (determination of the user-visible name of the host or resource from target information such as an address or DNS name). But reverse mapping has become less useful over the years --at least to users -- as more and more names have been associated with many host addresses and as CIDR [CIDR] has proven problematic for mapping smaller address blocks to meaningful names.
具有通用性的目录，支持本地定制搜索（最重要的是匹配）功能的单个目录，或本地确定的多个目录。每一个都有它的吸引力。除第一个之外的任何一个都将基本上防止反向映射（从目标信息（如地址或DNS名称）确定主机或资源的用户可见名称）。但随着越来越多的名称与许多主机地址相关联，而且CIDR[CIDR]在将较小的地址块映射为有意义的名称时被证明是有问题的，多年来，反向映射已经变得不那么有用了，至少对用户来说是如此。
Locally-tailored searches and mappings would permit national variations on interpretation of which strings matched which other ones, an arrangement that is especially important when different localities apply different rules to, e.g., matching of characters with and without diacriticals. But, of course, this implies that a URL may evaluate properly or not depending on either settings on a client machine or the network connectivity of the user. That is not, in general, a desirable situation, since it implies that users could not, in the general case, share URLs (or other host references) and that a particular user might not be able to carry references from one host or location to another.
本地定制的搜索和映射将允许各国在解释哪些字符串与哪些其他字符串匹配时有所不同，这一安排在不同的地方应用不同的规则时尤其重要，例如，匹配带或不带变音符号的字符。但是，当然，这意味着URL的计算可能正确，也可能不正确，这取决于客户端计算机上的设置或用户的网络连接。一般来说，这不是一种理想的情况，因为它意味着用户在一般情况下不能共享URL（或其他主机引用），并且特定用户可能无法将引用从一个主机或位置传递到另一个主机或位置。
And, of course, completely separate directories would permit translation and transliteration functions to be embedded in the directory, giving much of the Internet a different appearance depending on which directory was chosen. The attractions of this are obvious, but, unless things were very carefully designed to preserve uniqueness and precise identities at the right points (which may or may not be possible), such a system would have many of the difficulties associated with multiple DNS roots.
当然，完全独立的目录将允许在目录中嵌入翻译和音译功能，根据所选目录的不同，互联网的外观也会有所不同。这样做的吸引力是显而易见的，但是，除非事情经过非常仔细的设计，在正确的点上保持唯一性和精确的身份（这可能是可能的，也可能是不可能的），否则这样一个系统将面临与多个DNS根相关的许多困难。
Finally, a system of separate directories and databases, if coupled with removal of the DNS-imposed requirement for unique names, would largely eliminate the need for a single worldwide authority to manage the top of the naming hierarchy.
最后，一个由单独的目录和数据库组成的系统，如果再加上取消DNS对唯一名称的强制要求，将在很大程度上消除单一全球机构管理命名层次结构顶部的需要。
The set of proposals implied by this document suggests an interesting set of security issues (i.e., nothing important is ever easy). A directory system used for locating network resources would presumably need to be as carefully protected against unauthorized changes as the DNS itself. There also might be new opportunities for problems in an arrangement involving two or more (sub)layers, especially if such a system were designed without central authority or uniqueness of names. It is uncertain how much greater those risks would be as compared to a DNS lookup sequence that involved looking up one name,
本文档所暗示的一组建议提出了一组有趣的安全问题（即，没有什么重要的事情是容易的）。用于定位网络资源的目录系统可能需要像DNS本身一样小心地防止未经授权的更改。在涉及两个或两个以上（子）层的安排中也可能出现新的问题，特别是如果这样一个系统的设计没有中央权威或名称的唯一性。与涉及查找一个名称的DNS查找序列相比，不确定这些风险会有多大，
getting back information, and then doing additional lookups potentially in different subtrees. That multistage lookup will often be the case with, e.g., NAPTR records [RFC 2915] unless additional restrictions are imposed. But additional steps, systems, and databases almost certainly involve some additional risks of compromise.
获取信息，然后在不同的子树中进行额外的查找。这种多级查找通常适用于NAPTR记录[RFC 2915]，除非施加额外的限制。但额外的步骤、系统和数据库几乎肯定会带来一些额外的风险。
None
没有一个
[Albitz] Any of the editions of Albitz, P. and C. Liu, DNS and BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001.
[Albitz]Albitz，P.和C.Liu，DNS和BIND，O'Reilly and Associates，1992、1997、1998和2001的任何版本。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), X3.4, 1968, "USA Code for Information Interchange". ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. Some time after ASCII was first formulated as a standard, ISO adopted international standard 646, which uses ASCII as a base. IS 646 actually contained two code tables: an "International Reference Version" (often referenced as ISO 646-IRV) which was essentially identical to the ASCII of the time, and a "Basic Version" (ISO 646-BV), which designates a number of character positions for national use.
[ASCII]美国国家标准协会（前身为美国标准协会），X3.42068，“美国信息交换代码”。ANSI X3.4-1968已被稍作修改的较新版本所取代，但1968年版本仍然是互联网的最终版本。在ASCII首次制定为标准后的一段时间，ISO采用了国际标准646，该标准以ASCII为基础。IS 646实际上包含两个代码表：一个“国际参考版本”（通常被称为ISO 646-IRV），基本上与当时的ASCII相同；另一个“基本版本”（ISO 646-BV），为国家使用指定许多字符位置。
[CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[CIDR]Fuller，V.，Li，T.，Yu，J.和K.Varadhan，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-ADDR.ARPA delegation", RFC 2317, March 1998.
Eidens，H.，de Groot，G.和P.Vixie，“无类别地址ARPA代表团”，RFC 2317，1998年3月。
[COM-SIZE] Size information supplied by Verisign Global Registry Services (the zone administrator, or "registry operator", for COM, see [REGISTRAR], below) to ICANN, third quarter 2002.
[COM-SIZE]Verisign全球注册服务公司（区域管理员或“注册运营商”）向ICANN提供的[COM-SIZE]大小信息，2002年第三季度。
[DNS-Search] Klensin, J., "A Search-based access model for the DNS", Work in Progress.
[DNS搜索]Klensin，J.，“基于搜索的DNS访问模型”，正在进行中。
[FINGER] Zimmerman, D., "The Finger User Information Protocol", RFC 1288, December 1991.
[FINGER]Zimmerman，D.，“FINGER用户信息协议”，RFC 12881991年12月。
Harrenstien, K., "NAME/FINGER Protocol", RFC 742, December 1977.
哈伦斯汀，K.，“姓名/手指协议”，RFC 742，1977年12月。
[IAB-OPES] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[IAB-OPES]Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB架构和政策考虑”，RFC 3238，2002年1月。
[IQUERY] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002.
[IQUERY]劳伦斯，D.，“淘汰IQUERY”，RFC 34252002年11月。
[IS646] ISO/IEC 646:1991 Information technology -- ISO 7-bit coded character set for information interchange
[IS646]ISO/IEC 646:1991信息技术信息交换用ISO 7位编码字符集
[IS10646] ISO/IEC 10646-1:2000 Information technology --
Universal Multiple-Octet Coded Character Set (UCS) --
Part 1: Architecture and Basic Multilingual Plane and
ISO/IEC 10646-2:2001 Information technology --
Universal Multiple-Octet Coded Character Set (UCS) --
Part 2: Supplementary Planes
[IS10646] ISO/IEC 10646-1:2000 Information technology --
Universal Multiple-Octet Coded Character Set (UCS) --
Part 1: Architecture and Basic Multilingual Plane and
ISO/IEC 10646-2:2001 Information technology --
Universal Multiple-Octet Coded Character Set (UCS) --
Part 2: Supplementary Planes
[MINC] The Multilingual Internet Names Consortium, http://www.minc.org/ has been an early advocate for the importance of expansion of DNS names to accommodate non-ASCII characters. Some of their specific proposals, while helping people to understand the problems better, were not compatible with the design of the DNS.
[MINC]多语言互联网名称联盟，http://www.minc.org/ 早期一直主张扩展DNS名称以容纳非ASCII字符的重要性。他们的一些具体建议虽然有助于人们更好地理解问题，但与DNS的设计不兼容。
[NAPTR] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[NAPTR]Mealling，M.和R.Daniel，“命名机构指针（NAPTR）DNS资源记录”，RFC 2915，2000年9月。
Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
Mealling，M，“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
Mealling，M.，“动态委托发现系统（DDDS）第二部分：算法”，RFC3402，2002年10月。
Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[REGISTRAR] In an early stage of the process that created the Internet Corporation for Assigned Names and Numbers (ICANN), a "Green Paper" was released by the US Government. That paper introduced new terminology and some concepts not needed by traditional DNS operations. The term "registry" was applied to the actual operator and database holder of a domain (typically at the top level, since the Green Paper was little concerned with anything else), while organizations that marketed names and made them available to "registrants" were known as "registrars". In the classic DNS model, the function of "zone administrator" encompassed both registry and registrar roles, although that model did not anticipate a commercial market in names.
[注册官]在创建互联网名称和号码分配公司（ICANN）的早期阶段，美国政府发布了一份“绿皮书”。该论文介绍了传统DNS操作不需要的新术语和一些概念。“注册”一词适用于域名的实际运营商和数据库持有人（通常是顶级的，因为绿皮书与其他事项无关），而销售名称并向“注册人”提供名称的组织被称为“注册人”。在经典的DNS模型中，“区域管理员”的功能包括注册和注册两个角色，尽管该模型并未预测名称上的商业市场。
[RFC625] Kudlick, M. and E. Feinler, "On-line hostnames service", RFC 625, March 1974.
[RFC625]Kudlick，M.和E.Feinler，“在线主机名服务”，RFC 625，1974年3月。
[RFC734] Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
[RFC734]Crispin，M.，“SUPDUP方案”，RFC 734，1977年10月。
[RFC811] Harrenstien, K., White, V. and E. Feinler, "Hostnames Server", RFC 811, March 1982.
[RFC811]哈伦斯坦，K.，怀特，V.和E.费恩勒，“主机名服务器”，RFC8111982年3月。
[RFC819] Su, Z. and J. Postel, "Domain naming convention for Internet user applications", RFC 819, August 1982.
[RFC819]Su，Z.和J.Postel，“互联网用户应用程序的域命名约定”，RFC819，1982年8月。
[RFC830] Su, Z., "Distributed system for Internet name service", RFC 830, October 1982.
[RFC830]Su，Z，“互联网名称服务的分布式系统”，RFC830，1982年10月。
[RFC882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, November 1983.
[RFC882]Mockapetris，P.，“域名：概念和设施”，RFC882，1983年11月。
[RFC883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, November 1983.
[RFC883]Mockapetris，P.，“域名：实现规范”，RFC883，1983年11月。
[RFC952] Harrenstien, K, Stahl, M. and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC952]Harrenstien，K，Stahl，M.和E.Feinler，“国防部互联网主机表规范”，RFC952，1985年10月。
[RFC953] Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME SERVER", RFC 953, October 1985.
[RFC953]K.Harrenstien，Stahl，M.和E.Feinler，“主机名服务器”，RFC953，1985年10月。
[RFC1034] Mockapetris, P., "Domain names, Concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名、概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591]Postel，J.，“域名系统结构和授权”，RFC15911994年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998
[RFC2295]Holtman，K.和A.Mutz，“HTTP中的透明内容协商”，RFC 2295，1998年3月
[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月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]Guttman，E.，Perkins，C.，Veizades，J.和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2825] IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols", RFC 2825, May 2000.
[RFC2825]IAB，Daigle，L.，Ed.，“纠结的网络：I18N、域名和其他互联网协议的问题”，RFC 28252000年5月。
[RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[RFC2826]IAB，“IAB对唯一DNS根的技术评论”，RFC 2826，2000年5月。
[RFC2972] Popp, N., Mealling, M., Masinter, L. and K. Sollins, "Context and Goals for Common Name Resolution", RFC 2972, October 2000.
[RFC2972]Popp，N.，Mealling，M.，Masinter，L.和K.Sollins，“共同名称解析的背景和目标”，RFC 2972，2000年10月。
[RFC3305] Mealling, M. and R. Denenberg, Eds., "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", RFC 3305, August 2002.
[RFC3305]Mealling，M.和R.Denenberg，编辑，“W3C/IETF URI规划联合兴趣小组的报告：统一资源标识符（URI）、URL和统一资源名称（URN）：澄清和建议”，RFC33052002年8月。
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3439]Bush，R.和D.Meyer，“一些互联网架构指南和哲学”，RFC 3439，2002年12月。
[Seng] Seng, J., et al., Eds., "Internationalized Domain Names: Registration and Administration Guideline for Chinese, Japanese, and Korean", Work in Progress.
[Seng]Seng，J.等人，编辑，“国际化域名：中文、日文和韩文的注册和管理指南”，正在进行中。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings (stringprep)", RFC 3454, December 2002.
[STRINGPREP]Hoffman，P.和M.Blanchet，“国际化弦的准备（STRINGPREP）”，RFC 3454，2002年12月。
The particular profile used for placing internationalized strings in the DNS is called "nameprep", described in Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names", Work in Progress.
用于在DNS中放置国际化字符串的特定配置文件称为“nameprep”，如Hoffman，P.和M.Blanchet，“nameprep:国际化域名的Stringprep配置文件”中所述，工作正在进行中。
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[TELNET]Postel，J.和J.Reynolds，“TELNET协议规范”，STD 8，RFC 854，1983年5月。
Postel, J. and J. Reynolds, "Telnet Option Specifications", STD 8, RFC 855, May 1983.
Postel，J.和J.Reynolds，“Telnet选项规范”，标准8，RFC 855，1983年5月。
[UNICODE] The Unicode Consortium, The Unicode Standard, Version 3.0, Addison-Wesley: Reading, MA, 2000. Update to version 3.1, 2001. Update to version 3.2, 2002.
[UNICODE]UNICODE联盟，UNICODE标准，3.0版，Addison-Wesley:Reading，马萨诸塞州，2000年。更新至3.12001版。更新至版本3.22002。
[UTR15] Davis, M. and M. Duerst, "Unicode Standard Annex #15: Unicode Normalization Forms", Unicode Consortium, March 2002. An integral part of The Unicode Standard, Version 3.1.1. Available at (http://www.unicode.org/reports/tr15/tr15-21.html).
[UTR15]Davis，M.和M.Duerst，“Unicode标准附件#15：Unicode规范化格式”，Unicode联盟，2002年3月。Unicode标准3.1.1版不可分割的一部分。可在(http://www.unicode.org/reports/tr15/tr15-21.html).
[WHOIS] Harrenstien, K, Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
[WHOIS]Harrenstien，K，Stahl，M.和E.Feinler，“NICNAME/WHOIS”，RFC 954，1985年10月。
[WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network Information Lookup Service, Whois++", RFC 1834, August 1995.
[WHOIS-UPDATE]Gargano，J.和K.Weiss，“WHOIS和网络信息查找服务，WHOIS++”，RFC 18341995年8月。
Weider, C., Fullton, J. and S. Spero, "Architecture of the Whois++ Index Service", RFC 1913, February 1996.
Weider，C.，Fullton，J.和S.Spero，“Whois++索引服务的体系结构”，RFC1913，1996年2月。
Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, June 1997;
Williamson，S.，Kosters，M.，Blacka，D.，Singh，J.和K.Zeilstra，“转诊Whois（RWhois）协议V1.5”，RFC 2167，1997年6月；
Daigle, L. and P. Faltstrom, "The application/whoispp-query Content-Type", RFC 2957, October 2000.
Daigle，L.和P.Faltstrom，“应用程序/WHOISP查询内容类型”，RFC 2957，2000年10月。
Daigle, L. and P. Falstrom, "The application/whoispp-response Content-type", RFC 2958, October 2000.
Daigle，L.和P.Falstrom，“应用程序/WHOISP响应内容类型”，RFC 2958，2000年10月。
[X29] International Telecommuncations Union, "Recommendation X.29: Procedures for the exchange of control information and user data between a Packet Assembly/Disassembly (PAD) facility and a packet mode DTE or another PAD", December 1997.
[X29]国际电信联盟，“建议X.29：数据包组装/拆卸（PAD）设施与数据包模式DTE或另一PAD之间控制信息和用户数据交换的程序”，1997年12月。
Many people have contributed to versions of this document or the thinking that went into it. The author would particularly like to thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie, Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific suggestions and/or challenging the assumptions and presentation of earlier versions and suggesting ways to improve them.
许多人对本文件的版本或其中的思想有所贡献。作者特别要感谢Harald Alvestrand、Rob Austein、Bob Braden、Vinton Cerf、Matt Crawford、Leslie Daigle、Patrik Faltstrom、Eric A.Hall、Ted Hardie、Paul Hoffman、Erik Nordmark、，以及Zita Wenzel提出具体建议和/或质疑早期版本的假设和陈述，并提出改进方法。
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140
马萨诸塞州剑桥322号马萨诸塞大道1770号约翰·C·克伦辛，邮编：02140
EMail: klensin+srch@jck.com
EMail: klensin+srch@jck.com
A mailing list has been initiated for discussion of the topics discussed in this document, and closely-related issues, at ietf-irnss@lists.elistx.com. See http://lists.elistx.com/archives/ for subscription and archival information.
已在ietf上发起了一份邮件列表，用于讨论本文件中讨论的主题以及密切相关的问题-irnss@lists.elistx.com. 看见http://lists.elistx.com/archives/ 用于订阅和存档信息。
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 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编辑功能的资金目前由互联网协会提供。