Network Working Group M. Haberler
Request for Comments: 5527 IPA
Category: Informational O. Lendl
enum.at
R. Stastny
Unaffiliated
May 2009
Network Working Group M. Haberler
Request for Comments: 5527 IPA
Category: Informational O. Lendl
enum.at
R. Stastny
Unaffiliated
May 2009
Combined User and Infrastructure ENUM in the e164.arpa Tree
e164.arpa树中的组合用户和基础结构枚举
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 memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after implementation of the long-term solution.
本备忘录定义了基础设施枚举的临时解决方案，以允许在e164.arpa中结合用户和基础设施枚举实施，作为国家选择。在实施长期解决方案后，将不推荐使用此临时解决方案。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Interim Solution ................................................3
4. The Algorithm ...................................................4
5. Determining the Position of the Branch ..........................5
6. Transition to the Long-Term Solution ............................6
7. Examples ........................................................7
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Interim Solution ................................................3
4. The Algorithm ...................................................4
5. Determining the Position of the Branch ..........................5
6. Transition to the Long-Term Solution ............................6
7. Examples ........................................................7
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms E.164 numbers [E164] into domain names and then queries the DNS (Domain Name Service) [RFC1034] for NAPTR (Naming Authority Pointer) records [RFC3401] in order to look up which services are available for a specific domain name.
ENUM（E.164数字映射[RFC3761]）是一个系统，它将E.164数字[E164]转换为域名，然后查询DNS（域名服务）[RFC1034]中的NAPTR（命名机构指针）记录[RFC3401]，以便查找特定域名的可用服务。
ENUM, as defined in RFC 3761 (User ENUM), is not well suited for the purpose of interconnection by carriers and voice-service providers, as can be seen by the use of various private tree arrangements based on ENUM mechanisms.
RFC 3761（用户ENUM）中定义的ENUM不适合运营商和语音服务提供商进行互连，这可以从基于ENUM机制的各种私有树安排的使用中看出。
Infrastructure ENUM is defined as the use of the technology in RFC 3761 [RFC3761] by the carrier-of-record (voice service provider) [RFC5067] for a specific E.164 number [E164] in order to publish a mapping of this telephone number to one or more Uniform Resource Identifiers (URIs) [RFC3986].
基础设施枚举定义为记录载体（语音服务提供商）[RFC5067]对特定E.164号码[E164]使用RFC 3761[RFC3761]中的技术，以发布该电话号码到一个或多个统一资源标识符（URI）[RFC3986]的映射。
Other voice service providers can query the DNS for this mapping and use the resulting URIs as input into their call-routing algorithm. These URIs are separate from any URIs that the end-user who registers an E.164 number in ENUM may wish to associate with that E.164 number.
其他语音服务提供商可以查询DNS以获取此映射，并使用生成的URI作为其呼叫路由算法的输入。这些URI与在ENUM中注册E.164号的最终用户可能希望与该E.164号关联的任何URI是分开的。
The requirements, terms, and definitions for Infrastructure ENUM are defined in [RFC5067].
[RFC5067]中定义了基础设施枚举的要求、术语和定义。
Using the same E.164 number to domain mapping techniques for other applications under a different, internationally agreed-upon apex (instead of e164.arpa) is straightforward on the technical side. This process of defining the Dynamic Delegation Discovery System (DDDS) [RFC3401] application for Infrastructure ENUM is defined in [RFC5526]. This is the long-term solution.
在不同的、国际商定的apex（而不是e164.arpa）下，为其他应用程序使用相同的E.164数字到域映射技术在技术方面是很简单的。[RFC5526]中定义了为基础结构枚举定义动态委派发现系统（DDDS）[RFC3401]应用程序的过程。这是长期的解决办法。
This document presents an interim solution for Infrastructure ENUM and a mechanism for transitioning to the long-term solution. The interim solution is based on establishing a branch in the e164.arpa tree, which resolvers may locate by following the algorithm described in Section 4. The location of the branch is dependent upon country-code length, and thus resolvers must determine the position of the branch based on the method described in Section 5. Finally, Section 6 provides a way that implementations following the procedures of Sections 4 and 5 may be seamlessly redirected to the long-term solution, when it becomes available.
本文档介绍了基础架构ENUM的临时解决方案以及向长期解决方案过渡的机制。临时解决方案基于在e164.arpa树中建立分支，解析器可以按照第4节中描述的算法定位该分支。分支的位置取决于国家代码长度，因此解析程序必须根据第5节中描述的方法确定分支的位置。最后，第6节提供了一种方法，当长期解决方案可用时，遵循第4节和第5节的过程的实现可以无缝地重定向到长期解决方案。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
The agreements to establish the long-term solution may take some time. It was therefore decided to develop an interim solution that can be used by individual countries to implement an interoperable Infrastructure ENUM tree immediately. The interim solution will be deprecated when the long-term solution [RFC5526] is deployed. It is therefore also required that the interim solution includes a smooth migration path to the long-term solution.
建立长期解决方案的协议可能需要一些时间。因此，决定制定一个临时解决方案，供个别国家使用，以立即实施可互操作的基础设施枚举树。当部署长期解决方案[RFC5526]时，临时解决方案将被弃用。因此，还要求临时解决方案包括一条通往长期解决方案的平滑过渡路径。
It is also required that existing ENUM clients querying User ENUM as defined in RFC 3761 [RFC3761] continue to work without any modification.
还要求查询RFC 3761[RFC3761]中定义的用户ENUM的现有ENUM客户端在不进行任何修改的情况下继续工作。
Because of various reasons (e.g., potentially different delegation points, different reliability requirements, and use of DNS wildcards), sharing a single domain name between the user itself and the respective carrier for a given number is not possible. Hence, a different domain name must be used to store infrastructure ENUM information.
由于各种原因（例如，可能不同的委托点、不同的可靠性要求和DNS通配符的使用），不可能在用户本身和给定号码的相应运营商之间共享单个域名。因此，必须使用不同的域名来存储基础结构枚举信息。
In order to avoid the delays associated with the long-term solution, the existing delegations and agreements around e164.arpa need to be leveraged.
为了避免与长期解决方案相关的延迟，需要利用围绕e164.arpa的现有授权和协议。
The method most easily fulfilling the requirements is to branch off the e164.arpa tree into a subdomain at the country-code delegation level below e164.arpa and deploy an Infrastructure ENUM subtree underneath, without touching User ENUM semantics at all.
最容易满足需求的方法是将e164.arpa树分支到e164.arpa下面国家代码授权级别的子域中，并在下面部署基础结构枚举子树，而根本不涉及用户枚举语义。
This allows countries using a dedicated country code to introduce the interim solution as a national matter to the concerned National Regulation Authority (NRA). The governing body of a shared country code and the owner of a global network code can also choose to implement this solution within their area of responsibility.
这允许使用专用国家代码的国家将临时解决方案作为国家事务提交给相关国家监管机构（NRA）。共享国家代码的管理机构和全球网络代码的所有者也可以选择在其职责范围内实施此解决方案。
Under this approach, ITU-T (International Telecommunication Union / Telecommunication Standardization Sector), IETF, and IAB involvement is only lightweight, e.g., to recommend the proper algorithm defined here to enable international interoperability.
在这种方法下，ITU-T（国际电信联盟/电信标准化部门）、IETF和IAB的参与只是轻量级的，例如，推荐此处定义的适当算法以实现国际互操作性。
RFC 3761 defines ENUM as a Dynamic Delegation Discovery System (DDDS) application according to RFC 3401 [RFC3401]. As such, ENUM defines the following components of the DDDS algorithm:
根据RFC 3401[RFC3401]，RFC 3761将ENUM定义为动态委派发现系统（DDDS）应用程序。因此，枚举定义DDDS算法的以下组件：
1. Application Unique String
1. 应用程序唯一字符串
2. First Well-Known Rule
2. 第一条众所周知的规则
3. Expected Output
3. 预期产量
4. Valid Databases
4. 有效数据库
The "Valid Databases" part contains the transformation of an E.164 telephone number into a domain name. Section 2.4 of RFC 3761 uses the following 4-step algorithm for this:
“有效数据库”部分包含将E.164电话号码转换为域名的过程。RFC 3761第2.4节使用以下四步算法：
1. Remove all characters with the exception of the digits.
1. 删除除数字以外的所有字符。
2. Put dots (".") between each digit.
2. 在每个数字之间加上点（“.”）。
3. Reverse the order of the digits.
3. 颠倒数字的顺序。
4. Append the string ".e164.arpa" to the end.
4. 在末尾追加字符串“.e164.arpa”。
The interim solution for Infrastructure ENUM uses a modified version of this algorithm:
Infrastructure ENUM的临时解决方案使用此算法的修改版本：
1. Determine the proper POSITION parameter for this E.164 number according to the algorithm in Section 5 of this document.
1. 根据本文件第5节中的算法，确定该E.164编号的正确位置参数。
2. Build an ordered list of single-digit strings from all digits appearing in the telephone number. All non-digit characters are ignored.
2. 从电话号码中出现的所有数字建立一个单位数字符串的有序列表。忽略所有非数字字符。
3. Insert a string consisting of "i" into this list, after POSITION strings. If the list of strings was shorter than POSITION elements, then report an error.
3. 在位置字符串之后，在此列表中插入一个由“i”组成的字符串。如果字符串列表短于位置元素，则报告错误。
4. Reverse the order of the list.
4. 颠倒列表的顺序。
5. Append the string "e164.arpa" to the end of the list.
5. 将字符串“e164.arpa”追加到列表的末尾。
6. Create a single domain name by joining the list together with dots (".") between each string.
6. 通过将列表与每个字符串之间的点（“.”）连接在一起，创建单个域名。
This is the only point where the interim Infrastructure ENUM (I-ENUM) solution differs from straight RFC 3761 ENUM. All other parts of User ENUM, including the enumservices registrations, apply to I-ENUM as well.
这是临时基础结构枚举（I-ENUM）解决方案与直接RFC 3761枚举唯一不同之处。用户ENUM的所有其他部分，包括enumservices注册，也适用于I-ENUM。
In order to allow for the deployment of this interim solution independent of IAB/ITU-T/RIPE-NCC negotiations, the branching label "i" cannot be inserted in the Tier-0 zone (i.e., the e164.arpa zone itself) currently managed by RIPE NCC. This condition acts as a lower bound on the choice of the POSITION parameter.
为了允许独立于IAB/ITU-T/RIME-NCC协商部署此临时解决方案，分支标签“i”不能插入当前由RIME NCC管理的0层区域（即e164.arpa区域本身）。此条件作为位置参数选择的下限。
For international E.164-numbers for geographic areas (Section 6.2.1 of [E164]) and for international E.164-numbers for global services (Section 6.2.2 of [E164]), the most sensible choice for POSITION is the number of digits in the country code of the number in question. This places the branch directly under the country-code level within the e164.arpa ENUM tree.
对于地理区域的国际E.164编号（见[E164]第6.2.1节）和全球服务的国际E.164编号（见[E164]第6.2.2节），最明智的位置选择是相关编号国家代码中的位数。这将分支直接放在e164.arpa枚举树中的国家代码级别下。
For international E.164-number for networks (Section 6.2.3 of [E164]), the appropriate choice for POSITION is the combined length of the CC (Country Code) and IC (Identification Code) fields.
对于网络的国际E.164编号（E164的第6.2.3节），适当的位置选择是CC（国家代码）和IC（识别代码）字段的组合长度。
For international E.164-number for groups of countries (Section 6.2.4 of [E164]), the value for POSITION is 4.
对于国家组的国际E.164编号（见[E164]第6.2.4节），位置值为4。
The authoritative source for up-to-date country code and network Identification Code allocations is published by the ITU-T as a complement to the recommendation E.164 [E164]. The current version of this complement is available from the ITU website under "ITU-T / Service Publications".
最新国家代码和网络标识代码分配的权威来源由ITU-T发布，作为建议E.164[E164]的补充。本补充文件的现行版本可在国际电联网站“ITU-T/服务出版物”下查阅。
Please note that country code 1 of the North American Numbering Plan (NANP) does not fall under the ITU classification of "groups of countries", but is a "shared country code" for a geographic area. Thus, the POSITION parameter for the NANP is 1.
请注意，北美编号计划（NANP）的国家代码1不属于ITU的“国家组”分类，而是一个地理区域的“共享国家代码”。因此，NANP的位置参数为1。
As of 2007, the POSITION value for a specific E.164 number can be determined with the following algorithm:
自2007年起，可使用以下算法确定特定E.164编号的位置值：
o If the number starts with 1 or 7, then POSITION is 1.
o 如果数字以1或7开头，则位置为1。
o If the number is in one of the following 2-digit country codes, then POSITION is 2: 20, 27, 30-34, 36, 39, 40, 41, 43-49, 51-58, 60-66, 81, 82, 84, 86, 90-95, or 98.
o 如果数字位于以下两位国家/地区代码之一，则位置为2:20、27、30-34、36、39、40、41、43-49、51-58、60-66、81、82、84、86、90-95或98。
o If the number starts with 388 or 881, then POSITION is 4.
o 如果数字以388或881开头，则位置为4。
o If the number starts with 878 or 882, then POSITION is 5.
o 如果数字以878或882开头，则位置为5。
o If the number starts with 883 and the next digit is < 5, then POSITION is 6.
o 如果数字以883开头，下一个数字小于5，则位置为6。
o If the number starts with 883 and the next digit is >= 5, then POSITION is 7.
o 如果数字以883开头，下一个数字>=5，则位置为7。
o In all other cases, POSITION is 3.
o 在所有其他情况下，位置为3。
Given the fact that the ITU-T recently allocated only 3-digit country codes, there are no more spare 1- and 2-digit country codes and existing 1- and 2-digit country codes are extremely unlikely to be recovered, the above list of existing 1- and 2-digit country codes can be considered very stable. The only problem may be for a country that has split, as happened recently, for example, to Yugoslavia.
鉴于ITU-T最近只分配了3位国家代码，没有多余的1位和2位国家代码，现有的1位和2位国家代码极不可能恢复，上述现有1位和2位国家代码列表可以认为非常稳定。唯一的问题可能是一个已经分裂的国家，例如最近发生在南斯拉夫的分裂。
Regarding network codes, up to 2007, the ITU-T has only allocated 1- and 2-digit ICs. Assignments of 3- and 4-digit ICs started in May 2007 in the +883 country code. Any further change in the ITU-T policy in this respect will need to be reflected in the above algorithm.
关于网络代码，截至2007年，ITU-T仅分配了1位和2位IC。3位数和4位数IC的分配于2007年5月在+883国家代码中开始。ITU-T政策在这方面的任何进一步变化都需要反映在上述算法中。
The proposed long-term solution for Infrastructure ENUM [RFC5526] is the establishment of a new zone apex for that tree. This apex will play the same role as "e164.arpa" does for User ENUM.
基础设施枚举[RFC5526]的拟议长期解决方案是为该树建立一个新的区域顶点。这个顶点将扮演与用户ENUM的“e164.arpa”相同的角色。
It is unrealistic to assume that all countries and all ENUM clients will manage to migrate from the interim solution to the long-term solution at a single point in time. It is thus necessary to plan for an incremental transition.
假设所有国家和所有ENUM客户将在一个时间点从临时解决方案迁移到长期解决方案是不现实的。因此，有必要规划渐进式过渡。
In order to achieve this, clients using the interim solution need to be redirected to the long-term I-ENUM tree for all country codes that have already switched to the long-term solution. This SHOULD be done
为了实现这一点，需要将使用临时解决方案的客户端重定向到所有已切换到长期解决方案的国家/地区代码的长期I-ENUM树。应该这样做
by placing DNAME [RFC2672] records at the branch (the "i") label pointing to the appropriate domain name in the long-term I-ENUM tree. All descendants at that branch label location where the DNAME record is inserted MUST be removed, as required by Section 3 of RFC 2672.
通过将DNAME[RFC2672]记录放置在分支（“i”）标签上，指向长期i-ENUM树中的相应域名。按照RFC 2672第3节的要求，必须删除插入DNAME记录的分支标签位置处的所有子体。
Therefore, ALL entities involved in making or answering DNS queries for I-ENUM MUST fully support the DNAME record type and its semantics. In particular, entities involved in I-ENUM lookups MUST correctly handle responses containing synthesized CNAMEs that may be generated as a consequence of DNAME processing by any other element in resolution, typically an iterative mode resolving name server.
因此，为I-ENUM进行或回答DNS查询所涉及的所有实体必须完全支持DNAME记录类型及其语义。特别是，参与I-ENUM查找的实体必须正确处理包含合成CNAME的响应，这些合成CNAME可能是解析中任何其他元素（通常是迭代模式解析名称服务器）处理DNAME的结果。
These entities MUST also apply adequate measures to detect loops and prevent non-terminating resolutions because of improperly configured DNAME records or combinations of DNAME and CNAME records.
这些实体还必须应用适当的措施来检测循环，并防止由于配置不当的DNAME记录或DNAME和CNAME记录的组合而导致的非终止解析。
Note: Some caching name server implementations are known to handle DNAMEs incorrectly. In the worst case, such bugs could stay undetected until a country transitions to the long-term solution. Therefore, ensuring full DNAME support from the start (and carefully testing that it actually works) is important.
注意：已知某些缓存名称服务器实现不正确地处理DNAME。在最坏的情况下，在一个国家过渡到长期解决方案之前，这些漏洞可能不会被发现。因此，从一开始就确保充分的DNAME支持（并仔细测试它是否实际工作）非常重要。
The domain name for the branch location and its DNAME record SHOULD be removed once the transition to the long-term solution is completed and all entities involved in I-ENUM have migrated to the new zone apex for I-ENUM.
分支位置的域名及其DNAME记录应在向长期解决方案的过渡完成且参与I-ENUM的所有实体已迁移到I-ENUM的新区域顶点后删除。
These are two examples of how E.164 numbers translate to Infrastructure ENUM domains according to the interim solution.
以下两个示例说明了根据临时解决方案，E.164数字如何转换为基础架构枚举域。
+1 21255501234 4.3.2.1.0.5.5.5.2.1.2.i.1.e164.arpa +44 2079460123 3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa
+121255501234 4.3.2.1.0.5.5.2.1.2.i.1.e164.arpa+44 2079460123.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa
Here is the list of the intermediate steps for the second example to visualize how the algorithm defined in Section 4 operates on "+44 2079460123":
以下是第二个示例的中间步骤列表，用于可视化第4节中定义的算法如何在“+44 2079460123”上运行：
1. "+44 2079460123" is within a 2-digit country code; thus, POSITION is 2.
1. “+44 2079460123”在2位国家/地区代码内；因此，位置为2。
2. The list of strings is ("4","4","2","0","7","9","4","6","0","1","2","3")
2. 字符串列表为（“4”、“4”、“2”、“0”、“7”、“9”、“4”、“6”、“0”、“1”、“2”、“3”）
3. POSITION is 2; thus, "i" is inserted between the second and the third string, yielding: ("4","4","i","2","0","7","9","4","6","0","1","2","3")
3. 位置为2；因此，在第二个字符串和第三个字符串之间插入“i”，产生：（“4”、“4”、“i”、“2”、“0”、“7”、“9”、“4”、“6”、“0”、“1”、“2”、“3”）
4. Reversing the list gives: ("3","2","1","0","6","4","9","7","0","2","i","4","4")
4. 颠倒列表给出：（“3”、“2”、“1”、“0”、“6”、“4”、“9”、“7”、“0”、“2”、“i”、“4”、“4”）
5. Appending "e164.arpa" yields: ("3","2","1","0","6","4","9","7","0","2","i","4","4","e164.arpa")
5. 附加“e164.arpa”的收益率为：（“3”、“2”、“1”、“0”、“6”、“4”、“9”、“7”、“0”、“2”、“i”、“4”、“4”、“e164.arpa”）
6. Concatenation with dots yields: "3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa"
6. 与点串联产生：“3.2.1.0.6.4.9.7.0.2.i.4.4.e164.arpa”
After the introduction of the long-term Infrastructure ENUM solution, using, for example, "ienum.example.net" as the new apex for I-ENUM, the administrators of +44 can implement a smooth transition by putting the following DNAME record in their zone:
引入长期基础架构枚举解决方案后，使用例如“ienum.example.net”作为I-ENUM的新顶点，+44的管理员可以通过在其区域中放置以下DNAME记录来实现平稳过渡：
i.4.4.e164.arpa. IN DNAME 4.4.ienum.example.net.
i、 4.4.e164.arpa。在DNAME 4.4.ienum.example.net中。
This way, clients using the interim I-ENUM solution end up querying the same tree as clients implementing the long-term solution.
这样，使用临时I-ENUM解决方案的客户机将查询与实现长期解决方案的客户机相同的树。
Privacy issues have been raised regarding the unwarranted disclosure of user information that would result from publishing Infrastructure ENUM information in the public DNS. For instance, such disclosure could be used for harvesting numbers in service or obtaining unlisted numbers.
由于在公共DNS中发布基础设施枚举信息而导致用户信息被无理披露，因此引发了隐私问题。例如，此类披露可用于获取服务中的号码或获取未列出的号码。
Given that number-range allocation is public information, we believe the easiest way to cope with such concerns is to fully unroll allocated number ranges in the Infrastructure ENUM subtree, wherever such privacy concerns exist. Whether or not a number is served would be exposed by the carrier-of-record when an attempt is made to contact the corresponding URI. We assume this to be an authenticated operation, which would not leak information to unauthorized parties.
鉴于数字范围分配是公开信息，我们认为解决此类问题的最简单方法是在基础设施枚举子树中完全展开分配的数字范围，无论存在此类隐私问题的地方。当试图联系相应的URI时，记录的载体将暴露是否提供了号码。我们假设这是一个经过身份验证的操作，不会向未经授权的方泄漏信息。
Entering all numbers in an allocated number range, whether serviced or not, or whether listed or unlisted, will prevent mining attempts for such number attributes.
输入已分配号码范围内的所有号码，无论是否已服务，或是否已列出或未列出，都将阻止对此类号码属性的挖掘尝试。
The result will be that the information in the public DNS will mirror number-range allocation information, but no more. Infrastructure ENUM will not tell you more than you can get by just dialing numbers.
结果将是公共DNS中的信息将镜像号码范围分配信息，但不再镜像。Infrastructure ENUM不会告诉您仅拨打电话号码所能得到的更多信息。
The URI pointing to the destination network of the carrier-of-record should also not disclose any privacy information about the identity of the end-user. It is therefore recommended to use either anonymized UserIDs or the E.164 number itself in the user part of the URI, such as in sip:+441632960084@example.com.
指向记录载体的目的地网络的URI也不应披露有关最终用户身份的任何隐私信息。因此，建议在URI的用户部分使用匿名用户ID或E.164号本身，例如在sip中：+441632960084@example.com.
We gratefully acknowledge suggestions and improvements by Jason Livingood and Tom Creighton of Comcast, Penn Pfautz of AT&T, Lawrence Conroy of Roke Manor Research, Jim Reid, and Alexander Mayrhofer of enum.at.
我们衷心感谢康卡斯特公司的杰森·利文戈德（Jason Livingood）和汤姆·克雷顿（Tom Creighton）、美国电话电报公司（AT&T）的潘·普法茨（Penn Pfautz）、罗克庄园研究公司（Roke Manor Research）的劳伦斯·康罗伊（Lawrence Conroy）、美国电话电报公司（enum.AT）的吉姆·里德（Jim Reid）和亚历山大。
[E164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.
[E164]ITU-T，“国际公共电信号码计划”，建议E.164，2005年2月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，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月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672]克劳福德，M.，“非终端DNS名称重定向”，RFC 26721999年8月。
[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月。
[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月。
[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月。
[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC 5067, November 2007.
[RFC5067]Lind，S.和P.Pfautz，“基础设施枚举要求”，RFC 5067，2007年11月。
[RFC5526] Livingood, J., Pfautz, P., and R. Stastny, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM", RFC 5526, April 2007.
[RFC5526]Livingood，J.，Pfautz，P.，和R.Stastny，“用于基础设施枚举的E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序”，RFC 5526，2007年4月。
Authors' Addresses
作者地址
Michael Haberler Internet Foundation Austria Karlsplatz 1/2/9 Wien 1010 Austria
米迦勒哈伯勒互联网基金会奥地利卡斯普拉茨1/2／9 Wien 1010奥地利
Phone: +43 664 4213465
EMail: ietf@mah.priv.at
URI: http://www.nic.at/ipa/
Phone: +43 664 4213465
EMail: ietf@mah.priv.at
URI: http://www.nic.at/ipa/
Otmar Lendl enum.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria
奥地利维也纳A-1010卡尔斯普拉茨1/2/9 Otmar Lendl enum.at股份有限公司
Phone: +43 1 5056416 33
EMail: otmar.lendl@enum.at
URI: http://www.enum.at/
Phone: +43 1 5056416 33
EMail: otmar.lendl@enum.at
URI: http://www.enum.at/
Richard Stastny Unaffiliated Anzbachgasse 43 1140 Vienna Austria
Richard Stastny非附属安扎巴赫加斯43 1140奥地利维也纳
Phone: +43 664 420 4100
EMail: richardstastny@gmail.com
Phone: +43 664 420 4100
EMail: richardstastny@gmail.com