Network Working Group J. Klensin
Request for Comments: 3696 February 2004
Category: Informational
Network Working Group J. Klensin
Request for Comments: 3696 February 2004
Category: Informational
Application Techniques for Checking and Transformation of Names
名称检查和转换的应用技术
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards.
许多互联网应用程序被设计用于从部分信息推断顶级域（或其他域名标签）。引入新的顶级域，特别是非国家代码域，暴露了这些应用程序使用的某些方法的缺陷。这些缺陷使得应用程序的用户更难或不可能访问整个互联网。本备忘录讨论了已使用的一些技术，并为随着域名环境的发展尽量减少其负面影响提供了一些指导。本文件在一个地方汇总了适用规则，并提供了实际标准的参考。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Restrictions on domain (DNS) names . . . . . . . . . . . . . . 3
3. Restrictions on email addresses . . . . . . . . . . . . . . . 5
4. URLs and URIs . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. URI syntax definitions and issues . . . . . . . . . . . 7
4.2. The HTTP URL . . . . . . . . . . . . . . . . . . . . . . 8
4.3. The MAILTO URL . . . . . . . . . . . . . . . . . . . . . 9
4.4. Guessing domain names in web contexts . . . . . . . . . 11
5. Implications of internationalization . . . . . . . . . . . . . 11
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Restrictions on domain (DNS) names . . . . . . . . . . . . . . 3
3. Restrictions on email addresses . . . . . . . . . . . . . . . 5
4. URLs and URIs . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. URI syntax definitions and issues . . . . . . . . . . . 7
4.2. The HTTP URL . . . . . . . . . . . . . . . . . . . . . . 8
4.3. The MAILTO URL . . . . . . . . . . . . . . . . . . . . . 9
4.4. Guessing domain names in web contexts . . . . . . . . . 11
5. Implications of internationalization . . . . . . . . . . . . . 11
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
Designers of user interfaces to Internet applications have often found it useful to examine user-provided values for validity before passing them to the Internet tools themselves. This type of test, most commonly involving syntax checks or application of other rules to domain names, email addresses, or "web addresses" (URLs or, occasionally, extended URI forms (see Section 4)) may enable better-quality diagnostics for the user than might be available from the protocol itself. Local validity tests on values are also thought to improve the efficiency of back-office processing programs and to reduce the load on the protocols themselves. Certainly, they are consistent with the well-established principle that it is better to detect errors as early as possible.
互联网应用程序用户界面的设计者经常发现，在将用户提供的值传递给互联网工具之前，检查其有效性是很有用的。这种类型的测试通常涉及对域名、电子邮件地址或“web地址”（URL或偶尔扩展的URI表单（见第4节））进行语法检查或应用其他规则，可以为用户提供比协议本身更好的诊断质量。对值进行本地有效性测试也被认为可以提高后台处理程序的效率，并减少协议本身的负载。当然，它们符合公认的原则，即最好尽早发现错误。
The tests must, however, be made correctly or at least safely. If criteria are applied that do not match the protocols, users will be inconvenienced, addresses and sites will effectively become inaccessible to some groups, and business and communications opportunities will be lost. Experience in recent years indicates that syntax tests are often performed incorrectly and that tests for top-level domain names are applied using obsolete lists and conventions. We assume that most of these incorrect tests are the result of the inability to conveniently locate exact definitions for the criteria to be applied. This document draws summaries of the applicable rules together in one place and supplies references to the
但是，必须正确或至少安全地进行试验。如果应用的标准与协议不匹配，用户将不方便，某些群体将无法访问地址和站点，商业和通信机会将丢失。近年来的经验表明，语法测试经常被错误地执行，顶级域名的测试是使用过时的列表和约定进行的。我们假设这些不正确的测试大多数是由于无法方便地找到要应用的标准的准确定义。本文件将适用规则的摘要放在一个地方，并提供参考
actual standards. It does not add anything to those standards; it merely draws the information together into a form that may be more accessible.
实际标准。它没有给这些标准增加任何内容；它只是将信息汇集在一起，形成一种更容易获取的形式。
Many experts on Internet protocols believe that tests and rules of these sorts should be avoided in applications and that the tests in the protocols and back-office systems should be relied on instead. Certainly implementations of the protocols cannot assume that the data passed to them will be valid. Unless the standards specify particular behavior, this document takes no position on whether or not the testing is desirable. It only identifies the correct tests to be made if tests are to be applied.
许多互联网协议专家认为，在应用程序中应该避免此类测试和规则，而应该依赖协议和后台系统中的测试。当然，协议的实现不能假定传递给它们的数据是有效的。除非标准规定了特定的行为，否则本文件对测试是否可取不采取任何立场。如果要进行测试，它仅确定要进行的正确测试。
The sections that follow discuss domain names, email addresses, and URLs.
接下来的部分讨论域名、电子邮件地址和URL。
The authoritative definitions of the format and syntax of domain names appear in RFCs 1035 [RFC1035], 1123 [RFC1123], and 2181 [RFC2181].
域名格式和语法的权威定义见RFCs 1035[RFC1035]、1123[RFC1123]和2181[RFC2181]。
Any characters, or combination of bits (as octets), are permitted in DNS names. However, there is a preferred form that is required by most applications. This preferred form has been the only one permitted in the names of top-level domains, or TLDs. In general, it is also the only form permitted in most second-level names registered in TLDs, although some names that are normally not seen by users obey other rules. It derives from the original ARPANET rules for the naming of hosts (i.e., the "hostname" rule) and is perhaps better described as the "LDH rule", after the characters that it permits. The LDH rule, as updated, provides that the labels (words or strings separated by periods) that make up a domain name must consist of only the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen. No other symbols or punctuation characters are permitted, nor is blank space. If the hyphen is used, it is not permitted to appear at either the beginning or end of a label. There is an additional rule that essentially requires that top-level domain names not be all-numeric.
DNS名称中允许使用任何字符或位的组合（如八位字节）。但是，大多数应用程序都需要一个首选的表单。此首选形式是顶级域或TLD名称中唯一允许的形式。一般来说，它也是TLD中注册的大多数二级名称中允许的唯一形式，尽管一些用户通常看不到的名称遵守其他规则。它源于主机命名的原始ARPANET规则（即“主机名”规则），在其允许的字符之后，可能更好地描述为“LDH规则”。更新后的LDH规则规定，构成域名的标签（由句点分隔的单词或字符串）必须仅由ASCII字母和数字字符以及连字符组成。不允许使用其他符号或标点符号，也不允许空白。如果使用连字符，则不允许在标签的开头或结尾出现连字符。还有一条附加规则，本质上要求顶级域名不全是数字。
When it is necessary to express labels with non-character octets, or to embed periods within labels, there is a mechanism for keying them in that utilizes an escape sequence. RFC 1035 [RFC1035] should be consulted if that mechanism is needed (most common applications, including email and the Web, will generally not permit those escaped strings). A special encoding is now available for non-ASCII characters, see the brief discussion in Section 5.
当需要用非字符八位字节表示标签，或在标签中嵌入句点时，有一种利用转义序列对其进行键控的机制。如果需要该机制，应咨询RFC 1035[RFC1035]（大多数常见应用程序，包括电子邮件和Web，通常不允许使用这些转义字符串）。非ASCII字符现在可以使用特殊编码，请参阅第5节中的简要讨论。
Most internet applications that reference other hosts or systems assume they will be supplied with "fully-qualified" domain names, i.e., ones that include all of the labels leading to the root, including the TLD name. Those fully-qualified domain names are then passed to either the domain name resolution protocol itself or to the remote systems. Consequently, purported DNS names to be used in applications and to locate resources generally must contain at least one period (".") character. Those that do not are either invalid or require the application to supply additional information. Of course, this principle does not apply when the purpose of the application is to process or query TLD names themselves. The DNS specification also permits a trailing period to be used to denote the root, e.g., "a.b.c" and "a.b.c." are equivalent, but the latter is more explicit and is required to be accepted by applications. This convention is especially important when a TLD name is being referred to directly. For example, while ".COM" has become the popular terminology for referring to that top-level domain, "COM." would be strictly and technically correct in talking about the DNS, since it shows that "COM" is a top-level domain name.
大多数引用其他主机或系统的internet应用程序都假定它们将提供“完全限定”域名，即包含指向根的所有标签（包括TLD名称）的域名。然后将这些完全限定的域名传递给域名解析协议本身或远程系统。因此，用于应用程序和定位资源的声称DNS名称通常必须至少包含一个句点（“.”）字符。那些不是无效的，或者需要应用程序提供附加信息。当然，当应用程序的目的是处理或查询TLD名称本身时，此原则不适用。DNS规范还允许使用尾随句点来表示根，例如，“a.b.c”和“a.b.c.”是等效的，但后者更明确，需要被应用程序接受。当直接引用TLD名称时，此约定尤其重要。例如，虽然“.COM”已经成为引用顶级域名的流行术语，“COM.”在谈论DNS时在技术上是严格正确的，因为它表明“COM”是顶级域名。
There is a long history of applications moving beyond the "one or more periods" test in an attempt to verify that a valid TLD name is actually present. They have done this either by applying some heuristics to the form of the name or by consulting a local list of valid names. The historical heuristics are no longer effective. If one is to keep a local list, much more effort must be devoted to keeping it up-to-date than was the case several years ago.
长期以来，应用程序都在尝试验证是否确实存在有效的TLD名称，从而超越“一个或多个周期”测试。他们可以通过对姓名的形式应用一些启发式方法，或者通过查阅本地有效姓名列表来做到这一点。历史的试探法不再有效。如果要保存本地列表，必须比几年前付出更多的努力使其保持最新。
The heuristics were based on the observation that, since the DNS was first deployed, all top-level domain names were two, three, or four characters in length. All two-character names were associated with "country code" domains, with the specific labels (with a few early exceptions) drawn from the ISO list of codes for countries and similar entities [IS3166]. The three-letter names were "generic" TLDs, whose function was not country-specific, and there was exactly one four-letter TLD, the infrastructure domain "ARPA." [RFC1591]. However, these length-dependent rules were conventions, rather than anything on which the protocols depended.
这些启发法基于这样一个观察：自从DNS首次部署以来，所有顶级域名的长度都是两个、三个或四个字符。所有两个字符的名称都与“国家代码”域相关联，具体标签（除少数早期例外）取自ISO国家和类似实体代码列表[IS3166]。三个字母的名称是“通用”TLD，其功能不是特定于国家的，只有一个四个字母的TLD，即基础设施域“ARPA”。[RFC1591]。然而，这些依赖于长度的规则是约定，而不是协议所依赖的任何东西。
Before the mid-1990s, lists of valid top-level domain names changed infrequently. New country codes were gradually, and then more rapidly, added as the Internet expanded, but the list of generic domains did not change at all between the establishment of the "INT." domain in 1988 and ICANN's allocation of new generic TLDs in 2000. Some application developers responded by assuming that any two-letter domain name could be valid as a TLD, but the list of generic TLDs was fixed and could be kept locally and tested. Several of these assumptions changed as ICANN started to allocate new top-level
在20世纪90年代中期之前，有效顶级域名的列表很少更改。随着互联网的发展，新的国家代码逐渐增加，随后又迅速增加，但从1988年建立“INT”域名到2000年ICANN分配新的通用TLD，通用域名的列表根本没有变化。一些应用程序开发人员的回应是，假设任何两个字母的域名都可以作为TLD有效，但通用TLD列表是固定的，可以在本地保存并测试。随着ICANN开始分配新的顶级服务，其中一些假设发生了变化
domains: one two-letter domain that does not appear in the ISO 3166-1 table [ISO.3166.1988] was tentatively approved, and new domains were created with three, four, and even six letter codes.
域：一个未出现在ISO 3166-1表[ISO.3166.1988]中的两个字母的域被暂时批准，新域被创建为三个、四个甚至六个字母的代码。
As of the first quarter of 2003, the list of valid, non-country, top-level domains was .AERO, .BIZ, .COM, .COOP, .EDU, .GOV, .INFO, .INT, .MIL, .MUSEUM, .NAME, .NET, .ORG, .PRO, and .ARPA. ICANN is expected to expand that list at regular intervals, so the list that appears here should not be used in testing. Instead, systems that filter by testing top-level domain names should regularly update their local tables of TLDs (both "generic" and country-code-related) by polling the list published by IANA [DomainList]. It is likely that the better strategy has now become to make the "at least one period" test, to verify LDH conformance (including verification that the apparent TLD name is not all-numeric), and then to use the DNS to determine domain name validity, rather than trying to maintain a local list of valid TLD names.
截至2003年第一季度，有效的非国家顶级域名列表为.AERO、.BIZ、.COM、.COOP、.EDU、.GOV、.INFO、.INT、.MIL、.MUSEUM、.NAME、.NET、.ORG、.PRO和.ARPA。ICANN预计将定期扩展该列表，因此此处显示的列表不应用于测试。相反，通过测试顶级域名进行过滤的系统应该通过轮询IANA[DomainList]发布的列表定期更新本地TLD表（包括“通用”和国家代码相关）。现在可能更好的策略是进行“至少一个周期”测试，验证LDH一致性（包括验证明显的TLD名称不全是数字），然后使用DNS确定域名有效性，而不是试图维护有效TLD名称的本地列表。
A DNS label may be no more than 63 octets long. This is in the form actually stored; if a non-ASCII label is converted to encoded "punycode" form (see Section 5), the length of that form may restrict the number of actual characters (in the original character set) that can be accommodated. A complete, fully-qualified, domain name must not exceed 255 octets.
DNS标签的长度不得超过63个八位字节。这是实际存储的形式；如果将非ASCII标签转换为编码的“punycode”形式（见第5节），则该形式的长度可能会限制可容纳的实际字符数（在原始字符集中）。完整、完全限定的域名不得超过255个八位字节。
Some additional mechanisms for guessing correct domain names when incomplete information is provided have been developed for use with the web and are discussed in Section 4.4.
在提供不完整信息的情况下，已经开发了一些用于猜测正确域名的附加机制，用于web，并在第4.4节中进行了讨论。
Reference documents: RFC 2821 [RFC2821] and RFC 2822 [RFC2822]
参考文件：RFC 2821[RFC2821]和RFC 2822[RFC2822]
Contemporary email addresses consist of a "local part" separated from a "domain part" (a fully-qualified domain name) by an at-sign ("@"). The syntax of the domain part corresponds to that in the previous section. The concerns identified in that section about filtering and lists of names apply to the domain names used in an email context as well. The domain name can also be replaced by an IP address in square brackets, but that form is strongly discouraged except for testing and troubleshooting purposes.
当代电子邮件地址由一个“本地部分”和一个“域部分”（完全限定的域名）用at符号（“@”）隔开。域部分的语法与上一节中的语法相对应。该部分中确定的有关过滤和名称列表的问题也适用于电子邮件上下文中使用的域名。域名也可以用方括号中的IP地址替换，但除测试和故障排除外，强烈建议不要使用这种形式。
The local part may appear using the quoting conventions described below. The quoted forms are rarely used in practice, but are required for some legitimate purposes. Hence, they should not be rejected in filtering routines but, should instead be passed to the email system for evaluation by the destination host.
局部零件可能使用下面描述的引用约定出现。引用的表格在实践中很少使用，但出于某些合法目的需要使用。因此，在筛选例程中不应拒绝它们，而应将它们传递给电子邮件系统，以便目标主机进行评估。
The exact rule is that any ASCII character, including control characters, may appear quoted, or in a quoted string. When quoting is needed, the backslash character is used to quote the following character. For example
确切的规则是，任何ASCII字符（包括控制字符）都可能显示为带引号的字符串或带引号的字符串。当需要引用时，反斜杠字符用于引用以下字符。例如
Abc\@def@example.com
Abc\@def@example.com
is a valid form of an email address. Blank spaces may also appear, as in
是电子邮件地址的有效形式。也可能出现空白，如中所示
Fred\ Bloggs@example.com
弗雷德Bloggs@example.com
The backslash character may also be used to quote itself, e.g.,
反斜杠字符也可用于引用自身，例如。，
Joe.\\Blow@example.com
乔\\Blow@example.com
In addition to quoting using the backslash character, conventional double-quote characters may be used to surround strings. For example
除了使用反斜杠字符进行引号外，还可以使用传统的双引号字符来包围字符串。例如
"Abc@def"@example.com
"Abc@def“@example.com
"Fred Bloggs"@example.com
“Fred Bloggs”@example.com
are alternate forms of the first two examples above. These quoted forms are rarely recommended, and are uncommon in practice, but, as discussed above, must be supported by applications that are processing email addresses. In particular, the quoted forms often appear in the context of addresses associated with transitions from other systems and contexts; those transitional requirements do still arise and, since a system that accepts a user-provided email address cannot "know" whether that address is associated with a legacy system, the address forms must be accepted and passed into the email environment.
是上述前两个示例的替代形式。这些引用的表单很少被推荐，在实践中也不常见，但如上所述，必须由处理电子邮件地址的应用程序支持。特别是，引用的形式通常出现在与其他系统和上下文的转换相关的地址上下文中；这些过渡要求仍然存在，而且由于接受用户提供的电子邮件地址的系统无法“知道”该地址是否与旧系统关联，因此必须接受地址表单并将其传递到电子邮件环境中。
Without quotes, local-parts may consist of any combination of alphabetic characters, digits, or any of the special characters
如果没有引号，本地部分可能由字母字符、数字或任何特殊字符的任意组合组成
! # $ % & ' * + - / = ? ^ _ ` . { | } ~
! # $ % & ' * + - / = ? ^ _ ` . { | } ~
period (".") may also appear, but may not be used to start or end the local part, nor may two or more consecutive periods appear. Stated differently, any ASCII graphic (printing) character other than the at-sign ("@"), backslash, double quote, comma, or square brackets may appear without quoting. If any of that list of excluded characters are to appear, they must be quoted. Forms such as
句号（“.”）也可以出现，但不能用于开始或结束本地部分，也不能出现两个或多个连续的句号。换言之，除at符号（“@”）、反斜杠、双引号、逗号或方括号以外的任何ASCII图形（打印）字符都可以不加引号地出现。如果要显示排除字符列表中的任何字符，则必须将其引用。例如
user+mailbox@example.com
使用者+mailbox@example.com
customer/department=shipping@example.com
customer/department=shipping@example.com
$A12345@example.com
$A12345@example.com
!def!xyz%abc@example.com
!def!xyz%abc@example.com
_somename@example.com
_somename@example.com
are valid and are seen fairly regularly, but any of the characters listed above are permitted. In the context of local parts, apostrophe ("'") and acute accent ("`") are ordinary characters, not quoting characters. Some of the characters listed above are used in conventions about routing or other types of special handling by some receiving hosts. But, since there is no way to know whether the remote host is using those conventions or just treating these characters as normal text, sending programs (and programs evaluating address validity) must simply accept the strings and pass them on.
是有效的，并且可以经常看到，但是上面列出的任何字符都是允许的。在局部部分的上下文中，撇号（“”）和锐重音（“`”）是普通字符，而不是引用字符。上面列出的一些字符用于某些接收主机有关路由或其他类型的特殊处理的约定中。但是，由于无法知道远程主机是否正在使用这些约定，或者只是将这些字符视为普通文本，因此发送程序（以及评估地址有效性的程序）必须简单地接受字符串并传递它们。
In addition to restrictions on syntax, there is a length limit on email addresses. That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. Systems that handle email should be prepared to process addresses which are that long, even though they are rarely encountered.
除了语法限制外，电子邮件地址还有长度限制。该限制是“本地部分”（在“@”之前）最多64个字符（八位字节），域部分（在“@”之后）最多255个字符（八位字节），总长度为320个字符。处理电子邮件的系统应该准备好处理那么长的地址，即使它们很少遇到。
The syntax for URLs (Uniform Resource Locators) is specified in [RFC1738]. The syntax for the more general "URI" (Uniform Resource Identifier) is specified in [RFC2396]. The URI syntax is extremely general, with considerable variations permitted according to the type of "scheme" (e.g., "http", "ftp", "mailto") that is being used. While it is possible to use the general syntax rules of RFC 2396 to perform syntax checks, they are general enough --essentially only specifying the separation of the scheme name and "scheme specific part" with a colon (":") and excluding some characters that must be escaped if used-- to provide little significant filtering or validation power.
URL（统一资源定位器）的语法在[RFC1738]中指定。[RFC2396]中指定了更通用的“URI”（统一资源标识符）的语法。URI语法非常通用，根据使用的“方案”类型（例如，“http”、“ftp”、“mailto”）允许有相当大的变化。虽然可以使用RFC 2396的通用语法规则来执行语法检查，但它们足够通用——基本上只指定方案名称和带有冒号（“：”）的“方案特定部分”之间的分隔，并且排除了一些在使用时必须转义的字符——提供的过滤或验证功能很少。
The following characters are reserved in many URIs -- they must be used for either their URI-intended purpose or must be encoded. Some particular schemes may either broaden or relax these restrictions (see the following sections for URLs applicable to "web pages" and electronic mail), or apply them only to particular URI component parts.
以下字符在许多URI中都是保留的——它们必须用于URI的预期用途，或者必须进行编码。一些特定的方案可能会扩大或放宽这些限制（有关适用于“网页”和电子邮件的URL，请参见以下章节），或者仅将其应用于特定的URI组件。
; / ? : @ & = + $ , ?
; / ? : @ & = + $ , ?
In addition, control characters, the space character, the double-quote (") character, and the following special characters
此外，还有控制字符、空格字符、双引号（“）字符和以下特殊字符
< > # %
< > # %
are generally forbidden and must either be avoided or escaped, as discussed below.
通常是禁止的，必须避免或逃脱，如下所述。
The colon after the scheme name, and the percent sign used to escape characters, are specifically reserved for those purposes, although ":" may also be used elsewhere in some schemes.
方案名称后的冒号和用于转义字符的百分号是专门为这些目的保留的，尽管在某些方案的其他地方也可能使用“：”。
When it is necessary to encode these, or other, characters, the method used is to replace it with a percent-sign ("%") followed by two hexidecimal digits representing its octet value. See section 2.4.1 of [RFC2396] for an exact definition. Unless it is used as a delimiter of the URI scheme itself, any character may optionally be encoded this way; systems that are testing URI syntax should be prepared for these encodings to appear in any component of the URI except the scheme name itself.
当需要对这些或其他字符进行编码时，使用的方法是将其替换为百分号（“%”），后跟两个十六进制数字，表示其八进制值。准确定义见[RFC2396]第2.4.1节。除非它被用作URI方案本身的分隔符，否则任何字符都可以选择性地以这种方式编码；测试URI语法的系统应该准备好让这些编码出现在URI的任何组件中，方案名称本身除外。
A "generic URI" syntax is specified and is more restrictive, but using it to test URI strings requires that one know whether or not the particular scheme in use obeys that syntax. Consequently, applications that intend to check or validate URIs should normally identify the scheme name and then apply scheme-specific tests. The rules for two of those -- HTTP [RFC1738] and MAILTO [RFC2368] URLs -- are discussed below, but the author of an application which intends to make very precise checks, or to reject particular syntax rather than just warning the user, should consult the relevant scheme-definition documents for precise syntax and relationships.
“generic URI”语法是指定的，并且限制性更强，但是使用它来测试URI字符串需要知道所使用的特定方案是否遵守该语法。因此，打算检查或验证URI的应用程序通常应该识别方案名称，然后应用特定于方案的测试。下面将讨论其中两个URL的规则——HTTP[RFC1738]和MAILTO[RFC2368]URL，但如果应用程序的作者打算进行非常精确的检查，或者拒绝特定的语法，而不仅仅是警告用户，则应查阅相关的方案定义文档，以了解精确的语法和关系。
Absolute HTTP URLs consist of the scheme name, a host name (expressed as a domain name or IP address), and optional port number, and then, optionally, a path, a search part, and a fragment identifier. These are separated, respectively, by a colon and the two slashes that precede the host name, a colon, a slash, a question mark, and a hash mark ("#"). So we have
绝对HTTP URL包括方案名称、主机名（表示为域名或IP地址）和可选端口号，然后是路径、搜索部分和片段标识符（可选）。它们分别由冒号和主机名前的两个斜杠、冒号、斜杠、问号和哈希标记（“#”）分隔。所以我们有
http://host:port/path?search#fragment
http://host:port/path?search#fragment
http://host/path/
http://host/path/
http://host/path#fragment
http://host/path#fragment
http://host/path?search
http://host/path?search
http://host
http://host
and other variations on that form. There is also a "relative" form, but it almost never appears in text that a user might, e.g., enter into a form. See [RFC2616] for details.
和其他形式的变化。还有一个“相对”表单，但它几乎从未出现在用户可能输入表单的文本中。详见[RFC2616]。
The characters
人物
/ ; ?
/ ; ?
are reserved within the path and search parts and must be encoded; the first of these may be used unencoded, and is often used within the path, to designate hierarchy.
在路径和搜索部分中保留，并且必须进行编码；第一个可以不编码地使用，并且通常在路径中使用，以指定层次结构。
MAILTO is a URL type whose content is an email address. It can be used to encode any of the email address formats discussed in Section 3 above. It can also support multiple addresses and the inclusion of headers (e.g., Subject lines) within the body of the URL. MAILTO is authoritatively defined in RFC 2368 [RFC2368]; anyone expecting to accept and test multiple addresses or mail header or body formats should consult that document carefully.
MAILTO是一种URL类型，其内容是电子邮件地址。它可用于对上文第3节中讨论的任何电子邮件地址格式进行编码。它还可以支持多个地址，并在URL正文中包含标题（例如，主题行）。MAILTO在RFC 2368[RFC2368]中有权威定义；任何希望接受和测试多个地址或邮件头或正文格式的人都应该仔细查阅该文档。
In accepting text for, or validating, a MAILTO URL, it is important to note that, while it can be used to encode any valid email address, it is not sufficient to copy an email address into a MAILTO URL since email addresses may include a number of characters that are invalid in, or have reserved uses for, URLs. Those characters must be encoded, as outlined in Section 4.1 above, when the addresses are mapped into the URL form. Conversely, addresses in MAILTO URLs cannot, in general, be copied directly into email contexts, since few email programs will reverse the decodings (and doing so might be interpreted as a protocol violation).
在接受或验证MAILTO URL的文本时，需要注意的是，虽然可以使用它对任何有效的电子邮件地址进行编码，但将电子邮件地址复制到MAILTO URL中是不够的，因为电子邮件地址可能包含许多在URL中无效或保留使用的字符。当地址映射到URL表单时，必须对这些字符进行编码，如上文第4.1节所述。相反，MAILTO URL中的地址通常不能直接复制到电子邮件上下文中，因为很少有电子邮件程序会反转解码（这样做可能会被解释为违反协议）。
The following characters may appear in MAILTO URLs only with the specific defined meanings given. If they appear in an email address (i.e., for some other purpose), they must be encoded:
以下字符可能仅出现在具有给定特定定义含义的MAILTO URL中。如果它们出现在电子邮件地址中（即出于其他目的），则必须对其进行编码：
: The colon in "mailto:"
：mailto中的冒号：
< > # " % { } | \ ^ ~ `
< > # " % { } | \ ^ ~ `
These characters are "unsafe" in any URL, and must always be encoded.
这些字符在任何URL中都是“不安全的”，必须始终进行编码。
The following characters must also be encoded if they appear in a MAILTO URL
如果下列字符出现在MAILTO URL中，则必须对其进行编码
? & = Used to delimit headers and their values when these are encoded into URLs.
? & = 用于在将标题及其值编码为URL时对其进行分隔。
Some examples may be helpful:
一些示例可能会有所帮助：
+-------------------------+-----------------------------+-----------+
| Email address | MAILTO URL | Notes |
+-------------------------+-----------------------------+-----------+
| Joe@example.com | mailto:joe@example.com | 1 |
| | | |
| user+mailbox@example | mailto: | 2 |
| .com | user%2Bmailbox@example | |
| | .com | |
| | | |
| customer/department= | mailto:customer%2F | 3 |
| shipping@example.com | department=shipping@example | |
| | .com | |
| | | |
| $A12345@example.com | mailto:$A12345@example | 4 |
| | .com | |
| | | |
| !def!xyz%abc@example | mailto:!def!xyz%25abc | 5 |
| .com | @example.com | |
| | | |
| _somename@example.com | mailto:_somename@example | 4 |
| | .com | |
+-------------------------+-----------------------------+-----------+
+-------------------------+-----------------------------+-----------+
| Email address | MAILTO URL | Notes |
+-------------------------+-----------------------------+-----------+
| Joe@example.com | mailto:joe@example.com | 1 |
| | | |
| user+mailbox@example | mailto: | 2 |
| .com | user%2Bmailbox@example | |
| | .com | |
| | | |
| customer/department= | mailto:customer%2F | 3 |
| shipping@example.com | department=shipping@example | |
| | .com | |
| | | |
| $A12345@example.com | mailto:$A12345@example | 4 |
| | .com | |
| | | |
| !def!xyz%abc@example | mailto:!def!xyz%25abc | 5 |
| .com | @example.com | |
| | | |
| _somename@example.com | mailto:_somename@example | 4 |
| | .com | |
+-------------------------+-----------------------------+-----------+
Table 1
表1
Notes on Table
桌上的笔记
1. No characters appear in the email address that require escaping, so the body of the MAILTO URL is identical to the email address.
1. 电子邮件地址中没有需要转义的字符，因此MAILTO URL的正文与电子邮件地址相同。
2. There is actually some uncertainty as to whether or not the "+" characters requires escaping in MAILTO URLs (the standards are not precisely clear). But, since any character in the address specification may optionally be encoded, it is probably safer to encode it.
2. 对于“+”字符是否需要在MAILTO URL中转义，实际上存在一些不确定性（标准并不明确）。但是，由于地址规范中的任何字符都可以选择性地进行编码，因此对其进行编码可能更安全。
3. The "/" character is generally reserved in URLs, and must be encoded as %2F.
3. “/”字符通常在URL中保留，必须编码为%2F。
4. Neither the "$" nor the "_" character are given any special interpretation in MAILTO URLs, so need not be encoded.
4. MAILTO URL中既没有对“$”字符也没有对“\”字符进行任何特殊解释，因此不需要对其进行编码。
5. While the "!" character has no special interpretation, the "%" character is used to introduce encoded sequences and hence it must always be encoded.
5. 虽然“！”字符没有特殊解释，“%”字符用于引入编码序列，因此必须始终对其进行编码。
Several web browsers have adopted a practice that permits an incomplete domain name to be used as input instead of a complete URL. This has, for example, permitted users to type "microsoft" and have the browser interpret the input as "http://www.microsoft.com/". Other browser versions have gone even further, trying to build DNS names up through a series of heuristics, testing each variation in turn to see if it appears in the DNS, and accepting the first one found as the intended domain name. Still, others automatically invoke search engines if no period appears or if the reference fails. If any of these approaches are to be used, it is often critical that the browser recognize the complete list of TLDs. If an incomplete list is used, complete domain names may not be recognized as such and the system may try to turn them into completely different names. For example, "example.aero" is a fully-qualified name, since "AERO." is a TLD name. But, if the system doesn't recognize "AERO" as a TLD name, it is likely to try to look up "example.aero.com" and "www.example.aero.com" (and then fail or find the wrong host), rather than simply looking up the user-supplied name.
一些web浏览器采用了一种做法，允许使用不完整的域名作为输入，而不是完整的URL。例如，这允许用户键入“microsoft”，并让浏览器将输入解释为“http://www.microsoft.com/". 其他浏览器版本甚至更进一步，试图通过一系列试探法建立DNS名称，依次测试每个变体，看看它是否出现在DNS中，并接受第一个发现的域名作为预期域名。不过，如果没有出现句点或引用失败，其他人会自动调用搜索引擎。如果要使用这些方法中的任何一种，浏览器识别TLD的完整列表通常是至关重要的。如果使用了不完整的列表，完整的域名可能无法识别，系统可能会尝试将它们转换为完全不同的名称。例如，“example.aero”是一个完全限定的名称，因为“aero.”是TLD名称。但是，如果系统不将“AERO”识别为TLD名称，它可能会尝试查找“example.AERO.com”和“www.example.AERO.com”（然后失败或找到错误的主机），而不是简单地查找用户提供的名称。
As discussed in Section 2 above, there are dangers associated with software that attempts to "know" the list of top-level domain names locally and take advantage of that knowledge. These name-guessing heuristics are another example of that situation: if the lists are up-to-date and used carefully, the systems in which they are embedded may provide an easier, and more attractive, experience for at least some users. But finding the wrong host, or being unable to find a host even when its name is precisely known, constitute bad experiences by any measure.
如上文第2节所述，试图在本地“了解”顶级域名列表并利用这些知识的软件存在相关危险。这些猜测姓名的启发式方法是这种情况的另一个例子：如果列表是最新的并且使用谨慎，那么嵌入它们的系统可能会为至少一些用户提供更简单、更具吸引力的体验。但是，无论从何种角度来看，找到错误的主机，或者即使主机的名字是准确的，也找不到主机，都是不好的经历。
More generally, there have been bad experiences with attempts to "complete" domain names by adding additional information to them. These issues are described in some detail in RFC 1535 [RFC1535].
更一般地说，在试图通过向域名添加额外信息来“完成”域名时，有过一些不好的经历。这些问题在RFC 1535[RFC1535]中有详细描述。
The IETF has adopted a series of proposals ([RFC3490] - [RFC3492]) whose purpose is to permit encoding internationalized (i.e., non-ASCII) names in the DNS. The primary standard, and the group generically, are known as "IDNA". The actual strings stored in the
IETF采纳了一系列建议（[RFC3490]-[RFC3492]），其目的是允许在DNS中编码国际化（即非ASCII）名称。主要标准和一般组称为“IDNA”。存储在
DNS are in an encoded form: the labels begin with the characters "xn--" followed by the encoded string. Applications should be prepared to accept and process the encoded form (those strings are consistent with the "LDH rule" (see Section 2) so should not raise any separate issues) and the use of local, and potentially other, characters as appropriate to local systems and circumstances.
DNS采用编码形式：标签以字符“xn--”开头，后跟编码字符串。应用程序应准备好接受和处理编码形式（这些字符串符合“LDH规则”（见第2节），因此不应提出任何单独的问题）以及根据本地系统和情况使用本地字符和可能的其他字符。
The IDNA specification describes the exact process to be used to validate a name or encoded string. The process is sufficiently complex that shortcuts or heuristics, especially for versions of labels written directly in Unicode or other coded character sets, are likely to fail and cause problems. In particular, the strings cannot be validated with syntax or semantic rules of any of the usual sorts: syntax validity is defined only in terms of the result of executing a particular function.
IDNA规范描述了用于验证名称或编码字符串的确切过程。该过程非常复杂，特别是对于直接以Unicode或其他编码字符集编写的标签版本，快捷方式或启发式方法可能会失败并导致问题。特别是，字符串不能用任何常规类型的语法或语义规则进行验证：语法有效性仅根据执行特定函数的结果定义。
In addition to the restrictions imposed by the protocols themselves, many domains are implementing rules about just which non-ASCII names they will permit to be registered (see, e.g., [JET], [RegRestr]). This work is still relatively new, and the rules and conventions are likely to be different for each domain, or at least each language or script group. Attempting to test for those rules in a client program to see if a user-supplied name might possibly exist in the relevant domain would almost certainly be ill-advised.
除了协议本身施加的限制外，许多域正在实施关于允许注册哪些非ASCII名称的规则（参见，例如，[JET]、[Regrest]）。这项工作还是相对较新的，对于每个域，或者至少每个语言或脚本组，规则和约定可能会有所不同。试图在客户端程序中测试这些规则，以查看用户提供的名称是否可能存在于相关域中，几乎肯定是不明智的。
One quick local test however, may be reasonable: as of the time of this writing, there should be no instances of labels in the DNS that start with two characters, followed by two hyphens, where the two characters are not "xn" (in, of course, either upper or lower case). Such label strings, if they appear, are probably erroneous or obsolete, and it may be reasonable to at least warn the user about them.
然而，一个快速的本地测试可能是合理的：在撰写本文时，DNS中不应该有以两个字符开头，然后是两个连字符的标签实例，其中两个字符不是“xn”（当然，大写或小写）。如果出现这样的标签字符串，它们可能是错误的或过时的，至少可以向用户发出警告。
There is ongoing work in the IETF and elsewhere to define internationalized formats for use in other protocols, including email addresses. Those forms may or may not conform to existing rules for ASCII-only identifiers; anyone designing evaluators or filters should watch that work closely.
IETF和其他地方正在进行工作，以定义用于其他协议（包括电子邮件地址）的国际化格式。这些表格可能符合也可能不符合仅ASCII标识符的现有规则；任何设计评估器或过滤器的人都应该密切关注其工作情况。
When an application accepts a string from the user and ultimately passes it on to an API for a protocol, the desirability of testing or filtering the text in any way not required by the protocol itself is hotly debated. If it must divide the string into its components, or otherwise interpret it, it obviously must make at least enough tests to validate that process. With, e.g., domain names or email addresses that can be passed on untouched, the appropriateness of
当应用程序接受来自用户的字符串并最终将其传递给协议的API时，以协议本身不需要的任何方式测试或过滤文本的可取性引起了激烈的争论。如果它必须将字符串划分为组件，或者以其他方式对其进行解释，那么它显然必须至少进行足够的测试来验证该过程。例如，如果域名或电子邮件地址可以原封不动地传递，则
trying to figure out which ones are valid and which ones are not requires a more complex decision, one that should include considerations of how to make exactly the correct tests and to keep information that changes and evolves up-to-date. A test containing obsolete information, can be extremely frustrating for potential correspondents or customers and may harm desired relationships.
要想弄清楚哪些是有效的，哪些不是，需要一个更复杂的决定，这个决定应该包括如何准确地进行正确的测试，以及如何使变化和发展的信息保持最新。包含过时信息的测试可能会让潜在的通讯员或客户非常沮丧，并且可能会损害期望的关系。
Since this document merely summarizes the requirements of existing standards, it does not introduce any new security issues. However, many of the techniques that motivate the document raise important security concerns of their own. Rejecting valid forms of domain names, email addresses, or URIs often denies service to the user of those entities. Worse, guessing at the user's intent when an incomplete address, or other string, is given can result in compromises to privacy or accuracy of reference if the wrong target is found and returned. From a security standpoint, the optimum behavior is probably to never guess, but instead, to force the user to specify exactly what is wanted. When that position involves a tradeoff with an acceptable user experience, good judgment should be used and the fact that it is a tradeoff recognized.
由于本文档仅总结了现有标准的要求，因此没有引入任何新的安全问题。然而，许多激发文档的技术都会引起它们自身的重要安全问题。拒绝有效形式的域名、电子邮件地址或URI通常会拒绝为这些实体的用户提供服务。更糟糕的是，如果发现并返回了错误的目标，那么在给出不完整的地址或其他字符串时猜测用户的意图可能会损害隐私或引用的准确性。从安全的角度来看，最佳的行为可能是永远不要猜测，而是强制用户准确地指定想要的内容。当该职位涉及到具有可接受的用户体验的权衡时，应使用良好的判断，并承认这是一个权衡。
Some characters have special or privileged meanings on some systems (i.e., ` on Unix). Applications should be careful to escape those locally if necessary. By the same token, they are valid, and should not be disallowed locally, or escaped when transmitted through Internet protocols, for such reasons if a remote site chooses to use them.
某些字符在某些系统上具有特殊或特权意义（例如，在Unix上为`字符）。如有必要，应用程序应小心地从本地逃逸。出于同样的原因，如果远程站点选择使用它们，它们是有效的，并且不应在本地被禁止，或者在通过Internet协议传输时被转义。
The presence of local checking does not permit remote checking to be bypassed. Note that this can apply to a single machine; in particular, a local MTA should not assume that a local MUA has properly escaped locally-significant special characters.
本地检查的存在不允许绕过远程检查。注意，这可能适用于单个机器；特别是，本地MTA不应假定本地MUA已正确转义本地重要的特殊字符。
The author would like to express his appreciation for helpful comments from Harald Alvestrand, Eric A. Hall, and the RFC Editor, and for partial support of this work from SITA. Responsibility for any errors remains, of course, with the author.
作者对Harald Alvestrand、Eric A.Hall和RFC编辑的有益评论表示感谢，并对SITA对这项工作的部分支持表示感谢。当然，任何错误的责任仍在于作者。
The first Internet-Draft on this subject was posted in February 2003. The document was submitted to the RFC Editor on 20 June 2003, returned for revisions on 19 August, and resubmitted on 5 September 2003.
关于这一主题的第一份互联网草案于2003年2月公布。该文件于2003年6月20日提交给RFC编辑，8月19日返回修订，并于2003年9月5日重新提交。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993.
[RFC1535]Gavron，E.，“广泛部署DNS软件的安全问题和建议纠正”，RFC 1535，1993年10月。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]Berners Lee，T.，Masinter，L.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2368] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[RFC2368]Hoffman，P.，Masinter，L.和J.Zawinski，“邮件URL方案”，RFC 2368，1998年7月。
[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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，Ed.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，Ed.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC3490] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491]Hoffman，P.和M.Blanchet，“Nameprep：国际化域名（IDN）的Stringprep配置文件”，RFC 3491，2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968. ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
[ASCII]美国国家标准协会（前美国标准协会），“美国信息交换代码”，ANSI X3.4-1968。ANSI X3.4-1968已被稍作修改的较新版本所取代，但1968年版本仍然是互联网的最终版本。
[DomainList] Internet Assigned Numbers Authority (IANA), Untitled
alphabetical list of current top-level domains.
http://data.iana.org/TLD/tlds-alpha-by-domain.txt
ftp://data.iana.org/TLD/tlds-alpha-by-domain.txt
[DomainList] Internet Assigned Numbers Authority (IANA), Untitled
alphabetical list of current top-level domains.
http://data.iana.org/TLD/tlds-alpha-by-domain.txt
ftp://data.iana.org/TLD/tlds-alpha-by-domain.txt
[ISO.3166.1988] International Organization for Standardization, "Codes for the representation of names of countries, 3rd edition", ISO Standard 3166, August 1988.
[ISO.3166.1988]国际标准化组织，“国家名称表示代码，第3版”，ISO标准3166，1988年8月。
[JET] Konishi, K., et al., "Internationalized Domain Names Registration and Administration Guideline for Chinese, Japanese and Korean", Work in Progress.
[JET]Konishi，K.等人，“中文、日文和韩文的国际化域名注册和管理指南”，工作正在进行中。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591]Postel，J.，“域名系统结构和授权”，RFC15911994年3月。
[RegRestr] Klensin, J., "Registration of Internationalized Domain Names: Overview and Method", Work in Progress, February 2004.
[Regrest]Klensin，J.，“国际化域名的注册：概述和方法”，正在进行的工作，2004年2月。
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
美国马萨诸塞州剑桥市322号马萨诸塞大道1770号约翰·C·克伦辛，邮编：02140
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。