Network Working Group L. Conroy
Request for Comments: 5483 RMRL
Category: Informational K. Fujiwara
JPRS
March 2009
Network Working Group L. Conroy
Request for Comments: 5483 RMRL
Category: Informational K. Fujiwara
JPRS
March 2009
ENUM Implementation Issues and Experiences
ENUM实施问题和经验
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol. It does not revise the standards but is intended to provide technical input to future revisions of those documents.
本文档介绍了基于ENUM协议实施系统的经验以及其他人创建的ENUM数据的经验。因此，它澄清了ENUM和动态委托发现系统标准。它的目的是通过报告在解释指定ENUM协议的文档集时存在的“问题”和潜在缺陷来帮助他人。它不修订标准，但旨在为这些文件的未来修订提供技术投入。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Document Goal ..............................................3
1.2. Terminology ................................................3
2. Character Sets and ENUM .........................................4
2.1. Character Sets - Non-ASCII Considered Harmful ..............4
2.1.1. Non-ASCII in the Regular Expression Field ...........5
2.1.2. Non-ASCII Support - Conclusions .....................6
2.2. Case Sensitivity ...........................................7
2.3. Regexp Field Delimiter .....................................7
2.4. Regexp Meta-Character Issue ................................8
3. Unsupported NAPTRs ..............................................8
3.1. Non-Compliant Client Behaviour .............................9
4. ENUM NAPTR Processing ..........................................10
4.1. Common Non-Compliant Client Behaviour .....................11
4.1.1. Example ............................................11
4.2. Order/Priority Values - Processing Sequence ...............12
4.3. Use of Order and Preference Fields ........................13
4.4. NAPTRs with Identical ORDER/PRIORITY Values ...............14
4.4.1. Compound NAPTRs and Implicit
ORDER/REFERENCE Values .............................14
4.5. Processing Order Value across Domains .....................15
5. Non-Terminal NAPTR Processing ..................................16
5.1. Non-Terminal NAPTRs - Necessity ...........................16
5.2. Non-Terminal NAPTRs - Considerations ......................17
5.2.1. Non-Terminal NAPTRs - General ......................17
5.2.2. Non-Terminal NAPTRs - Loop Detection and Response ..17
5.2.3. Field Content in Non-Terminal NAPTRs ...............17
6. Backwards Compatibility ........................................20
6.1. Services Field Syntax .....................................20
7. Collected Implications for ENUM Provisioning ...................21
8. Collected Implications for ENUM Clients ........................23
8.1. Non-Terminal NAPTR Processing .............................25
9. Security Considerations ........................................26
10. Acknowledgements ..............................................27
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................29
1. Introduction ....................................................3
1.1. Document Goal ..............................................3
1.2. Terminology ................................................3
2. Character Sets and ENUM .........................................4
2.1. Character Sets - Non-ASCII Considered Harmful ..............4
2.1.1. Non-ASCII in the Regular Expression Field ...........5
2.1.2. Non-ASCII Support - Conclusions .....................6
2.2. Case Sensitivity ...........................................7
2.3. Regexp Field Delimiter .....................................7
2.4. Regexp Meta-Character Issue ................................8
3. Unsupported NAPTRs ..............................................8
3.1. Non-Compliant Client Behaviour .............................9
4. ENUM NAPTR Processing ..........................................10
4.1. Common Non-Compliant Client Behaviour .....................11
4.1.1. Example ............................................11
4.2. Order/Priority Values - Processing Sequence ...............12
4.3. Use of Order and Preference Fields ........................13
4.4. NAPTRs with Identical ORDER/PRIORITY Values ...............14
4.4.1. Compound NAPTRs and Implicit
ORDER/REFERENCE Values .............................14
4.5. Processing Order Value across Domains .....................15
5. Non-Terminal NAPTR Processing ..................................16
5.1. Non-Terminal NAPTRs - Necessity ...........................16
5.2. Non-Terminal NAPTRs - Considerations ......................17
5.2.1. Non-Terminal NAPTRs - General ......................17
5.2.2. Non-Terminal NAPTRs - Loop Detection and Response ..17
5.2.3. Field Content in Non-Terminal NAPTRs ...............17
6. Backwards Compatibility ........................................20
6.1. Services Field Syntax .....................................20
7. Collected Implications for ENUM Provisioning ...................21
8. Collected Implications for ENUM Clients ........................23
8.1. Non-Terminal NAPTR Processing .............................25
9. Security Considerations ........................................26
10. Acknowledgements ..............................................27
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................29
The goal of this document is to clarify the ENUM and Dynamic Delegation Discovery System (DDDS) standards. It does not itself revise ENUM or DDDS standards but is intended to provide technical input to future revisions of those documents. It also serves to advise implementers on the pitfalls that they may find. It highlights areas where ENUM implementations have differed over interpretation of the standards documents or have outright failed to implement some features as specified.
本文档的目标是阐明ENUM和动态委托发现系统（DDDS）标准。它本身并不修订ENUM或DDDS标准，但旨在为这些文件的未来修订提供技术投入。它还可以就实施者可能发现的陷阱提供建议。它强调了枚举实现在标准文档的解释上存在差异或完全未能实现指定的某些特性的领域。
As well as providing clarifications to standards text, this document also mentions potential choices that can be made, in an attempt to help foster interworking between components that use this protocol. The reader is reminded that others may make different choices.
除了对标准文本进行澄清外，本文件还提到了可能做出的选择，以帮助促进使用本协议的组件之间的互通。提醒读者，其他人可能会做出不同的选择。
The core specifications for the E.164 Number Mapping (ENUM) protocol [RFC3761] and the Dynamic Delegation Discovery System (DDDS) [RFC3403] [RFC3401] [RFC3402] [RFC3404] [RFC3405] are defined elsewhere. Unfortunately, this document cannot provide an overview of the specifications, so the reader is assumed to have read and understood the complete set of ENUM normative documents.
E.164数字映射（ENUM）协议[RFC3761]和动态委托发现系统（DDDS）[RFC3403][RFC3401][RFC3402][RFC3404][RFC3405]的核心规范在别处定义。不幸的是，本文件不能提供规范概述，因此假定读者已经阅读并理解了完整的ENUM规范性文件集。
The Domain Name System (DNS) is ENUM's database. ENUM uses the NAPTR (Naming Authority Pointer) resource record type to store its DDDS rules into DNS domains. ENUM relies on DNS services. Thus, it is also important for ENUM implementers to carry out a thorough analysis of all of the existing DNS standard documents to understand what services are provided to ENUM and what load ENUM provisioning and queries will place on the DNS.
域名系统（DNS）是ENUM的数据库。ENUM使用NAPTR（命名机构指针）资源记录类型将其DDDS规则存储到DNS域中。枚举依赖于DNS服务。因此，ENUM实施者对所有现有DNS标准文档进行彻底分析也很重要，以了解向ENUM提供了哪些服务，以及ENUM配置和查询将在DNS上加载哪些负载。
A great deal of the rationale for making the choices listed in this document is available to those who explore the standards. The trick of course is in understanding those standards and the subtle implications that are involved in some of their features. In almost all cases, the choices presented here are merely selections from values that are permissible within the standards.
本文件所列选择的大量理由可供探索标准的人员使用。当然，诀窍在于理解这些标准及其某些特性所涉及的微妙含义。在几乎所有情况下，此处提供的选择仅是从标准中允许的值中进行选择。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
[RFC3403] and [RFC3761] specify respectively that NAPTR resource records and ENUM support Unicode using the UTF-8 encoding defined in [RFC3629]. This raises an issue when implementations use "single byte" string-processing routines. If there are multi-byte characters within an ENUM NAPTR, incorrect processing may well result from these UTF-8-unaware systems.
[RFC3403]和[RFC3761]分别指定NAPTR资源记录和枚举支持使用[RFC3629]中定义的UTF-8编码的Unicode。当实现使用“单字节”字符串处理例程时，这会引发一个问题。如果枚举NAPTR中存在多字节字符，则这些UTF-8-1系统很可能会导致错误处理。
The UTF-8 encoding has a US-ASCII equivalent range, so that all characters in US-ASCII [ASCII] from 0x00 to 0x7F hexadecimal have an identity map to the UTF-8 encoding; the encodings are the same. In UTF-8, characters with Unicode code points above this range will be encoded using more than one byte, all of which will be in the range 0x80 to 0xFF hexadecimal. Thus, it is important to consider the different fields of a NAPTR and whether or not multi-byte characters can or should appear in them.
UTF-8编码具有US-ASCII等效范围，因此从0x00到0x7F十六进制的US-ASCII[ASCII]中的所有字符都具有UTF-8编码的标识映射；编码是相同的。在UTF-8中，Unicode代码点高于此范围的字符将使用多个字节进行编码，所有字节都将在0x80到0xFF十六进制范围内。因此，重要的是考虑一个NAPTR的不同字段和多字节字符是否可以或应该出现在它们中。
In addition, characters in the non-printable portion of US-ASCII (0x00 to 0x1F hexadecimal, plus 0x7F hexadecimal) are "difficult". Although NAPTRs are processed by machine, they may sometimes need to be written in a human-readable form. Specifically, if NAPTR content is shown to an end user so that he or she may choose, it is imperative that the content is human-readable. Thus, it is unwise to use non-printable characters even if they lie within the US-ASCII range; the ENUM client may have good reason to reject NAPTRs that include these characters as they cannot readily be presented to an end user.
此外，US-ASCII的不可打印部分（0x00到0x1F十六进制，加上0x7F十六进制）中的字符是“困难的”。尽管NAPTR由机器处理，但有时可能需要以人类可读的形式编写。具体地说，如果向最终用户显示NAPTR内容以便他或她可以选择，则内容必须是人类可读的。因此，使用不可打印字符是不明智的，即使它们位于US-ASCII范围内；ENUM客户端可能有很好的理由拒绝包含这些字符的NAPTR，因为它们不容易呈现给最终用户。
There are two numeric fields in a NAPTR: the ORDER and PREFERENCE/ PRIORITY fields. As these contain binary values, no risk is involved because string processing should not be applied to them. The string-based fields are the Flags, Services, and Regexp fields. The Replacement field holds an uncompressed domain name, encoded according to the standard DNS mechanism [RFC1034][RFC1035]. The Internationalised Domain Name (IDN) can be supported (as specified in [RFC3490], [RFC3491], and [RFC3492]). Any such IDN MUST be further encoded using Punycode [RFC3492]. As the Replacement field holds a domain name that is not subject to replacement or modification (other than Punycode processing), it is not of concern here.
NAPTR中有两个数字字段：顺序字段和首选项/优先级字段。因为它们包含二进制值，所以不涉及任何风险，因为不应该对它们应用字符串处理。基于字符串的字段是标志、服务和Regexp字段。替换字段包含未压缩的域名，根据标准DNS机制[RFC1034][RFC1035]进行编码。可以支持国际化域名（IDN）（如[RFC3490]、[RFC3491]和[RFC3492]中所述）。任何此类IDN必须使用Punycode[RFC3492]进行进一步编码。由于替换字段包含一个不需要替换或修改的域名（Punycode处理除外），因此这里不需要担心。
Taking the string fields in turn, the Flags field contains characters that indicate the disposition of the NAPTR. This may be empty, in which case the NAPTR is "non-terminal", or it may include a flag
依次使用字符串字段，Flags字段包含指示NAPTR处置的字符。这可能是空的，在这种情况下，NAPTR是“非终端”，或者它可能包括一个标志
character as specified in [RFC3761]. These characters all fall into the printable US-ASCII equivalent range, so multi-byte characters cannot occur.
[RFC3761]中规定的字符。这些字符都属于可打印的US-ASCII等效范围，因此不能出现多字节字符。
The Services field includes the DDDS Application identifier ("E2U") used for ENUM, a set of Enumservice identifiers, any of which may embed the ':' separator character, together with the '+' character used to separate Enumservices from one another and from this DDDS Application identifier. In Section 2.4.2 of [RFC3761], Enumservice identifier tokens are specified as 1*32 ALPHA/DIGIT, so there is no possibility of non-ASCII characters in the Services field.
服务字段包括用于ENUM的DDDS应用程序标识符（“E2U”），一组Enumservice标识符，其中任何一个标识符都可以嵌入“：”分隔符，以及用于将Enumservices彼此和此DDDS应用程序标识符分开的“+”字符。在[RFC3761]的第2.4.2节中，枚举服务标识符标记被指定为1*32 ALPHA/位，因此服务字段中不可能存在非ASCII字符。
The Regexp field is more complex. It forms a sed-like substitution expression, defined in [RFC3402], and consists of two sub-fields:
Regexp字段更复杂。它形成了[RFC3402]中定义的类似sed的替换表达式，由两个子字段组成：
o a POSIX Extended Regular Expression (ERE) sub-field [IEEE.1003-2.1992]
o POSIX扩展正则表达式（ERE）子字段[IEEE.1003-2.1992]
o a replacement (Repl) sub-field [RFC3402].
o 替换（Repl）子字段[RFC3402]。
Additionally, [RFC3402] specifies that a flag character may be appended, but the only flag currently defined there (the 'i' case-insensitivity flag) is not appropriate for ENUM -- see Section 2.2.
此外，[RFC3402]指定可以附加一个标志字符，但当前在其中定义的唯一标志（“i”不区分大小写标志）不适用于枚举——请参见第2.2节。
The ERE sub-field matches against the "Application Unique String"; for ENUM, this is defined in [RFC3761] to consist of digit characters, with an initial '+' character. It is similar to a global-number-digits production of a tel: URI, as specified in [RFC3966], but with visual-separators removed. In short, it is a telephone number (see [E.164]) in restricted format. All of these characters fall into the US-ASCII equivalent range of UTF-8 encoding, as do the characters significant to the ERE processing.
ERE子字段与“应用程序唯一字符串”匹配；对于枚举，在[RFC3761]中定义为由数字字符组成，并带有初始“+”字符。它类似于[RFC3966]中指定的tel:URI的全局数字生成，但删除了可视分隔符。简而言之，它是一个限制格式的电话号码（见[E.164]）。所有这些字符都属于UTF-8编码的US-ASCII等效范围，对于ERE处理非常重要的字符也是如此。
Strictly, the ERE might include other characters. The ERE could include choice elements matching against different items, some of which might not be an ENUM Application Unique String. Those alternative matching elements might conceivably include non-ASCII characters. As an operational issue, it is not reasonable to include such constructs, as ENUM NAPTRs match against telephone numbers.
严格来说，ERE可能包含其他字符。ERE可以包括与不同项匹配的选项元素，其中一些可能不是枚举应用程序唯一的字符串。这些替代匹配元素可能包括非ASCII字符。作为一个操作问题，包含这样的构造是不合理的，因为ENUM NAPTRs与电话号码匹配。
In the normal situation in which E2U NAPTRs are provisioned in ENUM domains, there will be no multi-byte characters within this sub-field, as the ERE will be intended to match against telephone numbers. ENUM clients must be able to handle NAPTRs that do contain such multi-byte characters (as the standard does not preclude them), but there is no operational reason for these ever being provisioned
在枚举域中提供E2U NAPTR的正常情况下，此子字段中不会有多字节字符，因为ERE将与电话号码匹配。ENUM客户端必须能够处理包含此类多字节字符的NAPTR（因为标准并不排除它们），但没有任何操作原因来配置这些字符
in ENUM domains. If NAPTRs provisioned in ENUM domains are encountered containing such multi-byte characters, these could reasonably be discarded.
在枚举域中。如果遇到在枚举域中配置的NAPTR包含此类多字节字符，则可以合理地丢弃这些字符。
The Repl sub-field can include a mixture of explicit text used to construct a URI and characters significant to the substitution expression, as defined in [RFC3403]. Whilst the latter set all fall into the US-ASCII equivalent range of UTF-8 encoding, this might not be the case for all conceivable text used to construct a URI. Presence of multi-byte characters could complicate URI generation and processing routines.
Repl子字段可以包括用于构造URI的显式文本和对替换表达式有意义的字符的混合，如[RFC3403]中所定义。虽然后一组都属于UTF-8编码的US-ASCII等效范围，但对于用于构造URI的所有可能的文本来说，情况可能并非如此。多字节字符的存在可能会使URI生成和处理例程复杂化。
URI generic syntax is defined in [RFC3986] as a sequence of characters chosen from a limited subset of the repertoire of US-ASCII characters. The current URIs use the standard URI character escaping rules specified in the URI generic syntax, and so any multi-byte character will be pre-processed; they will not occur in the explicit text used to construct a URI within the Repl sub-field.
URI通用语法在[RFC3986]中定义为从US-ASCII字符集的有限子集中选择的字符序列。当前URI使用URI通用语法中指定的标准URI字符转义规则，因此将预处理任何多字节字符；它们不会出现在用于在Repl子字段中构造URI的显式文本中。
As currently specified, ENUM only permits URIs to be generated in the Regexp field. However, even if this were to be extended in future revisions of the ENUM specification to allow the use of Internationalised Resource Identifiers (IRIs), defined in [RFC3987], further support for non-ASCII characters may be avoided. IRIs are defined as extending the syntax of URIs, and RFC 3987 specifies a mapping from IRIs to URIs. IRI syntax allows characters with multi-byte UTF-8 encoding.
按照当前的规定，ENUM只允许在Regexp字段中生成URI。然而，即使在未来的ENUM规范修订版中对此进行扩展，以允许使用[RFC3987]中定义的国际化资源标识符（IRI），也可以避免对非ASCII字符的进一步支持。IRIs被定义为扩展URI的语法，RFC3987指定了从IRIs到URI的映射。IRI语法允许使用多字节UTF-8编码的字符。
Given that this is the only place within an ENUM NAPTR where such multi-byte encodings might reasonably be found, a simple solution is to use the mapping method specified in Section 3.1 of [RFC3987] to convert any IRI into its equivalent URI.
鉴于这是枚举NAPTR中唯一可以合理找到此类多字节编码的地方，一个简单的解决方案是使用[RFC3987]第3.1节中指定的映射方法将任何IRI转换为其等效URI。
This process consists of two elements; the domain part of an IRI MUST be processed using Punycode if it has a non-ASCII domain name, and the remainder MUST be processed using the extended escaping rules specified in [RFC3987] if it contains characters outside the normal URI repertoire. Using this process, there will be no non-ASCII characters in any part of any URI, even if it has been converted from an IRI that contains such characters.
这个过程包括两个要素；如果IRI的域部分具有非ASCII域名，则必须使用Punycode进行处理；如果IRI的域部分包含正常URI指令表之外的字符，则必须使用[RFC3987]中指定的扩展转义规则进行处理。使用此过程，任何URI的任何部分都不会有非ASCII字符，即使它已从包含此类字符的IRI转换而来。
From the analysis just given, the only place within an ENUM NAPTR where non-ASCII characters might be found is the Regexp field. It is possible to remove any requirement to process characters outside the
根据刚才给出的分析，在ENUM NAPTR中可能找到非ASCII字符的唯一位置是Regexp字段。可以删除在外部处理字符的任何要求
US-ASCII equivalent range by adding very few operational restrictions. There is no obvious benefit in providing characters outside this range. Handling multi-byte characters complicates development and operation of client programs, and many existing programs do not include such support.
通过添加很少的操作限制，US-ASCII等效范围。提供此范围之外的字符没有明显的好处。处理多字节字符会使客户端程序的开发和操作复杂化，而且许多现有程序不包括这种支持。
As the gain from permitting characters outside the US-ASCII equivalent range is unclear, and the costs of multi-byte character processing are very clear, ENUM NAPTRs SHOULD NOT include characters outside the printable US-ASCII equivalent range.
由于允许字符超出US-ASCII等效范围的好处尚不清楚，且多字节字符处理的成本也很明显，因此ENUM NAPTRs不应包括超出可打印US-ASCII等效范围的字符。
The only place where NAPTR field content is case sensitive is in any static text in the Repl sub-field of the Regexp field. Everywhere else, case-insensitive processing can be used.
NAPTR字段内容区分大小写的唯一位置是在Regexp字段的Repl子字段中的任何静态文本中。在其他任何地方，都可以使用不区分大小写的处理。
The case-insensitivity flag ('i') could be added at the end of the Regexp field. However, in ENUM, the ERE sub-field operates on a string defined as the '+' character, followed by a sequence of digit characters. This flag is redundant for E2U NAPTRs, as it does not act on the Repl sub-field contents.
不区分大小写标志（'i'）可以添加到Regexp字段的末尾。但是，在ENUM中，ERE子字段对定义为“+”字符的字符串进行操作，后跟一系列数字字符。该标志对于E2U NAPTRs是多余的，因为它不作用于Repl子字段内容。
Thus, the case-sensitivity flag is inappropriate for ENUM, and SHOULD NOT be provisioned into E2U NAPTRs.
因此，区分大小写标志不适用于ENUM，不应提供给E2U NAPTRs。
It is not possible to select a delimiter character that cannot appear in one of the sub-fields. The '!' character is used as a delimiter in all of the examples in [RFC3403] and in [RFC3761]. It is the only character seen in existing zones, and a number of different client implementations are still "hardwired" to expect this character as a delimiter.
无法选择不能出现在其中一个子字段中的分隔符。“！”在[RFC3403]和[RFC3761]中的所有示例中，字符用作分隔符。它是在现有区域中看到的唯一字符，许多不同的客户端实现仍然“硬连线”期望将此字符作为分隔符。
The '!' character will not normally appear in the ERE sub-field. It may appear in the content of some URIs, as it is a valid character (e.g., in http URLs). If it is present in the Regexp field, then that instance MUST be escaped using the standard technique proposed in Section 3.2 of [RFC3402]: a backslash character (U+005C) should be inserted before it in the string. Otherwise, a client may attempt to process this as a standard delimiter and interpret the Regexp field contents differently from the system that provisioned it.
“！”字符通常不会出现在ERE子字段中。它可能出现在某些URI的内容中，因为它是一个有效字符（例如，在http URL中）。如果该实例存在于Regexp字段中，则必须使用[RFC3402]第3.2节中建议的标准技术对该实例进行转义：应在该实例之前插入反斜杠字符（U+005C）到字符串中。否则，客户端可能会尝试将其作为标准分隔符进行处理，并以不同于设置它的系统的方式解释Regexp字段内容。
In ENUM, the ERE sub-field may include a literal character '+', as the Application Unique String on which it operates includes this. However, if it is present, then '+' MUST be escaped using a single backslash character (to produce the sub-string U+005C U+002B), as '+' is a meta-character in POSIX Extended Regular Expression syntax.
在ENUM中，ERE子字段可能包含一个文字字符“+”，因为它操作的应用程序唯一字符串包含这个字符。但是，如果存在，则必须使用单个反斜杠字符对“+”进行转义（以生成子字符串U+005C U+002B），因为“+”是POSIX扩展正则表达式语法中的元字符。
Not escaping the '+' character produces an invalid ERE, but is a common mistake. Even standards have given incorrect examples; the obsolete [RFC2916] (Section 3.4.3, example 3) has this problem.
不转义“+”字符会产生无效的ERE，但这是一个常见错误。即使是标准也给出了错误的例子；过时的[RFC2916]（第3.4.3节，示例3）存在此问题。
For example, the following NAPTR example is incorrect: * IN NAPTR 100 10 "u" "E2U+sip" "!^+4655(.*)$!sip:\\1@example.net!" .
例如，以下NAPTR示例不正确：*在NAPTR 100 10“u”E2U+sip“！^+4655（.*）！sip中：\\1@example.net!" .
A correct way to write this example is: * IN NAPTR 100 10 "u" "E2U+sip" "!^\\+4655(.*)$!sip:\\1@example.net!" .
编写此示例的正确方法是：*在NAPTR 100 10“u”E2U+sip“！^\\+4655（.*）！sip中：\\1@example.net!" .
Note that when a NAPTR resource record is shown in DNS master file syntax (as in this example above), the backslash itself must be escaped using a second backslash. The DNS on-the-wire packet will have only a single backslash.
请注意，当NAPTR资源记录以DNS主文件语法显示时（如上例所示），反斜杠本身必须使用第二个反斜杠转义。有线数据包上的DNS将只有一个反斜杠。
An ENUM client MAY discard a NAPTR received in response to an ENUM query because:
枚举客户端可能会放弃响应枚举查询而接收的NAPTR，因为：
o the NAPTR is syntactically or semantically incorrect,
o NAPTR在语法或语义上不正确，
o the NAPTR has a different (non-empty) DDDS Application identifier from the 'E2U' used in ENUM,
o NAPTR的DDDS应用程序标识符与ENUM中使用的“E2U”不同（非空），
o the NAPTR's ERE does not match the Application Unique String for this ENUM query,
o NAPTR的ERE与此枚举查询的应用程序唯一字符串不匹配，
o the ENUM client does not recognise any Enumservice held in this NAPTR, or
o ENUM客户端无法识别此NAPTR中持有的任何Enumservice，或
o this NAPTR (only) contains an Enumservice that is unsupported.
o 此NAPTR（仅限）包含不受支持的枚举服务。
These conditions SHOULD NOT cause the whole ENUM query to terminate, and processing SHOULD continue with the next NAPTR in the returned Resource Record Set (RRSet).
这些条件不应导致整个枚举查询终止，处理应继续处理返回的资源记录集（RRSet）中的下一个NAPTR。
When an ENUM client encounters a compound NAPTR (i.e., one containing more than one Enumservice -- see also Section 4.4.1) and cannot process or cannot recognise one of the Enumservices within it, that ENUM client SHOULD ignore this Enumservice and continue with the next Enumservice within this NAPTR's Services field, discarding the NAPTR only if it cannot handle any of the Enumservices contained. These conditions SHOULD NOT be considered errors.
当ENUM客户端遇到复合NAPTR（即包含多个Enumservice的NAPTR，另请参见第4.4.1节）且无法处理或无法识别其中的一个Enumservice时，该ENUM客户端应忽略此Enumservice并继续使用此NAPTR的Services字段中的下一个Enumservice，仅当NAPTR无法处理包含的任何枚举服务时，才会丢弃该NAPTR。这些条件不应视为错误。
ENUM uses regular-expression processing when generating URIs from the Regexp field of "terminal" NAPTRs. Just as with all uses of regular expressions, there is a potential for buffer overrun when generating this output. There may be repeated back-reference patterns in a NAPTR's Repl sub-field, and the output these generate may consume a considerable amount of buffer space.
从“terminal”NAPTRs的Regexp字段生成URI时，ENUM使用正则表达式处理。正如正则表达式的所有用途一样，在生成此输出时，存在缓冲区溢出的可能性。NAPTR的Repl子字段中可能存在重复的反向引用模式，这些模式生成的输出可能会消耗大量的缓冲区空间。
Even if an ENUM client would normally encounter only NAPTRs with short URIs, it may also receive NAPTRs with repeated back-reference patterns in their Repl sub-fields that could generate strings longer than the client's buffer. Such NAPTRs may have been misconfigured accidentally or by design. The client MUST NOT fail in this case. It SHOULD NOT discard the entire ENUM query, but instead just discard the NAPTR that would otherwise have caused this overrun.
即使枚举客户机通常只会遇到URI较短的NAPTR，它也可能会在其Repl子字段中接收具有重复反向引用模式的NAPTR，这些模式可能会生成比客户机缓冲区更长的字符串。此类NAPTR可能是意外或设计错误配置的。在这种情况下，客户端不能失败。它不应该丢弃整个枚举查询，而应该丢弃可能导致此溢出的NAPTR。
If a problem is detected when processing an ENUM query across multiple domains (by following non-terminal NAPTR references), then the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD continue at the next NAPTR after the non-terminal NAPTR that referred to the domain in which the problem would have occurred. See Section 5.2.2 for more details.
如果在跨多个域处理枚举查询时（通过遵循非终端NAPTR引用）检测到问题，则不应放弃枚举查询，而是应在引用可能发生问题的域的非终端NAPTR之后的下一个NAPTR继续处理。详见第5.2.2节。
Through monitoring current ENUM clients, a number of non-compliant behaviours have been detected. These behaviours are incorrect, but may be encountered in still-operational client implementations.
通过监视当前的ENUM客户端，发现了许多不符合要求的行为。这些行为是不正确的，但在仍在运行的客户端实现中可能会遇到。
ENUM clients have been known to discard NAPTRs in which the Services field holds more than one Enumservice.
众所周知，枚举客户端会丢弃服务字段中包含多个枚举服务的NAPTR。
ENUM clients have also been known to discard NAPTRs with a "non-greedy" ERE sub-field expression (i.e., EREs that are dissimilar to "^.*$").
众所周知，ENUM客户机也会丢弃带有“非贪婪”ERE子字段表达式的NAPTR（即与“^.*$”不同的ERE）。
ENUM clients have been known to discard NAPTRs that do not use '!' as their Regexp delimiter character.
已知枚举客户端会丢弃不使用“！”的NAPTR作为它们的Regexp分隔符。
ENUM clients have been known to discard NAPTRs in which the delimiter is NOT the last character in the Regexp field.
已知枚举客户机会丢弃分隔符不是Regexp字段中最后一个字符的NAPTR。
ENUM clients have been known to discard NAPTRs with an empty Flags field (i.e., "non-terminal" NAPTRs).
众所周知，枚举客户端会丢弃带有空标志字段的NAPTR（即“非终端”NAPTR）。
ENUM clients have been known to ignore the ORDER field value entirely, sorting the NAPTRs in an RRSet based solely on the PREFERENCE/PRIORITY field values.
众所周知，ENUM客户端完全忽略ORDER字段值，仅根据PREFERENCE/PRIORITY字段值在RRSet中对naptr进行排序。
Finally, many ENUM clients have been known to discard a NAPTR where they have local knowledge that the URI that would be generated by processing the NAPTR is unusable. This behaviour is, strictly speaking, non-compliant, but might be considered reasonable (see Section 4.1).
最后，许多ENUM客户机已知会丢弃NAPTR，因为它们在本地知道通过处理NAPTR生成的URI不可用。严格来说，这种行为是不合规的，但可能被认为是合理的（见第4.1节）。
ENUM is a DDDS Application, and the way in which NAPTRs in an RRSet are processed reflects this. The details are described in Section 3.3 of [RFC3402]. The client is expected to sort the records it receives into a sequence and then process those records in that sequence. The sequence reflects the ORDER and PREFERENCE/PRIORITY field values in each of the NAPTRs.
ENUM是一个DDDS应用程序，RRSet中NAPTR的处理方式反映了这一点。详情见[RFC3402]第3.3节。客户机需要将收到的记录按顺序排序，然后按顺序处理这些记录。序列反映每个NAPTR中的顺序和首选项/优先级字段值。
The ORDER field value is the major, or most significant, sort term and the PREFERENCE/PRIORITY field value is the minor, or least significant, sort term. The combination of ORDER and PREFERENCE/ PRIORITY field values indicates the sequence chosen by the publisher of this data, and NAPTRs will be considered in this sequence.
顺序字段值是主要或最重要的排序项，首选项/优先级字段值是次要或最不重要的排序项。“顺序”和“首选项/优先级”字段值的组合表示发布者选择的该数据的顺序，在此顺序中将考虑NAPTR。
Once the NAPTRs are sorted into sequence, further processing is done to determine if each of the NAPTRs is appropriate for this ENUM evaluation. This involves looking at the Flags field. If the Flags field is empty, this is a "non-terminal" NAPTR and is processed as described in Section 5.
将NAPTR按顺序排序后，将进行进一步处理，以确定每个NAPTR是否适合此枚举计算。这涉及到查看Flags字段。如果标志字段为空，则这是一个“非终端”NAPTR，并按照第5节所述进行处理。
If the "u" Flag is present (and so the NAPTR is a "terminal" rule that generates a URI), the Services field is checked to ensure that this NAPTR is intended for ENUM (i.e., that this NAPTR includes the "E2U" DDDS Application identifier in the Services field). The ERE in the Regexp field is checked and must match the Application Unique String (AUS) for this ENUM evaluation (the queried telephone number). Unless each of these checks succeeds, the NAPTR is discarded and the next in sequence is processed.
如果存在“u”标志（因此NAPTR是生成URI的“终端”规则），则检查服务字段以确保此NAPTR用于ENUM（即，此NAPTR在服务字段中包括“E2U”DDDS应用程序标识符）。已选中Regexp字段中的ERE，并且必须与此枚举计算的应用程序唯一字符串（AUS）匹配（查询的电话号码）。除非每个检查都成功，否则将丢弃NAPTR，并处理序列中的下一个。
During this processing, clients will also consider the Enumservices within the Services field. Enumservices indicate the kind of interaction that can be achieved through use of the URI this NAPTR generates. If there is local knowledge that a NAPTR includes only an Enumservice that is either not supported or not recognised, then this
在此处理过程中，客户端还将考虑服务字段中的枚举服务。Enumservices表示通过使用NAPTR生成的URI可以实现的交互类型。如果本地知道NAPTR仅包括不受支持或不被识别的Enumservice，则
NAPTR can be discarded and the next in sequence will be processed. Thus, for a system that has support only for SIP interactions, if it receives an RRSet in which the "best" NAPTR indicates the H323 Enumservice, then that client could reasonably discard that NAPTR and go on to the next in sequence.
可以丢弃NAPTR，并处理序列中的下一个。因此，对于仅支持SIP交互的系统，如果它接收到一个RRSet，其中“最佳”NAPTR指示H323 Enumservice，则该客户机可以合理地丢弃该NAPTR并按顺序继续下一个NAPTR。
The processing of ORDER and PREFERENCE/PRIORITY fields has been a significant source of confusion, and many ENUM clients do not implement the processing exactly as specified.
顺序和首选项/优先级字段的处理一直是造成混淆的一个重要原因，许多枚举客户端没有完全按照指定的方式实现处理。
In particular, many ENUM clients use local prior knowledge about URIs during ENUM processing. If a client has prior knowledge that a particular URI will not result in an acceptable outcome, it might discard that NAPTR and consider the next one in the sequence. Examples of such local prior knowledge include: the URI does not resolve, authentication has been recently rejected, or user policies mark a particular URI as unacceptable (the URI could be a "premium rate" telephone number that would be charged at an unacceptable rate).
特别是，许多枚举客户机在枚举处理期间使用有关URI的本地先验知识。如果客户端事先知道某个URI将不会得到可接受的结果，它可能会丢弃NAPTR并考虑序列中的下一个。此类本地先验知识的示例包括：URI未解析、身份验证最近已被拒绝，或者用户策略将特定URI标记为不可接受（URI可能是以不可接受的费率收费的“溢价”电话号码）。
Strictly speaking, this behaviour is non-compliant if the next NAPTR record has a different ORDER value. The ENUM algorithm (Section 3.3 of [RFC3402] and Section 4.1 of [RFC3403]) states that once a match has been found for the Application Unique String (AUS), and the service description satisfies the client's requirements, NAPTR records with larger ORDER values must not be considered (but other NAPTR records with the same ORDER value can still be considered).
严格来说，如果下一条NAPTR记录具有不同的订单值，则此行为是不符合的。枚举算法（RFC3402第3.3节和RFC3403第4.1节）规定，一旦找到应用程序唯一字符串（AUS）的匹配项，且服务描述满足客户要求，则不得考虑订单值较大的NAPTR记录（但仍可以考虑具有相同订单值的其他NAPTR记录）。
However, embedding local knowledge about the URI within the ENUM evaluation process is almost universal in systems employing ENUM. Also, since the difference between ORDER and PRIORITY/PREFERENCE has been unclear, NAPTR records have been provisioned in ways that would make strictly compliant systems unusable in practice. Given that such systems are intended to provide communications, this non-compliant, "embedded decision" behaviour is understandable.
然而，在使用ENUM的系统中，在ENUM评估过程中嵌入关于URI的本地知识几乎是通用的。此外，由于顺序和优先权/优先权之间的差异尚不清楚，NAPTR记录的提供方式将使严格遵守的系统在实践中无法使用。鉴于此类系统旨在提供通信，这种不合规的“嵌入式决策”行为是可以理解的。
It is proposed that when the ENUM specification is updated, processing of ORDER and PRIORITY/PREFERENCE should be updated based on implementation and deployment experiences described in this document.
建议在更新ENUM规范时，应根据本文档中描述的实施和部署经验更新顺序和优先级/首选项的处理。
The example in this section is intended to further understanding about the difference between what [RFC3402] and [RFC3403] specify and what existing ENUM clients do.
本节中的示例旨在进一步了解[RFC3402]和[RFC3403]指定的内容与现有ENUM客户端所做的工作之间的区别。
WARNING: The NAPTR records shown in this section are intended to illustrate somewhat unclear corner cases, and are not intended as good examples of how to do ENUM provisioning.
警告：本节中显示的NAPTR记录旨在说明一些不明确的情况，而不是如何进行枚举资源调配的好例子。
Consider the following RRset, which maps numbers in the UK drama range to one server, and all other numbers to a second server: * 3600 IN NAPTR 1 1 "u" "e2u+sip" "!^(\\+441632960.*)$!sips:\\1@atlanta.example.com!" . * 3600 IN NAPTR 2 1 "u" "e2u+sip" "!^(.*)$!sip:\\1@biloxi.example.com!" .
考虑下面的RRSET，它将英国戏剧范围中的数字映射到一个服务器，并将所有其他数字映射到第二服务器：在NAPTR 1“1”U“E2U+SIP”“^ ^（\+441632960＊）$ $！SIPS：* 3600）：1@atlanta.example.com!" . * 3600英寸NAPTR 2 1“u”e2u+sip“！^（.*）！sip:\\1@biloxi.example.com!" .
According to the processing specified in [RFC3402] and [RFC3403], the ENUM client is never intended to consider the second rule for e.g., AUS "+441632960123", even if it does not support "sips" URIs, or the atlanta.example.com server cannot be reached, or the user indicates he or she doesn't wish to contact atlanta.example.com. However, existing ENUM implementations are known to do this, and as described above, it can be useful if the alternative is failing to communicate at all.
根据[RCF3402]和[RCF3403]中指定的处理，EnUM客户端从不打算考虑第二规则，例如，AUS“+ 441632960123”，即使它不支持“SIPS”URI，也不能到达AtalTA.ExpPule.com服务器，或者用户表示他或她不希望联系Atalth.ExpLo.com。但是，已知现有的枚举实现可以做到这一点，如上所述，如果替代方案根本无法通信，那么它可能会很有用。
To prevent a client from considering the second rule for the UK drama range, the example could be rewritten to have more predictable behaviour as follows: * 3600 IN NAPTR 1 1 "u" "e2u+sip" "!^(\\+441632960.*)$!sips:\\1@atlanta.example.com!" . * 3600 IN NAPTR 2 1 "u" "e2u+sip" "!^(\\+[^4].*|\\+4[^4].*|\\+44[^1].*|\\+441[^6].*|\\+4416[^3].*| \\+44163[^2].*|\\+441632[^9].*|\\+4416329[^6].*| \\+44163296[^0].*)$!sip:\\1@biloxi.example.com!" .
为了防止客户考虑英国戏剧系列的第二条规则，可以将示例改写为具有更可预测的行为，如下所示：*3600 IN NAPTR 1 1“u”e2u+sip“！^（\\+441632960.*）$！sips:\\1@atlanta.example.com!" . * 3600英寸NAPTR 2 1“u”“e2u+sip”！^（\+[^4].\+4[^4].\\+44[^1].\\+441[^6].\\+4416[^3].\\+44163[^2].\\+441632[^9].\+4416329[^6].\+44163296[^0].$！sip:\\1@biloxi.example.com!" .
[RFC3761] and [RFC3403] state that the ENUM client MUST sort the NAPTRs using the ORDER field value ("lowest value is first") and SHOULD order the NAPTRs using the PREFERENCE/PRIORITY field value as the minor sort term (again, lowest value first). The NAPTRs in the sorted list must be processed in order. Subsequent NAPTRs with worse ORDER values must only be dealt with once the current ones with a better ORDER value have been processed.
[RFC3761]和[RFC3403]指出，枚举客户端必须使用排序字段值（“最低值为第一”）对NAPTR进行排序，并应使用首选项/优先级字段值作为次要排序项（同样，最低值为第一）对NAPTR进行排序。必须按顺序处理已排序列表中的NAPTR。只有在处理了具有较好顺序值的当前NAPTR后，才能处理具有较差顺序值的后续NAPTR。
However, as described in the introduction to this section, this stated behaviour is a simplification. Once sorted into a sequence reflecting ORDER and PREFERENCE/PRIORITY values, other fields are also considered during evaluation of retrieved NAPTRs; local knowledge may play a factor in the decision process, once a NAPTR has reached that point in the sequence at which it is considered.
然而，如本节导言所述，上述行为是一种简化。一旦排序为反映顺序和首选项/优先级值的序列，在评估检索到的NAPTR时也会考虑其他字段；一旦NAPTR达到考虑顺序中的某一点，本地知识可能会在决策过程中发挥作用。
ENUM clients may also include the end user "in the decision loop", offering the end user the choice from a list of possible NAPTRs. Conceptually this choice is embedded within step 4 of the DDDS algorithm (as described in Section 3.3 of [RFC3402]). Given that the ORDER field value is the major sort term, one would expect a conforming ENUM client to present only those NAPTRs with the currently "best" ORDER field value as choices. When/if all the presented options had been rejected, then the ENUM client might offer those with the "next best" ORDER field value, and so on. As this may be confusing for the end user, some clients simply offer all of the available NAPTRs as options to the end user for his or her selection at once, in the sequence defined by the ORDER and PREFERENCE/PRIORITY fields.
ENUM客户端还可以将最终用户包括在“决策循环”中，让最终用户从可能的NAPTR列表中进行选择。从概念上讲，该选择嵌入在DDDS算法的步骤4中（如[RFC3402]第3.3节所述）。考虑到订单字段值是主要的排序术语，人们期望一致的ENUM客户机只提供那些具有当前“最佳”订单字段值的NAPTR作为选项。当/如果所有呈现的选项都被拒绝，则枚举客户端可能会提供具有“次优”顺序字段值的选项，依此类推。由于这可能会让最终用户感到困惑，一些客户端只是按照顺序和首选项/优先级字段定义的顺序，将所有可用的NAPTR作为选项一次提供给最终用户供其选择。
In summary, ENUM clients will take into account the Services field value, the Flags field, and the Regexp ERE sub-field, along with the ORDER and PREFERENCE/PRIORITY field values, and may consider local policies or available local knowledge.
总之，EnUM客户端将考虑服务字段值、标志字段和ReGEXP ELE子字段，以及顺序和优先级/优先级字段值，并且可以考虑本地策略或可用的本地知识。
The Registrant and the ENUM zone provisioning system he or she uses must be aware of this and SHOULD NOT rely on ENUM clients solely taking account of the value of the ORDER and the PREFERENCE/PRIORITY fields alone.
注册人和他或她使用的枚举区域设置系统必须了解这一点，并且不应仅依赖于枚举客户端（仅考虑订单值和首选项/优先级字段）。
Specifically, it is unsafe to assume that an ENUM client will not consider another NAPTR if there is one with a better ORDER value. The instructions in Section 4.1 and Section 8 of [RFC3403] may or may not be followed strictly by different ENUM clients for perfectly justifiable reasons.
具体来说，假设EnUM客户机如果有更好的订单值，则不考虑另一个NAPTR是不安全的。[RFC3403]第4.1节和第8节中的说明可能会，也可能不会因完全合理的原因被不同的ENUM客户端严格遵守。
Where the ENUM client presents a list of possible URLs to the end user for his or her choice, it MUST do so in the sequence defined by the ORDER and PREFERENCE/PRIORITY values specified by the Registrant.
当ENUM客户端向最终用户提供可能的URL列表供其选择时，它必须按照注册人指定的顺序和首选项/优先级值定义的顺序进行。
However, a Registrant SHOULD place into his or her zone only contacts that he or she is willing to support; even those with the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an end user.
但是，注册人应只在其区域中放置他或她愿意支持的联系人；最终用户甚至可以选择具有最差顺序和首选项/优先级值的那些。
NAPTRs in ENUM zones that hold incorrect ORDER values can cause major problems. [RFC3403] highlights that having both ORDER and PREFERENCE/PRIORITY fields is a historical artifact of the NAPTR resource record type. It is reasonable to have a common default value for the ORDER field, relying on the PREFERENCE/PRIORITY field to indicate the preferred sort.
枚举区域中的NAPTR包含不正确的顺序值可能会导致重大问题。[RFC3403]强调同时具有顺序和首选项/优先级字段是NAPTR资源记录类型的历史工件。订单字段有一个通用的默认值是合理的，依赖于首选项/优先级字段来指示首选排序。
We have noticed a number of ENUM domains with NAPTRs that have identical PREFERENCE/PRIORITY field values and different ORDER values. This may be the result of an ENUM zone provisioning system "bug" or a misunderstanding over the uses of the two fields, or simply a difference of interpretation of the standards.
我们注意到许多具有NAPTR的枚举域具有相同的首选项/优先级字段值和不同的顺序值。这可能是由于枚举区域设置系统“bug”或对这两个字段的使用存在误解，或者仅仅是标准的解释不同造成的。
To clarify, the ORDER field value is the major sort term, and the PREFERENCE/PRIORITY field value is the minor sort term. Thus, one should expect to have a set of NAPTRs in a zone with identical ORDER field values and different PREFERENCE/PRIORITY field values; not the other way around.
为了澄清，顺序字段值是主要排序项，首选项/优先级字段值是次要排序项。因此，人们应该期望在具有相同顺序字段值和不同首选项/优先级字段值的区域中有一组NAPTR；而不是相反。
To avoid these common interoperability issues, it is recommended that ENUM NAPTRs SHOULD hold a default value in their ORDER field.
为了避免这些常见的互操作性问题，建议枚举NAPTR在其顺序字段中保留默认值。
From experience, it has been learned that there are zones that hold discrete NAPTRs with identical ORDER and identical PREFERENCE/ PRIORITY field values. This will lead to indeterminate client behaviour and so SHOULD NOT normally occur.
从经验中可以看出，有些区域包含具有相同顺序和相同首选项/优先级字段值的离散NAPTR。这将导致不确定的客户行为，因此通常不会发生。
Such a condition indicates that these NAPTRs are truly identical in priority and that there is no preference between the services these NAPTRs offer. Implementers SHOULD NOT assume that the DNS will deliver NAPTRs within an RRSet in a particular sequence.
这种情况表明这些NAPTR在优先级上完全相同，并且这些NAPTR提供的服务之间没有优先权。实施者不应假设DNS将以特定顺序在RRSet内交付NAPTR。
Multiple NAPTRs with identical ORDER and identical PREFERENCE/ PRIORITY field values SHOULD NOT be provisioned into an RRSet unless the intent is that these NAPTRs are truly identical in priority and there is no preference between them.
不应将具有相同顺序和相同首选项/优先级字段值的多个NAPTR设置到RRSet中，除非目的是这些NAPTR的优先级完全相同，并且它们之间没有首选项。
Some ENUM client implementations have considered this case to be an error and have rejected such duplicates entirely. Others have attempted to further randomise the order in which such duplicates are processed. Thus, use of such duplicate NAPTRs is unwise, as client implementations exist that will behave in different ways.
一些ENUM客户机实现已将此情况视为错误，并已完全拒绝此类重复。其他人则试图进一步随机处理这些复制品的顺序。因此，使用这种重复的NAPTR是不明智的，因为存在以不同方式运行的客户端实现。
With [RFC3761], it is possible to have more than one Enumservice associated with a single NAPTR. These Enumservices share the same Regexp field and so generate the same URI. Such a "compound" NAPTR could well be used to indicate a mobile phone that supports both "voice:tel" and "sms:tel" Enumservices. The Services field in that case would be "E2U+voice:tel+sms:tel".
使用[RFC3761]，可以将多个Enumservice与单个NAPTR关联。这些Enumservices共享相同的Regexp字段，因此生成相同的URI。这种“复合”NAPTR可以很好地用于表示同时支持“语音：电话”和“短信：电话”服务的移动电话。在这种情况下，服务字段将是“E2U+语音：电话+短信：电话”。
A compound NAPTR can be treated as a set of NAPTRs that each hold a single Enumservice. These reconstructed NAPTRs share the same ORDER and PREFERENCE/PRIORITY field values but should be treated as if each had a logically different priority. In this case, the reconstructed NAPTR holding the leftmost Enumservice within the compound NAPTR has the best priority, and the reconstructed NAPTR holding the rightmost Enumservice has the worst priority in this set.
复合NAPTR可以被视为一组NAPTR，每个NAPTR都包含一个枚举服务。这些重构的NAPTR共享相同的顺序和首选项/优先级字段值，但应将其视为具有逻辑上不同的优先级。在这种情况下，在复合NAPTR中持有最左侧Enumservice的重构NAPTR具有最佳优先级，持有最右侧Enumservice的重构NAPTR具有该集合中最差的优先级。
To avoid indeterminate behaviour, it is recommended that ENUM clients SHOULD process the Enumservices within a compound NAPTR in a left-to-right sequence. ENUM provisioning systems SHOULD assume that such a processing order will be used and provision the Enumservices within a compound NAPTR accordingly.
为了避免不确定行为，建议枚举客户端以从左到右的顺序处理复合NAPTR中的枚举服务。枚举供应系统应假设将使用这样的处理顺序，并相应地在复合NAPTR中供应枚举服务。
Using a different ORDER field value in different domains is unimportant for most queries. However, DDDS includes a mechanism for continuing a search for NAPTRs in another domain by including a reference to that other domain in a "non-terminal" NAPTR. The treatment of non-terminal NAPTRs is covered in the next section. If they are supported, then the way that ORDER and PREFERENCE/PRIORITY field values are processed is affected.
对于大多数查询来说，在不同的域中使用不同的ORDER字段值并不重要。然而，DDDS包括通过在“非终端”NAPTR中包括对该另一域的引用来继续在另一域中搜索NAPTR的机制。下一节将介绍非终末NAPTR的处理。如果支持它们，则顺序和首选项/优先级字段值的处理方式将受到影响。
Two main questions remain from the specifications of DDDS and [RFC3761]:
DDDS和[RFC3761]的规范仍存在两个主要问题：
o If there is a different (lower) ORDER field value in a domain referred to by a non-terminal NAPTR, then does this mean that the ENUM client discards any remaining NAPTRs in the referring RRSet?
o 如果非终端NAPTR引用的域中存在不同（较低）顺序的字段值，那么这是否意味着枚举客户端将丢弃引用的RRSet中的任何剩余NAPTR？
o Conversely, if the domain referred to by a non-terminal NAPTR contains entries that only have a higher ORDER field value, then does the ENUM client ignore those NAPTRs in the referenced domain?
o 相反，如果非终端NAPTR引用的域包含仅具有高阶字段值的条目，则枚举客户端是否会忽略引用域中的那些NAPTR？
Whilst one interpretation of [RFC3761] is that the answer to both questions is "yes", this is not the way that those examples of non-terminal NAPTRs that do exist (and those ENUM clients that support them) seem to be designed.
虽然[RFC3761]的一种解释是，两个问题的答案都是“是”，但这并不是那些确实存在的非终端NAPTR示例（以及支持它们的ENUM客户端）的设计方式。
In keeping with the interpretation made so far, ENUM implementations MUST consider the ORDER and PREFERENCE/PRIORITY values only within the context of the domain currently being processed in an ENUM query. These values MUST be discarded when processing other RRSets in the query.
与迄今为止的解释一致，EnUM实现必须仅在EnUM查询中当前正在处理的域的上下文中考虑顺序和优先级/优先级值。在处理查询中的其他RRSET时，必须丢弃这些值。
Consider an ENUM RRSet that contains a non-terminal NAPTR record. This non-terminal NAPTR holds, as its target, another domain that has a set of NAPTRs. In effect, this is similar to the non-terminal NAPTR being replaced by the NAPTRs contained in the domain to which it points.
考虑包含非终结性NAPTR记录的枚举RRSET。此非终端NAPTR将另一个具有一组NAPTR的域作为其目标。实际上，这类似于非终端NAPTR被它所指向的域中包含的NAPTR替换。
It is possible to have a non-terminal NAPTR in a domain that is, itself, pointed to by another non-terminal NAPTR. Thus, a set of domains forms a "chain", and the list of NAPTRs to be considered is the set of all NAPTRs contained in all of the domains in that chain.
在由另一个非终端NAPTR指向的域中，可以有一个非终端NAPTR。因此，一组域形成一个“链”，要考虑的NAPTR列表是该链中所有域中包含的所有NAPTR的集合。
For an ENUM management system to support non-terminal NAPTRs, it is necessary for it to be able to analyse, validate, and (where needed) correct not only the NAPTRs in its current ENUM domain but also those referenced by non-terminal NAPTRs in other domains. If the domains pointed to have non-terminal NAPTRs of their own, the management system will have to check each of the referenced domains in turn, as their contents form part of the result of a query on the "main" ENUM domain. The domain content in the referenced domains may well not be under the control of the ENUM management system, and so it may not be possible to correct any errors in those RRSets. This is both complex and prone to error in the management system design, and any reported errors in validation may well be non-intuitive for users.
对于支持非终端NAPTR的枚举管理系统，不仅需要能够分析、验证和（必要时）纠正其当前枚举域中的NAPTR，还需要能够分析、验证和纠正其他域中非终端NAPTR引用的NAPTR。如果指向的域具有自己的非终端NAPTR，则管理系统必须依次检查每个引用域，因为它们的内容构成对“主”枚举域的查询结果的一部分。引用域中的域内容可能不受枚举管理系统的控制，因此可能无法更正这些RRSET中的任何错误。这既复杂又容易在管理系统设计中出错，而且任何报告的验证错误对于用户来说都可能是不直观的。
For an ENUM client, supporting non-terminal NAPTRs can also be difficult. Processing non-terminal NAPTRs causes a set of sequential DNS queries that can take an indeterminate time, and requires extra resources and complexity to handle fault conditions like non-terminal loops. The indeterminacy of response time makes ENUM-supported Telephony Applications difficult (such as in an "ENUM-aware" Private Branch Exchange (PBX)), whilst the added complexity and resources needed makes support problematic in embedded devices like "ENUM-aware" mobile phones.
对于ENUM客户端，支持非终端NAPTR也可能很困难。处理非终端NAPTR会导致一组顺序DNS查询，这些查询可能需要不确定的时间，并且需要额外的资源和复杂性来处理非终端循环等故障条件。响应时间的不确定性使得ENUM支持的电话应用程序很困难（例如在“ENUM感知”专用分支交换机（PBX）中），而所需的额外复杂性和资源使得在“ENUM感知”移动电话等嵌入式设备中的支持成问题。
Given that, in principle, a non-terminal NAPTR can be replaced by the NAPTRs in the domain to which it points, support of non-terminal NAPTRs is not needed and non-terminal NAPTRs may not be useful. Furthermore, some existing ENUM clients do not support non-terminal NAPTRs and ignore them if received.
考虑到原则上非终端NAPTR可以被其所指向域中的NAPTR替换，因此不需要对非终端NAPTR的支持，非终端NAPTR可能没有用处。此外，一些现有的ENUM客户端不支持非终端NAPTR，并且在收到时忽略它们。
To avoid interoperability problems, some kind of acceptable advice is needed on non-terminal NAPTRs. As current support is limited, non-terminal NAPTRs SHOULD NOT be used in ENUM unless it is clear that all of the ENUM clients this environment supports can process these.
为了避免互操作性问题，需要对非终端NAPTR提供某种可接受的建议。由于当前的支持有限，不应在ENUM中使用非终端NAPTR，除非很清楚此环境支持的所有ENUM客户端都可以处理这些NAPTR。
The following specific issues need to be considered if non-terminal NAPTRs are to be supported in a particular environment. These issues are gleaned from experience and indicate the kinds of conditions that should be considered before support for non-terminal NAPTRs is contemplated. Note that these issues are in addition to the point just mentioned on ENUM provisioning or management system complexity and the potential for that management system to have no control over the zone contents to which non-terminal NAPTRs in its managed zones refer.
如果要在特定环境中支持非终端NAPTR，则需要考虑以下具体问题。这些问题是从经验中收集的，并指出了在考虑支持非终端NAPTR之前应考虑的各种条件。请注意，这些问题是对刚才提到的枚举供应或管理系统复杂性以及该管理系统可能无法控制其管理区域中的非终端NAPTR所引用的区域内容的补充。
As mentioned earlier, a non-terminal NAPTR in one RRSet refers to the NAPTRs contained in another domain. The NAPTRs in the domain referred to by the non-terminal NAPTR may have a different ORDER value from that in the referring non-terminal NAPTR. See Section 4.5 for details.
如前所述，一个RRSet中的非终端NAPTR指的是另一个域中包含的NAPTR。非终端NAPTR引用的域中的NAPTR可能与引用的非终端NAPTR中的NAPTR具有不同的顺序值。详见第4.5节。
Where a chain of non-terminal NAPTRs refers back to a domain already traversed in the current query, a "non-terminal" or referential loop is implied. An implementation MAY treat a chain of more than 5 domains traversed during a single ENUM query as an indication that a self-referential loop has been entered.
如果非终端NAPTR链引用回当前查询中已遍历的域，则暗示“非终端”或引用循环。实现可以将单个枚举查询期间遍历的超过5个域的链视为已进入自引用循环的指示。
There are many techniques that can be used to detect such a loop, but the simple approach of counting the number of domains queried in the current ENUM query suffices.
有许多技术可以用来检测这样的循环，但是计算当前枚举查询中查询的域数的简单方法就足够了。
Where a loop has been detected, processing SHOULD continue at the next NAPTR in the referring domain (i.e., after the non-terminal NAPTR that included the reference that triggered the loop detection).
如果检测到循环，则应在引用域中的下一个NAPTR处继续处理（即，在包含触发循环检测的引用的非终端NAPTR之后）。
The set of specifications defining DDDS and its applications are complex and multi-layered. This reflects the flexibility that the system provides but does mean that some of the specifications need clarification as to their interpretation, particularly where non-terminal rules are concerned.
定义DDD及其应用程序的规范集是复杂和多层次的。这反映了系统提供的灵活性，但确实意味着一些规范需要澄清其解释，特别是在涉及非终端规则的情况下。
Section 2.4.1 of [RFC3761] states that the only flag character valid for use with the "E2U" DDDS Application is 'u'. The flag 'u' is defined (in Section 4.3 of [RFC3404]) thus: 'The "u" flag means that the output of the Rule is a URI'.
[RFC3761]第2.4.1节规定，与“E2U”DDDS应用程序一起使用的唯一有效标志字符为“u”。标志“u”的定义（见[RFC3404]第4.3节）如下：“u”标志表示规则的输出为URI”。
Section 2.4.1 of [RFC3761] also states that an empty Flags field indicates a non-terminal NAPTR. This is also the case for other DDDS Application specifications, such as that specified in [RFC3404]. One could well argue that this is a feature potentially common to all DDDS Applications, and so might have been specified in [RFC3402] or [RFC3403].
[RFC3761]第2.4.1节还规定，空标志字段表示非终端NAPTR。其他DDDS应用规范也是如此，如[RFC3404]中规定的规范。有人可能会争辩说，这是所有DDDS应用程序可能共有的特性，因此可能在[RFC3402]或[RFC3403]中指定。
The Flags field will be empty in non-terminal NAPTRs encountered in ENUM processing. ENUM does not have any other way to indicate a non-terminal NAPTR.
在枚举处理过程中遇到的非终端NAPTR中，“标志”字段将为空。ENUM没有任何其他方式来指示非终端NAPTR。
Furthermore, [RFC3761] states that any Enumservice Specification requires definition of the URI that is the expected output of this Enumservice. This means that, at present, there is no way to specify an Enumservice that is non-terminal; such a non-terminal NAPTR has, by definition, no URI as its expected output, instead returning a key (DNS domain name) that is to be used in the "next round" of DDDS processing.
此外，[RFC3761]指出，任何Enumservice规范都需要定义此Enumservice的预期输出URI。这意味着，目前无法指定非终端的Enumservice；根据定义，这种非终端NAPTR没有URI作为其预期输出，而是返回将在DDDS处理的“下一轮”中使用的密钥（DNS域名）。
This in turn means that a non-terminal NAPTR cannot hold a valid (non-empty) Services field when used in ENUM. Section 2.4.2 of [RFC3761] specifies the syntax for this field content and requires at least one element of type <servicespec> (i.e., at least one Enumservice identifier). Given that there cannot be a non-terminal Enumservice (and so no such Registered Enumservice identifier), this syntax cannot be met with a non-terminal NAPTR; there are no non-terminal Enumservices to put into this field.
这反过来意味着在枚举中使用时，非终端NAPTR不能保存有效（非空）服务字段。[RFC3761]第2.4.2节规定了此字段内容的语法，并要求至少有一个<servicespec>类型的元素（即至少一个Enumservice标识符）。假设不存在非终端Enumservice（因此没有此类注册的Enumservice标识符），则非终端NAPTR无法满足此语法；没有要放入此字段的非终端枚举服务。
A reasonable interpretation of the specifications is that for a non-terminal NAPTR, the Services field must also be empty. This appears to be the approach taken by those clients that do either process non-terminal NAPTRs or check the validity of the fields.
规范的合理解释是，对于非终端NAPTR，服务字段也必须为空。这似乎是那些处理非终端NAPTR或检查字段有效性的客户机所采用的方法。
It is expected that future revisions of the ENUM standard will clarify this text, making this interpretation plain. This was the intent of the current standard, and the intent will be made explicit in its revision.
预计ENUM标准的未来修订版将澄清该文本，使该解释变得简单明了。这是当前标准的意图，其修订版中将明确说明这一意图。
In keeping with existing implementations, in a non-terminal NAPTR encountered in an ENUM query, the Services field SHOULD be empty, and clients SHOULD ignore any content it contains.
与现有实现保持一致，在枚举查询中遇到的非终端NAPTR中，服务字段应为空，客户端应忽略其中包含的任何内容。
Of course, such non-terminal NAPTRs with an empty Services field are not specific to any DDDS Application. Thus, other means must be used to ensure a non-terminal NAPTR that is intended only for a particular DDDS Application cannot be encountered during a lookup for another DDDS Application (for example, by ensuring that the same domain is not used to host NAPTRs for more than one such DDDS Application).
当然，这种带有空服务字段的非终端NAPTR并不特定于任何DDDS应用程序。因此，必须使用其他方法来确保在查找另一个DDDS应用程序的过程中不会遇到仅用于特定DDDS应用程序的非终端NAPTR（例如，通过确保不使用同一域为多个此类DDDS应用程序托管NAPTR）。
5.2.3.3. Regular Expression and Replacement Field Content with Non-Terminal NAPTRs
5.2.3.3. 正则表达式和替换字段内容与非终端NAPTR
The descriptive text in Section 4.1 of [RFC3403] is intended to explain how the fields are to be used in a NAPTR. However, the descriptions associated with the Regexp and Replacement elements have led to some confusion over which of these should be considered when dealing with non-terminal NAPTRs.
[RFC3403]第4.1节中的描述性文本旨在解释NAPTR中如何使用字段。然而，与Regexp和Replacement元素相关的描述导致了一些混淆，即在处理非终端NAPTR时应该考虑哪些元素。
[RFC3403] is specific; these two elements are mutually exclusive. This means that if the Regexp element is not empty, then the Replacement element must be empty, and vice versa. However, [RFC3403] does not specify which is used with terminal and non-terminal rules.
[RFC3403]是具体的；这两个要素是相互排斥的。这意味着如果Regexp元素不是空的，那么替换元素必须是空的，反之亦然。但是，[RFC3403]未指定与终端和非终端规则一起使用的规则。
The descriptive text of Section 4.1 of [RFC3403] for the NAPTR Replacement element shows that this element holds an uncompressed domain name. Thus, it is clear that this element cannot be used to deliver the terminal string for any DDDS Application that does not have a domain name as its intended terminal output.
[RFC3403]第4.1节关于NAPTR替换元素的描述性文本显示，该元素拥有未压缩的域名。因此，很明显，该元素不能用于为任何没有域名作为其预期终端输出的DDDS应用程序传递终端字符串。
However, the first paragraph of descriptive text for the NAPTR Regexp element has led to some confusion. It appears that the Regexp element is to be used to find "the next domain name to lookup". This might be interpreted as meaning that a client program processing the DDDS Application could need to examine each non-terminal NAPTR to decide whether the Regexp element or instead the Replacement element should be used to construct the key (a domain name) to be used next in non-terminal rule processing.
但是，NAPTR Regexp元素的描述性文本的第一段导致了一些混乱。似乎要使用Regexp元素查找“下一个要查找的域名”。这可能被解释为，处理DDDS应用程序的客户端程序可能需要检查每个非终端NAPTR，以确定是使用Regexp元素还是替换元素来构造接下来在非终端规则处理中使用的密钥（域名）。
Given that a NAPTR holding a terminal rule (a "terminal NAPTR") must use the Substitution expression field to generate the expected output of that DDDS Application, the Regexp element is also used in such rules. Indeed, unless that DDDS Application has a domain name as its terminal output, the Regexp element is the only possibility.
假设持有终端规则（“终端NAPTR”）的NAPTR必须使用替换表达式字段来生成该DDDS应用程序的预期输出，则在此类规则中也会使用Regexp元素。事实上，除非DDDS应用程序有一个域名作为其终端输出，否则Regexp元素是唯一的可能。
Thus, from the descriptive text of this section, a Replacement element can be used only in NAPTRs holding a non-terminal rule (a "non-terminal NAPTR") unless that DDDS Application has a domain name as its terminal output, whilst the alternative Regexp element may be used either to generate a domain name as the next key to be used in the non-terminal case or to generate the output of the DDDS Application.
因此，从本节的描述文本来看，替换元素只能在持有非终端规则（“非终端NAPTR”）的NAPTR中使用，除非DDDS应用程序将域名作为其终端输出，而可选的Regexp元素可用于生成域名作为非终端情况下使用的下一个密钥，或生成DDDS应用程序的输出。
Note that each DDDS Application is free to specify the set of flags to be used with that application. This includes specifying whether a particular flag is associated with a terminal or non-terminal rule, and also includes specifying the interpretation of an empty Flags field (i.e., whether this is to be interpreted as a terminal or non-terminal rule, and if it is terminal, then what is the expected output). ENUM (as specified in Section 2.4.1 of [RFC3761]) uses only the 'u' flag, with an empty Flags field indicating a non-terminal NAPTR.
请注意，每个DDDS应用程序都可以自由指定与该应用程序一起使用的标志集。这包括指定特定标志是否与终端或非终端规则关联，还包括指定空标志字段的解释（即，是否将其解释为终端或非终端规则，如果是终端，则预期输出是什么）。枚举（如[RFC3761]第2.4.1节所述）仅使用“u”标志，空标志字段表示非终端NAPTR。
The general case in which a client program must check which of the two elements to use in non-terminal NAPTR processing complicates implementation, and this interpretation has NOT been made in current ENUM implementations. It would be useful to define exactly when a client program can expect to process the Regexp element and when to expect to process the Replacement element, if only to improve robustness. Generating an ENUM domain name from the Regexp field is difficult at best and impossible for the general case of a variable-length telephone number, or one that has more than 9 digits. Thus, it is proposed that when the ENUM specification is updated, this option is deprecated, and using the Regexp field for non-terminal ENUM NAPTRs is prohibited.
一般情况下，客户端程序必须检查在非终端NAPTR处理中使用这两个元素中的哪一个元素，这会使实现复杂化，并且在当前的枚举实现中没有进行这种解释。准确地定义客户机程序何时可以处理Regexp元素以及何时可以处理替换元素是非常有用的，即使只是为了提高健壮性。从Regexp字段生成ENUM域名充其量是很困难的，对于长度可变的电话号码或具有9位数以上的电话号码的一般情况来说，这是不可能的。因此，建议在更新ENUM规范时，不推荐使用此选项，并且禁止对非终端ENUM NAPTR使用Regexp字段。
In keeping with current implementations, the target domain of a non-terminal ENUM NAPTR MUST be placed in the (non-empty) Replacement field. This field MUST be interpreted as holding the domain name that forms the next key output from this non-terminal rule. Conversely, the Regexp field MUST be empty in a non-terminal NAPTR encountered in ENUM processing, and ENUM clients MUST ignore its content.
为了与当前实现保持一致，非终端枚举NAPTR的目标域必须放在（非空）替换字段中。此字段必须解释为包含构成此非终端规则下一个密钥输出的域名。相反，在枚举处理过程中遇到的非终端NAPTR中，Regexp字段必须为空，并且枚举客户端必须忽略其内容。
[RFC3761] is the current standard for the syntax for NAPTRs supporting the ENUM DDDS Application. This obsoletes the original specification that was given in [RFC2916]. RFC 3761 made a change to the syntax of the Services field of the NAPTR that reflects a refinement of the concept of ENUM processing.
[RFC3761]是支持ENUM DDDS应用程序的NAPTRs语法的当前标准。这就废弃了[RFC2916]中给出的原始规范。RFC3761对NAPTR的服务字段的语法进行了更改，这反映了枚举处理概念的改进。
As defined in [RFC3403], there is now a single identifier that indicates the DDDS Application. In the obsolete specification [RFC2915], there were zero or more "Resolution Service" identifiers (the equivalent of the DDDS Application). The same identifier string for the DDDS identifier or the Resolution Service is defined in both the [RFC3761] and [RFC2916] specifications: "E2U".
如[RFC3403]中所定义，现在有一个单一的标识符指示DDDS应用程序。在过时的规范[RFC2915]中，有零个或多个“解析服务”标识符（相当于DDDS应用程序）。[RFC3761]和[RFC2916]规范中都定义了DDDS标识符或解析服务的相同标识符字符串：“E2U”。
Also, [RFC3761] defines at least one but potentially several Enumservice sub-fields; in the obsolete specification, only one "protocol" sub-field was allowed.
此外，[RFC3761]定义了至少一个但可能有几个Enumservice子字段；在过时的规范中，只允许一个“协议”子字段。
In many ways, the most important change for implementations is that the order of the sub-fields has been reversed. [RFC3761] specifies that the DDDS Application identifier is the leftmost sub-field, followed by one or more Enumservice sub-fields, each separated by the '+' character delimiter. [RFC2916] specified that the protocol sub-field was the leftmost, followed by the '+' delimiter, in turn followed by the "E2U" resolution service tag.
在许多方面，实现中最重要的变化是子字段的顺序颠倒了。[RFC3761]指定DDDS应用程序标识符是最左边的子字段，后跟一个或多个Enumservice子字段，每个子字段由“+”字符分隔符分隔。[RFC2916]指定协议子字段是最左边的，后跟“+”分隔符，然后是“E2U”解析服务标记。
[RFC2915] and [RFC2916] have been obsoleted by [RFC3401] - [RFC3404] and by [RFC3761]. However, [RFC3824] suggests that ENUM clients should be prepared to accept NAPTRs with the obsolete syntax. Thus, an ENUM client implementation may have to deal with both forms. This need not be difficult. For example, an implementation could process the Services field into a set of tokens and expect exactly one of these tokens to be "E2U". In this way, the ENUM client might be designed to handle both the old and the current forms without added complexity.
[RFC2915]和[RFC2916]已被[RFC3401]-[RFC3404]和[RFC3761]淘汰。然而，[RFC3824]建议枚举客户端应该准备好接受语法过时的NAPTR。因此，枚举客户机实现可能必须处理这两种形式。这并不困难。例如，一个实现可以将Services字段处理为一组令牌，并期望这些令牌中正好有一个是“E2U”。通过这种方式，枚举客户机可以设计为既处理旧表单又处理当前表单，而不会增加复杂性。
To facilitate this method, IANA should reject any request to register an Enumservice with the label "E2U".
为了简化此方法，IANA应拒绝任何使用标签“E2U”注册Enumservice的请求。
To summarise, ENUM clients MUST support ENUM NAPTRs according to [RFC3761] syntax. ENUM clients SHOULD also support ENUM NAPTRs according to the obsolete syntax of [RFC2916]; there are still zones that hold "old" syntax NAPTRs. ENUM zones MUST NOT be provisioned with NAPTRs according to the obsolete form, and MUST be provisioned with NAPTRs in which the Services field is according to [RFC3761].
总之，ENUM客户端必须根据[RFC3761]语法支持ENUM NAPTRs。ENUM客户端还应根据[RFC2916]的过时语法支持ENUM NAPTRs；仍然有保留“旧”语法NAPTR的区域。枚举区域不得根据过时表单配置NAPTRs，必须根据[RFC3761]配置服务字段所在的NAPTRs。
ENUM NAPTRs SHOULD NOT include characters outside the printable US-ASCII equivalent range (U+0020 to U+007E) unless it is clear that all ENUM clients they are designed to support will be able to process such characters correctly. If ENUM zone provisioning systems require non-ASCII characters, these systems SHOULD encode the non-ASCII data to emit only US-ASCII characters by applying the appropriate
ENUM NAPTR不应包含可打印US-ASCII等效范围（U+0020到U+007E）之外的字符，除非明确说明其设计支持的所有ENUM客户端都能够正确处理此类字符。如果枚举区域设置系统需要非ASCII字符，则这些系统应通过应用适当的
mechanism ([RFC3492], [RFC3987]). Non-printable characters SHOULD NOT be used, as ENUM clients may need to present NAPTR content in a human-readable form.
机制（[RFC3492]，[RFC3987]）。不应使用不可打印的字符，因为枚举客户端可能需要以人类可读的形式呈现NAPTR内容。
The case-sensitivity flag ('i') is inappropriate for ENUM, and SHOULD NOT be provisioned into the Regexp field of E2U NAPTRs.
区分大小写标志（'i'）不适用于枚举，不应设置到E2U NAPTRs的Regexp字段中。
ENUM zone provisioning systems SHOULD use '!' (U+0021) as their Regexp delimiter character.
枚举区域设置系统应使用“！”（U+0021）作为其Regexp分隔符。
If the Regexp delimiter is a character in the static text of the Repl sub-field, it MUST be "escaped" using the escaped-delimiter production of the BNF specification shown in Section 3.2 of [RFC3402] (i.e., "\!", U+005C U+0021). Note that when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash.
If the Regexp delimiter is a character in the static text of the Repl sub-field, it MUST be "escaped" using the escaped-delimiter production of the BNF specification shown in Section 3.2 of [RFC3402] (i.e., "\!", U+005C U+0021). Note that when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash.translate error, please retry
If present in the ERE sub-field of an ENUM NAPTR, the literal character '+' MUST be escaped as "\+" (i.e. U+005C U+002B). Note that, as always, when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash.
如果存在于枚举NAPTR的ERE子字段中，则文字字符“+”必须转义为“\+”（即U+005C U+002B）。请注意，与往常一样，当以DNS主文件语法输入NAPTR资源记录时，必须使用第二个反斜杠对反斜杠本身进行转义。
The Registrant and the ENUM zone provisioning system he or she uses SHOULD NOT rely on ENUM clients solely taking account of the value of the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs. Thus, a Registrant SHOULD place into his or her zone only contacts that he or she is willing to support; even those with the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an end user.
注册人和他或她使用的枚举区域设置系统不应仅依赖于枚举客户端，并考虑到顺序值和枚举NAPTRs中的首选项/优先级字段。因此，注册人只应将其愿意支持的联系人放入其区域；最终用户甚至可以选择具有最差顺序和首选项/优先级值的那些。
Many apparent mistakes in ORDER and PREFERENCE/PRIORITY values have been detected in provisioned ENUM zones. To avoid these common interoperability issues, provisioning systems SHOULD NOT use different ORDER field values for NAPTRs in a Resource Record Set (RRSet). To generalise, all ENUM NAPTRs SHOULD hold a default value in their ORDER field. A value of "100" is recommended, as it seems to be used in most provisioned domains.
在已设置的枚举区域中检测到许多顺序和首选项/优先级值方面的明显错误。为了避免这些常见的互操作性问题，资源调配系统不应为资源记录集（RRSet）中的NAPTR使用不同的顺序字段值。一般来说，所有枚举NAPTR都应该在其顺序字段中保留默认值。建议使用值“100”，因为它似乎用于大多数已配置的域。
Multiple NAPTRs with identical ORDER and identical PREFERENCE/ PRIORITY field values SHOULD NOT be provisioned into an RRSet unless the intent is that these NAPTRs are truly identical and there is no preference between them. Implementers SHOULD NOT assume that the DNS will deliver NAPTRs within an RRSet in a particular sequence.
不应将具有相同顺序和相同首选项/优先级字段值的多个NAPTR设置到RRSet中，除非目的是这些NAPTR真正相同并且它们之间没有首选项。实施者不应假设DNS将以特定顺序在RRSet内交付NAPTR。
An ENUM zone provisioning system SHOULD assume that, if it generates compound NAPTRs, the Enumservices will normally be processed in left-to-right order within such NAPTRs.
枚举区域设置系统应假定，如果生成复合NAPTR，则通常会在此类NAPTR内按从左到右的顺序处理枚举服务。
ENUM zone provisioning systems SHOULD assume that, once a non-terminal NAPTR has been selected for processing, the ORDER field value in a domain referred to by that non-terminal NAPTR will be considered only within the context of that referenced domain (i.e., the ORDER value will be used only to sort within the current RRSet and will not be used in the processing of NAPTRs in any other RRSet).
枚举区域设置系统应假设，一旦选择非终端NAPTR进行处理，该非终端NAPTR引用的域中的订单字段值将仅在该引用域的上下文中考虑（即，订单值将仅用于当前RRSet内的排序，不会用于处理任何其他RRSet中的NAPTR）。
Whilst this client behaviour is non-compliant, ENUM provisioning systems and their users should be aware that some ENUM clients have been detected with poor (or no) support for non-trivial ERE sub-field expressions.
虽然此客户端行为不符合要求，但枚举资源调配系统及其用户应该知道，检测到一些枚举客户端对非平凡ERE子字段表达式的支持较差（或没有）。
ENUM provisioning systems SHOULD be cautious in the use of multiple back-reference patterns in the Repl sub-field of NAPTRs they provision. Some clients have limited buffer space for character expansion when generating URIs (see also Section 3). These provisioning systems SHOULD check the back-reference replacement patterns they use, ensuring that regular expression processing will not produce excessive-length URIs.
枚举供应系统在其供应的NAPTR的Repl子字段中使用多个反向引用模式时应谨慎。某些客户端在生成URI时，字符扩展的缓冲区空间有限（另请参见第3节）。这些资源调配系统应该检查它们使用的反向引用替换模式，确保正则表达式处理不会产生过长的URI。
As current support is limited, non-terminal NAPTRs SHOULD NOT be provisioned in ENUM zones unless it is clear that all ENUM clients that this environment supports can process these.
由于当前支持有限，不应在枚举区域中配置非终端NAPTR，除非此环境支持的所有枚举客户端都可以处理这些NAPTR。
When populating a set of domains with NAPTRs, ENUM zone provisioning systems SHOULD NOT configure non-terminal NAPTRs so that more than 5 such NAPTRs will be processed in an ENUM query.
使用NAPTR填充一组域时，枚举区域设置系统不应配置非终端NAPTR，以便在枚举查询中处理超过5个此类NAPTR。
In a non-terminal NAPTR encountered in an ENUM query (i.e., one with an empty Flags field), the Services field SHOULD be empty.
在枚举查询（即带有空标志字段的查询）中遇到的非终端NAPTR中，服务字段应为空。
A non-terminal NAPTR MUST include its target domain in the (non-empty) Replacement field. This field MUST be interpreted as holding the domain name that forms the next key output from this non-terminal rule. The Regexp field MUST be empty in a non-terminal NAPTR intended to be encountered during an ENUM query.
非终端NAPTR必须在（非空）替换字段中包含其目标域。此字段必须解释为包含构成此非终端规则下一个密钥输出的域名。在枚举查询期间遇到的非终端NAPTR中，Regexp字段必须为空。
ENUM zones MUST NOT be provisioned with NAPTRs according to the obsolete form, and MUST be provisioned with NAPTRs in which the Services field is according to [RFC3761].
枚举区域不得根据过时表单配置NAPTRs，必须根据[RFC3761]配置服务字段所在的NAPTRs。
ENUM clients SHOULD NOT discard NAPTRs in which they detect characters outside the US-ASCII printable range (0x20 to 0x7E hexadecimal).
枚举客户端不应丢弃检测到US-ASCII可打印范围（0x20到0x7E十六进制）以外字符的NAPTR。
ENUM clients MAY discard NAPTRs that have octets in the Flags, Services, or Regexp fields that have byte values outside the US-ASCII equivalent range (i.e., byte values above 0x7F). Clients MUST be ready to encounter NAPTRs with such values without failure.
枚举客户端可能会丢弃在标志、服务或Regexp字段中有八位字节且字节值超出US-ASCII等效范围（即字节值高于0x7F）的NAPTR。客户机必须准备好遇到具有此类值的NAPTR而不会失败。
ENUM clients SHOULD NOT assume that the delimiter is the last character of the Regexp field.
枚举客户端不应假定分隔符是Regexp字段的最后一个字符。
Unless they are sure that in their environment this is the case, in general an ENUM client may still encounter NAPTRs that have been provisioned with a following 'i' (case-insensitive) flag, even though that flag has no effect at all in an ENUM scenario.
除非他们确定在他们的环境中是这种情况，否则一般来说，枚举客户机可能仍然会遇到已设置了以下“i”（不区分大小写）标志的NAPTR，即使该标志在枚举场景中根本无效。
ENUM clients SHOULD discard NAPTRs that have more or less than 3 unescaped instances of the delimiter character within the Regexp field.
枚举客户端应丢弃在Regexp字段中具有多于或少于3个未转义的分隔符实例的NAPTR。
In the spirit of being liberal with what it will accept, if the ENUM client is sure how the Regexp field should be interpreted, then it may choose to process the NAPTR even in the face of an incorrect number of unescaped delimiter characters. If it is not clear how the Regexp field should be interpreted, then the client must discard the NAPTR.
本着自由开放的精神，如果ENUM客户端确定应该如何解释Regexp字段，那么即使面对数量不正确的未转义分隔符字符，它也可能选择处理NAPTR。如果不清楚如何解释Regexp字段，则客户端必须放弃NAPTR。
Where the ENUM client presents a list of possible URLs to the end user for his or her choice, it MAY present all NAPTRs -- not just the ones with the highest currently unprocessed ORDER field value. The client SHOULD keep to the ORDER and PREFERENCE/PRIORITY values specified by the Registrant.
当ENUM客户端向最终用户提供一个可能的URL列表供其选择时，它可能会显示所有NAPTR，而不仅仅是当前未处理的订单字段值最高的那些。客户应遵守注册人指定的顺序和优先权/优先级值。
ENUM clients SHOULD accept all NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values, and process them in the sequence in which they appear in the DNS response. (There is no benefit in further randomising the order in which these are processed, as intervening DNS Servers might have done this already).
枚举客户端应接受具有相同顺序和相同首选项/优先级字段值的所有NAPTR，并按照它们在DNS响应中出现的顺序处理它们。（进一步随机处理这些数据的顺序没有好处，因为介入的DNS服务器可能已经这样做了）。
ENUM clients receiving compound NAPTRs (i.e., ones with more than one Enumservice) SHOULD process these Enumservices using a left-to-right sort ordering, so that the first Enumservice to be processed will be the leftmost one, and the last will be the rightmost one.
接收复合NAPTR的ENUM客户端（即具有多个Enumservice的客户端）应使用从左到右的排序顺序处理这些Enumservices，以便要处理的第一个Enumservice将是最左边的，最后一个将是最右边的。
ENUM clients SHOULD consider the ORDER field value only when sorting NAPTRs within a single RRSet. The ORDER field value SHOULD NOT be taken into account when processing NAPTRs across a sequence of DNS queries created by traversal of non-terminal NAPTR references.
EnUM客户端只需在单个RRSET中对NAPTRs进行排序时就考虑Orror字段值。通过遍历非终端NAPTR引用创建的DNS查询序列处理NAPTR时，不应考虑订单字段值。
ENUM clients MUST be ready to process NAPTRs that use a different character from '!' as their Regexp Delimiter without failure.
枚举客户端必须准备好处理使用与“！”不同字符的NAPTR作为它们的Regexp分隔符，不会失败。
ENUM clients MUST be ready to process NAPTRs that have non-trivial patterns in their ERE sub-field values without failure.
枚举客户端必须准备好处理在其ERE子字段值中具有非平凡模式的NAPTR，而不会出现故障。
ENUM clients MUST be ready to process NAPTRs with a DDDS Application identifier other than 'E2U' without failure.
ENUM客户端必须准备好处理DDDS应用程序标识符不是“E2U”的NAPTR，而不会出现故障。
ENUM clients MUST be ready to process NAPTRs with many copies of back-reference patterns within the Repl sub-field without failure (see also Section 3).
ENUM客户端必须准备好在Repl子字段中处理具有多个反向引用模式副本的NAPTR而不会出现故障（另请参见第3节）。
If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query to terminate and processing SHOULD continue with the next NAPTR in the returned Resource Record Set (RRSet).
如果NAPTR被丢弃，这不应导致整个枚举查询终止，处理应继续处理返回的资源记录集（RRSet）中的下一个NAPTR。
When an ENUM client encounters a compound NAPTR (i.e., one containing more than one Enumservice) and cannot process or cannot recognise one of the Enumservices within it, that ENUM client SHOULD ignore this Enumservice and continue with the next Enumservice within this NAPTR's Services field, discarding the NAPTR only if it cannot handle any of the Enumservices contained. These conditions SHOULD NOT be considered errors.
当ENUM客户端遇到复合NAPTR（即，包含多个Enumservice的NAPTR）且无法处理或无法识别其中的一个Enumservice时，该ENUM客户端应忽略此Enumservice，并继续使用此NAPTR的Services字段中的下一个Enumservice，仅当NAPTR无法处理包含的任何枚举服务时，才会丢弃该NAPTR。这些条件不应视为错误。
ENUM clients MUST support ENUM NAPTRs according to [RFC3761] syntax. ENUM clients SHOULD also support ENUM NAPTRs according to the obsolete syntax of [RFC2916]; there are still zones that hold "old" syntax NAPTRs.
ENUM客户端必须根据[RFC3761]语法支持ENUM NAPTRs。ENUM客户端还应根据[RFC2916]的过时语法支持ENUM NAPTRs；仍然有保留“旧”语法NAPTR的区域。
ENUM clients MUST be ready to process NAPTRs with an empty Flags field ("non-terminal" NAPTRs) without failure. More generally, non-terminal NAPTR processing SHOULD be implemented, but ENUM clients MAY discard non-terminal NAPTRs they encounter.
枚举客户端必须准备好处理带有空标志字段（“非终端”NAPTRs）的NAPTRs，而不会出现故障。更一般地说，应该实现非终端NAPTR处理，但枚举客户端可能会丢弃它们遇到的非终端NAPTR。
ENUM clients SHOULD ignore any content of the Services field when encountering a non-terminal NAPTR with an empty Flags field.
当遇到带有空标志字段的非终端NAPTR时，枚举客户端应忽略服务字段的任何内容。
ENUM clients receiving a non-terminal NAPTR with an empty Flags field MUST treat the Replacement field as holding the domain name to be used in the next round of the ENUM query. An ENUM client MUST discard such a non-terminal NAPTR if the Replacement field is empty or does not contain a valid domain name. By definition, it follows that the Regexp field will be empty in such a non-terminal NAPTR. If present in a non-terminal NAPTR, a non-empty Regexp field MUST be ignored by ENUM clients.
接收带有空标志字段的非终端NAPTR的枚举客户端必须将替换字段视为包含下一轮枚举查询中使用的域名。如果替换字段为空或不包含有效域名，则枚举客户端必须放弃此类非终端NAPTR。根据定义，在这种非终端NAPTR中，Regexp字段将为空。如果存在于非终端NAPTR中，则枚举客户端必须忽略非空的Regexp字段。
If a problem is detected when processing an ENUM query across multiple domains (by following non-terminal NAPTR references), then the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD continue at the next NAPTR after the non-terminal NAPTR that referred to the domain in which the problem would have occurred.
如果在跨多个域处理枚举查询时（通过遵循非终端NAPTR引用）检测到问题，则不应放弃枚举查询，而是应在引用可能发生问题的域的非终端NAPTR之后的下一个NAPTR继续处理。
If all NAPTRs in a domain traversed as a result of a reference in a non-terminal NAPTR have been discarded, then the ENUM client SHOULD continue its processing with the next NAPTR in the "referring" RRSet (i.e., the one including the non-terminal NAPTR that caused the traversal).
如果由于非终端NAPTR中的引用而遍历的域中的所有NAPTR已被丢弃，则枚举客户端应继续处理“引用”RRSet中的下一个NAPTR（即，包括导致遍历的非终端NAPTR的NAPTR）。
ENUM clients MAY consider a chain of more than 5 "non-terminal" NAPTRs traversed in a single ENUM query as an indication that a referential loop has been entered.
EnUM客户端可以考虑在一个EnUM查询中遍历超过5个“非终结”NAPTR链，作为引用循环已被输入的指示。
Where a domain is about to be entered as the result of a reference in a non-terminal NAPTR, and the ENUM client has detected a potential referential loop, then the client SHOULD discard the non-terminal NAPTR from its processing and continue with the next NAPTR in its list. It SHOULD NOT make the DNS query indicated by that non-terminal NAPTR.
如果域即将作为非终端NAPTR中引用的结果输入，并且枚举客户端已检测到潜在的引用循环，则客户端应将非终端NAPTR从其处理中丢弃，并继续使用其列表中的下一个NAPTR。它不应进行由该非终端NAPTR指示的DNS查询。
In addition to the security implications of recommendations in this document, those in the basic use of ENUM (and specified in the normative documents for this protocol) should be considered as well; this document does not negate those in any way.
除了本文件中建议的安全影响外，还应考虑基本使用ENUM（以及本议定书规范性文件中规定的）的安全影响；本文件不会以任何方式否定这些观点。
The clarifications throughout this document are intended only as that: clarifications of text in the normative documents. They do not appear to have any security implications above those mentioned in the normative documents.
本文件中的澄清仅为：规范性文件中的文本澄清。它们似乎没有超出规范性文件中提到的安全含义。
The suggestions in Section 2, Section 4, and Section 6 do not appear to have any security considerations (either positive or negative).
第2节、第4节和第6节中的建议似乎没有任何安全考虑（正面或负面）。
The suggestions in Section 5.2.2 are a valid approach to a known security threat. It does not open an advantage to an attacker in causing excess processing or memory usage in the client. It does, however, mean that an ENUM client will traverse a "tight loop" of non-terminal NAPTRs in two domains 5 times before the client detects this as a loop; this does introduce slightly higher processing load than would be provided using other methods, but avoids the risks they incur.
第5.2.2节中的建议是解决已知安全威胁的有效方法。攻击者在客户端中造成过多的处理或内存使用，这对攻击者没有好处。然而，这确实意味着，在客户端将其检测为循环之前，ENUM客户端将在两个域中遍历非终端NAPTR的“紧密循环”5次；与使用其他方法相比，这确实会带来略高的处理负载，但可以避免它们带来的风险。
As mentioned in Section 3, ENUM uses regular expressions to generate URIs. Though it is a standard feature of DDDS, use of "non-greedy" regular expressions with multiple back-reference patterns in the Repl sub-field does create the potential for buffer-overrun attacks. Provisioning system designers SHOULD be aware of this and SHOULD limit the repeated use of back-reference replacement patterns. Conversely, ENUM client implementers SHOULD avoid using fixed character buffers when generating URIs from Repl sub-fields that include Back-reference patterns, and MUST avoid failure in the case of buffer exhaustion.
如第3节所述，枚举使用正则表达式生成URI。尽管这是DDDS的标准功能，但在Repl子字段中使用具有多个反向引用模式的“非贪婪”正则表达式确实会造成缓冲区溢出攻击的可能性。资源调配系统设计者应该意识到这一点，并且应该限制重复使用反向引用替换模式。相反，当从包含反向引用模式的Repl子字段生成URI时，枚举客户机实现者应该避免使用固定字符缓冲区，并且必须避免在缓冲区耗尽的情况下失败。
We would like to thank the various development teams who implemented ENUM (both creation systems and clients) and who read the normative documents differently -- without these differences it would have been harder for us all to develop robust clients and suitably conservative management systems. We would also thank those who allowed us to check their implementations to explore behaviour; their trust and help were much appreciated.
我们要感谢实施ENUM（创建系统和客户机）的各个开发团队，感谢他们以不同的方式阅读规范性文件——如果没有这些差异，我们所有人都将更难开发健壮的客户机和适当保守的管理系统。我们还要感谢那些允许我们检查其实现以探索行为的人；非常感谢他们的信任和帮助。
In particular, thanks to Richard Stastny for his hard work on a similar task, TS 102 172 [ETSI-TS102172] under the aegis of ETSI, and for supporting some of the ENUM implementations that exist today.
特别要感谢Richard Stastny在ETSI的支持下在类似任务TS 102 172[ETSI-TS102172]上的辛勤工作，以及支持目前存在的一些ENUM实现。
Finally, thanks for the dedication of Michael Mealling in giving us such detailed DDDS specifications, without which the ENUM development effort would have had a less rigorous framework on which to build. This document reflects how complex a system it is: without the intricacy of [RFC3401] - [RFC3404] and the work that went into them, it could have been very difficult to ensure interoperability.
最后，感谢Michael Mealling为我们提供了如此详细的DDDS规范，如果没有这些规范，ENUM开发工作将有一个不那么严格的框架来构建。本文档反映了系统的复杂性：如果没有[RFC3401]-[RFC3404]的复杂性和它们所做的工作，就很难确保互操作性。
[E.164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.
[E.164]ITU-T，“国际公共电信号码计划”，建议E.164，2005年2月。
[IEEE.1003-2.1992] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Standard 1003.2, January 1993.
[IEEE.1003-2.1992]电气和电子工程师协会，“信息技术-便携式操作系统接口（POSIX）-第2部分：外壳和实用程序（第1卷）”，IEEE标准1003.2，1993年1月。
[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月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3402]Mealling，M.“动态委托发现系统（DDDS）第二部分：算法”，RFC3402，2002年10月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403]Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC34032002年10月。
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[RFC3404]Mealling，M.“动态委托发现系统（DDDS）第四部分：统一资源标识符（URI）”，RFC34042002年10月。
[RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, October 2002.
[RFC3405]Mealling，M.“动态委托发现系统（DDDS）第五部分：URI.ARPA分配程序”，BCP 65，RFC 3405，2002年10月。
[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月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3761]Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[ASCII]美国国家标准协会，“编码字符集-信息交换用7位美国标准代码”，ANSI X3.41986。
[ETSI-TS102172] ETSI, "Minimum Requirements for Interoperability of European ENUM Implementations", ETSI TS 102 172, October 2004.
[ETSI-TS102172]ETSI，“欧洲ENUM实施互操作性的最低要求”，ETSI TS 102 172，2004年10月。
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC2915]Mealling，M.和R.Daniel，“命名机构指针（NAPTR）DNS资源记录”，RFC 2915，2000年9月。
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[RFC2916]Faltstrom，P.，“E.164编号和DNS”，RFC 29162000年9月。
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401]Mealling，M.“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004.
[RFC3824]Peterson，J.，Liu，H.，Yu，J.，和B.Campbell，“在会话启动协议（SIP）中使用E.164号码”，RFC 38242004年6月。
Authors' Addresses
作者地址
Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey United Kingdom
劳伦斯·康罗伊·罗克庄园研究罗克庄园老索尔兹伯里巷罗姆西英国
Phone: +44-1794-833666
EMail: lconroy@insensate.co.uk
URI: http://www.sienum.co.uk
Phone: +44-1794-833666
EMail: lconroy@insensate.co.uk
URI: http://www.sienum.co.uk
Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F 3-8-1 Nishi-Kanda Chiyoda-ku Tokyo 101-0165 JAPAN
日本东京101-0165西神田千代田区东13楼3-8-1号千代田日本注册服务有限公司
EMail: fujiwara@jprs.co.jp
URI: http://jprs.co.jp/en/
EMail: fujiwara@jprs.co.jp
URI: http://jprs.co.jp/en/