Network Working Group P. Faltstrom
Request for Comments: 3761 Cisco Systems, Inc.
Obsoletes: 2916 M. Mealling
Category: Standards Track VeriSign
April 2004
Network Working Group P. Faltstrom
Request for Comments: 3761 Cisco Systems, Inc.
Obsoletes: 2916 M. Mealling
Category: Standards Track VeriSign
April 2004
The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401.
本文档讨论使用域名系统（DNS）存储E.164号码。更具体地说，DNS如何用于识别连接到一个E.164号码的可用服务。它特别淘汰了RFC 2916，以使其符合RFC 3401中指定的文档系列中的动态委托发现系统（DDDS）应用程序规范。必须注意的是，如果不阅读RFC 3401中讨论的文件，就不可能阅读和理解本文件。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use for these mechanisms for private dialing plans. . . . 3
1.3. Application of local policy . . . . . . . . . . . . . . . 3
2. The ENUM Application Specifications . . . . . . . . . . . . . 4
2.1. Application Unique String . . . . . . . . . . . . . . . . 5
2.2. First Well Known Rule . . . . . . . . . . . . . . . . . . 5
2.3. Expected Output . . . . . . . . . . . . . . . . . . . . . 5
2.4. Valid Databases . . . . . . . . . . . . . . . . . . . . . 5
2.4.1. Flags. . . . . . . . . . . . . . . . . . . . . . . 6
2.4.2. Services Parameters. . . . . . . . . . . . . . . . 7
2.5. What constitutes an 'Enum Resolver'?. . . . . . . . . . . 8
3. Registration mechanism for Enumservices . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use for these mechanisms for private dialing plans. . . . 3
1.3. Application of local policy . . . . . . . . . . . . . . . 3
2. The ENUM Application Specifications . . . . . . . . . . . . . 4
2.1. Application Unique String . . . . . . . . . . . . . . . . 5
2.2. First Well Known Rule . . . . . . . . . . . . . . . . . . 5
2.3. Expected Output . . . . . . . . . . . . . . . . . . . . . 5
2.4. Valid Databases . . . . . . . . . . . . . . . . . . . . . 5
2.4.1. Flags. . . . . . . . . . . . . . . . . . . . . . . 6
2.4.2. Services Parameters. . . . . . . . . . . . . . . . 7
2.5. What constitutes an 'Enum Resolver'?. . . . . . . . . . . 8
3. Registration mechanism for Enumservices . . . . . . . . . . . 8
3.1. Registration Requirements . . . . . . . . . . . . . . . . 8
3.1.1. Functionality Requirement. . . . . . . . . . . . . 8
3.1.2. Naming requirement . . . . . . . . . . . . . . . . 9
3.1.3. Security requirement . . . . . . . . . . . . . . . 9
3.1.4. Publication Requirements . . . . . . . . . . . . . 10
3.2. Registration procedure. . . . . . . . . . . . . . . . . . 10
3.2.1. IANA Registration. . . . . . . . . . . . . . . . . 10
3.2.2. Registration Template. . . . . . . . . . . . . . . 11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
6.1. DNS Security. . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Caching Security. . . . . . . . . . . . . . . . . . . . . 14
6.3. Call Routing Security . . . . . . . . . . . . . . . . . . 14
6.4. URI Resolution Security . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. Changes since RFC 2916 . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References. . . . . . . . . . . . . . . . . . . 16
9.2. Informative References. . . . . . . . . . . . . . . . . . 16
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
3.1. Registration Requirements . . . . . . . . . . . . . . . . 8
3.1.1. Functionality Requirement. . . . . . . . . . . . . 8
3.1.2. Naming requirement . . . . . . . . . . . . . . . . 9
3.1.3. Security requirement . . . . . . . . . . . . . . . 9
3.1.4. Publication Requirements . . . . . . . . . . . . . 10
3.2. Registration procedure. . . . . . . . . . . . . . . . . . 10
3.2.1. IANA Registration. . . . . . . . . . . . . . . . . 10
3.2.2. Registration Template. . . . . . . . . . . . . . . 11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
6.1. DNS Security. . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Caching Security. . . . . . . . . . . . . . . . . . . . . 14
6.3. Call Routing Security . . . . . . . . . . . . . . . . . . 14
6.4. URI Resolution Security . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. Changes since RFC 2916 . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References. . . . . . . . . . . . . . . . . . . 16
9.2. Informative References. . . . . . . . . . . . . . . . . . 16
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401 [6]. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401 [6].
本文档讨论使用域名系统（DNS）存储E.164号码。更具体地说，DNS如何用于识别连接到一个E.164号码的可用服务。它特别淘汰了RFC 2916，以使其符合RFC 3401[6]中指定的文档系列中的动态委托发现系统（DDDS）应用程序规范。需要注意的是，如果不阅读RFC 3401[6]中讨论的文件，就不可能阅读和理解本文件。
Through transformation of International Public Telecommunication Numbers in the international format [5], called within this document E.164 numbers, into DNS names and the use of existing DNS services like delegation through NS records and NAPTR records, one can look up what services are available for a specific E.164 in a decentralized way with distributed management of the different levels in the lookup process.
通过将本文件中称为E.164号的国际格式的国际公共电信号[5]转换为DNS名称，并使用现有DNS服务，如通过NS记录和NAPTR记录进行授权，通过对查找过程中不同级别的分布式管理，可以以分散的方式查找特定E.164的可用服务。
The domain "e164.arpa" is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers. In order to facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator according to the
正在填充域“e164.arpa”，以便在DNS中提供存储E.164号码的基础设施。为了便于分布式操作，该域被划分为子域。希望在DNS中列出的E.164号码的持有人应根据
policy which is attached to the zone. One should start looking for this information by examining the SOA resource record associated with the zone, just like in normal DNS operations.
附加到区域的策略。应该通过检查与区域相关联的SOA资源记录来开始查找此信息，就像在正常DNS操作中一样。
Of course, as with other domains, policies for such listings will be controlled on a subdomain basis and may differ in different parts of the world.
当然，与其他域一样，此类列表的策略将在子域基础上进行控制，并且可能在世界不同地区有所不同。
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 BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
All other capitalized terms are taken from the vocabulary found in the DDDS algorithm specification found in RFC 3403 [2].
所有其他大写术语取自RFC 3403[2]中DDDS算法规范中的词汇表。
This document describes the operation of these mechanisms in the context of numbers allocated according to the ITU-T recommendation E.164. The same mechanisms might be used for private dialing plans. If these mechanisms are re-used, the suffix used for the private dialing plan MUST NOT be e164.arpa, to avoid conflict with this specification. Parties to the private dialing plan will need to know the suffix used by their private dialing plan for correct operation of these mechanisms. Further, the application unique string used SHOULD be the full number as specified, but without the leading '+', and such private use MUST NOT be called "ENUM".
本文件描述了这些机制在根据ITU-T建议E.164分配号码的情况下的操作。同样的机制也可用于私人拨号计划。如果重复使用这些机制，则专用拨号计划使用的后缀不得为e164.arpa，以避免与本规范冲突。私人拨号计划各方需要知道其私人拨号计划使用的后缀，以便正确操作这些机制。此外，所使用的应用程序唯一字符串应为指定的完整数字，但不带前导“+”，并且此类私有用途不得称为“ENUM”。
The Order field in the NAPTR record specifies in what order the DNS records are to be interpreted. This is because DNS does not guarantee the order of records returned in the answer section of a DNS packet. In most ENUM cases this isn't an issue because the typical regular expression will be '!^.*$!' since the first query often results in a terminal Rule.
NAPTR记录中的顺序字段指定DNS记录的解释顺序。这是因为DNS不保证在DNS数据包的应答部分中返回的记录的顺序。在大多数枚举情况下，这不是问题，因为典型的正则表达式是“！^.*$！”因为第一个查询通常会产生一个终端规则。
But there are other cases (non-terminal Rules) where two different Rules both match the given Application Unique String. As each Rule is evaluated within the algorithm, one may match a more significant piece of the AUS than the other. For example, by using a non-terminal NAPTR a given set of numbers is sent to some private-dialing-plan-specific zone. Within that zone there are two Rules that state that if a match is for the entire exchange and the service is SIP related then the first, SIP-specific rule is used. But the other Rule matches a longer piece of the AUS, specifying that for
但也有其他情况（非终端规则），其中两个不同的规则都匹配给定的应用程序唯一字符串。由于每个规则都是在算法中评估的，因此其中一个规则可能比另一个规则匹配更重要的AU。例如，通过使用非终端NAPTR，一组给定的号码被发送到某个专用拨号计划特定的区域。在该区域内，有两条规则规定，如果匹配是针对整个exchange的，并且服务与SIP相关，则使用第一条特定于SIP的规则。但另一条规则与更长的AU匹配，为
some other service (instant messaging) that the Rule denotes a departmental level service. If the shorter matching Rule comes before the longer match, it can 'mask' the other rules. Thus, the order in which each Rule is tested against the AUS is an important corner case that many DDDS applications take advantage of.
该规则表示部门级服务的其他一些服务（即时消息）。如果较短的匹配规则出现在较长的匹配规则之前，则它可以“屏蔽”其他规则。因此，针对AUS测试每个规则的顺序是许多DDDS应用程序利用的一个重要的转折点。
In the case where the zone authority wishes to state that two Rules have the same effect or are identical in usage, then the Order for those records is set to the same value. In that case, the Preference is used to specify a locally over-ridable suggestion by the zone authority that one Rule might simply be better than another for some reason.
如果区域管理局希望声明两条规则具有相同的效力或使用相同，则将这些记录的顺序设置为相同的值。在这种情况下，首选项用于指定区域管理局提出的本地可超越建议，即出于某种原因，一条规则可能优于另一条规则。
For ENUM this specifies where a client is allowed to apply local policy and where it is not. The Order field in the NAPTR is a request from the holder of the E.164 number that the records be handled in a specific way. The Preference field is merely a suggestion from that E.164 holder that one record might be better than another. A client implementing ENUM MUST adhere to the Order field but can simply take the Preference value "on advisement" as part of a client context specific selection method.
对于ENUM，它指定允许客户端应用本地策略的位置和不允许客户端应用本地策略的位置。NAPTR中的Order字段是E.164号码持有者要求以特定方式处理记录的请求。偏好字段仅仅是E.164持有者的建议，即一个记录可能比另一个记录更好。实现ENUM的客户机必须遵守Order字段，但可以简单地将首选项值“on advision”作为客户机上下文特定选择方法的一部分。
This template defines the ENUM DDDS Application according to the rules and requirements found in [7]. The DDDS database used by this Application is found in [2] which is the document that defines the NAPTR DNS Resource Record type.
此模板根据[7]中的规则和要求定义ENUM DDDS应用程序。此应用程序使用的DDDS数据库位于[2]中，该文档定义了NAPTR DNS资源记录类型。
ENUM is only applicable for E.164 numbers. ENUM compliant applications MUST only query DNS for what it believes is an E.164 number. Since there are numerous dialing plans which can change over time, it is probably impossible for a client application to have perfect knowledge about every valid and dialable E.164 number. Therefore a client application, doing everything within its power, can end up with what it thinks is a syntactically correct E.164 number which in reality is not actually valid or dialable. This implies that applications MAY send DNS queries when, for example, a user mistypes a number in a user interface. Because of this, there is the risk that collisions between E.164 numbers and non-E.164 numbers can occur. To mitigate this risk, the E2U portion of the service field MUST NOT be used for non-E.164 numbers.
ENUM仅适用于E.164编号。符合ENUM的应用程序必须仅查询其认为是E.164号码的DNS。由于有许多拨号计划可以随着时间的推移而改变，因此客户端应用程序可能不可能完全了解每个有效的可拨打的E.164号码。因此，客户机应用程序在其力所能及的范围内完成所有工作，最终可能会得到一个语法正确的E.164号码，而实际上该号码是无效的或不可拨打的。这意味着，例如，当用户在用户界面中错误键入数字时，应用程序可能会发送DNS查询。因此，存在E.164数字和非E.164数字之间可能发生冲突的风险。为降低此风险，服务字段的E2U部分不得用于非E.164号码。
The Application Unique String is a fully qualified E.164 number minus any non-digit characters except for the '+' character which appears at the beginning of the number. The "+" is kept to provide a well understood anchor for the AUS in order to distinguish it from other telephone numbers that are not part of the E.164 namespace.
应用程序唯一字符串是一个完全限定的E.164数字减去除数字开头出现的“+”字符以外的任何非数字字符。保留“+”是为了为AUS提供一个易于理解的锚，以便将其与不属于E.164名称空间的其他电话号码区分开来。
For example, the E.164 number could start out as "+44-116-496-0348". To ensure that no syntactic sugar is allowed into the AUS, all non-digits except for "+" are removed, yielding "+441164960348".
例如，E.164编号可以以“+44-116-496-0348”开头。为确保不允许在AUS中使用语法糖，将删除除“+”之外的所有非数字，生成“+441164960348”。
The First Well Known Rule for this Application is the identity rule. The output of this rule is the same as the input. This is because the E.164 namespace and this Applications databases are organized in such a way that it is possible to go directly from the name to the smallest granularity of the namespace directly from the name itself.
此应用程序的第一条众所周知的规则是标识规则。此规则的输出与输入相同。这是因为E.164名称空间和该应用程序数据库的组织方式可以直接从名称到名称空间的最小粒度，直接从名称本身。
Take the previous example, the AUS is "+441164960348". Applying the First Well Known Rule produces the exact same string, "+441164960348".
以上一个示例为例，AUS为“+441164960348”。应用第一条众所周知的规则会产生完全相同的字符串“+441164960348”。
The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the 'absoluteURI' production in the Collected ABNF found in RFC2396 [4].
根据RFC2396[4]中收集的ABNF中的“absoluteURI”生成，最后一个DDDS循环的输出是绝对形式的统一资源标识符。
At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" (RFC 3403) [2] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain-names.
目前，仅为此应用程序指定了一个DDDS数据库。“动态委派发现系统（DDDS）第三部分：DNS数据库”（RFC 3403）[2]指定使用NAPTR DNS资源记录包含重写规则的DDDS数据库。此数据库的密钥编码为域名。
The output of the First Well Known Rule for the ENUM Application is the E.164 number minus all non-digit characters except for the +. In order to convert this to a unique key in this Database the string is converted into a domain-name according to this algorithm:
ENUM应用程序的第一条众所周知的规则的输出是E.164数字减去除+以外的所有非数字字符。为了将其转换为该数据库中的唯一密钥，将根据以下算法将字符串转换为域名：
1. Remove all characters with the exception of the digits. For example, the First Well Known Rule produced the Key "+442079460148". This step would simply remove the leading "+", producing "442079460148".
1. 删除除数字以外的所有字符。例如，第一条众所周知的规则产生了键“+442079460148”。此步骤只需删除前导的“+”，生成“442079460148”。
2. Put dots (".") between each digit. Example: 4.4.2.0.7.9.4.6.0.1.4.8
2. 在每个数字之间加上点（“.”）。示例：4.4.2.0.7.9.4.6.0.1.4.8
3. Reverse the order of the digits. Example: 8.4.1.0.6.4.9.7.0.2.4.4
3. 颠倒数字的顺序。示例：8.4.1.0.6.4.9.7.0.2.4.4
4. Append the string ".e164.arpa" to the end. Example: 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa
4. 在末尾追加字符串“.e164.arpa”。示例：8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa
This domain-name is used to request NAPTR records which may contain the end result or, if the flags field is blank, produces new keys in the form of domain-names from the DNS.
此域名用于请求可能包含最终结果的NAPTR记录，或者，如果标志字段为空，则从DNS生成域名形式的新密钥。
Some nameserver implementations attempt to be intelligent about items that are inserted into the additional information section of a given DNS response. For example, BIND will attempt to determine if it is authoritative for a domain whenever it encodes one into a packet. If it is, then it will insert any A records it finds for that domain into the additional information section of the answer until the packet reaches the maximum length allowed. It is therefore potentially useful for a client to check for this additional information. It is also easy to contemplate an ENUM enhanced nameserver that understand the actual contents of the NAPTR records it is serving and inserts more appropriate information into the additional information section of the response. Thus, DNS servers MAY interpret Flag values and use that information to include appropriate resource records in the Additional Information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See the Additional Information Processing section of RFC 3403 [2], Section 4.2 for more information on NAPTR records and the Additional Information section of a DNS response packet.
某些名称服务器实现试图对插入到给定DNS响应的附加信息部分的项进行智能化。例如，每当BIND将一个域编码到一个数据包中时，它将尝试确定它是否对一个域具有权威性。如果是，那么它将把为该域找到的任何A记录插入应答的附加信息部分，直到数据包达到允许的最大长度。因此，客户机检查此附加信息可能很有用。还可以很容易地考虑一个ENUM增强的名称服务器，它可以理解它所服务的NAPTR记录的实际内容，并在响应的附加信息部分插入更合适的信息。因此，DNS服务器可以解释标志值并使用该信息在DNS分组的附加信息部分中包括适当的资源记录。鼓励客户查看更多信息，但不要求客户查看。有关NAPTR记录和DNS响应数据包的附加信息部分的更多信息，请参阅RFC 3403[2]的附加信息处理部分，第4.2节。
The character set used to encode the substitution expression is UTF-8. The allowed input characters are all those characters that are allowed anywhere in an E.164 number. The characters allowed to be in a Key are those that are currently defined for DNS domain-names.
用于编码替换表达式的字符集是UTF-8。允许的输入字符是E.164号码中任何位置允许的所有字符。密钥中允许的字符是当前为DNS域名定义的字符。
This Database contains a field that contains flags that signal when the DDDS algorithm has finished. At this time only one flag, "U", is defined. This means that this Rule is the last one and that the output of the Rule is a URI [4]. See RFC 3404 [3].
此数据库包含一个字段，其中包含DDDS算法完成时发出信号的标志。此时仅定义了一个标志“U”。这意味着该规则是最后一条规则，并且该规则的输出是一个URI[4]。参见RFC 3404[3]。
If a client encounters a record with an unknown flag, it MUST ignore it and move to the next Rule. This test takes precedence over any ordering since flags can control the interpretation placed on fields.
如果客户机遇到带有未知标志的记录，它必须忽略该记录并移动到下一个规则。此测试优先于任何顺序，因为标志可以控制放置在字段上的解释。
A novel flag might change the interpretation of the regexp and/or replacement fields such that it is impossible to determine if a record matched a given target.
新标志可能会更改regexp和/或替换字段的解释，从而无法确定记录是否与给定目标匹配。
If this flag is not present then this rule is non-terminal. If a Rule is non-terminal then clients MUST use the Key produced by this Rewrite Rule as the new Key in the DDDS loop (i.e., causing the client to query for new NAPTR records at the domain-name that is the result of this Rule).
如果此标志不存在，则此规则为非终端。如果规则是非终端的，则客户端必须使用此重写规则生成的密钥作为DDDS循环中的新密钥（即，使客户端在作为此规则结果的域名上查询新的NAPTR记录）。
Service Parameters for this Application take the following form and are found in the Service field of the NAPTR record.
此应用程序的服务参数采用以下形式，可在NAPTR记录的服务字段中找到。
service-field = "E2U" 1*(servicespec)
servicespec = "+" enumservice
enumservice = type 0*(subtypespec)
subtypespec = ":" subtype
type = 1*32(ALPHA / DIGIT)
subtype = 1*32(ALPHA / DIGIT)
service-field = "E2U" 1*(servicespec)
servicespec = "+" enumservice
enumservice = type 0*(subtypespec)
subtypespec = ":" subtype
type = 1*32(ALPHA / DIGIT)
subtype = 1*32(ALPHA / DIGIT)
In other words, a non-optional "E2U" (used to denote ENUM only Rewrite Rules in order to mitigate record collisions) followed by 1 or more or more Enumservices which indicate what class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character.
换句话说，一个非可选的“E2U”（用于表示仅枚举重写规则以减轻记录冲突），后跟一个或多个枚举服务，指示给定端点提供的功能类别。每个Enumservice都由一个初始“+”字符表示。
Enumservice specifications contain the functional specification (i.e., what it can be used for), the valid protocols, and the URI schemes that may be returned. Note that there is no implicit mapping between the textual string "type" or "subtype" in the grammar for the Enumservice and URI schemes or protocols. The mapping, if any, must be made explicit in the specification for the Enumservice itself. A registration of a specific Type also has to specify the Subtypes allowed.
Enumservice规范包含功能规范（即，它可以用于什么）、有效协议和可能返回的URI方案。请注意，Enumservice语法中的文本字符串“type”或“subtype”与URI方案或协议之间没有隐式映射。映射（如果有）必须在Enumservice本身的规范中明确。特定类型的注册还必须指定允许的子类型。
The only exception to the registration rule is for Types and Subtypes used for experimental purposes, and those are to start with the facet "X-". These elements are unregistered, experimental, and should be used only with the active agreement of the parties exchanging them.
注册规则的唯一例外是用于实验目的的类型和子类型，这些类型和子类型以facet“X-”开头。这些元素是未注册的、实验性的，只有在交换它们的各方积极同意的情况下才能使用。
The registration mechanism is specified in Section 3.
第3节规定了登记机制。
There has been some confusion over what exactly an ENUM Resolver returns and what relation that has to the 'Note 1' section in RFC 3402. On first reading it seems as though it might be possible for an ENUM Resolver to return two Rules.
对于枚举解析器究竟返回什么以及与RFC3402中的“note1”部分有什么关系，存在一些混淆。在第一次阅读时，似乎枚举解析器可能返回两个规则。
The ENUM algorithm always returns a single rule. Specific applications may have application-specific knowledge or facilities that allow them to present multiple results or speed selection, but these should never change the operation of the algorithm.
枚举算法始终返回单个规则。特定应用程序可能具有特定于应用程序的知识或设施，允许它们呈现多个结果或速度选择，但这些不应改变算法的操作。
As specified in the ABNF found in Section 2.4.2, an 'enumservice' is made up of 'types' and 'subtypes'. For any given 'type', the allowable 'subtypes' must be specified in the registration. There is currently no concept of a registered 'subtype' outside the scope of a given 'type'. Thus the registration process uses the 'type' as its main key within the IANA Registry. While the combination of each type and all of its subtypes constitutes the allowed values for the 'enumservice' field, it is not sufficient to simply document those values. A complete registration will also include the allowed URI schemes, a functional specification, security considerations, intended usage, and any other information needed to allow for interoperability within ENUM. In order to be a registered ENUM Service, the entire specification, including the template, requires approval by the IESG and publication of the Enumservice registration specification as an RFC.
如第2.4.2节ABNF所述，“enumservice”由“类型”和“子类型”组成。对于任何给定的“类型”，必须在注册中指定允许的“子类型”。目前，在给定“类型”的范围之外没有注册“子类型”的概念。因此，注册过程使用“类型”作为IANA注册表中的主键。虽然每个类型及其所有子类型的组合构成了“enumservice”字段的允许值，但仅仅记录这些值是不够的。完整的注册还将包括允许的URI方案、功能规范、安全注意事项、预期用途，以及允许在ENUM中实现互操作性所需的任何其他信息。为了成为已注册的ENUM服务，整个规范（包括模板）需要得到IESG的批准，并将Enumservice注册规范作为RFC发布。
Service registration proposals are all expected to conform to various requirements laid out in the following sections.
服务注册建议均应符合以下各节规定的各项要求。
A registered Enumservice must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify what is expected when using that very NAPTR record, and the URI which is the outcome of the use of it.
当从另一个NAPTR资源记录中选择一个NAPTR资源记录时，注册的Enumservice必须能够充当选择机制。这意味着注册必须指定在使用该NAPTR记录时所期望的内容，以及作为使用结果的URI。
Specifically, a registered Enumservice MUST specify the URI scheme(s) that may be used for the Enumservice, and, when needed, other information which will have to be transferred into the URI resolution process itself (LDAP Distinguished Names, transferring of the AUS into the resulting URI, etc).
具体而言，注册的Enumservice必须指定可用于Enumservice的URI方案，以及在需要时必须传输到URI解析过程本身的其他信息（LDAP可分辨名称、将AU传输到结果URI中等）。
An Enumservice MUST be unique in order to be useful as a selection criteria. Since an Enumservice is made up of a type and a type-dependent subtype, it is sufficient to require that the 'type' itself be unique. The 'type' MUST be unique, conform to the ABNF specified in Section 2.4.2, and MUST NOT start with the facet "X-" which is reserved for experimental, private use.
Enumservice必须是唯一的，才能用作选择标准。由于Enumservice由类型和依赖类型的子类型组成，因此要求“类型”本身是唯一的就足够了。“类型”必须是唯一的，符合第2.4.2节中规定的ABNF，并且不得以面“X-”开头，该面保留供实验和私人使用。
The subtype, being dependent on the type, MUST be unique within a given 'type'. It must conform to the ABNF specified in Section 2.4.2, and MUST NOT start with the facet "X-" which is reserved for experimental, private use. The subtype for one type MAY be the same as a subtype for a different registered type but it is not sufficient to simply reference another type's subtype. The function of each subtype must be specified in the context of the type being registered.
依赖于类型的子类型在给定的“类型”中必须是唯一的。它必须符合第2.4.2节中规定的ABNF，并且不得以刻面“X-”开始，该刻面保留供实验、私人使用。一个类型的子类型可能与另一个注册类型的子类型相同，但仅引用另一个类型的子类型是不够的。必须在注册的类型的上下文中指定每个子类型的函数。
An analysis of security issues is required for all registered Enumservices. (This is in accordance with the basic requirements for all IETF protocols.)
所有注册的EnumService都需要对安全问题进行分析。（这符合所有IETF协议的基本要求。）
All descriptions of security issues must be as accurate as possible regardless of registration tree. In particular, a statement that there are "no security issues associated with this Enumservice" must not be confused with "the security issues associated with this Enumservice have not been assessed".
无论注册树如何，安全问题的所有描述都必须尽可能准确。特别是，不能将“不存在与此Enumservice关联的安全问题”的声明与“未评估与此Enumservice关联的安全问题”混淆。
There is no requirement that an Enumservice must be secure or completely free from risks. Nevertheless, all known security risks must be identified in the registration of an Enumservice.
没有要求Enumservice必须是安全的或完全没有风险的。然而，必须在注册Enumservice时识别所有已知的安全风险。
The security considerations section of all registrations is subject to continuing evaluation and modification.
所有注册的“安全注意事项”部分将继续进行评估和修改。
Some of the issues that should be looked at in a security analysis of an Enumservice are:
在对Enumservice进行安全性分析时应注意的一些问题包括：
1. Complex Enumservices may include provisions for directives that institute actions on a user's resources. In many cases provision can be made to specify arbitrary actions in an unrestricted fashion which may then have devastating results. Especially if there is a risk for a new ENUM lookup, and because of that an infinite loop in the overall resolution process of the E.164.
1. 复杂的枚举服务可能包括对用户资源执行操作的指令的规定。在许多情况下，可以作出规定，以不受限制的方式规定任意行动，这可能会产生毁灭性的后果。特别是如果存在新枚举查找的风险，并且因此在E.164的整体解析过程中存在无限循环。
2. Complex Enumservices may include provisions for directives that institute actions which, while not directly harmful, may result in disclosure of information that either facilitates a subsequent attack or else violates the users privacy in some way.
2. 复杂的Enumservices可能包括一些指令的规定，这些指令采取的行动虽然不直接有害，但可能会导致信息泄露，从而助长后续攻击或以某种方式侵犯用户隐私。
3. An Enumservice might be targeted for applications that require some sort of security assurance but do not provide the necessary security mechanisms themselves. For example, an Enumservice could be defined for storage of confidential security services information such as alarm systems or message service passcodes, which in turn require an external confidentiality service.
3. Enumservice可能针对需要某种安全保证但本身不提供必要安全机制的应用程序。例如，可以定义Enumservice来存储机密安全服务信息，例如报警系统或消息服务密码，而这些信息反过来又需要外部机密服务。
Proposals for Enumservices registrations MUST be published as one of the following documents; RFC on the Standards Track, Experimental RFC, or as a BCP.
服务注册建议书必须作为以下文件之一发布：；标准轨道上的RFC、实验性RFC或BCP。
IANA will retain copies of all Enumservice registration proposals and "publish" them as part of the Enumservice Registration tree itself.
IANA将保留所有Enumservice注册建议的副本，并将其作为Enumservice注册树本身的一部分“发布”。
Provided that the Enumservice has obtained the necessary approval, and the RFC is published, IANA will register the Enumservice and make the Enumservice registration available to the community in addition to the RFC publication itself.
如果Enumservice已获得必要的批准，并且RFC已发布，IANA将注册Enumservice，并在RFC发布本身之外向社区提供Enumservice注册。
Enumservice registrations will be published in the IANA repository and made available via anonymous FTP at the following URI: "ftp://ftp.iana.org/assignments/enum-services/".
Enumservice注册将在IANA存储库中发布，并通过匿名FTP在以下URI处提供：ftp://ftp.iana.org/assignments/enum-services/".
Change control of Enumservices stay with the IETF via the RFC publication process. Especially, Enumservice registrations may not be deleted; Enumservices which are no longer believed appropriate for use can be declared OBSOLETE by publication of a new RFC and a change to their "intended use" field; such Enumservice will be clearly marked in the lists published by IANA.
Enumservices的变更控制通过RFC发布过程由IETF负责。特别是，不能删除服务注册；通过发布新的RFC并更改其“预期用途”字段，可以宣布不再适合使用的服务为过时服务；IANA发布的列表中将明确标明此类服务。
Enumservice Type:
枚举服务类型：
Enumservice Subtype(s):
枚举服务子类型：
URI Scheme(s):
URI方案：
Functional Specification:
功能规格：
Security considerations:
安全考虑：
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
预期用途：（通用、有限用途或过时）
Author:
作者：
Any other information that the author deems interesting:
作者认为有趣的任何其他信息：
Note: In the case where a particular field has no value, that field is left completely blank, especially in the case where a given type has no subtypes.
注意：在特定字段没有值的情况下，该字段完全保留为空，特别是在给定类型没有子类型的情况下。
The examples below use theoretical services that contain Enumservices which might not make sense, but that are still used for educational purposes. For example, the protocol used is in some cases exactly the same string as the URI scheme. That was the specification in RFC 2916, but this 'default' specification of an Enumservice is no longer allowed. All Enumservices need to be registered explicitly by the procedure specified in section Section 3.
下面的示例使用的理论服务包含可能没有意义但仍用于教育目的的枚举服务。例如，在某些情况下，所使用的协议与URI方案的字符串完全相同。这是RFC2916中的规范，但不再允许Enumservice的这种“默认”规范。所有Enumservices都需要通过第3节中指定的过程进行显式注册。
$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" . NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" . NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" .
$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa。NAPTR 10 100“u”E2U+sip“！^.*$！sip:info@example.com!" . NAPTR 10 101“u”E2U+h323“！^.*$！h323:info@example.com!" . NAPTR 10 102“u”E2U+msg“！^.*$！邮件收件人：info@example.com!" .
This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is preferably contacted by SIP, secondly via H.323 for voice, and thirdly by SMTP for messaging. Note that the tokens "sip", "h323", and "msg" are Types registered with IANA, and they have no implicit connection with the protocols or URI schemes with the same names.
这说明域3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa。最好通过SIP进行联系，第二次通过H.323进行语音联系，第三次通过SMTP进行消息传递。注意，令牌“sip”、“h323”和“msg”是向IANA注册的类型，它们与具有相同名称的协议或URI方案没有隐式连接。
In all cases, the next step in the resolution process is to use the resolution mechanism for each of the protocols, (specified by the URI schemes sip, h323 and mailto) to know what node to contact for each.
在所有情况下，解析过程的下一步是使用每个协议的解析机制（由URI方案sip、h323和mailto指定），以了解每个协议要联系的节点。
RFC 2916 (which this document replaces) requested IANA to delegate the E164.ARPA domain following instructions to be provided by the IAB. The domain was delegated according to those instructions. Names within this zone are to be delegated to parties according to the ITU-T Recommendation E.164. The names allocated should be hierarchic in accordance with ITU-T Recommendation E.164, and the codes should be assigned in accordance with that Recommendation.
RFC 2916（本文件取代）要求IANA按照IAB提供的指示授权E164.ARPA域。根据这些指示委派了域。根据ITU-T建议E.164，该区域内的名称将委托给各方。根据ITU-T建议E.164，分配的名称应具有层次性，代码应根据该建议分配。
IAB is to coordinate with ITU-T TSB if the technical contact for the domain e164.arpa is to change, as ITU-T TSB has an operational working relationship with this technical contact which needs to be reestablished.
如果域e164.arpa的技术联系人发生变化，IAB将与ITU-T TSB进行协调，因为ITU-T TSB与该技术联系人之间存在业务工作关系，需要重新建立。
Delegations in the zone e164.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert.
e164.arpa区域内的授权（不是e164.arpa授权域内的授权）应在专家审查后完成，IESG将任命一名指定专家。
IANA has created a registry for Enumservices as specified in Section 3. Whenever a new Enumservice is registered by the RFC process in the IETF, IANA is at the time of publication of the RFC to register the Enumservice and add a pointer to the RFC itself.
IANA已按照第3节的规定为Enumservices创建了一个注册表。每当RFC进程在IETF中注册新的Enumservice时，IANA都会在RFC发布时注册Enumservice并添加指向RFC本身的指针。
As ENUM uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the data one gets back is authentic. As ENUM is deployed on the global Internet, it is expected to be a popular target for various kind of attacks, and attacking the underlying DNS infrastructure is one way of attacking the ENUM service itself.
由于ENUM使用DNS，而DNS目前的形式是一种不安全的协议，因此没有任何机制来确保返回的数据是真实的。由于ENUM部署在全球互联网上，预计它将成为各种攻击的热门目标，攻击底层DNS基础设施是攻击ENUM服务本身的一种方式。
There are multiple types of attacks that can happen against DNS that ENUM implementations should be aware of. The following threats are taken from Threat Analysis Of The Domain Name System [10]:
枚举实现应该注意针对DNS可能发生的多种类型的攻击。以下威胁来自域名系统的威胁分析[10]：
Packet Interception Some of the simplest threats against DNS are various forms of packet interception: monkey-in-the-middle attacks, eavesdropping on requests combined with spoofed responses that beat the real response back to the resolver, and so forth. In any of these
数据包截获针对DNS的一些最简单的威胁是各种形式的数据包截获：中间猴子攻击、结合欺骗响应的请求窃听，这些欺骗响应将真实响应打回到解析程序，等等。在任何一种情况下
scenarios, the attacker can simply tell either party (usually the resolver) whatever it wants that party to believe. While packet interception attacks are far from unique to DNS, DNS's usual behavior of sending an entire query or response in a single unsigned, unencrypted UDP packet makes these attacks particularly easy for any bad guy with the ability to intercept packets on a shared or transit network.
在这种情况下，攻击者可以简单地告诉任何一方（通常是解析器）它希望该方相信的任何内容。虽然数据包截获攻击远不是DNS独有的，但DNS通常在一个未签名、未加密的UDP数据包中发送整个查询或响应，这使得这些攻击对于任何有能力在共享或传输网络上截获数据包的坏人来说尤其容易。
ID Guessing and Query Prediction Since the ID field in the DNS header is only a 16-bit field and the server UDP port associated with DNS is a well-known value, there are only 2**32 possible combinations of ID and client UDP port for a given client and server. Thus it is possible for a reasonable brute force attack to allow an attacker to masquerade as a trusted server. In most respects, this attack is similar to a packet interception attack except that it does not require the attacker to be on a transit or shared network.
ID猜测和查询预测由于DNS标头中的ID字段仅为16位字段，且与DNS关联的服务器UDP端口为已知值，因此对于给定的客户端和服务器，只有2**32个可能的ID和客户端UDP端口组合。因此，合理的暴力攻击有可能使攻击者伪装成受信任的服务器。在大多数方面，此攻击与数据包拦截攻击相似，只是它不要求攻击者位于传输或共享网络上。
Name-based Attacks Name-based attacks use the actual DNS caching behavior as a tool to insert bad data into a victim's cache, thus potentially subverting subsequent decisions based on DNS names. Most examples occur with CNAME, NS and DNAME Resource Records as they redirect a victim's query to another location. The common thread in all of these attacks is that response messages allow the attacker to introduce arbitrary DNS names of the attacker's choosing and provide further information that the attacker claims is associated with those names; unless the victim has better knowledge of the data associated with those names, the victim is going to have a hard time defending against this class of attacks.
基于名称的攻击基于名称的攻击将实际的DNS缓存行为用作将坏数据插入受害者缓存的工具，从而可能破坏基于DNS名称的后续决策。大多数示例都出现在CNAME、NS和DNAME资源记录中，因为它们将受害者的查询重定向到另一个位置。所有这些攻击的共同点是，响应消息允许攻击者引入攻击者选择的任意DNS名称，并提供攻击者声称与这些名称相关的进一步信息；除非受害者更好地了解与这些姓名相关的数据，否则受害者将很难抵御此类攻击。
Betrayal By A Trusted Server Another variation on the packet interception attack is the trusted server that turns out not to be so trustworthy, whether by accident or by intent. Many client machines are only configured with stub resolvers, and use trusted servers to perform all of their DNS queries on their behalf. In many cases the trusted server is furnished by the user's ISP and advertised to the client via DHCP or PPP options. Besides accidental betrayal of this trust relationship (via server bugs, successful server break-ins, etc), the server itself may be configured to give back answers that are not what the user would expect (whether in an honest attempt to help the user or to further some other goal such as furthering a business partnership between the ISP and some third party).
受信任服务器的背叛数据包拦截攻击的另一个变体是被证明不那么可信的受信任服务器，无论是出于偶然还是出于故意。许多客户端计算机仅配置了存根解析程序，并使用受信任的服务器代表它们执行所有DNS查询。在许多情况下，受信任的服务器由用户的ISP提供，并通过DHCP或PPP选项向客户端公布。除了意外背叛这种信任关系（通过服务器错误、成功的服务器入侵等），服务器本身可能会被配置为返回用户不期望的答案（无论是为了真诚地帮助用户，还是为了进一步实现其他目标，如促进ISP与第三方之间的业务合作）。
Denial of Service As with any network service (or, indeed, almost any service of any kind in any domain of discourse), DNS is vulnerable to denial of service attacks. DNS servers are also at risk of being used as denial of service amplifiers, since DNS response packets tend to be significantly longer than DNS query packets.
拒绝服务与任何网络服务（或者，事实上，任何话语领域中几乎任何类型的服务）一样，DNS容易受到拒绝服务攻击。DNS服务器也有被用作拒绝服务放大器的风险，因为DNS响应数据包往往比DNS查询数据包长得多。
Authenticated Denial of Domain Names The existence of RR types whose absence causes an action other than immediate failure (such as missing MX and SRV RRs, which fail over to A RRs) constitutes a real threat. In the specific case of ENUM, even the immediate failure of a missing RR can be considered a problem as a method for changing call routing policy.
已验证的域名拒绝存在RR类型，其缺失会导致除即时故障以外的其他行为（如缺失MX和SRV RRs，其故障转移到RRs）构成真正的威胁。在ENUM的特定情况下，即使缺少RR的即时故障也可以被视为更改呼叫路由策略的方法的问题。
Because of these threats, a deployed ENUM service SHOULD include mechanisms which ameliorate these threats. Most of these threats can be solved by verifying the authenticity of the data via mechanisms such as DNSSEC [8] once it is deployed. Others, such and Denial Of Service attacks, cannot be solved by data authentication. It is important to remember that these threats include not only the NAPTR lookups themselves, but also the various records needed for the services to be useful (for example NS, MX, SRV and A records).
由于这些威胁，部署的ENUM服务应该包括改善这些威胁的机制。部署数据后，通过DNSSEC[8]等机制验证数据的真实性，可以解决大多数威胁。数据认证无法解决其他攻击，如攻击和拒绝服务攻击。必须记住，这些威胁不仅包括NAPTR查找本身，还包括服务有用所需的各种记录（例如NS、MX、SRV和A记录）。
Even if DNSSEC is deployed, a service that uses ENUM for address translation should not blindly trust that the peer is the intended party as all kind of attacks against DNS can not be protected against with DNSSEC. A service should always authenticate the peers as part of the setup process for the service itself and never blindly trust any kind of addressing mechanism.
即使部署了DNSSEC，使用ENUM进行地址转换的服务也不应盲目相信对等方是目标方，因为DNSSEC无法防止针对DNS的各种攻击。作为服务本身设置过程的一部分，服务应该始终对对等方进行身份验证，并且永远不要盲目信任任何类型的寻址机制。
Finally, as an ENUM service will be implementing some type of security mechanism, software which implements ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses, including large responses, EDNS0 signaling, unknown RRs, etc.
最后，由于ENUM服务将实现某种类型的安全机制，因此实现ENUM的软件必须准备好接收DNSSEC和其他标准化DNS安全响应，包括大型响应、EDNS0信令、未知RRs等。
The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR records in the zone that is changed. The use of this in an environment where IP-addresses are for hire (for example, when using DHCP [9]) must therefore be done very carefully.
DNS中的缓存可以使更改的传播时间与更改区域中NAPTR记录的生存时间相同。因此，在IP地址出租的环境中（例如，在使用DHCP[9]时），必须非常小心地使用此功能。
There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name-translation services. In these areas, any system that permits users,
许多国家（和其他编号环境）都有多家呼叫路由和号码/姓名翻译服务提供商。在这些区域，任何允许用户，
or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes.
或假定的用户代理更改路由或供应商信息可能会为实际未经授权的更改提供激励（在某些情况下，还会拒绝合法的更改请求）。此类环境的设计应具有适当的机制，用于识别和验证请求变更的人以及授权这些变更。
A large amount of Security Issues have to do with the resolution process itself, and use of the URIs produced by the DDDS mechanism. Those have to be specified in the registration of the Enumservice used, as specified in Section 3.1.3.
大量的安全问题与解决过程本身以及DDDS机制产生的URI的使用有关。根据第3.1.3节的规定，必须在所使用的Enumservice的注册中指定。
Support and ideas leading to RFC 2916 have come from people at Ericsson, Bjorn Larsson and the group which implemented this scheme in their lab to see that it worked. Input has also arrived from ITU-T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and Enumservice Definition), the ENUM working group in the IETF, John Klensin and Leif Sunnegardh.
爱立信、比约恩·拉尔森以及在实验室实施该方案以确保其有效性的小组的人员对RFC2916的支持和想法。ITU-T SG2、工作组1/2（编号、路由、全球移动和Enumservice定义）、IETF中的ENUM工作组、John Klesins和Leif Sunnegardh也提供了投入。
This update of RFC 2916 is created with specific input from: Randy Bush, David Conrad, Richard Hill, Jon Peterson, Jim Reid, Joakim Stralmark, Robert Walter and James Yu.
RFC 2916的此更新是根据以下人员的具体输入创建的：兰迪·布什、大卫·康拉德、理查德·希尔、乔恩·彼得森、吉姆·里德、约阿金·斯特拉马克、罗伯特·沃尔特和詹姆斯·余。
Part from clarifications in the text in this document, the major changes are two:
从本文件文本中的澄清部分来看，主要变化有两个：
The document uses an explicit DDDS algorithm, and not only NAPTR resource records in an "ad-hoc" mode. In reality this doesn't imply any changes in deployed base of applications, as the algorithm used for ENUM resolution is exactly the same.
该文档使用了显式DDDS算法，而不仅仅是“即席”模式下的NAPTR资源记录。实际上，这并不意味着部署的应用程序基础有任何变化，因为用于枚举解析的算法完全相同。
The format of the service field has changed. The old format was of the form "example+E2U", while the new format is "E2U+example". Reason for this change have to with the added subtypes in the enumservice, the ability to support more than one enumservice per NAPTR RR, and a general agreement in the IETF that the main selector between different NAPTR with the same owner (E2U in this case) should be first.
服务字段的格式已更改。旧格式为“示例+E2U”，而新格式为“E2U+示例”。此更改的原因必须与enumservice中添加的子类型、每个NAPTR RR支持多个enumservice的能力以及IETF中的一般协议有关，即应首先选择具有相同所有者的不同NAPTR（在本例中为E2U）之间的主选择器。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[2] Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[3] Mealling，M.“动态委托发现系统（DDDS）第四部分：统一资源标识符（URI）解析应用”，RFC3404，2002年10月。
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[5] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997.
[5] ITU-T，“国际公共电信号码计划”，建议E.164，1997年5月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[6] Mealling，M，“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[7] Mealling，M.，“动态委托发现系统（DDDS）第二部分：算法”，RFC3402，2002年10月。
[8] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[8] Eastlake，D.，“域名系统安全扩展”，RFC 25351999年3月。
[9] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[9] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[10] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name System", Work in Progress, April 2004.
[10] Atkins，D.和R.Austein，“域名系统的威胁分析”，正在进行的工作，2004年4月。
Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden
Patrik Faltstrom思科系统有限公司Ledasa 273 71瑞典洛夫斯塔德
EMail: paf@cisco.com
URI: http://www.cisco.com
EMail: paf@cisco.com
URI: http://www.cisco.com
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling，弗吉尼亚州，美国20166
Email: michael@verisignlabs.com
URI: http://www.verisignlabs.com
Email: michael@verisignlabs.com
URI: http://www.verisignlabs.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编辑功能的资金目前由互联网协会提供。