Internet Engineering Task Force (IETF) S. Bradner
Request for Comments: 6116 Harvard University
Obsoletes: 3761 L. Conroy
Category: Standards Track Roke Manor Research
ISSN: 2070-1721 K. Fujiwara
JPRS
March 2011
Internet Engineering Task Force (IETF) S. Bradner
Request for Comments: 6116 Harvard University
Obsoletes: 3761 L. Conroy
Category: Standards Track Roke Manor Research
ISSN: 2070-1721 K. Fujiwara
JPRS
March 2011
The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）
Abstract
摘要
This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761.
本文档讨论了使用域名系统（DNS）存储与E.164号码相关的数据，并将这些号码解析为可用于（例如）电话呼叫设置的URI。本文档还描述了如何使用DNS识别与E.164号码相关的服务。本文件淘汰了RFC 3761。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6116.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6116.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括简化的BSD许可证文本，如本规范第4.e节所述
the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
如简化的BSD许可证所述，信托法律条款和许可证不提供任何担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Use of These Mechanisms for Private Dialing Plans ...............4
3. The ENUM Application Specifications .............................4
3.1. Application Unique String ..................................4
3.2. First Well Known Rule ......................................5
3.3. Expected Output ............................................5
3.4. Valid Databases ............................................5
3.4.1. Optional Name Server Additional Section Processing ..6
3.4.2. Flags ...............................................6
3.4.3. Service Parameters ..................................7
3.4.3.1. ENUM Services ..............................7
3.4.3.2. Compound NAPTRs and Implicit
ORDER/PREFERENCE Values ....................8
3.5. The ENUM Algorithm Always Returns a Single Rule ............8
3.6. Case Sensitivity in ENUM ...................................8
3.7. Collision Avoidance ........................................9
4. ENUM Service Example ...........................................10
5. Clarification of DDDS Use in ENUM ..............................10
5.1. Collected Implications for ENUM Provisioning ..............11
5.2. Collected Implications for ENUM Clients ...................13
5.2.1. Non-Terminal NAPTR Processing ......................15
6. IANA Considerations ............................................16
7. Security Considerations ........................................17
7.1. DNS Security ..............................................17
7.2. Caching Security ..........................................18
7.3. Call Routing Security .....................................19
7.4. URI Resolution Security ...................................19
8. Acknowledgements ...............................................19
9. Changes from RFC 3761 ..........................................19
10. References ....................................................20
10.1. Normative References .....................................20
10.2. Informative References ...................................21
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Use of These Mechanisms for Private Dialing Plans ...............4
3. The ENUM Application Specifications .............................4
3.1. Application Unique String ..................................4
3.2. First Well Known Rule ......................................5
3.3. Expected Output ............................................5
3.4. Valid Databases ............................................5
3.4.1. Optional Name Server Additional Section Processing ..6
3.4.2. Flags ...............................................6
3.4.3. Service Parameters ..................................7
3.4.3.1. ENUM Services ..............................7
3.4.3.2. Compound NAPTRs and Implicit
ORDER/PREFERENCE Values ....................8
3.5. The ENUM Algorithm Always Returns a Single Rule ............8
3.6. Case Sensitivity in ENUM ...................................8
3.7. Collision Avoidance ........................................9
4. ENUM Service Example ...........................................10
5. Clarification of DDDS Use in ENUM ..............................10
5.1. Collected Implications for ENUM Provisioning ..............11
5.2. Collected Implications for ENUM Clients ...................13
5.2.1. Non-Terminal NAPTR Processing ......................15
6. IANA Considerations ............................................16
7. Security Considerations ........................................17
7.1. DNS Security ..............................................17
7.2. Caching Security ..........................................18
7.3. Call Routing Security .....................................19
7.4. URI Resolution Security ...................................19
8. Acknowledgements ...............................................19
9. Changes from RFC 3761 ..........................................19
10. References ....................................................20
10.1. Normative References .....................................20
10.2. Informative References ...................................21
This document discusses the use of the Domain Name System (DNS) [RFC1034] [RFC1035] for storage of data associated with E.164 [E.164] numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document includes a Dynamic Delegation Discovery System (DDDS) Application specification, as detailed in the document series described in [RFC3401]. This document obsoletes [RFC3761].
本文档讨论使用域名系统（DNS）[RFC1034][RFC1035]存储与E.164[E.164]号码相关的数据，并将这些号码解析为可以（例如）在电话呼叫设置中使用的URI。本文档还描述了如何使用DNS识别与E.164号码相关的服务。本文档包括动态委派发现系统（DDDS）应用程序规范，详见[RFC3401]中描述的文档系列。本文件废除了[RFC3761]。
Using the process defined in this document, International Public Telecommunication Numbers in the international format defined in International Telecommunications Union (ITU) Recommendation E.164 [E.164] (called here "E.164 numbers") can be transformed into DNS names. Using existing DNS services (such as delegation through NS records and queries for NAPTR resource records), one can look up the services associated with that E.164 number. This takes advantage of standard DNS architectural features of decentralized control and management of the different levels in the lookup process.
使用本文件中定义的过程，可以将国际电信联盟（ITU）建议E.164[E.164]（此处称为“E.164号码”）中定义的国际格式的国际公共电信号码转换为DNS名称。使用现有的DNS服务（例如通过NS记录委派和查询NAPTR资源记录），可以查找与该E.164号相关的服务。这利用了标准DNS体系结构的特点，即分散控制和管理查找过程中的不同级别。
The domain "e164.arpa" has been assigned to provide an infrastructure in the DNS for storage of data associated with E.164 numbers. To facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers who want these numbers to be listed in the DNS should contact the appropriate zone administrator as listed in the policy 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.
已分配域“e164.arpa”以在DNS中提供基础设施，用于存储与E.164号码相关的数据。为了便于分布式操作，该域被划分为子域。E.164号码的持有者如果希望在DNS中列出这些号码，应联系区域所附政策中列出的相应区域管理员。应该通过检查与区域相关联的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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
DNS resource record types mentioned in this document are defined, respectively, in [RFC1035] (NS, SOA, A, MX), [RFC3403] (NAPTR), and [RFC2782] (SRV).
本文档中提到的DNS资源记录类型分别在[RFC1035]（NS、SOA、A、MX）、[RFC3403]（NAPTR）和[RFC2782]（SRV）中定义。
All other capitalized terms are taken from the vocabulary found in the DDDS algorithm specification found in [RFC3402].
所有其他大写术语取自[RFC3402]中DDDS算法规范中的词汇表。
Similar mechanisms might be used for other kinds of digit strings (such as numbers in private dialing plans). If these mechanisms are used for dialing plans (or for other unrelated digit strings), the domain apex used for such translation MUST NOT be e164.arpa, to avoid conflict with this specification.
类似的机制也可用于其他类型的数字字符串（如私人拨号计划中的数字）。如果这些机制用于拨号计划（或其他不相关的数字字符串），则用于此类转换的域顶点不得为e164.arpa，以避免与本规范冲突。
Also, the Application Unique String (see Section 3.1) used with dialing plans SHOULD be the full number as specified, without the leading '+' character. The '+' character is used to further distinguish E.164 numbers in international format from dialed digit strings or other digit sequences.
此外，拨号计划使用的应用程序唯一字符串（见第3.1节）应为指定的完整数字，不带前导“+”字符。“+”字符用于进一步区分国际格式的E.164数字与拨号数字串或其他数字序列。
For example, to address the E.164 number +44-3069-990038 a user might dial "03069990038" or "00443069990038" or "011443069990038". These dialed digit strings differ from one another, but none of them start with the '+' character.
例如，要拨打E.164号码+44-3069-990038，用户可以拨打“03069990038”或“00443069990038”或“0144403069990038”。这些拨号数字字符串彼此不同，但没有一个以“+”字符开头。
Finally, if these techniques are used for dialing plans or other digit strings, implementers and operators of systems using these techniques for such purpose MUST NOT describe these schemes as "ENUM". The initial "E" in ENUM stands for E.164, and the term "ENUM" is used exclusively to describe application of these techniques to E.164 numbers according to this specification.
最后，如果这些技术用于拨号计划或其他数字字符串，则为此目的使用这些技术的系统的实现者和操作员不得将这些方案描述为“枚举”。ENUM中的初始“E”代表E.164，术语“ENUM”专门用于描述根据本规范将这些技术应用于E.164编号。
This template defines the ENUM DDDS Application according to the rules and requirements found in [RFC3402]. The DDDS database used by this Application is found in [RFC3403], which is the document that defines the NAPTR DNS resource record type.
此模板根据[RFC3402]中的规则和要求定义ENUM DDDS应用程序。此应用程序使用的DDDS数据库位于[RFC3403]中，该文档定义了NAPTR DNS资源记录类型。
ENUM is designed as a way to translate from E.164 numbers to URIs using NAPTR records stored in DNS. The First Well Known Rule for any ENUM query creates a key (a fully qualified domain name, or FQDN, within the e164.arpa domain apex) from an E.164 number. This FQDN is queried for NAPTR records and returned records are processed and interpreted according to this specification.
ENUM被设计为使用DNS中存储的NAPTR记录将E.164数字转换为URI的一种方式。任何枚举查询的第一条众所周知的规则都是从E.164号创建一个密钥（e164.arpa域顶点内的完全限定域名或FQDN）。查询此FQDN以查找NAPTR记录，并根据此规范处理和解释返回的记录。
The Application Unique String (AUS) is a fully qualified E.164 number minus any non-digit characters except for the '+' character that 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.
应用程序唯一字符串（AUS）是一个完全限定的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 converts an AUS into an initial key. That key is used as an index into the Application's Rules Database. For ENUM, the Rules Database is the DNS, so the key is a fully qualified domain name (FQDN).
第一条众所周知的规则将AUS转换为初始密钥。该键用作应用程序规则数据库的索引。对于ENUM，规则数据库是DNS，因此密钥是完全限定域名（FQDN）。
In order to convert the AUS to a unique key in this database, the string is converted into a domain name according to this algorithm:
为了将AUS转换为此数据库中的唯一密钥，将根据以下算法将字符串转换为域名：
1. Remove all characters with the exception of the digits. For example, given the E.164 number "+44-20-7946-0148" (which would then have been converted into an AUS of "+442079460148"), this step would simply remove the leading '+', producing "442079460148". 2. Reverse the order of the digits. Example: "841064970244" 3. Put dots ('.') between each digit. Example: "8.4.1.0.6.4.9.7.0.2.4.4" 4. Append the string ".e164.arpa." to the end and interpret as a domain name. Example: 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
1. 删除除数字以外的所有字符。例如，给定E.164编号“+44-20-7946-0148”（该编号随后将转换为“+442079460148”的AUS），此步骤将简单地删除前导“+”，生成“442079460148”。2.颠倒数字的顺序。示例：“841064970244”3。在每个数字之间加上点（'.'）。示例：“8.4.1.0.6.4.9.7.0.2.4.4”4。将字符串“.e164.arpa.”追加到末尾并解释为域名。示例：8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa。
The E.164 namespace and this Application's database 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, so no further processing is required to generate the initial key.
E.164名称空间和此应用程序的数据库的组织方式可以直接从名称到名称空间的最小粒度（直接从名称本身），因此无需进一步处理即可生成初始密钥。
This domain name is used to request NAPTR records. Each of these records may contain the end result or, if its flags field is empty, produces a new key in the form of a domain name that is used to request further NAPTR records from the DNS.
此域名用于请求NAPTR记录。这些记录中的每一条都可能包含最终结果，或者，如果其标志字段为空，则生成一个域名形式的新密钥，用于从DNS请求进一步的NAPTR记录。
The output of the last DDDS loop is a Uniform Resource Identifier in its absolute form according to the <absolute-URI> production in the Collected ABNF found in [RFC3986].
根据[RFC3986]中收集的ABNF中的<absolute URI>结果，最后一个DDDS循环的输出是绝对形式的统一资源标识符。
At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" [RFC3403] 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数据库”[RFC3403]指定使用NAPTR DNS资源记录包含重写规则的DDDS数据库。此数据库的密钥编码为域名。
The character set used for the substitution expression is UTF-8 [RFC3629]. 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[RFC3629]。允许的输入字符是E.164号码中任何位置允许的所有字符。密钥中允许的字符是当前为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.
某些名称服务器实现试图对插入到给定DNS响应的附加信息部分的项进行智能化。例如，每当BIND将一个域编码到一个数据包中时，它将尝试确定它是否对一个域具有权威性。如果是，那么它将把为该域找到的任何A记录插入应答的附加信息部分，直到数据包达到允许的最大长度。因此，客户机检查此附加信息可能很有用。
It is also easy to contemplate an ENUM enhanced nameserver that understands 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 section of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See Section 4.2 of [RFC3403] ("Additional Information Processing") for more information on NAPTR records and the additional information section of a DNS response packet.
还可以很容易地考虑使用ENUM增强的名称服务器，它可以理解它所服务的NAPTR记录的实际内容，并将更合适的信息插入到响应的附加信息部分。因此，DNS服务器可以解释标志值并使用该信息在DNS分组的附加信息部分中包括适当的资源记录。鼓励客户查看更多信息，但不要求客户查看。有关NAPTR记录和DNS响应数据包的附加信息部分的更多信息，请参见[RFC3403]（“附加信息处理”）的第4.2节。
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 [RFC3986]. See Section 4.3 of [RFC3404].
此数据库包含一个字段，其中包含DDDS算法完成时发出信号的标志。此时仅定义了一个标志“U”。这意味着该规则是最后一条规则，并且该规则的输出是一个URI[RFC3986]。见[RFC3404]第4.3节。
If a client encounters a resource 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 resource 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 the result produced by this rewrite Rule MUST be an FQDN. Clients MUST use this result as the new Key in the
如果此标志不存在，则此规则为非终点。如果规则是非终端的，则此重写规则生成的结果必须是FQDN。客户端必须将此结果用作
DDDS loop (i.e., the client will query for NAPTR resource records at this FQDN).
DDDS循环（即，客户端将在此FQDN处查询NAPTR资源记录）。
Service Parameters for this Application take the following Augmented Backus-Naur Form (ABNF, specified in [RFC5234]) and are found in the Services field of the NAPTR record that holds a terminal Rule. Where the NAPTR holds a non-terminal Rule, the Services field SHOULD be empty, and clients SHOULD ignore its content.
此应用程序的服务参数采用以下扩展的Backus Naur形式（ABNF，在[RFC5234]中指定），可在保存终端规则的NAPTR记录的服务字段中找到。如果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) is followed by one or more Enumservices that indicate the class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character.
换句话说，非可选的“E2U”（用于表示仅枚举重写规则以减轻记录冲突）后面是一个或多个枚举服务，指示给定端点提供的功能类别。每个Enumservice都由一个初始“+”字符表示。
Enumservices may be specified and registered via the process defined in "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117]. This registration process is not open to any Enumservice that has '-' as the second character in its type string.
可以通过“Enumservices的IANA注册：指南、模板和IANA注意事项”[RFC6117]中定义的流程指定和注册Enumservices。此注册过程不向任何将“-”作为其类型字符串中的第二个字符的Enumservice打开。
In particular, this registration process is not open to Enumservice types starting with the facet "X-". This "X-" facet is reserved for experimental or trial use, and any such Enumservices cannot be registered using the normal process.
特别是，此注册过程不向以facet“X-”开头的枚举服务类型开放。此“X-”方面保留供实验或试用，任何此类Enumservices都不能使用正常过程注册。
Finally, any Enumservice type that starts with the facet "P-" is intended for use exclusively on private networks. As such, NAPTRs containing Enumservice types starting "P-" should not be seen on the global Internet. Even if an ENUM client recognizes and can engage in the Enumservice, it may be incapable of resolving the URI generated by the containing NAPTR. These Enumservices WILL NOT be registered.
最后，任何以方面“P-”开头的Enumservice类型都专门用于专用网络。因此，包含以“P-”开头的Enumservice类型的NAPTR不应出现在全球Internet上。即使ENUM客户端识别并可以参与ENUM服务，它也可能无法解析包含NAPTR的服务器生成的URI。这些服务将不会注册。
Such Enumservices MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets (RRSets) from entities outside the private network context in which these Enumservices are intended for use. Unless an ENUM client is sure
不得在任何系统中提供此类Enumservices，该系统为来自专用网络上下文之外的实体的NAPTR资源记录集（RRSET）DNS查询提供答案，这些Enumservices将在专用网络上下文中使用。除非ENUM客户端确定
that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet.
如果它连接到为其配置和使用这些NAPTR的专用网络，则它必须丢弃Enumservice类型以“P-”方面开头的任何NAPTR。
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".
可以将多个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. A left-to-right priority is assumed.
复合NAPTR可以被视为一组NAPTR，每个NAPTR都包含一个枚举服务。这些重构的NAPTR共享相同的顺序和首选项/优先级字段值，但应将其视为具有逻辑上不同的优先级。假定从左到右的优先级。
The ENUM algorithm always returns a single Rule. Individual 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.
枚举算法始终返回单个规则。单个应用程序可能具有特定于应用程序的知识或设施，允许它们呈现多个结果或速度选择，但这些不应改变算法的操作。
Case sensitivity was not mentioned at all in [RFC3761] (or [RFC2916]), but has been seen as an issue during interoperability test events since then. There are a lot of case-sensitive clients in current deployment.
[RFC3761]（或[RFC2916]）中根本没有提到区分大小写，但此后在互操作性测试事件中被视为一个问题。当前部署中有许多区分大小写的客户端。
The only place where NAPTR field content is case sensitive is in any static text in the Repl sub-field of the Regexp field (see Section 3.2 of [RFC3402] for Regexp field definitions). In that sub-field, case must be preserved when generating the record output. Elsewhere, case sensitivity is not used.
NAPTR字段内容区分大小写的唯一位置是Regexp字段的Repl子字段中的任何静态文本（Regexp字段定义见[RFC3402]第3.2节）。在该子字段中，生成记录输出时必须保留大小写。在其他地方，不使用区分大小写。
Where ENUM clients can be exposed to NAPTR records that may hold field content of different capitalization, clients MUST use case-insensitive processing. ENUM clients that operate using the Internet to send their queries, typically called "Public ENUM" scenarios, fall into this category.
当枚举客户端可以暴露于可能包含不同大小写的字段内容的NAPTR记录时，客户端必须使用不区分大小写的处理。使用Internet发送查询的枚举客户端（通常称为“公共枚举”方案）属于这一类。
Some ENUM clients operate within closed networks; for example, within isolated data networks operated by Communication Service Providers. These are typically called "Infrastructure ENUM" scenarios. All
一些ENUM客户端在封闭的网络中运行；例如，在通信服务提供商运营的隔离数据网络中。这些场景通常称为“基础架构枚举”场景。全部的
zones provisioned within such closed networks usually have a known capitalization for ENUM record string content, as provisioning systems for such networks are often carefully controlled. In such an environment, clients are never exposed to records with capitalization that is "unexpected" and so can be (and have been) designed with case sensitive processing. Only if a client is known to operate in an environment in which capitalization of all ENUM records it will encounter is known and controlled MAY that client use case sensitive processing.
在这样的封闭网络中供应的区域通常具有已知的枚举记录字符串内容的大小写，因为这类网络的供应系统通常受到仔细控制。在这样的环境中，客户永远不会接触到“意外”的大写记录，因此可以（并且已经）使用区分大小写的处理进行设计。只有当已知客户机在其将遇到的所有枚举记录的大小写都是已知的且受控制的环境中运行时，该客户机才能使用区分大小写的处理。
An ENUM-compliant application MUST only pass numbers to the ENUM client query process that it believes are E.164 numbers (e.g., it MUST NOT pass dialed digit strings to the ENUM query process).
符合ENUM的应用程序必须仅将其认为是164个数字的数字传递给ENUM客户端查询进程（例如，不得将已拨数字字符串传递给ENUM查询进程）。
Since number plans may change over time, it can be impossible for a client to know if the number it intends to query is assigned and active within the current number plan. Thus it is important that such clients can distinguish data associated with the E.164 number plan from that associated with other digit strings (i.e., numbers NOT in accordance with the E.164 number plan).
由于号码计划可能会随着时间的推移而变化，因此客户不可能知道其要查询的号码是否在当前号码计划中分配并处于活动状态。因此，重要的是，此类客户机能够区分与E.164数字计划相关联的数据和与其他数字字符串相关联的数据（即不符合E.164数字计划的数字）。
It is the responsibility of operators that are provisioning data into domains to ensure that data associated with a query on an E.164 number cannot be mistaken for data associated with other uses of NAPTRs.
向域中提供数据的运营商有责任确保与E.164号查询相关联的数据不会被误认为与NAPTRs的其他用途相关联的数据。
Three techniques are used to achieve this:
要实现这一点，需要使用三种技术：
o the domain apex used for purposes other than data associated with the E.164 number plan MUST NOT be e164.arpa.
o 用于与E.164编号计划相关的数据以外的目的的域顶点不得为e164.arpa。
o for use other than with E.164 numbers, the Application Unique String MUST NOT begin with the '+' character, whilst for ENUM use, the AUS MUST begin with this character.
o 对于除E.164数字以外的其他用途，应用程序唯一字符串不得以“+”字符开头，而对于枚举使用，AUS必须以该字符开头。
o NAPTRs that are intended for other DDDS applications MUST NOT include the E2U token in their service field, whilst NAPTRs intended for ENUM use MUST include this token.
o 用于其他DDDS应用程序的NAPTR不得在其服务字段中包含E2U令牌，而用于枚举的NAPTR必须包含此令牌。
$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. NAPTR 100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" . NAPTR 100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" . NAPTR 100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa。NAPTR 100 50“u”E2U+sip！^（\\+44163296083）$！sip:\\1@example.com!" . NAPTR 100 51“u”E2U+h323“！^\\+441632960083$！h323:operator@example.com!" . NAPTR 100 52“u”E2U+电子邮件：mailto”“！^.*$！mailto: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 Enumservice tokens "sip", "h323", and "email" are Enumservice 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进行消息传递。请注意，Enumservice令牌“sip”、“h323”和“email”是向IANA注册的Enumservice类型，它们与具有相同名称的协议或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.
在所有情况下，解析过程的下一步是使用每个协议（由URI方案sip、h323和mailto指定）的解析机制来了解要联系的节点。
In each of the first two records, the ERE sub-field matches only queries that have been made for the telephone number +441632960083. In the last record, the ERE matches any Application Unique String value. The first record also demonstrates how the matched pattern can be used in the generated URI.
在前两条记录中，ERE子字段仅匹配对电话号码+441632960083的查询。在最后一条记录中，ERE匹配任何应用程序唯一的字符串值。第一条记录还演示了如何在生成的URI中使用匹配的模式。
Note that where NAPTR resource records are shown in DNS master file syntax (as in this example above), each backslash must itself be escaped using a second backslash. The DNS on-the-wire packet will have only a single backslash in each case.
请注意，如果NAPTR资源记录以DNS主文件语法显示（如上例所示），则必须使用第二个反斜杠对每个反斜杠本身进行转义。有线数据包上的DNS在每种情况下都只有一个反斜杠。
ENUM is a DDDS Application. This means that it relies on the DDDS for its operation. DDDS is designed to be flexible, but that opens the possibility of differences of interpretation. This section is intended to cover ENUM-specific interpretation of text within the DDDS specifications. The goal is to ensure interoperability between ENUM clients and provisioning systems used to populate domains with E2U NAPTRs.
ENUM是一个DDDS应用程序。这意味着它的运作依赖于DDDS。DDDS的设计是灵活的，但这就打开了解释差异的可能性。本节旨在涵盖DDDS规范中特定于枚举的文本解释。目标是确保枚举客户端和用于使用E2U NAPTR填充域的供应系统之间的互操作性。
As part of on-going development work on the ENUM specifications, [RFC5483] provides an (informative) analysis of the way in which ENUM client and provisioning system implementations behave and the interoperability issues that have arisen. The following recommendations reflect that analysis, and further narrative explaining the issues can be found in that RFC.
作为正在进行的ENUM规范开发工作的一部分，[RFC5483]对ENUM客户端和供应系统实现的行为方式以及出现的互操作性问题进行了（信息性）分析。以下建议反映了这一分析，在RFC中可以找到解释问题的进一步说明。
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 MUST encode the non-ASCII data to emit only US-ASCII characters by applying the appropriate mechanism (such as those in [RFC3492], [RFC3987]). Non-printable characters SHOULD NOT be used, as ENUM clients may need to present NAPTR content in a human-readable form.
ENUM NAPTR不应包含可打印US-ASCII等效范围（U+0020到U+007E）之外的字符，除非明确说明其设计支持的所有ENUM客户端都能够正确处理此类字符。如果枚举区域设置系统需要非ASCII字符，则这些系统必须通过应用适当的机制（如[RFC3492]、[RFC3987]中的机制）对非ASCII数据进行编码，以仅发出US-ASCII字符。不应使用不可打印的字符，因为枚举客户端可能需要以人类可读的形式呈现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字段中。
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中的首选项/优先级字段。因此，注册人只应将其愿意支持的联系人放入其区域；最终用户甚至可以选择具有最差顺序和首选项/优先级值的那些。
All E2U 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.
所有E2U NAPTR应在其订单字段中保留默认值。建议使用值“100”，因为它似乎用于大多数已配置的域。
Some ENUM clients have been known to pre-discard NAPTRs within an RRSet simply because these records do not have the lowest ORDER value found in that RRSet. Other ENUM client implementations appear to have confused ORDER and PREFERENCE/PRIORITY fields, using the latter as the major sort term rather than the former as specified. Conversely, ENUM zones have been provisioned within which the ORDER value varies but the PREFERENCE/PRIORITY field value is static. This may have been intentional, but given the different client behavior in the face of varying ORDER field values, it may not produce the desired response.
已知一些枚举客户机在RRSet中预先丢弃NAPTR，这仅仅是因为这些记录没有在该RRSet中找到的最低顺序值。其他枚举客户机实现似乎有混乱的顺序和首选项/优先级字段，使用后者作为主要排序术语，而不是指定的前者。相反，已设置枚举区域，其中顺序值不同，但首选项/优先级字段值是静态的。这可能是有意为之，但鉴于面对不同顺序字段值时的不同客户端行为，它可能不会产生所需的响应。
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）。
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.
如果Regexp分隔符是Repl子字段的静态文本中的一个字符，则必须使用[RFC3402]第3.2节所示BNF规范的转义分隔符产品对其进行“转义”（即“\！”，U+005C U+0021）。请注意，在DNS主文件语法中输入NAPTR资源记录时，必须使用第二个反斜杠对反斜杠本身进行转义。
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资源记录时，必须使用第二个反斜杠对反斜杠本身进行转义。
Whilst this client behavior 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. 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时，某些客户端的字符扩展缓冲区空间有限。这些资源调配系统应该检查它们使用的反向引用替换模式，确保正则表达式处理不会产生过长的URI。
ENUM zones MUST NOT be provisioned with NAPTRs according to the obsolete syntax of [RFC2916], and MUST be provisioned with NAPTRs in which the Services field is according to Section 3.4.3 of this document.
根据[RFC2916]的过时语法，枚举区域不得配置NAPTRs，并且必须配置NAPTRs，其中服务字段符合本文档第3.4.3节的要求。
[RFC2915] and [RFC2916] have been obsoleted by [RFC3401]-[RFC3404] and by this document, respectively.
[RFC2915]和[RFC2916]分别被[RFC3401]-[RFC3404]和本文件淘汰。
Enumservices in which the Enumservice type starts with the facet "P-" MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets from entities outside the private network context in which these Enumservices are intended for use.
Enumservice类型以方面“P-”开头的Enumservices不得在任何系统中设置，该系统为来自专用网络上下文之外的实体的NAPTR资源记录集的DNS查询提供答案，这些Enumservices将在专用网络上下文中使用。
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 that may be 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, as this field will be interpreted as holding the FQDN 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必须在（非空）替换字段中包含其目标域，因为此字段将被解释为持有形成此非终端规则下一个键输出的FQDN。在枚举查询期间遇到的非终端NAPTR中，Regexp字段必须为空。
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 RRSet.
如果NAPTR被丢弃，这不应导致整个枚举查询终止，处理应继续处理返回的RRSet中的下一个NAPTR。
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 MUST sort the records of a retrieved NAPTR RRSet into sequence using the ORDER and PREFERENCE fields of those records. The ORDER is to be treated as the major sort term, with lowest numerical values being earlier in the sequence. The PREFERENCE/PRIORITY field is to be treated as the minor sort term, with lowest numerical values being earlier in the sequence.
ENUM客户端必须使用检索到的NAPTR RRSet记录的顺序和首选项字段将这些记录按顺序排序。顺序将被视为主要排序项，最低数值在序列中较早。首选项/优先级字段将被视为次要排序项，最低数值在序列中较早。
ENUM clients SHOULD NOT discard a NAPTR record until it is considered or a record previous to it in the evaluation sequence has been accepted.
在考虑NAPTR记录或接受评估序列中该记录之前，枚举客户端不应丢弃该记录。
Notably, if a record has a "worse" ORDER value than others in this RRSet, that record MUST NOT be discarded before consideration unless a record has been accepted as the result of this ENUM query.
值得注意的是，如果一条记录的顺序值比此RRSet中的其他记录“更差”，则在考虑之前不得丢弃该记录，除非该记录已被接受为此枚举查询的结果。
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 lowest currently unprocessed ORDER field value. The client SHOULD observe 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 randomizing the order in which these are processed, as intervening DNS Servers might have done this already).
枚举客户端应接受具有相同顺序和相同首选项/优先级字段值的所有NAPTR，并按照它们在DNS响应中出现的顺序处理它们。（进一步随机处理这些数据的顺序没有好处，因为介入的DNS服务器可能已经这样做了）。
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 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 MUST be ready to process NAPTRs that use a different character from '!' as their Regexp Delimiter without failure.
枚举客户端必须准备好处理使用与“！”不同字符的NAPTR作为它们的Regexp分隔符，不会失败。
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, 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, the client MUST discard the NAPTR.
本着自由开放的精神，如果ENUM客户端确定应该如何解释Regexp字段，那么即使面对数量不正确的未转义分隔符字符，它也可能选择处理NAPTR。如果不清楚如何解释Regexp字段，则客户端必须放弃NAPTR。
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 many copies of back-reference patterns within the Repl sub-field without failure.
ENUM客户端必须准备好在Repl子字段中处理具有多个反向引用模式副本的NAPTR，而不会出现故障。
ENUM clients MUST be ready to process NAPTRs with a DDDS Application identifier other than 'E2U' without failure.
ENUM客户端必须准备好处理DDDS应用程序标识符不是“E2U”的NAPTR，而不会出现故障。
When an ENUM client encounters a compound NAPTR (i.e., one containing more than one Enumservice) and cannot process or cannot recognize 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 syntax defined in Section 3.4.3. ENUM clients SHOULD also support ENUM NAPTRs according to the obsolete syntax of [RFC2916]; there are still zones that hold "old" syntax NAPTRs. The informational [RFC3824] recommended such support.
ENUM客户端必须根据第3.4.3节中定义的语法支持ENUM NAPTRs。ENUM客户端还应根据[RFC2916]的过时语法支持ENUM NAPTRs；仍然有保留“旧”语法NAPTR的区域。参考[RFC3824]建议提供此类支持。
Unless an ENUM client is sure that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet.
除非ENUM客户端确定它已连接到为其配置和使用这些NAPTR的专用网络，否则它必须丢弃任何具有以“P-”方面开头的Enumservice类型的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 FQDN 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 FQDN. 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的枚举客户端必须将替换字段视为包含要在下一轮枚举查询中使用的FQDN。如果替换字段为空或不包含有效的FQDN，则枚举客户端必须放弃此类非终端NAPTR。根据定义，在这种非终端NAPTR中，Regexp字段将为空。如果存在于非终端NAPTR中，则枚举客户端必须忽略非空的Regexp字段。
If a problem is detected when processing an ENUM query across multiple domains (by following non-terminal NAPTR references), the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD
如果在跨多个域处理枚举查询时（通过遵循非终端NAPTR引用）检测到问题，则不应放弃枚举查询，而应进行处理
continue at the next NAPTR after the non-terminal NAPTR that referred to the domain in which the problem would have occurred.
在引用可能发生问题的域的非终端NAPTR之后的下一个NAPTR继续。
If all NAPTRs in a domain traversed as a result of a reference in a non-terminal NAPTR have been discarded, 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 MUST be prepared to encounter a referential loop in which a sequence of non-terminal NAPTRs are retrieved within an ENUM query that refer back to an earlier FQDN. ENUM clients MUST be able to detect and recover from such a loop, without failure.
枚举客户端必须准备好遇到引用循环，在该循环中，在引用早期FQDN的枚举查询中检索非终端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链，作为引用循环已被输入的指示。
When 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, 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查询。
RFC 2916 and then RFC 3761 (which this document replaces) requested IANA to delegate the E164.ARPA domain following instructions that were provided by the IAB (as described in [RFC3245]). The domain was delegated according to those instructions (which are published at <http://www.ripe.net/data-tools/dns/enum/iab-instructions>).
RFC 2916和RFC 3761（本文件取代）要求IANA按照IAB提供的说明（如[RFC3245]所述）委托E164.ARPA域。已根据这些说明（发布于）委派域<http://www.ripe.net/data-tools/dns/enum/iab-instructions>).
Names within this zone are to be delegated to parties consistent with ITU Recommendation E.164. The names allocated should be hierarchic in accordance with ITU Recommendation E.164, and the codes should be assigned in accordance with that Recommendation.
根据ITU建议E.164，该区域内的名称将委托给各方。根据ITU建议E.164，分配的名称应具有层次性，代码应根据该建议分配。
The IAB is to coordinate with the ITU Telecommunications Standardization Bureau (TSB) if the technical contact for the domain e164.arpa is to change, as ITU TSB has an operational working relationship with this technical contact that would need to be reestablished.
如果域e164.arpa的技术联系人发生变化，IAB将与ITU电信标准化局（TSB）进行协调，因为ITU TSB与该技术联系人之间存在需要重新建立的运营工作关系。
See [RFC6117] for Enumservice-related IANA Considerations.
有关Enumservice相关IANA注意事项，请参见[RFC6117]。
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 kinds 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 consider. See Threat Analysis of the Domain Name System [RFC3833] for a review of the various threats to the DNS.
EnUM实现应该考虑的攻击类型有多种类型。请参阅域名系统的威胁分析[RFC3833]，了解对DNS的各种威胁。
Because of these threats, a deployed ENUM service SHOULD include mechanisms to mitigate these threats. Most of the threats can be solved by verifying the authenticity of the data via mechanisms such as DNS Security (DNSSEC) [RFC4033].
由于存在这些威胁，部署的枚举服务应包括缓解这些威胁的机制。大多数威胁可以通过DNS安全（DNSSEC）[RFC4033]等机制验证数据的真实性来解决。
Others, such as 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).
其他攻击，如拒绝服务攻击，无法通过数据身份验证解决。必须记住，这些威胁不仅包括NAPTR查找本身，还包括服务有用所需的各种记录（例如NS、MX、SRV和A记录）。
Even if DNSSEC is deployed, it cannot protect against every kind of attack on DNS. ENUM is often used for number or address translation; retrieving an address through an ENUM lookup with DNSSEC support does not, however, ensure that the service is immune to attack. It is unwise for a service blindly to trust that the address it has retrieved is valid and that the entity to which it connects using that address is the service peer it intended to contact. A service SHOULD always authenticate the entity to which it connects during the service setup phase, and not rely on address or identity data retrieved outside that service.
即使部署了DNSSEC，它也无法抵御对DNS的各种攻击。ENUM通常用于数字或地址转换；但是，通过DNSSEC支持的枚举查找检索地址并不能确保服务不受攻击。一个服务盲目地相信它检索到的地址是有效的，并且它使用该地址连接到的实体是它打算联系的服务对等方，这是不明智的。服务应始终在服务设置阶段对其连接的实体进行身份验证，而不依赖于在该服务外部检索的地址或标识数据。
Finally, as an ENUM service will be implementing some type of security mechanism, software that implements ENUM MUST be prepared to receive DNSSEC and other standardized DNS security responses, including large responses and other EDNS0 signaling (see [RFC2671]), unknown resource records (see [RFC3597]), and so on.
最后，由于枚举服务将实现某种类型的安全机制，因此实现枚举的软件必须准备好接收DNSSEC和其他标准化DNS安全响应，包括大型响应和其他EDNS0信令（请参见[RFC2671]）、未知资源记录（请参见[RFC3597]），等等。
The DNS architecture makes extensive use of caching of records at intermediary nodes to improve performance. The propagation time (for changes to resource records to be reflected in query responses to end nodes) approaches the "time to live" value for those records. There may be a number of different resource records involved in the resolution of a communication target. Changes to these records may not be synchronized (particularly if these resource records indicate different times to live). Thus a change in any one of these records may cause inappropriate decisions on communications targets to be made. Given that DNS Update (specified in [RFC2136]) can introduce quite rapid changes in content in different zones, these transient states may become important.
DNS体系结构广泛使用中间节点上的记录缓存来提高性能。传播时间（用于在对终端节点的查询响应中反映对资源记录的更改）接近这些记录的“生存时间”值。在通信目标的解析过程中可能会涉及许多不同的资源记录。对这些记录的更改可能不同步（特别是当这些资源记录指示不同的生存时间时）。因此，这些记录中任何一项的更改都可能导致对通信目标做出不适当的决定。考虑到DNS更新（在[RFC2136]中指定）可以在不同区域中引入相当快速的内容更改，这些瞬时状态可能变得非常重要。
Consider a typical set of queries that follow an ENUM query that returns a SIP URI (for details, see [RFC3263]):
考虑EnUM查询返回一个SIP URI的一组典型查询（详情请参阅[RCF3263]）：
o Evaluation of the SIP URI triggers a query on the SIP domainpart for D2U/D2T NAPTRs.
o 对SIPURI的评估会触发对D2U/D2T NAPTR的SIP domainpart的查询。
o This in turn triggers a query on that record's target domain for SRV records.
o 这反过来会触发该记录的目标域上的SRV记录查询。
o The SRV records will return the SIP server hostname, which will trigger a further query on that hostname for an A record to get the server's associated IP address.
o SRV记录将返回SIP服务器主机名，这将触发对该主机名的进一步查询，以获取服务器的关联IP地址。
o Finally, the local SIP User Agent Client will then attempt to initiate a communications session to that IP address.
o 最后，本地SIP用户代理客户端将尝试发起到该IP地址的通信会话。
The E2U NAPTR may have changed its URI, indicating a new SIP identity. The D2U NAPTR for the SIP URI domainpart may have changed its target. The SRV record pointed to by that D2U NAPTR may have changed its target hostname. The hostname's A record may have changed its IP address. Finally, if the server exists in an environment where IP-addresses are dynamically assigned (for example, when using DHCP [RFC2131]), an unexpected end point may have been allocated to the IP address returned from the SIP resolution chain.
E2U NAPTR可能已更改其URI，表示新的SIP标识。SIP URI domainpart的D2U NAPTR可能已更改其目标。D2U NAPTR指向的SRV记录可能已更改其目标主机名。主机名的A记录可能已更改其IP地址。最后，如果服务器存在于动态分配IP地址的环境中（例如，当使用DHCP[RFC2131]时），则可能已将意外端点分配给从SIP解析链返回的IP地址。
In environments where changes to any of the chain of resource records or dynamic assignments to IP addresses occur, those systems provisioning this data SHOULD take care to minimize changes and to consider the respective times to live of resource records and/or DHCP lease times. Users of this data SHOULD take care to detect and recover from unintended communications session attempts; in a transient environment, these may occur.
在对任何资源链的记录或IP地址的动态分配发生变化的环境中，提供这些数据的那些系统应注意最小化变化，并考虑各自的时间以生存资源记录和/或DHCP租约时间。此数据的用户应注意检测并从非预期的通信会话尝试中恢复；在瞬态环境中，这些可能会发生。
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 "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117].
大量的安全问题与解决过程本身以及DDDS机制产生的URI的使用有关。按照“Enumservices的IANA注册：指南、模板和IANA注意事项”[RFC6117]中的规定，必须在所用Enumservice的注册中指定这些内容。
This document is an update of RFC 3761, which was edited by Patrik Faltstrom and Michael Mealling. Please see the Acknowledgements section in that RFC for additional acknowledgements. The authors would also like to thank Alfred Hoenes and Bernie Hoeneisen for their detailed reviews.
本文件是由Patrik Faltstrom和Michael Mealling编辑的RFC 3761的更新。请参阅该RFC中的确认部分，以了解更多确认。作者还要感谢阿尔弗雷德·霍恩斯和伯尼·霍内森的详细评论。
A section has been added to explain the way in which DDDS is used with this specification. These recommendations have been collected from experience of ENUM deployment. Differences of interpretation of the DDDS specifications led to interoperability issues; this document updates RFC 3761 to add many clarifications, intended to ameliorate interoperability.
增加了一节来解释DDDS与本规范一起使用的方式。这些建议是从ENUM部署的经验中收集的。DDDS规范解释的差异导致互操作性问题；本文档更新了RFC 3761，添加了许多澄清，旨在改善互操作性。
Clarifications include a default value for the ORDER field and for the Regexp delimiter character, required use of Replacement field in non-terminal NAPTRs, and that string matching is case insensitive (Section 3.6).
澄清包括订单字段和Regexp分隔符字符的默认值、非终端NAPTR中替换字段的必需使用，以及字符串匹配不区分大小写（第3.6节）。
Other substantive changes include removing the discussion of registration mechanisms, (now specified in "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" [RFC6117]), correcting an existing error by adding "-" as a valid character in the type and subtype fields specified in Services Parameters (Section 3.4.3) and adding the "P-" private service type (Section 3.4.3.1).
其他实质性更改包括取消对注册机制的讨论（现在在“Enumservices的IANA注册：指南、模板和IANA注意事项”[RFC6117]中指定），通过在服务参数（第3.4.3节）中指定的类型和子类型字段中添加“-”作为有效字符来更正现有错误并添加“P-”专用服务类型（第3.4.3.1节）。
[E.164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.
[E.164]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月。
[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月。
[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月。
[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月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[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月。
[RFC3245] Klensin, J., Ed., and IAB, "The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)", RFC 3245, March 2002.
[RFC3245]Klensin，J.，Ed.，和IAB，“电话号码映射（ENUM）操作决策的历史和背景：为ITU-T研究组2（SG2）提供的信息性文件”，RFC 32452002年3月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，2002年6月。
[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月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
[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月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC5483] Conroy, L. and K. Fujiwara, "ENUM Implementation Issues and Experiences", RFC 5483, March 2009.
[RFC5483]Conroy，L.和K.Fujiwara，“ENUM实施问题和经验”，RFC 5483，2009年3月。
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations" RFC 6117, March 2011.
[RFC6117]Hoenesen，B.，Mayrhofer，A.，和J.Livingood，“Enumservices的IANA注册：指南、模板和IANA注意事项”，RFC 61172011年3月。
Authors' Addresses
作者地址
Scott Bradner Harvard University 29 Oxford St. Cambridge MA 02138 USA
斯科特·布拉德纳哈佛大学29牛津圣剑桥马萨诸塞州02138
Phone: +1-617-495-3864
EMail: sob@harvard.edu
Phone: +1-617-495-3864
EMail: sob@harvard.edu
Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey United Kingdom
劳伦斯·康罗伊·罗克庄园研究罗克庄园老索尔兹伯里巷罗姆西英国
Phone: +44-1794-833666
EMail: lconroy@insensate.co.uk
URI: http://lawrence.tel
Phone: +44-1794-833666
EMail: lconroy@insensate.co.uk
URI: http://lawrence.tel
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.jp/en/
EMail: fujiwara@jprs.co.jp
URI: http://jprs.jp/en/