Internet Engineering Task Force (IETF) B. Hoeneisen
Request for Comments: 6117 Ucom.ch
Obsoletes: 3761 A. Mayrhofer
Category: Standards Track enum.at
ISSN: 2070-1721 J. Livingood
Comcast
March 2011
Internet Engineering Task Force (IETF) B. Hoeneisen
Request for Comments: 6117 Ucom.ch
Obsoletes: 3761 A. Mayrhofer
Category: Standards Track enum.at
ISSN: 2070-1721 J. Livingood
Comcast
March 2011
IANA Registration of Enumservices: Guide, Template, and IANA Considerations
Enumservices的IANA注册：指南、模板和IANA注意事项
Abstract
摘要
This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications.
本文件规定了Enumservices IANA注册指南的修订版，描述了相应的注册程序，并提供了创建Enumservice规范的指南。
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/rfc6117.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6117.
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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Registration Requirements . . . . . . . . . . . . . . . . . . 5
3.1. Functionality Requirements . . . . . . . . . . . . . . . . 5
3.2. Naming Requirements . . . . . . . . . . . . . . . . . . . 5
3.3. Security Requirements . . . . . . . . . . . . . . . . . . 6
3.4. Publication Requirements . . . . . . . . . . . . . . . . . 7
4. Enumservice Creation Cookbook . . . . . . . . . . . . . . . . 7
4.1. General Enumservice Considerations . . . . . . . . . . . . 7
4.2. Classification, Type and Subtype . . . . . . . . . . . . . 9
4.2.1. General Type/Subtype Considerations . . . . . . . . . 9
4.2.2. Protocol-Based Enumservices Class . . . . . . . . . . 10
4.2.3. Application-Based Enumservice Classes . . . . . . . . 10
4.2.4. Data Type-Based Enumservice Class . . . . . . . . . . 12
4.2.5. Other Enumservice . . . . . . . . . . . . . . . . . . 13
5. Required Sections and Information . . . . . . . . . . . . . . 13
5.1. Introduction (REQUIRED) . . . . . . . . . . . . . . . . . 13
5.2. IANA Registration (REQUIRED) . . . . . . . . . . . . . . . 13
5.2.1. Enumservice Class (<class>) . . . . . . . . . . . . . 13
5.2.2. Enumservice Type (<type>) . . . . . . . . . . . . . . 14
5.2.3. Enumservice Subtype (<subtype>) . . . . . . . . . . . 14
5.2.4. URI Scheme(s) (<urischeme>) . . . . . . . . . . . . . 15
5.2.5. Functional Specification (<functionalspec>) . . . . . 15
5.2.6. Security Considerations (<security>) . . . . . . . . . 15
5.2.7. Intended Usage (<usage>) . . . . . . . . . . . . . . . 16
5.2.8. Enumservice Specification (<registrationdocs>) . . . . 16
5.2.9. Requesters (<requesters>) . . . . . . . . . . . . . . 17
5.2.10. Further Information (<additionalinfo>) . . . . . . . . 17
5.3. Examples (REQUIRED) . . . . . . . . . . . . . . . . . . . 18
5.4. Implementation Recommendations / Notes (OPTIONAL) . . . . 18
5.5. DNS Considerations (REQUIRED) . . . . . . . . . . . . . . 18
5.6. Security Considerations (REQUIRED) . . . . . . . . . . . . 19
5.7. IANA Considerations (REQUIRED) . . . . . . . . . . . . . . 20
5.8. Other Sections (OPTIONAL) . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Registration Requirements . . . . . . . . . . . . . . . . . . 5
3.1. Functionality Requirements . . . . . . . . . . . . . . . . 5
3.2. Naming Requirements . . . . . . . . . . . . . . . . . . . 5
3.3. Security Requirements . . . . . . . . . . . . . . . . . . 6
3.4. Publication Requirements . . . . . . . . . . . . . . . . . 7
4. Enumservice Creation Cookbook . . . . . . . . . . . . . . . . 7
4.1. General Enumservice Considerations . . . . . . . . . . . . 7
4.2. Classification, Type and Subtype . . . . . . . . . . . . . 9
4.2.1. General Type/Subtype Considerations . . . . . . . . . 9
4.2.2. Protocol-Based Enumservices Class . . . . . . . . . . 10
4.2.3. Application-Based Enumservice Classes . . . . . . . . 10
4.2.4. Data Type-Based Enumservice Class . . . . . . . . . . 12
4.2.5. Other Enumservice . . . . . . . . . . . . . . . . . . 13
5. Required Sections and Information . . . . . . . . . . . . . . 13
5.1. Introduction (REQUIRED) . . . . . . . . . . . . . . . . . 13
5.2. IANA Registration (REQUIRED) . . . . . . . . . . . . . . . 13
5.2.1. Enumservice Class (<class>) . . . . . . . . . . . . . 13
5.2.2. Enumservice Type (<type>) . . . . . . . . . . . . . . 14
5.2.3. Enumservice Subtype (<subtype>) . . . . . . . . . . . 14
5.2.4. URI Scheme(s) (<urischeme>) . . . . . . . . . . . . . 15
5.2.5. Functional Specification (<functionalspec>) . . . . . 15
5.2.6. Security Considerations (<security>) . . . . . . . . . 15
5.2.7. Intended Usage (<usage>) . . . . . . . . . . . . . . . 16
5.2.8. Enumservice Specification (<registrationdocs>) . . . . 16
5.2.9. Requesters (<requesters>) . . . . . . . . . . . . . . 17
5.2.10. Further Information (<additionalinfo>) . . . . . . . . 17
5.3. Examples (REQUIRED) . . . . . . . . . . . . . . . . . . . 18
5.4. Implementation Recommendations / Notes (OPTIONAL) . . . . 18
5.5. DNS Considerations (REQUIRED) . . . . . . . . . . . . . . 18
5.6. Security Considerations (REQUIRED) . . . . . . . . . . . . 19
5.7. IANA Considerations (REQUIRED) . . . . . . . . . . . . . . 20
5.8. Other Sections (OPTIONAL) . . . . . . . . . . . . . . . . 20
6. The Process of Registering New Enumservices . . . . . . . . . 21
6.1. Step 1: Read This Document in Detail . . . . . . . . . . . 22
6.2. Step 2: Write and Submit Registration Document . . . . . . 22
6.3. Step 3: Request Comments From the IETF Community . . . . . 23
6.3.1. Outcome 1: No Changes Needed . . . . . . . . . . . . . 23
6.3.2. Outcome 2: Changes, But No Further Comments
Requested . . . . . . . . . . . . . . . . . . . . . . 23
6.3.3. Outcome 3: Changes and Further Comments Requested . . 23
6.4. Step 4: Submit Registration Document to IANA . . . . . . . 24
6.5. Step 5: Expert Review . . . . . . . . . . . . . . . . . . 24
6.5.1. Outcome 1: Experts Approve the Registration
Document . . . . . . . . . . . . . . . . . . . . . . . 25
6.5.2. Outcome 2: Changes Required . . . . . . . . . . . . . 25
6.5.3. Outcome 3: Experts Reject the Registration Document . 25
6.6. Step 6: Publication of the Registration Document . . . . . 25
6.7. Step 7: Adding Enumservice to the IANA Registry . . . . . 25
7. Expert Review . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Expert Selection Process . . . . . . . . . . . . . . . . . 26
7.2. Review Guidelines . . . . . . . . . . . . . . . . . . . . 26
7.3. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . 27
8. Revision of Existing Enumservice Specifications . . . . . . . 27
9. Extension of Existing Enumservice Specifications . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1. Considerations Regarding This Document . . . . . . . . . . 28
10.2. Enumservice Security Considerations Guideline . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. Registry Update . . . . . . . . . . . . . . . . . . . . . 28
11.2. Registration Template (XML chunk) . . . . . . . . . . . . 28
11.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.4. Structure . . . . . . . . . . . . . . . . . . . . . . . . 30
11.5. Expert Review Procedure . . . . . . . . . . . . . . . . . 30
11.6. Registration Procedure . . . . . . . . . . . . . . . . . . 30
11.6.1. Published as an RFC . . . . . . . . . . . . . . . . . 31
11.6.2. Published as a Non-RFC . . . . . . . . . . . . . . . . 31
11.7. Change Control . . . . . . . . . . . . . . . . . . . . . . 32
11.8. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 32
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. IANA Registration Template Examples . . . . . . . . . 36
Appendix B. Changes from RFC 3761 . . . . . . . . . . . . . . . . 39
6. The Process of Registering New Enumservices . . . . . . . . . 21
6.1. Step 1: Read This Document in Detail . . . . . . . . . . . 22
6.2. Step 2: Write and Submit Registration Document . . . . . . 22
6.3. Step 3: Request Comments From the IETF Community . . . . . 23
6.3.1. Outcome 1: No Changes Needed . . . . . . . . . . . . . 23
6.3.2. Outcome 2: Changes, But No Further Comments
Requested . . . . . . . . . . . . . . . . . . . . . . 23
6.3.3. Outcome 3: Changes and Further Comments Requested . . 23
6.4. Step 4: Submit Registration Document to IANA . . . . . . . 24
6.5. Step 5: Expert Review . . . . . . . . . . . . . . . . . . 24
6.5.1. Outcome 1: Experts Approve the Registration
Document . . . . . . . . . . . . . . . . . . . . . . . 25
6.5.2. Outcome 2: Changes Required . . . . . . . . . . . . . 25
6.5.3. Outcome 3: Experts Reject the Registration Document . 25
6.6. Step 6: Publication of the Registration Document . . . . . 25
6.7. Step 7: Adding Enumservice to the IANA Registry . . . . . 25
7. Expert Review . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Expert Selection Process . . . . . . . . . . . . . . . . . 26
7.2. Review Guidelines . . . . . . . . . . . . . . . . . . . . 26
7.3. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . 27
8. Revision of Existing Enumservice Specifications . . . . . . . 27
9. Extension of Existing Enumservice Specifications . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1. Considerations Regarding This Document . . . . . . . . . . 28
10.2. Enumservice Security Considerations Guideline . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. Registry Update . . . . . . . . . . . . . . . . . . . . . 28
11.2. Registration Template (XML chunk) . . . . . . . . . . . . 28
11.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.4. Structure . . . . . . . . . . . . . . . . . . . . . . . . 30
11.5. Expert Review Procedure . . . . . . . . . . . . . . . . . 30
11.6. Registration Procedure . . . . . . . . . . . . . . . . . . 30
11.6.1. Published as an RFC . . . . . . . . . . . . . . . . . 31
11.6.2. Published as a Non-RFC . . . . . . . . . . . . . . . . 31
11.7. Change Control . . . . . . . . . . . . . . . . . . . . . . 32
11.8. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 32
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. IANA Registration Template Examples . . . . . . . . . 36
Appendix B. Changes from RFC 3761 . . . . . . . . . . . . . . . . 39
E.164 Number Mapping (ENUM) [RFC6116] provides an identifier mapping mechanism to map E.164 numbers [ITU.E164.2005] to Uniform Resource Identifiers (URIs) [RFC3986] using the Domain Name System (DNS) [RFC1035]. One of the primary concepts of ENUM is the definition of "Enumservices", which allows for providing different URIs for different applications of said mapping mechanism.
E.164数字映射（ENUM）[RFC6116]提供了一种标识符映射机制，使用域名系统（DNS）[RFC1035]将E.164数字[ITU.E164.2005]映射到统一资源标识符（URI）[RFC3986]。ENUM的主要概念之一是“Enumservices”的定义，它允许为所述映射机制的不同应用提供不同的uri。
This document specifies a revision of the IANA registry for Enumservices, which was originally described in [RFC3761]. This document obsoletes Section 3 of RFC 3761 while RFC 6116 obsoletes RFC 3761.
本文档指定了Enumservices的IANA注册表的修订版，最初在[RFC3761]中进行了描述。本文件废除了RFC 3761第3节，而RFC 6116废除了RFC 3761。
The new registration processes, which are detailed in Section 6, have been specifically designed to be decoupled from the existence of the ENUM working group. Compared to RFC 3761, the main changes are as follows:
第6节详细介绍了新的登记程序，这些程序是专门为与ENUM工作组的存在脱钩而设计的。与RFC 3761相比，主要变化如下：
o For an Enumservice to be inserted to the IANA registry, "Specification Required", which implies the use of a Designated Expert, according to "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226], are now sufficient.
o 对于要插入IANA注册表的Enumservice，“需要规范”，这意味着根据“在RFCs中编写IANA注意事项部分的指南”[RFC5226]，使用指定专家，现在就足够了。
o The IANA Registration Template has been supplemented with elements for "Enumservice Class" and "Enumservice Specification".
o IANA注册模板补充了“Enumservice类”和“Enumservice规范”的元素。
The IETF's ENUM Working Group has encountered an unnecessary amount of variation in the format of Enumservice Specifications. The ENUM Working Group's view of what particular information is required and/or recommended has also evolved, and capturing these best current practices is helpful in both the creation of new Enumservice Specifications, as well as the revision or refinement of existing Enumservice Specifications.
IETF的ENUM工作组在ENUM服务规范的格式上遇到了不必要的变化。ENUM工作组对需要和/或建议哪些特定信息的看法也发生了变化，获取这些当前最佳实践有助于创建新的Enumservice规范，以及修订或完善现有Enumservice规范。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
For the purpose of this document:
就本文件而言：
o "Registration Document" refers to a draft specification that defines an Enumservice and proposes its registration following the procedures outlined herein.
o “注册文件”是指定义Enumservice并按照本文概述的程序建议其注册的规范草案。
o "Enumservice Specification" refers to a Registration Document that has been approved by the experts and published according to "Specification Required" as defined in [RFC5226].
o “Enumservice Specification”是指经专家批准并根据[RFC5226]中定义的“所需规范”发布的注册文件。
As specified in the Augmented Backus-Naur Form (ABNF, [RFC5234]) found in Section 3.4.3 of [RFC6116], an Enumservice is made up of Types and Subtypes. For any given Type, the allowable Subtypes (if any) must be defined in the Enumservice Specification. There is currently no concept of a registered Subtype outside the scope of a given Type.
如[RFC6116]第3.4.3节中的扩充巴科斯诺尔表（ABNF，[RFC5234]）所述，Enumservice由类型和子类型组成。对于任何给定类型，必须在Enumservice规范中定义允许的子类型（如果有）。在给定类型的范围之外，目前没有注册子类型的概念。
While the combination of each Type and all of its Subtypes constitutes the allowed values for the "Enumservice" field, it is not sufficient to just list their allowed values. To allow for interoperability, a complete Enumservice Specification MUST document the semantics of the Type and Subtype values to be registered, and MUST contain all sections listed in Section 5 of this document.
虽然每个类型及其所有子类型的组合构成了“Enumservice”字段的允许值，但仅列出其允许值是不够的。为了实现互操作性，完整的Enumservice规范必须记录要注册的类型和子类型值的语义，并且必须包含本文档第5节中列出的所有部分。
Furthermore, in order for an Enumservice to be registered, the entire Registration Document requires approval by the experts according to "Specification Required", which implies the use of a Designated Expert, as set out in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226] and Section 7.2 of this document.
此外，为了注册Enumservice，整个注册文件需要根据“所需规范”获得专家的批准，这意味着使用指定专家，如“RFCs中IANA注意事项编写指南”[RFC5226]和本文件第7.2节所述。
All Enumservice Specifications are expected to conform also to various requirements laid out in the following sections.
所有服务规范也应符合以下章节中规定的各种要求。
A registered Enumservice must be able to function as a selection mechanism for choosing one Naming Authority Pointer (NAPTR) [RFC3403] DNS Resource Record (RR) from a set of such RRs. That means the Enumservice Specification MUST define how to use the NAPTR RR and the URI(s) the NAPTR RR resolves to.
注册的Enumservice必须能够作为一种选择机制，用于从一组此类RRs中选择一个命名机构指针（NAPTR）[RFC3403]DNS资源记录（RR）。这意味着Enumservice规范必须定义如何使用NAPTR RR和NAPTR RR解析到的URI。
Specifically, a registered Enumservice MUST specify the URI Scheme(s) that may be used for the Enumservice, and, when needed, other information that will have to be transferred into the URI resolution process itself.
具体而言，注册的Enumservice必须指定可用于Enumservice的URI方案，以及在需要时必须传输到URI解析进程本身的其他信息。
The name of an Enumservice MUST be unique in order to be useful as a selection criteria:
Enumservice的名称必须唯一，才能用作选择条件：
o The Type MUST be unique.
o 类型必须是唯一的。
o The Subtype (being dependent on the Type) MUST be unique within a given Type.
o 子类型（依赖于类型）在给定类型中必须是唯一的。
Types and Subtypes MUST conform to the ABNF specified in Section 3.4.3 of [RFC6116].
类型和子类型必须符合[RFC6116]第3.4.3节中规定的ABNF。
The ABNF specified in Section 3.4.3 of [RFC6116] allows the "-" (dash) character for Types and Subtypes. To avoid confusion with possible future prefixes, a "-" MUST NOT be used as the first nor as the second character of a Type nor a Subtype. Furthermore, a "-" MUST NOT be used as the last character of a Type nor a Subtype. In addition, Types and Subtypes are case insensitive and SHOULD be specified in lowercase letters.
[RFC6116]第3.4.3节中规定的ABNF允许类型和子类型使用“-”（破折号）字符。为避免与将来可能出现的前缀混淆，类型或子类型的第一个或第二个字符不能使用“-”。此外，不能将“-”用作类型或子类型的最后一个字符。此外，类型和子类型不区分大小写，应以小写字母指定。
Note: The legacy IANA registry of Enumservices contains Type and Subtype strings with uppercase letters. Implementors could be tempted to refuse handling uppercase Type or Subtype strings, which could negatively affect interoperability.
注意：Enumservices的旧版IANA注册表包含大写字母的类型和子类型字符串。实现者可能会拒绝处理大写类型或子类型字符串，这可能会对互操作性产生负面影响。
To avoid confusion with Enumservice fields using a deprecated (obsolete) syntax, Type and Subtype MUST NOT start with the string "e2u".
为避免与使用不推荐（过时）语法的Enumservice字段混淆，类型和子类型不得以字符串“e2u”开头。
The Subtype for one Type MAY have the same identifier as a Subtype for another Type, but it is not sufficient to simply reference another Type's Subtype. The functionality of each Subtype MUST be fully specified in the context of the Type being registered.
一个类型的子类型可能与另一个类型的子类型具有相同的标识符，但仅引用另一个类型的子类型是不够的。必须在所注册类型的上下文中完全指定每个子类型的功能。
Section 4 contains further naming requirements.
第4节包含进一步的命名要求。
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 and extensive as feasible. 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 completely free of security risks. Nevertheless, all known security risks MUST be identified in an Enumservice Specification.
没有要求Enumservice必须完全没有安全风险。然而，必须在Enumservice规范中识别所有已知的安全风险。
Some of the issues to 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 look-up, and because of that an infinite loop in the overall resolution process of the E.164 number).
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来存储机密安全服务信息，例如报警系统或消息服务密码，而这些信息反过来又需要外部机密服务。
Enumservices Specifications MUST be published according to the requirements for "Specification Required" set out in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]. RFCs fulfill these requirements. Therefore, it is strongly RECOMMENDED to publish Enumservice Specifications as RFCs.
Enumservices规范必须根据“在RFCs中编写IANA注意事项部分的指南”[RFC5226]中规定的“所需规范”要求发布。RFC满足这些要求。因此，强烈建议将Enumservice规范发布为RFC。
In case the Enumservice Specification is not published as an RFC, sufficient information that allows unique identification of the Enumservice Specification MUST be provided.
如果Enumservice规范未作为RFC发布，则必须提供允许唯一标识Enumservice规范的足够信息。
ENUM is an extremely flexible identifier mapping mechanism, using E.164 (phone) numbers as input identifiers, and returning URIs as output identifiers. Because of this flexibility, almost every use case for ENUM could be implemented in several ways.
ENUM是一种非常灵活的标识符映射机制，使用E.164（电话）号码作为输入标识符，并返回URI作为输出标识符。由于这种灵活性，几乎所有ENUM用例都可以通过多种方式实现。
Section 2 of "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226] provides motivation for why management of a namespace might be necessary. Even though the namespace for Enumservices is rather large (up to 32 alphanumeric characters), there are reasons to manage this in accordance with Section 2 of [RFC5226]. The following is a list of motivations applying to Enumservices:
“在RFCs中编写IANA注意事项部分的指南”[RFC5226]的第2节为为什么需要管理名称空间提供了动机。尽管Enumservices的名称空间相当大（最多32个字母数字字符），但仍有理由根据[RFC5226]第2节进行管理。以下是应用于Enumservices的动机列表：
o Prevent hoarding or wasting of values: Enumservice Types are not an opaque identifier to prevent collisions in the namespace, but rather identify the use of a certain technology in the context of ENUM. Service Types might also be displayed to end users in implementations, so meaningful Type strings having a clear relation to the protocols and applications used are strongly RECOMMENDED. Therefore, preventing hoarding, wasting, or "hijacking" of Enumservice Type strings is important.
o 防止囤积或浪费值：Enumservice类型不是防止命名空间中冲突的不透明标识符，而是标识在ENUM上下文中使用的特定技术。服务类型也可能在实现中显示给最终用户，因此强烈建议使用与所使用的协议和应用程序有明确关系的有意义的类型字符串。因此，防止Enumservice类型字符串的囤积、浪费或“劫持”非常重要。
o Sanity check to ensure sensible or necessary requests: This applies to Enumservices, since especially various Enumservices for the same purpose would reduce the chance of successful interoperability, and unnecessarily increase confusion among implementers.
o 健全性检查以确保合理或必要的请求：这适用于Enumservices，因为特别是用于相同目的的各种Enumservices将降低成功互操作性的机会，并且不必要地增加实现者之间的混淆。
o Delegation of namespace portions: Theoretically, the Type and/or Subtype structure of Enumservices would allow for delegations of Type values, and self-supporting management of Subtype values by a delegate within the Type value. Such delegates could, for example, be other standardization bodies. However, this would require clear policies regarding publication and use of such Subtypes. Delegation of Enumservice namespace portions is therefore currently not supported.
o 命名空间部分的委托：理论上，Enumservices的类型和/或子类型结构允许类型值的委托，以及由类型值内的委托对子类型值进行自我支持的管理。例如，此类代表可以是其他标准化机构。然而，这将需要关于此类子类型的发布和使用的明确政策。因此，目前不支持委派Enumservice命名空间部分。
o Interoperability: Since the benefit of an Enumservice rises with the number of supporting clients, the registration and use of several services for a similar or identical purpose clearly reduces interoperability. Operational circumstances suggest to keep the space occupied by all services published in the NAPTR RRSet at any owner in the e164.arpa domain bounded. Registration of nearly identical services and subsequent competing or parallel use could easily increase the DNS operational complexity.
o 互操作性：由于Enumservice的好处随着支持客户端的数量而增加，因此为类似或相同目的注册和使用多个服务显然会降低互操作性。操作环境建议将NAPTR RRSet中发布的所有服务占用的空间限制在e164.arpa域中的任何所有者处。注册几乎相同的服务以及随后的竞争或并行使用可能很容易增加DNS操作的复杂性。
Generally, before commencing work on a new Enumservice registration, the following should be considered:
一般而言，在开始新的Enumservice注册工作之前，应考虑以下事项：
o Is there an existing Enumservice that could fulfill the desired functionality without overloading it? Check the IANA Enumservice Registry at <http://www.iana.org/assignments/enum-services>.
o 是否有一个现有的Enumservice可以在不过载的情况下实现所需的功能？检查位于的IANA Enumservice注册表<http://www.iana.org/assignments/enum-services>.
o Is there work in progress, or previous work, on a similar Enumservice? Check the <enum@ietf.org> mailing list archives at <http://www.ietf.org/mail-archive/web/enum/index.html>, and search the Internet-Drafts Archive at <http://tools.ietf.org/>. Some Internet-Drafts may have expired and no longer be available in the Internet-Drafts Archive, or some work on Enumservices may have been considered outside the IETF; therefore, we also recommend a web search.
o 类似的枚举服务是否有正在进行的工作或以前的工作？检查<enum@ietf.org>邮寄名单档案<http://www.ietf.org/mail-archive/web/enum/index.html>，并在<http://tools.ietf.org/>. 一些互联网草案可能已经过期，不再在互联网草案档案中可用，或者一些关于Enumservices的工作可能已经在IETF之外考虑；因此，我们也建议使用web搜索。
o Section 4.2 provides three general categories for Enumservice classification. In some cases, there might be several options for designing an Enumservice. For example, a mapping service using HTTP could be considered a "protocol Type" Enumservice (using HTTP as the protocol), while it could also be viewed as an "application Type" Enumservice, with the application providing access to mapping services. In such a case where several options are available, defining use cases before commencing work on the Enumservice itself might be useful before making a decision on which aspect of the Enumservice is more important.
o 第4.2节提供了服务分类的三个一般类别。在某些情况下，设计Enumservice可能有几个选项。例如，使用HTTP的映射服务可以被视为“协议类型”枚举服务（使用HTTP作为协议），而它也可以被视为“应用程序类型”枚举服务，应用程序提供对映射服务的访问。在有多个选项可用的情况下，在决定Enumservice的哪个方面更重要之前，在开始Enumservice本身的工作之前定义用例可能很有用。
Because of their flexibility, Enumservices can be and are used in a lot of different ways. This section contains a classification of Enumservices, and provides guidance for choosing suitable Type and Subtype strings for each individual Enumservice Class.
由于Enumservices的灵活性，它们可以并且可以以许多不同的方式使用。本节包含Enumservices的分类，并为每个Enumservice类选择合适的类型和子类型字符串提供指导。
The Classification of each Enumservice MUST be listed in the Registration Document (see Section 5.2). If the Enumservice cannot be assigned to one of the classes outlined below, the Registration Document MUST contain a section on the difficulties encountered while trying to classify the service to help the experts in their decision.
每个Enumservice的分类必须在注册文件中列出（见第5.2节）。如果无法将Enumservice分配给以下概述的类别之一，则注册文件必须包含一节，说明在尝试对服务进行分类时遇到的困难，以帮助专家做出决策。
To avoid confusion, the name of a URI Scheme MUST NOT be used as a Type string for an Enumservice that is not specifically about the respective protocol or URI Scheme. For example, the Type string "imap" would be inadequate for use in an Enumservice about "Internet mapping" services, because it corresponds to an existing URI Scheme / protocol for something different.
为避免混淆，URI方案的名称不得用作与相应协议或URI方案无关的Enumservice的类型字符串。例如，类型字符串“imap”不足以在Enumservice中使用“Internet映射”服务，因为它对应于不同内容的现有URI方案/协议。
If Subtypes are defined, the minimum number SHOULD be two (including the empty Subtype, if defined). The choice of just one possible Subtype for a given Type does not add any information when selecting an ENUM record, and hence can be left out completely. However, potential future expansion of a Type towards several Subtypes may justify the use of Subtypes, even in the case that just one is currently defined, as noted in Section 9.
如果定义了子类型，则最小数量应为两个（如果定义了空子类型，则包括空子类型）。在选择枚举记录时，仅为给定类型选择一个可能的子类型不会添加任何信息，因此可以完全忽略。然而，一个类型将来可能扩展到几个子类型，这可能证明使用子类型是合理的，即使在目前只定义了一个子类型的情况下，如第9节所述。
It is perfectly legal under a certain Type to mix the Enumservice without a Subtype (empty Subtype) with Enumservices containing a Subtype. In that case, however, the Enumservice with an empty Subtype SHOULD be specified to reflect the base service, while the other Enumservices SHOULD be specified to reflect variants.
在特定类型下，将没有子类型（空子类型）的Enumservice与包含子类型的Enumservices混合使用是完全合法的。但是，在这种情况下，应指定具有空子类型的Enumservice以反映基本服务，而应指定其他Enumservices以反映变体。
Such an Enumservice indicates that an interaction using the named protocol will result for use of this NAPTR. The expected behavior of a system using this Enumservice MUST be clear from the protocol.
这样的Enumservice表示使用命名协议的交互将导致使用此NAPTR。使用此Enumservice的系统的预期行为必须从协议中清除。
A good indication that an Enumservice belongs to this Class is the fact that a client does not need to understand the actual application to make use of an instance of this Enumservice.
Enumservice属于此类的一个很好的迹象是，客户端不需要了解实际应用程序即可使用该Enumservice的实例。
Examples of such Enumservices include "xmpp" [RFC4979] and "sip" [RFC3764].
此类枚举服务的示例包括“xmpp”[RFC4979]和“sip”[RFC3764]。
A protocol-based Enumservice SHOULD use the lowercase name of the protocol as its Type string. Names as registered in the IANA Port Number Registry (<http://www.iana.org/assignments/port-numbers>, defined in Section 8 and 9 of [RFC2780]) are preferred.
基于协议的枚举服务应使用协议的小写名称作为其类型字符串。在IANA端口号注册表中注册的名称(<http://www.iana.org/assignments/port-numbers>首选[RFC2780]第8节和第9节中定义的。
Where there is a single URI Scheme associated with this protocol, a Subtype SHOULD NOT be specified for the Enumservice.
如果存在与此协议关联的单个URI方案，则不应为Enumservice指定子类型。
Where there are a number of different URI Schemes associated with this protocol, the Enumservice Specification MAY use the empty Subtype for all URI Schemes that it specifies as mandatory to implement. For each URI Scheme that is not mandatory to implement, a distinct Subtype string MUST be used.
如果有许多不同的URI方案与此协议关联，Enumservice规范可能会对其指定为必须实现的所有URI方案使用空子类型。对于每个非强制实现的URI方案，必须使用不同的子类型字符串。
If Subtypes are defined, it is RECOMMENDED to use the URI Scheme name as the Subtype string.
如果定义了子类型，建议使用URI方案名称作为子类型字符串。
Application-based Enumservices are used when the kind of service intended is not fully defined by a protocol specification. There are three cases here:
当协议规范未完全定义所需的服务类型时，将使用基于应用程序的枚举服务。这里有三种情况：
o Common Application Enumservice:
o 通用应用程序枚举服务：
The application reflects a kind of interaction that can be realized by different protocols, but where the intent of the publisher is the same. From a user's perspective, there is a common kind of interaction -- how that interaction is implemented is not important. The Enumservice Specification MUST describe the interaction and expected behavior in enough detail that an
应用程序反映了一种可以通过不同协议实现的交互，但发布者的意图是相同的。从用户的角度来看，有一种常见的交互——如何实现交互并不重要。Enumservice规范必须足够详细地描述交互和预期行为，以便
implementation can decide if this activity is one in which it can engage. However, it is RECOMMENDED that the Enumservice be defined in a way that will allow others to use it at a later date. An Enumservice that defines a generalized application is preferred to one that has narrow use.
实现可以决定此活动是否是它可以参与的活动。但是，建议以允许其他人稍后使用的方式定义Enumservice。定义通用应用程序的Enumservice比使用范围窄的Enumservice更好。
An example of this flavor of Enumservice is email. Whilst this might appear to be a "pure" protocol scheme, it is not. The URI Scheme is 'mailto', and it does not identify the protocol used to offer or retrieve emails by the sender or the recipient.
这种服务风格的一个例子是电子邮件。虽然这似乎是一个“纯”协议方案，但事实并非如此。URI方案是“mailto”，它不标识发件人或收件人用于提供或检索电子邮件的协议。
Another example is the Short Messaging Service (SMS), where the existence of such an Enumservice indicates that the publishing entity is capable of engaging in sending or receiving a message according to the SMS specifications. The underlying protocol used and the URI Scheme for the addressable end point can differ, but the "user visible" interaction of sending and receiving an SMS is similar.
另一个示例是短消息传递服务（SMS），其中这种服务的存在指示发布实体能够根据SMS规范参与发送或接收消息。所使用的底层协议和可寻址端点的URI方案可能不同，但发送和接收SMS的“用户可见”交互是类似的。
o Subset Enumservice:
o 子集枚举服务：
The application interaction reflects a subset of the interactions possible by use of a protocol. Use of this Enumservice indicates that some options available by use of the protocol will not be accepted or are not possible in this case. Any such Enumservice Specification MUST define the options available by use of this NAPTR in enough detail that an implementation can decide whether or not it can use this Enumservice. Examples of this kind of Enumservice are "voice:tel" and "fax:tel". In both cases, the URI holds a telephone number. However, the essential feature of these Enumservices is that the telephone number is capable of receiving a voice call or of receiving a Facsimile transmission, respectively. These form subsets of the interactions capable of using the telephone number, and so have their own Enumservices. These allow an end point to decide if it has the appropriate capability to engage in the advertised user service (a voice call or sending a fax) rather than just being capable of making a connection to such a destination address. This is especially important where there is no underlying mechanism within the protocol to negotiate a different kind of user interaction.
应用程序交互反映了使用协议可能进行的交互的子集。使用此Enumservice表示使用协议提供的某些选项将不被接受，或者在这种情况下不可能。任何此类Enumservice规范都必须足够详细地定义通过使用此NAPTR可用的选项，以便实现能够决定是否可以使用此Enumservice。这类服务的例子有“语音：电话”和“传真：电话”。在这两种情况下，URI都包含一个电话号码。然而，这些服务的基本特征是电话号码能够分别接收语音呼叫或传真传输。这些构成了能够使用电话号码的交互的子集，因此具有自己的服务。这些允许端点决定其是否具有参与广告用户服务（语音呼叫或发送传真）的适当能力，而不仅仅是能够连接到这样的目的地地址。当协议中没有协商不同类型用户交互的底层机制时，这一点尤为重要。
o Ancillary Application Enumservice
o 辅助应用服务
Another variant on this is the Ancillary Application. This is one in which further processing (potentially using a number of different protocols or methods) is the intended result of using this Enumservice. An example of this kind of application is the "pstn:tel" Enumservice. This indicates that the NAPTR holds
这方面的另一个变体是辅助应用程序。在这种情况下，进一步处理（可能使用许多不同的协议或方法）是使用此服务的预期结果。这种应用程序的一个例子是“pstn:tel”服务。这表示NAPTR有效
number portability data. It implies that the client should engage in number portability processing using the associated URI. Note that this Enumservice usually does not itself define the kind of interaction available using the associated URI. That application is negotiated with some other "out of band" means (either through prior negotiation, or explicitly through the number portability process, or through negotiation following the selection of the final destination address).
号码可携性数据。这意味着客户端应该使用相关的URI进行号码可移植性处理。请注意，此Enumservice本身通常不使用关联的URI定义可用的交互类型。该应用程序通过其他一些“带外”方式进行协商（通过事先协商，或明确通过号码可移植性过程，或通过选择最终目的地地址后的协商）。
It is recommended that Application-class Enumservices use the lowercase well-known name of the abstract application as the Type string.
建议应用程序类Enumservices使用抽象应用程序的已知小写名称作为类型字符串。
It is RECOMMENDED that the URI Scheme(s) used by the application be used as the Subtype string(s). Subtype strings MAY be shared between URI Schemes, if all the URI Schemes within the same Subtype are mandatory to implement.
建议将应用程序使用的URI方案用作子类型字符串。如果同一子类型中的所有URI方案都必须实现，则子类型字符串可以在URI方案之间共享。
If it is foreseen that there is only one URI Scheme ever to be used with the application, the empty Subtype string MAY be used.
如果预见到应用程序只使用一个URI方案，则可以使用空的子类型字符串。
"Data Type" Enumservices typically refer to a specific data type or format, which may be addressed using one or more URI Schemes and protocols. Examples of such Enumservices include "vpim" [RFC4238] and "vcard" [RFC4969].
“数据类型”枚举服务通常指的是特定的数据类型或格式，可以使用一个或多个URI方案和协议对其进行寻址。此类服务的示例包括“vpim”[RFC4238]和“vcard”[RFC4969]。
It is recommended to use the lowercase well known name of the data type or format name as the Type string.
建议使用数据类型的小写已知名称或格式名称作为类型字符串。
It is RECOMMENDED to use the URI Schemes used to access the service as Subtype strings. Subtype strings MAY be shared between URI Schemes, if all the URI Schemes within the same Subtype are mandatory to implement.
建议使用用于访问服务的URI方案作为子类型字符串。如果同一子类型中的所有URI方案都必须实现，则子类型字符串可以在URI方案之间共享。
If there is only one URI Scheme foreseen to access the data type or format, the empty Subtype string MAY be used.
如果预计只有一个URI方案可以访问数据类型或格式，则可以使用空的子类型字符串。
In case an Enumservice proposal cannot be assigned to any of the classes mentioned above, the <class> element (Enumservice Class) in the IANA Registration Template (see Section 5.2) MUST be populated with "Other". In that case, the Enumservice Specification MUST contain a section elaborating on why the Enumservice does not fit into the classification structure.
如果无法将Enumservice提案分配给上述任何类别，则IANA注册模板（见第5.2节）中的<class>元素（Enumservice类别）必须填充“其他”。在这种情况下，Enumservice规范必须包含一节，详细说明Enumservice不适合分类结构的原因。
There are several sections that MUST appear in an Enumservice Specification. These sections are as follows, and they SHOULD be in the given order.
Enumservice规范中必须出现几个部分。这些部分如下所示，它们应该按照给定的顺序排列。
The following terms SHOULD begin with a capital letter, whenever they
refer to the IANA Registration:
o Class
o Type
o Subtype
o URI Scheme
The following terms SHOULD begin with a capital letter, whenever they
refer to the IANA Registration:
o Class
o Type
o Subtype
o URI Scheme
An introductory section MUST be included. This section will explain, in plain English, the purpose and intended use of the proposed Enumservice registration.
必须包括介绍部分。本节将用通俗易懂的英语解释拟议Enumservice注册的目的和预期用途。
The Introduction SHOULD start with a short sentence about ENUM, introduce the protocol used in the Enumservice, and discuss the Enumservice as it refers from the E.164 number to the protocol or service.
介绍应以一句关于ENUM的短句开始，介绍Enumservice中使用的协议，并讨论Enumservice，因为它从E.164编号指向协议或服务。
This section MUST be included in an Enumservice Specification. Where a given Enumservice Type has multiple Subtypes, there MUST be a separate "IANA Registration" section for each Subtype. The following sections list the elements that are to be used in the XML-chunk-based Registration Template of an "IANA Registration" section.
此部分必须包含在Enumservice规范中。如果给定的Enumservice类型有多个子类型，则每个子类型必须有单独的“IANA注册”部分。以下部分列出了“IANA注册”部分中基于XML块的注册模板中要使用的元素。
This element contains the Class of the Enumservice as defined in Section 4.2. Its value MUST be one of (without quotes):
此元素包含第4.2节中定义的Enumservice类。其值必须为以下值之一（不带引号）：
o "Protocol-Based": The Enumservice belongs to the Protocol-based class as described in Section 4.2.2.
o “基于协议”：Enumservice属于第4.2.2节所述的基于协议的类别。
o "Application-Based, Common": The Enumservice is a "common" case of the Application-based class as described in Section 4.2.3.
o “基于应用程序的通用”：Enumservice是第4.2.3节中描述的基于应用程序的类的“通用”情况。
o "Application-Based, Subset": The Enumservice belongs to the "subset" case of the Application-based class as described in Section 4.2.3.
o “基于应用程序的子集”：Enumservice属于第4.2.3节所述基于应用程序的类的“子集”情况。
o "Application-Based, Ancillary": The Enumservice is an "ancillary" case of the Application-based class, as described in Section 4.2.3.
o “基于应用程序的辅助”：Enumservice是基于应用程序类的“辅助”案例，如第4.2.3节所述。
o "Data Type-Based": The Enumservice belongs to the Data Type-Based class as described in Section 4.2.4.
o “基于数据类型”：Enumservice属于第4.2.4节所述的基于数据类型的类。
o "Other": The majority of the functionality of the Enumservice does not fall into one of the classes defined.
o “其他”：Enumservice的大部分功能不属于定义的类别之一。
Class Example
课例
<class>Protocol-Based</class>
<class>Protocol-Based</class>
The Type of the Enumservice. All Types SHOULD be listed in lower-case. The choice of Type depends on the Enumservice Class. Please find further instructions in Section 4.
枚举服务的类型。所有类型应以小写字母列出。类型的选择取决于Enumservice类。请参阅第4节中的进一步说明。
Type Example
类型示例
<type>foo</type>
<type>foo</type>
The Subtype of the Enumservice. All Subtypes SHOULD be listed in lower-case. The choice of Subtype depends on the Enumservice Class. Should the Enumservice not utilize a Subtype, then the <subtype> element MUST be omitted in the IANA Registration Template. If a given Enumservice Type has multiple Subtypes, then there MUST be a separate IANA Registration Template for each Subtype. Please find further instructions in Section 4.
枚举服务的子类型。所有子类型应以小写字母列出。子类型的选择取决于Enumservice类。如果Enumservice不使用子类型，则必须在IANA注册模板中省略<Subtype>元素。如果给定的Enumservice类型有多个子类型，则每个子类型必须有单独的IANA注册模板。请参阅第4节中的进一步说明。
Subtype Example
子类型示例
<subtype>bar</subtype>
<subtype>bar</subtype>
The URI Schemes [RFC3986] that are used with the Enumservice. The selection of URI Schemes often depends on the Enumservice Class, Type, and/or Subtype. A colon MUST NOT be placed after the URI Scheme name. If there is more than one URI Scheme, then one <urischeme> element per URI scheme MUST be used in the IANA Registration Template. Please find further instructions in Section 4.
与Enumservice一起使用的URI方案[RFC3986]。URI方案的选择通常取决于Enumservice类、类型和/或子类型。不能将冒号放在URI方案名称之后。如果存在多个URI方案，则必须在IANA注册模板中为每个URI方案使用一个<urischeme>元素。请参阅第4节中的进一步说明。
URI Scheme Example
URI方案示例
<urischeme>bar</urischeme>
<urischeme>sbar</urischeme>
<urischeme>bar</urischeme>
<urischeme>sbar</urischeme>
Note: A client cannot choose a specific ENUM record in a record set based on the URI Scheme - the selection is only based on Type and Subtype, in accordance with [RFC3402].
注意：客户机无法根据URI方案在记录集中选择特定的枚举记录-根据[RFC3402]，选择仅基于类型和子类型。
The Functional Specification describes how the Enumservice is used in connection with the URI to which it resolves.
功能规范描述了如何结合Enumservice解析到的URI使用Enumservice。
Functional Specification Example
功能规范示例
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified can be addressed by the associated
URI in order to foo the bar.
</paragraph>
<paragraph>
[...]
</paragraph>
</functionalspec>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified can be addressed by the associated
URI in order to foo the bar.
</paragraph>
<paragraph>
[...]
</paragraph>
</functionalspec>
Where the terms used are non-obvious, they should be defined in the Enumservice Specification, or a reference to an external document containing their definition should be provided.
如果使用的术语不明显，则应在Enumservice规范中对其进行定义，或者应提供对包含其定义的外部文档的引用。
A reference to the "Security Considerations" section of a given Enumservice Specification.
对给定Enumservice规范的“安全注意事项”部分的引用。
Security Considerations Example
安全注意事项示例
<security>
See <xref type="rfc" data="rfc4979"/>, Section 6.
</security>
<security>
See <xref type="rfc" data="rfc4979"/>, Section 6.
</security>
One of the following values (without quotes):
下列值之一（不带引号）：
o "COMMON": Indicates that the Enumservice is intended for widespread use on the public Internet, and that its scope is not limited to a certain environment.
o “通用”：表示Enumservice旨在在公共互联网上广泛使用，其范围不限于特定环境。
o "LIMITED USE": Indicates that the Enumservice is intended for use on a limited scope, for example in private ENUM-like application scenarios. The use case provided in the Enumservice Specification should describe such a scenario.
o “有限使用”：表示Enumservice打算在有限的范围内使用，例如在类似于私有ENUM的应用程序场景中。Enumservice规范中提供的用例应该描述这样的场景。
o "DEPRECATED": Indicates that the Enumservice has been declared deprecated (Section 11.7) and is not to be used in new deployments. Applications SHOULD however expect to encounter legacy instances of this Enumservice.
o “已弃用”：表示Enumservice已声明为已弃用（第11.7节），并且不会在新部署中使用。但是，应用程序应该会遇到此枚举服务的遗留实例。
Intended Usage Example
预期用途示例
<usage>COMMON</usage>
<usage>COMMON</usage>
Reference(s) to the Document(s) containing the Enumservice Specification.
对包含Enumservice规范的文档的引用。
Enumservice Specification Examples
枚举服务规范示例
<registrationdocs>
<xref type="rfc" data="rfc4979"/>
</registrationdocs>
<registrationdocs>
<xref type="rfc" data="rfc4979"/>
</registrationdocs>
or
或
<registrationdocs>
<xref type="rfc" data="rfc2026"/> (obsoleted by RFC 2551)
<xref type="rfc" data="rfc2551"/>
</registrationdocs>
<registrationdocs>
<xref type="rfc" data="rfc2026"/> (obsoleted by RFC 2551)
<xref type="rfc" data="rfc2551"/>
</registrationdocs>
or
或
<registrationdocs> [International Telecommunications Union, "Enumservice Specification for Foobar", ITU-F Recommendation B.193, Release 73, Mar 2009.] </registrationdocs>
<registrationdocs>[国际电信联盟，“Foobar的Enumservice规范”，ITU-F建议B.193，第73版，2009年3月。]</registrationdocs>
The persons requesting the registration of the Enumservice. Usually these are the authors of the Enumservice Specification.
请求注册Enumservice的人员。通常，他们是Enumservice规范的作者。
Requesters Example
请求者示例
<requesters>
<xref type="person" data="John_Doe"/>
</requesters>
<requesters>
<xref type="person" data="John_Doe"/>
</requesters>
[...]
[...]
<people>
<person id="John_Doe">
<name>John Doe</name>
<org>ACME Research and Development Inc.</org>
<uri>mailto:jd@acme.example.com</uri>
<updated>2008-11-20</updated>
</person>
</people>
<people>
<person id="John_Doe">
<name>John Doe</name>
<org>ACME Research and Development Inc.</org>
<uri>mailto:jd@acme.example.com</uri>
<updated>2008-11-20</updated>
</person>
</people>
If there is more than one requester, there MUST be one <xref> element per requester in the <requesters> element, and one <person> chunk per requester in the <people> element.
如果有多个请求者，<requesters>元素中每个请求者必须有一个<xref>元素，<people>元素中每个请求者必须有一个<person>区块。
Any other information the authors deem interesting, including artwork.
作者认为有趣的任何其他信息，包括艺术品。
Further Information Example
更多信息示例
<additionalinfo>
<paragraph>more info goes here</paragraph>
</additionalinfo>
<additionalinfo>
<paragraph>more info goes here</paragraph>
</additionalinfo>
Note: If there is no such additional information, then the <additionalinfo> element is omitted.
注意：如果没有此类附加信息，则省略<additionalinfo>元素。
This section MUST show at least one example of the Enumservice being registered, for illustrative purposes. The example(s) shall in no way limit the various forms that a given Enumservice may take, and this should be noted at the beginning of this section of the document. The example(s) MUST show the specific formatting of the intended NAPTRs (according to [RFC3403] and [RFC6116]), including one or more NAPTR example(s), AND a brief textual description, consisting of one or more sentences written in plain English, explaining the various parts or attributes of the record(s).
为了便于说明，本节必须显示正在注册的Enumservice的至少一个示例。示例不得以任何方式限制给定Enumservice可能采用的各种形式，且应在本节开头注明。示例必须显示预期NAPTR的具体格式（根据[RFC3403]和[RFC6116]），包括一个或多个NAPTR示例，以及简短的文本描述，包括一个或多个用纯英语编写的句子，解释记录的各个部分或属性。
The example(s) SHOULD contain a brief description how a client supporting this Enumservice could behave, if that description was not already given in, e.g., the Introduction or the Functional Specification.
示例应包含对支持此Enumservice的客户端的行为的简要描述，如果该描述尚未在介绍或功能规范中给出。
The example(s) SHOULD follow any relevant IETF guidelines on the use of domain names, phone numbers, and other resource identifier examples, such as [RFC2606].
示例应遵循任何有关使用域名、电话号码和其他资源标识符示例的IETF指南，如[RFC2606]。
For example: $ORIGIN 9.7.8.0.6.9.2.3.6.1.4.4.e164.arpa. @ IN NAPTR 100 10 "u" "E2U+foo:bar" "!^.*$!bar://example.com/!" .
例如：$ORIGIN 9.7.8.0.6.9.2.3.6.1.4.4.e164.arpa.@在NAPTR 100中10“u”E2U+foo:bar“！^.*$！bar://example.com/!" .
Recommendations that pertain to implementation and/or operations SHOULD be included. Such a section is helpful to someone reading an Enumservice Specification and trying to understand how best to use it to support their network or service.
应包括与实施和/或操作有关的建议。这样的部分对于阅读Enumservice规范并试图理解如何最好地使用它来支持其网络或服务的人很有帮助。
In case the inclusion of protocols and URI Schemes into ENUM specifically introduces new DNS issues, those MUST be described within this section.
如果将协议和URI方案包含到ENUM中会特别引入新的DNS问题，则必须在本节中描述这些问题。
Such DNS issues include, but are not limited to:
此类DNS问题包括但不限于：
o Assumptions about ownership or administrative control of the namespace.
o 关于命名空间的所有权或管理控制的假设。
o Requirement or need to use DNS wildcards.
o 要求或需要使用DNS通配符。
o Incompatibility with DNS wildcards.
o 与DNS通配符不兼容。
o Presence or absence of respective NAPTR Resource Records at particular levels in the DNS hierarchy (e.g., only for "full" E.164 numbers or wildcards only).
o DNS层次结构中特定级别上是否存在相应的NAPTR资源记录（例如，仅适用于“完整”的，如164个数字或通配符）。
o Use of any Resource Records (especially non-NAPTR) within or beyond the e164.arpa namespace other than those needed to resolve the domain names that appear in the "replacement" URI.
o 使用e164.arpa命名空间内或之外的任何资源记录（尤其是非NAPTR），解析“替换”URI中出现的域名所需的记录除外。
o Potential for significant additional load on the nameserver chain due to use of the service, and the mitigation of such additional load.
o 由于使用该服务，名称服务器链上可能会出现显著的额外负载，并减轻此类额外负载。
o Mitigation of potential for DNS loops, specifically in cases where the result URI of an Enumservice might be used to trigger additional (subsequent) ENUM queries. This applies in particular to Enumservices using the 'tel' URI Scheme [RFC3966] or any other (future) URI Scheme using (E.164) numbers. "The ENUM Dip Indicator Parameter for the tel URI" [RFC4759] provides an example of a loop mitigation mechanism.
o 减少DNS循环的可能性，特别是在Enumservice的结果URI可能用于触发其他（后续）ENUM查询的情况下。这尤其适用于使用“tel”URI方案[RFC3966]或使用（E.164）号码的任何其他（未来）URI方案的Enumservices。“tel URI的ENUM Dip指示符参数”[RFC4759]提供了循环缓解机制的示例。
Rationale: some Enumservices try to exploit side effects of the DNS that need to be explicitly discussed.
理由：一些Enumservices试图利用DNS的副作用，这些副作用需要明确讨论。
A section explaining any potential security threats that are especially applicable to the given registration MUST be included. This MUST also include any information about access to Personally Identifiable Information (PII).
必须包括一节，解释特别适用于给定注册的任何潜在安全威胁。这还必须包括有关访问个人身份信息（PII）的任何信息。
An Enumservice Specification SHOULD NOT include general and obvious security recommendations, such as securing servers with strong password authentication.
Enumservice规范不应包括一般和明显的安全建议，例如使用强密码身份验证保护服务器。
For additional background, please note that [RFC3552] provides guidance to write a good Security Considerations section. In addition, [RFC6116] already outlines security considerations affecting ENUM as a whole. Enumservice Specifications do not need to and SHOULD NOT repeat considerations already listed in that document. However, Enumservice Specifications SHOULD include a reference to that section.
对于其他背景，请注意[RFC3552]提供了编写良好安全注意事项部分的指导。此外，[RFC6116]已经概述了影响整个ENUM的安全注意事项。Enumservice规范不需要也不应该重复该文档中已经列出的注意事项。但是，Enumservice规范应该包括对该部分的引用。
Also, ENUM refers to resources using existing URI Schemes and protocols. Enumservice Specifications do not need to and SHOULD NOT repeat security considerations affecting those protocols and URI Schemes themselves.
此外，ENUM指的是使用现有URI方案和协议的资源。Enumservice规范不需要也不应该重复影响这些协议和URI方案本身的安全考虑。
However, in some cases, the inclusion of those protocols and URI Schemes into ENUM specifically could introduce new security issues. In these cases, those issues or risks MUST be covered in the "Security Considerations" section of the Enumservice Specification. Authors should pay particular attention to any indirect risks that are associated with a proposed Enumservice, including cases where the proposed Enumservice could lead to the discovery or disclosure of Personally Identifiable Information (PII).
然而，在某些情况下，将这些协议和URI方案包含到ENUM中可能会带来新的安全问题。在这些情况下，这些问题或风险必须包含在Enumservice规范的“安全注意事项”部分中。作者应特别注意与提议的Enumservice相关的任何间接风险，包括提议的Enumservice可能导致发现或披露个人身份信息（PII）的情况。
Describe the task IANA needs to fulfill to process the Enumservice Registration Document.
描述IANA处理Enumservice注册文档需要完成的任务。
For example: This document requests the IANA registration of the Enumservice with Type "foo" and Subtype "bar" according to the definitions in this document, [RFC6117], and [RFC6116].
例如：根据本文档[RFC6117]和[RFC6116]中的定义，本文档请求Enumservice的IANA注册，类型为“foo”，子类型为“bar”。
For example: This document requests an update of the IANA registration of the Enumservice Type "foo" with Subtype "bar", according to the definitions in this document, [RFC6117], and [RFC6116]. Therefore, in the existing IANA registration for this Enumservice, the <registrationdocs> element (Enumservice Specification) is enhanced by adding a supplementary reference that points to this document.
例如：根据本文档[RFC6117]和[RFC6116]中的定义，本文档要求更新Enumservice类型为“foo”且子类型为“bar”的IANA注册。因此，在该Enumservice的现有IANA注册中，<registrationdocs>元素（Enumservice规范）通过添加指向该文档的补充引用而得到增强。
For example: This document requests an update of the IANA registration of the Enumservice Type "foo" with all its Subtypes, in order to declare it deprecated. Therefore, in the existing IANA registration for this Enumservice, the <usage> element (Intended Usage) is changed to "DEPRECATED", and the <registrationdocs> element (Enumservice Specification) is enhanced by adding a supplementary reference that points to this document.
例如：本文档请求更新Enumservice类型“foo”及其所有子类型的IANA注册，以声明其已弃用。因此，在该Enumservice的现有IANA注册中，<usage>元素（预期用途）更改为“弃用”，并且通过添加指向该文档的补充引用来增强<registrationdocs>元素（Enumservice规范）。
Other sections beyond those required above MAY be included in an Enumservice Specification. These sections may relate to the specifics of the intended use of the Enumservice registration, as well as to any associated technical, operational, administrative, or other concerns.
上述要求之外的其他部分可能包含在Enumservice规范中。这些章节可能涉及Enumservice注册的预期用途的细节，以及任何相关的技术、操作、管理或其他问题。
A use case SHOULD be included by the authors of the proposal, so that experts can better understand the problem the proposal seeks to solve (intended use of the Enumservice). The inclusion of such a use case
提案的作者应包括一个用例，以便专家能够更好地理解提案试图解决的问题（服务的预期用途）。包含这样一个用例
will both accelerate the Expert Review process, as well as make any eventual registration easier to understand and implement by other parties.
这将加快专家审评进程，并使任何最终登记更容易被其他缔约方理解和执行。
This section is an illustration of the process by which a new Enumservice Registration Document is submitted for review and comment, how such proposed Enumservices are reviewed, and how they are published. This section is a non-normative description of the process. The normative process is described in [RFC5226].
本节说明了提交新Enumservice注册文档以供审查和评论的过程、如何审查此类拟议Enumservice以及如何发布这些服务。本节是对过程的非规范性描述。[RFC5226]中描述了规范过程。
Figure 1 shows what authors of a Registration Document describing an Enumservice must carry out before said Registration Document can be formally submitted to IANA for Expert Review. Figure 2 shows the process from Expert Review onwards.
图1显示了描述Enumservice的注册文档的作者必须执行哪些操作，然后才能将所述注册文档正式提交给IANA进行专家审查。图2显示了从专家评审开始的过程。
+----------------------------+
| Step 1: Read this document |
+----------------------------+
|
V
+-------------------------------+
| Step 2: Write R-D and submit |
+-------------------------------+
|
V
+--------------------------------------------+
| Step 3: Announce R-D and solicit feedback |<--+
+--------------------------------------------+ |
| |
V |
.^. |
. . |
+------------+ . Feed- . +------------+
| Update R-D |<---------< back >------------>| Update R-D |
| and submit | non-sub- . results . substantial | and submit |
+------------+ stantial . in: . changes +------------+
| changes . . needed
| needed Y
| | no changes needed
| V
| +-----------------------------+
+-------->| Step 4: Submit R-D to IANA |
+-----------------------------+
:
:
V
+----------------------------+
| Step 1: Read this document |
+----------------------------+
|
V
+-------------------------------+
| Step 2: Write R-D and submit |
+-------------------------------+
|
V
+--------------------------------------------+
| Step 3: Announce R-D and solicit feedback |<--+
+--------------------------------------------+ |
| |
V |
.^. |
. . |
+------------+ . Feed- . +------------+
| Update R-D |<---------< back >------------>| Update R-D |
| and submit | non-sub- . results . substantial | and submit |
+------------+ stantial . in: . changes +------------+
| changes . . needed
| needed Y
| | no changes needed
| V
| +-----------------------------+
+-------->| Step 4: Submit R-D to IANA |
+-----------------------------+
:
:
V
R-D: Registration Document
R-D：注册文件
Figure 1
图1
This document, particularly in Sections 3, 4, and 5, describes all of the recommended and required sections, as well as requirements and suggestions for content of an Enumservice Specification.
本文档，特别是第3、4和5节，描述了所有推荐和必需的部分，以及Enumservice规范内容的要求和建议。
An Internet-Draft (or another specification as appropriate) must be written and made publicly available (submitted). The Registration Document shall follow the guidelines according to Sections 4 and 5 of
互联网草案（或其他适当的规范）必须编写并公开（提交）。注册文件应遵循本协议第4节和第5节规定的指南
this document. The Review Guidelines for experts are defined in Section 7.2.
这份文件。第7.2节定义了专家评审指南。
The authors shall send an email to <enum@ietf.org>, in which comments on the Registration Document are requested. A proper public reference (a URL is recommended) to the Registration Document must be included in this email.
作者应向以下地址发送电子邮件：<enum@ietf.org>，其中要求对注册文件提出意见。此电子邮件中必须包含注册文件的适当公开引用（建议使用URL）。
Note: The ENUM WG mailing list <enum@ietf.org> will be kept open after conclusion of the ENUM WG.
注意：ENUM WG邮件列表<enum@ietf.org>将在ENUM工作组结束后继续开放。
The authors should allow a reasonable period of time to elapse, such as two to four weeks, in order to collect any feedback. The authors then consider whether or not to take any of those comments into account, by making changes to the Registration Document and submitting a revision, or otherwise proceeding. The following outcomes are open to the authors. The choice of path is left to the authors' judgement.
作者应该留出一段合理的时间，例如两到四周，以便收集任何反馈。然后，作者考虑是否通过修改注册文件并提交修订或其他方式来考虑这些评论中的任何一项。以下结果对作者开放。道路的选择由作者来决定。
Note: Whatever the outcome is, the experts performing the Expert Review later in the process are not bound to any decision during this phase.
注：无论结果如何，在该过程后期执行专家评审的专家在此阶段不受任何决定的约束。
No changes to the Registration Document are made, and the authors proceed to Step 4 below.
未对注册文件进行任何更改，作者继续执行下面的步骤4。
This outcome is recommended when the feedback received does not lead to a new revision of the Registration Document.
当收到的反馈不会导致注册文件的新修订时，建议采用此结果。
The authors update the Registration Document and is/are confident that all issues are resolved and do not require further discussion. The authors proceed to Step 4 below.
作者更新了注册文件，并确信所有问题都已解决，无需进一步讨论。作者继续进行下面的第4步。
This outcome is recommended when minor objections have been raised, or minor changes have been suggested.
当有人提出小的反对意见或建议进行小的修改时，建议采用这种结果。
The authors update and submit the Registration Document, and proceed to Step 3 above, which involves sending another email to <enum@ietf.org> to request additional comments for the updated version.
作者更新并提交注册文档，然后继续执行上面的步骤3，其中包括向发送另一封电子邮件<enum@ietf.org>请求对更新版本的其他注释。
This outcome is recommended when substantial objections have been raised, or substantial changes have been suggested.
当有人提出实质性反对意见或建议进行实质性修改时，建议采用此结果。
The authors submit the Registration Document to IANA (using the <http://www.iana.org/> website) for Expert Review.
作者向IANA提交注册文件（使用<http://www.iana.org/>网站）供专家审查。
:
:
V
+-----------------------+
| Step 5: Expert Review |<-------------+
+-----------------------+ |
| |
V |
.^. |
. . |
.---------. . Expert . +------------+
( Bad luck! )<-------- < Review >------------>| Update R-D |
`---------' experts . results . changes | and submit |
reject . in: . required +------------+
. .
Y
| experts approve
V
+-----------------------------------+
| Step 6: Publication of R-D |
+-----------------------------------+
|
V
+---------------------------------------------+
| Step 7: Adding Enumservice to IANA Registry |
+---------------------------------------------+
:
:
V
+-----------------------+
| Step 5: Expert Review |<-------------+
+-----------------------+ |
| |
V |
.^. |
. . |
.---------. . Expert . +------------+
( Bad luck! )<-------- < Review >------------>| Update R-D |
`---------' experts . results . changes | and submit |
reject . in: . required +------------+
. .
Y
| experts approve
V
+-----------------------------------+
| Step 6: Publication of R-D |
+-----------------------------------+
|
V
+---------------------------------------------+
| Step 7: Adding Enumservice to IANA Registry |
+---------------------------------------------+
R-D: Registration Document
R-D：注册文件
Figure 2
图2
IANA will take care of the "Expert Review" according to [RFC5226]. The Expert Review guidelines are outlined in Section 7.2 of this document. The authors must be prepared for further interaction with IANA and the experts.
IANA将根据[RFC5226]负责“专家评审”。本文件第7.2节概述了专家评审指南。作者必须做好与IANA和专家进一步互动的准备。
No (more) changes to the Registration Document are made. IANA will inform the authors, who then will proceed to Step 6 below.
没有（更多）更改注册文件。IANA将通知提交人，然后提交人将进入下面的第6步。
The experts might require changes before they can approve the Registration Document. The authors update and submit the Registration Document. The authors inform the experts about the available update, who then continue the Expert Review Process.
专家在批准注册文件之前可能需要进行更改。作者更新并提交注册文件。作者将可用更新通知专家，然后专家继续专家审查过程。
The expert might reject the Registration, which means the Expert Review process is discontinued.
专家可能会拒绝注册，这意味着专家审查过程将中止。
The authors are responsible for ensuring that the Registration Document is published according to "Specification Required" as defined in [RFC5226].
作者负责确保按照[RFC5226]中定义的“所需规范”发布注册文件。
As set out in Section 3.4 it is strongly RECOMMENDED that Enumservice Specifications be published RFCs. As to every RFC, the normal IETF publication process applies (see [Instructions2authors]); i.e., the Registration Document is submitted in the form of an Internet Draft (e.g. via an IETF Working Group or a sponsoring Area Director). [Instructions2authors] also contains an option to publish an RFC as 'Independent Submission', which is further described in "Independent Submissions to the RFC Editor" [RFC4846].
如第3.4节所述，强烈建议在RFC中发布Enumservice规范。对于每个RFC，通常的IETF发布过程适用（见[说明2作者]）；i、 例如，注册文件以互联网草案的形式提交（例如，通过IETF工作组或赞助区域主任）。[Instructions2authors]还包含将RFC发布为“独立提交”的选项，这在“向RFC编辑器的独立提交”[RFC4846]中有进一步说明。
In cases where the Registration Document is to be published as an RFC, the RFC publication process ensures that IANA will add the Enumservice to the registry.
如果注册文档将作为RFC发布，RFC发布过程将确保IANA将Enumservice添加到注册表中。
In cases where the Registration Document is to be published in a specification other than RFC, the authors must inform IANA, as soon as the Enumservice Specification has been published according to "Specification Required" as defined in [RFC5226]. The <registrationdocs> element in the IANA Registration Template must contain an unambiguous reference to the Enumservice Specification (see also Section 5.2). In addition, the authors must provide IANA with a stable URL to the Enumservice Specification, in order that IANA may obtain the information included in the Enumservice Specification. IANA will then add the Enumservice to the registry.
如果注册文件将以RFC以外的规范发布，作者必须在Enumservice规范按照[RFC5226]中定义的“所需规范”发布后立即通知IANA。IANA注册模板中的<registrationdocs>元素必须包含对Enumservice规范的明确引用（另请参见第5.2节）。此外，作者必须为IANA提供指向Enumservice规范的稳定URL，以便IANA可以获得Enumservice规范中包含的信息。然后，IANA会将Enumservice添加到注册表中。
According to Section 3.2 of [RFC5226], experts are appointed by the IESG. The IESG is responsible for ensuring that there is always a sufficient pool of experts available.
根据[RFC5226]第3.2节，专家由IESG任命。IESG负责确保始终有足够的可用专家库。
Generally, the "Expert Review" process of an Enumservice follows the guidelines documented in Section 3.3 of "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]. Note that RFC 5226 says 'The review may be wide or narrow, depending on the situation and the judgment of the designated expert'. Therefore, the following list should be considered a guideline, rather than a binding list.
通常，Enumservice的“专家评审”过程遵循“RFCs中编写IANA注意事项部分的指南”[RFC5226]第3.3节中记录的指南。请注意，RFC 5226表示“根据情况和指定专家的判断，审查可能是宽的，也可能是窄的”。因此，以下清单应被视为指南，而不是具有约束力的清单。
In case of conflicts between [RFC5226] and the guidelines in this section, [RFC5226] remains authoritative.
如果[RFC5226]与本节中的指南存在冲突，[RFC5226]仍具有权威性。
The expert evaluates the criteria as set out in [RFC5226], and should additionally consider the following:
专家评估在[RCF5226]中所列的标准，并且应另外考虑如下：
o Verify conformance with the ENUM specification [RFC6116].
o 验证是否符合枚举规范[RFC6116]。
o Verify that the requirements set out in this document (Sections 3 and 5) are met. This includes checking for completeness and whether all the aspects described in Sections 3 and 5 are sufficiently addressed.
o 验证是否满足本文件（第3节和第5节）中规定的要求。这包括检查完整性以及第3节和第5节中描述的所有方面是否得到充分解决。
o If a use case is provided, the experts should verify whether the proposed Enumservice does actually match the use case. The experts should also determine whether the use case could be covered by an existing Enumservice.
o 如果提供了一个用例，专家们应该验证提议的Enumservice是否确实与用例匹配。专家们还应该确定用例是否可以被现有的Enumservice覆盖。
o Verify that the Enumservice proposed cannot be confused with identical (or similar) other Enumservices already registered.
o 验证建议的Enumservice不能与已注册的相同（或类似）其他Enumservice混淆。
o If the Enumservice is classified according to Section 4.2, the experts must verify that the principles of the Class in question are followed.
o 如果根据第4.2节对Enumservice进行分类，专家必须验证是否遵循了相关类别的原则。
o In case the Enumservice is not classified, the experts must verify whether a convincing reason for the deviation is provided in the Registration Document.
o 如果服务未分类，专家必须核实注册文件中是否提供了令人信服的偏差原因。
o Investigate whether the proposed Enumservice has any negative side effects on existing clients and infrastructure, particularly the DNS.
o 调查建议的Enumservice是否对现有客户端和基础架构（尤其是DNS）有任何负面影响。
o If the output of processing an Enumservice might be used for input to more ENUM processing (especially services returning 'tel' URIs), the experts should verify that the authors have adequately addressed the issue of potential query loops.
o 如果处理Enumservice的输出可能用于输入更多ENUM处理（特别是返回“tel”URI的服务），专家应验证作者是否充分解决了潜在查询循环的问题。
Appeals of Expert Review decisions follow the process described in Section 7 of [RFC5226] and Section 6.5 of [RFC2026].
专家评审决定的上诉遵循[RFC5226]第7节和[RFC2026]第6.5节所述的程序。
Many Enumservice registrations, published via IETF RFCs, already exist at the time of the development of this document. These existing Enumservice Specifications MAY be revised to comply with the specifications contained herein. All revisions of Enumservice Specifications MUST be compliant with the specifications contained herein.
在编写本文档时，通过IETF RFCs发布的许多Enumservice注册已经存在。这些现有的Enumservice规范可能会进行修订，以符合本文包含的规范。Enumservice规范的所有修订版必须符合此处包含的规范。
Note: Enumservice Specifications updated only by [RFC6118] are not compliant with the specifications contained herein!
注意：仅由[RFC6118]更新的Enumservice规范不符合此处包含的规范！
There are cases where it is more sensible to extend an existing Enumservice registration rather than propose a new one. Such cases include adding a new Subtype to an existing Type. Depending on the nature of the extension, the original Enumservice Specification needs to be extended (Updates) or replaced (Obsoletes) [RFC2223]. Specifically, an update is appropriate when a new Subtype is being added without changes to the existing repertoire. A replacement is needed if there is a change to the default, or changes to the assumptions of URI support in clients.
在某些情况下，扩展现有的Enumservice注册比提出新注册更为明智。此类情况包括向现有类型添加新的子类型。根据扩展的性质，需要扩展（更新）或替换（废弃）原始Enumservice规范[RFC2223]。具体而言，当添加新的子类型而不更改现有曲目集时，更新是合适的。如果默认设置发生更改，或者客户端中URI支持的假设发生更改，则需要进行替换。
Any Enumservice Specifications for existing Enumservices that are extended MUST comply with the specifications contained herein. As a consequence, revisions of existing Enumservice Specifications may be required according to Section 8.
扩展的现有Enumservice的任何Enumservice规范必须符合本文包含的规范。因此，可能需要根据第8节对现有的Enumservice规范进行修订。
Since this document does not introduce any new technology, protocol, or Enumservice Specification, there are no specific security issues to be considered for this document. However, as this is a guide to authors of new Enumservice Specifications, the next section should be considered closely by authors and experts.
由于本文档未引入任何新技术、协议或Enumservice规范，因此本文档不需要考虑任何特定的安全问题。但是，由于这是新Enumservice规范作者的指南，因此作者和专家应仔细考虑下一节。
Guidelines concerning the Security Considerations section of an Enumservice Specification can be found in Section 5.6.
有关Enumservice规范的安全注意事项部分的指南，请参见第5.6节。
IANA updated the registry "Enumservice Registrations" as defined in (this) Section 11, which replaces the old mechanism as defined in [RFC3761].
IANA更新了第11节中定义的注册表“Enumservice Registrations”，它取代了[RFC3761]中定义的旧机制。
It is noted that the process described herein applies only to ordinary Enumservice registrations (i.e., the registration process of "X-" Enumservices is beyond the scope of this document, and as per [RFC6116] "P-" Enumservices will not be registered at all).
注意，本文描述的过程仅适用于普通Enumservice注册（即，“X-”Enumservices的注册过程超出了本文的范围，并且根据[RFC6116]“P-”Enumservices将根本不注册）。
<record>
<class> <!-- Enumservice Class --> </class>
<type> <!-- Type --> </type>
<subtype> <!-- Subtype --> </subtype>
<urischeme> <!-- URI Schema Name --> </urischeme>
<urischeme> <!-- another URI Schema Name --> </urischeme>
<functionalspec>
<paragraph>
<!-- Text that explains the functionality of
the Enumservice to be registered -->
</paragraph>
</functionalspec>
<security>
<!-- Security Considerations of the
Enumservice to be registered -->
</security>
<usage> <!-- COMMON, LIMITED USE, or OBSOLETE --> </usage>
<registrationdocs>
<record>
<class> <!-- Enumservice Class --> </class>
<type> <!-- Type --> </type>
<subtype> <!-- Subtype --> </subtype>
<urischeme> <!-- URI Schema Name --> </urischeme>
<urischeme> <!-- another URI Schema Name --> </urischeme>
<functionalspec>
<paragraph>
<!-- Text that explains the functionality of
the Enumservice to be registered -->
</paragraph>
</functionalspec>
<security>
<!-- Security Considerations of the
Enumservice to be registered -->
</security>
<usage> <!-- COMMON, LIMITED USE, or OBSOLETE --> </usage>
<registrationdocs>
<!-- Change accordingly -->
<xref type="rfc" data="rfc2551"/>
</registrationdocs>
<requesters>
<!-- Change accordingly -->
<xref type="person" data="John_Doe"/>
<xref type="person" data="Jane_Dale"/>
</requesters>
<additionalinfo>
<paragraph>
<!-- Text with additional information about
the Enumservice to be registered -->
</paragraph>
<artwork>
<!-- There can be artwork sections, too -->
:-)
</artwork>
</additionalinfo>
</record>
<!-- Change accordingly -->
<xref type="rfc" data="rfc2551"/>
</registrationdocs>
<requesters>
<!-- Change accordingly -->
<xref type="person" data="John_Doe"/>
<xref type="person" data="Jane_Dale"/>
</requesters>
<additionalinfo>
<paragraph>
<!-- Text with additional information about
the Enumservice to be registered -->
</paragraph>
<artwork>
<!-- There can be artwork sections, too -->
:-)
</artwork>
</additionalinfo>
</record>
<people>
<person id="John_Doe">
<name> <!-- Firstname Lastname --> </name>
<org> <!-- Organisation Name --> </org>
<uri> <!-- mailto: or http: URI --> </uri>
<updated> <!-- date format YYYY-MM-DD --> </updated>
</person>
<!-- repeat person section for each person -->
</people>
<people>
<person id="John_Doe">
<name> <!-- Firstname Lastname --> </name>
<org> <!-- Organisation Name --> </org>
<uri> <!-- mailto: or http: URI --> </uri>
<updated> <!-- date format YYYY-MM-DD --> </updated>
</person>
<!-- repeat person section for each person -->
</people>
Authors of an Enumservice Specification are encouraged to use these XML chunks as a template to create the IANA Registration Template. Examples for the use of this template are contained in Appendix A.
我们鼓励Enumservice规范的作者使用这些XML块作为模板来创建IANA注册模板。本模板的使用示例见附录A。
Approved Enumservice registrations are published in the IANA registry named "Enumservice Registrations", which is available at the following URI: <http://www.iana.org/assignments/enum-services>.
批准的Enumservice注册在名为“Enumservice registrations”的IANA注册表中发布，该注册表位于以下URI：<http://www.iana.org/assignments/enum-services>.
This registry publishes representations derived from the IANA Registration Template as described in Section 11.2 and specified in Section 5.2.
本注册中心发布第11.2节所述和第5.2节规定的源自IANA注册模板的表示。
Where the Enumservice Specification is not an RFC, IANA must hold an escrow copy of that Enumservice Specification. Said escrow copy will act as the master reference for that Enumservice registration.
如果Enumservice规范不是RFC，IANA必须持有该Enumservice规范的托管副本。上述托管副本将作为该服务注册的主要参考。
IANA maintains the Enumservice Registry sorted in alphabetical order. The first sort field is Type, the second is Subtype.
IANA维护按字母顺序排序的Enumservice注册表。第一个排序字段是Type，第二个是Subtype。
[RFC6118] updates the existing Enumservices by transforming them into the new XML-chunk-based IANA Registration Template (see also Section 8).
[RFC6118]通过将现有Enumservices转换为新的基于XML块的IANA注册模板来更新它们（另请参见第8节）。
Whenever a Registration Document is submitted via the IANA website, IANA will take care of the "Expert Review" process according to "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226].
无论何时通过IANA网站提交注册文件，IANA都将根据“在RFCs中编写IANA注意事项部分的指南”[RFC5226]处理“专家评审”过程。
To prevent clashes, IANA will check whether a request with identical "type:subtype" (or "type" without Subtype) was submitted for Expert Review earlier and will inform the experts accordingly. The experts are authorized to resolve clashes as they see fit. The requesters may need to update their registration request before getting expert approval.
为防止冲突，IANA将检查具有相同“类型：子类型”（或“类型”无子类型）的请求是否已提前提交给专家审查，并将相应地通知专家。专家们被授权在他们认为合适的时候解决冲突。申请者可能需要在获得专家批准之前更新其注册申请。
Once the experts have conditionally approved the Enumservice, IANA will inform the authors. This information should also include a reminder that (i) the authors are now responsible for publication of the Registration Document (see also Section 6.6) and (ii) the Enumservice will be added to the IANA registry only after its Enumservice Specification is published according to the "Specification Required" policy as defined in [RFC5226] (see also Section 6.7).
一旦专家有条件地批准Enumservice，IANA将通知作者。该信息还应包括以下提醒：（i）作者现在负责发布注册文件（另见第6.6节）和（ii）Enumservice只有在其Enumservice规范根据[RFC5226]中定义的“所需规范”政策发布后才会添加到IANA注册中心（另见第6.7节）。
Note: After sending the approval note to the authors, IANA has no further responsibilities besides keeping internal records of approved Registration Documents. IANA will be involved again at registration of the Enumservice (see Section 11.6).
注：在向作者发送批准通知后，IANA除了保留已批准注册文件的内部记录外，没有其他责任。IANA将再次参与Enumservice的注册（见第11.6节）。
There is a slight difference in process depending on whether or not the Enumservice Specification will be published as an RFC. The reason for this difference lies in the current RFC publication process that includes IANA interaction shortly before publication of an RFC.
根据Enumservice规范是否将作为RFC发布，过程中会有细微的差异。造成这种差异的原因在于当前的RFC发布过程，该过程在RFC发布之前不久包括IANA交互。
As per the RFC publication process, IANA will receive the Enumservice Specification to carry out IANA actions shortly before publication of the RFC. The IANA action will be to register the Enumservice, i.e., add the Enumservice to the IANA "Enumservice Registrations" registry (see also Section 11.3).
根据RFC发布流程，IANA将收到Enumservice规范，以便在RFC发布前不久执行IANA操作。IANA的操作是注册Enumservice，即将Enumservice添加到IANA“Enumservice注册”注册表中（另请参见第11.3节）。
IANA must only add Enumservices to the Registry, if the experts have (conditionally) approved the corresponding Enumservice Specification. IANA should attempt to resolve possible conflicts arising from this together with the experts. In case there are substantial changes between the (conditionally) approved and the to be published version, IANA may reject the request after consulting the experts.
如果专家（有条件地）批准了相应的Enumservice规范，IANA只能将Enumservices添加到注册表中。IANA应与专家一起努力解决由此产生的可能冲突。如果（有条件地）批准的版本与即将发布的版本之间存在重大变化，IANA可在咨询专家后拒绝该请求。
IANA must ensure that any further substantial changes the Enumservice Specification might undergo before final RFC publication are approved by the experts.
IANA必须确保在专家批准最终RFC发布之前，Enumservice规范可能会经历任何进一步的实质性更改。
Note: Clearly editorial changes (such as typos) or minor changes in purely editorial sections (such as Authors' Addresses, Acknowledgments, References, and alike) are not considered substantial.
注：显然，编辑更改（如打字错误）或纯编辑部分的微小更改（如作者地址、致谢、参考资料等）不被视为实质性更改。
Once the authors have informed IANA about the publication, IANA must ensure that the requirements for "Specification Required" as defined in [RFC5226] are met, the reference to the specification is unambiguous, and the content of the Enumservice Specification is identical to the Registration Document as approved by the experts. IANA will then register the Enumservice, i.e., add the Enumservice to the IANA "Enumservice Registrations" registry, and make an escrow copy (see also Section 11.3).
一旦作者将出版物通知IANA，IANA必须确保满足[RFC5226]中定义的“所需规范”的要求，规范的参考是明确的，Enumservice规范的内容与专家批准的注册文件相同。IANA随后将注册Enumservice，即将Enumservice添加到IANA“Enumservice Registrations”注册表中，并制作托管副本（另请参见第11.3节）。
IANA must only add Enumservices to the Registry, if the experts have approved the corresponding Enumservice Specification. IANA should attempt to resolve possible conflicts arising from this together with the experts. In case there are substantial changes between the approved and the published version, IANA may reject the request after consulting the experts.
如果专家已经批准了相应的Enumservice规范，IANA只能将Enumservices添加到注册表中。IANA应与专家一起努力解决由此产生的可能冲突。如果批准的版本与发布的版本之间存在重大变化，IANA可在咨询专家后拒绝该请求。
Note: Clearly editorial changes (such as typos) or minor changes in purely editorial sections (such as Authors' Addresses, Acknowledgments, References, and alike) are not considered substantial.
注：显然，编辑更改（如打字错误）或纯编辑部分的微小更改（如作者地址、致谢、参考资料等）不被视为实质性更改。
Change control of any Enumservice registrations is done by "Specification Required", which implies the use of a Designated Expert, according to [RFC5226]. Updates of Enumservice Specifications MUST comply with the requirements described in this document. Updates are handled the same way as initial Enumservice registrations.
根据[RFC5226]，任何Enumservice注册的变更控制均由“所需规范”完成，这意味着使用指定专家。Enumservice规范的更新必须符合本文档中描述的要求。更新的处理方式与初始Enumservice注册相同。
Authorized Change Controllers are the experts and the IESG.
授权变更控制者是专家和IESG。
Enumservice registrations must not be deleted. An Enumservice that is believed to be no longer appropriate for use can be declared deprecated by publication of a new Enumservice Specification, changing the Enumservice <usage> element (Intended Usage) to "DEPRECATED"; such Enumservices will be clearly marked in the lists published by IANA. As obsoletions are updates, they are also handled the same way as initial Enumservice registrations. Alternatively, Enumservices may be declared deprecated by an IESG action.
不能删除枚举服务注册。通过发布新的Enumservice规范，将Enumservice<usage>元素（预期用途）更改为“deprecated”，可以声明不再适合使用的Enumservice已弃用；IANA发布的列表中将明确标明此类服务。由于淘汰是更新，因此它们的处理方式也与初始Enumservice注册相同。或者，可以通过IESG操作声明Enumservices已弃用。
As stated in Section 3.2, a "-" (dash) MUST NOT be used as the first nor as the second nor as the last character of a Type or a Subtype. Furthermore, Type or Subtype of any Enumservice MUST NOT be set to, nor start with, "E2U". Any Enumservice registration requests not following these restrictions must be rejected by IANA, and the Expert Review process should not be initiated.
如第3.2节所述，不得将“-”（破折号）用作类型或子类型的第一个、第二个或最后一个字符。此外，任何Enumservice的类型或子类型都不能设置为“E2U”，也不能以“E2U”开头。IANA必须拒绝任何不符合这些限制的Enumservice注册请求，并且不应启动专家审查流程。
Section 5.2 contains examples for Enumservice registrations. Therefore, IANA must not register an Enumservice with Type or Subtype set to "foo", "bar", or "sbar", unless the experts explicitly confirm an exception.
第5.2节包含枚举服务注册的示例。因此，IANA不得注册类型或子类型设置为“foo”、“bar”或“sbar”的Enumservice，除非专家明确确认异常。
The authors would like to thank the following people who have provided feedback or significant contributions to the development of this document: Jari Arkko, Stewart Bryant, Gonzalo Camarillo, Lawrence Conroy, Michelle Cotton, Miguel Garcia, David Harrington, Alfred Hoenes, Ari Keranen, Peter Koch, Edward Lewis, Alexey Melnikov, Jon Peterson, Pekka Savola, and Peter Saint-Andre.
作者要感谢为本文件的编制提供反馈或重大贡献的以下人员：雅丽·阿尔科、斯图尔特·布莱恩特、冈萨洛·卡马里洛、劳伦斯·康罗伊、米歇尔·科顿、米格尔·加西亚、大卫·哈林顿、阿尔弗雷德·霍恩斯、阿里·凯拉宁、彼得·科赫、爱德华·刘易斯、阿列克谢·梅尔尼科夫、乔恩·彼得森、，佩卡·萨沃拉和彼得·圣安德烈。
Lawrence Conroy has provided extensive text for the Enumservice Classification section.
Lawrence Conroy为Enumservice Classification部分提供了大量文本。
Section 3 of [RFC3761], which was edited by Patrik Faltstrom and Michael Mealling, has been incorporated into this document. Please see the Acknowledgments section in RFC 3761 for additional acknowledgments.
由Patrik Faltstrom和Michael Mealling编辑的[RFC3761]第3节已纳入本文件。请参阅RFC 3761中的确认部分，了解更多确认。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[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月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, March 2011.
[RFC6116]Bradner，S.，Conroy，L.，和K.Fujiwara，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 6116，2011年3月。
[ITU.E164.2005] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, Feb 2005.
[ITU.E164.2005]国际电信联盟，“国际公共电信编号计划”，ITU-T建议E.164，2005年2月。
[Instructions2authors] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", RFC Editor http:// www.rfc-editor.org/rfc-editor/instructions2authors.txt, August 2004.
[Instructions2authors]Reynolds，J.和R.Braden，“征求意见（RFC）作者须知”，RFC编辑http://www.RFC-Editor.org/RFC-Editor/Instructions2authors.txt，2004年8月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223]Postel，J.和J.Reynolds，“RFC作者须知”，RFC 2223，1997年10月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 2780，2000年3月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC3764] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
[RFC3764]Peterson，J.，“会话启动协议（SIP）记录地址的枚举服务注册”，RFC 3764，2004年4月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[RFC4238] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, October 2005.
[RFC4238]Vaudreuil，G.“语音消息路由服务”，RFC 4238，2005年10月。
[RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip Indicator Parameter for the "tel" URI", RFC 4759, December 2006.
[RFC4759]Stastny，R.，Shockey，R.，和L.Conroy，“电话”URI的枚举倾角指示器参数”，RFC 4759，2006年12月。
[RFC4846] Klensin, J. and D. Thaler, "Independent Submissions to the RFC Editor", RFC 4846, July 2007.
[RFC4846]Klensin，J.和D.Thaler，“向RFC编辑提交的独立意见”，RFC 48462007年7月。
[RFC4969] Mayrhofer, A., "IANA Registration for vCard Enumservice", RFC 4969, August 2007.
[RFC4969]Mayrhofer，A.，“vCard Enumservice的IANA注册”，RFC 4969，2007年8月。
[RFC4979] Mayrhofer, A., "IANA Registration for Enumservice 'XMPP'", RFC 4979, August 2007.
[RFC4979]Mayrhofer，A.，“枚举服务'XMPP'的IANA注册”，RFC 4979，2007年8月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA Registrations of Enumservices", RFC 6118, March 2011.
[RFC6118]Hoenesen，B.和A.Mayrhofer，“Enumservices遗留IANA注册的更新”，RFC 6118，2011年3月。
This section contains non-normative examples of the XML-chunk-based IANA Registration Template:
本节包含基于XML块的IANA注册模板的非规范性示例：
This is the first example:
这是第一个例子：
<record>
<class>Protocol-Based</class>
<type>email</type>
<subtype>mailto</subtype>
<urischeme>mailto</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
can be addressed by the associated URI in
order to send an email.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4355"/>, Section 6.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4355"/>
</registrationdocs>
<requesters>
<xref type="person" data="Lawrence_Conroy"/>
</requesters>
</record>
<record>
<class>Protocol-Based</class>
<type>email</type>
<subtype>mailto</subtype>
<urischeme>mailto</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
can be addressed by the associated URI in
order to send an email.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4355"/>, Section 6.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4355"/>
</registrationdocs>
<requesters>
<xref type="person" data="Lawrence_Conroy"/>
</requesters>
</record>
<people>
<person id="Lawrence_Conroy">
<name>Lawrence Conroy</name>
<org>Siemens Roke Manor Research</org>
<uri>mailto:lwc@roke.co.uk</uri>
<updated>2008-11-20</updated>
</person>
</people>
<people>
<person id="Lawrence_Conroy">
<name>Lawrence Conroy</name>
<org>Siemens Roke Manor Research</org>
<uri>mailto:lwc@roke.co.uk</uri>
<updated>2008-11-20</updated>
</person>
</people>
This is the second example.
这是第二个例子。
<record>
<class>Protocol-Based</class>
<type>xmpp</type>
<urischeme>xmpp</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the
resource identified is an XMPP entity.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4979"/>, Section 6.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4979"/>
</registrationdocs>
<requesters>
<xref type="person" data="Alexander_Mayrhofer"/>
</requesters>
</record>
<record>
<class>Protocol-Based</class>
<type>xmpp</type>
<urischeme>xmpp</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the
resource identified is an XMPP entity.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4979"/>, Section 6.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4979"/>
</registrationdocs>
<requesters>
<xref type="person" data="Alexander_Mayrhofer"/>
</requesters>
</record>
<people>
<person id="Alexander_Mayrhofer">
<name>Alexander Mayrhofer</name>
<org>enum.at GmbH</org>
<uri>mailto:alexander.mayrhofer@enum.at</uri>
<updated>2008-10-10</updated>
</person>
</people>
<people>
<person id="Alexander_Mayrhofer">
<name>Alexander Mayrhofer</name>
<org>enum.at GmbH</org>
<uri>mailto:alexander.mayrhofer@enum.at</uri>
<updated>2008-10-10</updated>
</person>
</people>
This is the third example:
这是第三个例子：
<record>
<class>Application-Based</class>
<type>voicemsg</type>
<subtype>sip</subtype>
<urischeme>sip</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified can be addressed by the associated
URI scheme in order to initiate a voice
communication session to a voice messaging system.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4279"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4279"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Donald_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of
examples in <xref type="rfc" data="rfc4279"/>,
Section 7.
</paragraph>
</additionalinfo>
</record>
<record>
<class>Application-Based</class>
<type>voicemsg</type>
<subtype>sip</subtype>
<urischeme>sip</urischeme>
<functionalspec>
<paragraph>
This Enumservice indicates that the resource
identified can be addressed by the associated
URI scheme in order to initiate a voice
communication session to a voice messaging system.
</paragraph>
</functionalspec>
<security>
See <xref type="rfc" data="rfc4279"/>, Section 3.
</security>
<usage>COMMON</usage>
<registrationdocs>
<xref type="rfc" data="rfc4279"/>
</registrationdocs>
<requesters>
<xref type="person" data="Jason_Livingood"/>
<xref type="person" data="Donald_Troshynski"/>
</requesters>
<additionalinfo>
<paragraph>
Implementers should review a non-exclusive list of
examples in <xref type="rfc" data="rfc4279"/>,
Section 7.
</paragraph>
</additionalinfo>
</record>
<people>
<person id="Jason_Livingood">
<name>Jason Livingood</name>
<org>Comcast Cable Communications</org>
<uri>mailto:jason_livingood@cable.comcast.com</uri>
<updated>2008-11-20</updated>
</person>
<people>
<person id="Jason_Livingood">
<name>Jason Livingood</name>
<org>Comcast Cable Communications</org>
<uri>mailto:jason_livingood@cable.comcast.com</uri>
<updated>2008-11-20</updated>
</person>
<person id="Donald_Troshynski">
<name>Donald Troshynski</name>
<org>Acme Packet</org>
<uri>mailto:dtroshynski@acmepacket.com</uri>
<updated>2008-11-20</updated>
</person>
</people>
<person id="Donald_Troshynski">
<name>Donald Troshynski</name>
<org>Acme Packet</org>
<uri>mailto:dtroshynski@acmepacket.com</uri>
<updated>2008-11-20</updated>
</person>
</people>
In the third IANA Registration Template example above, the "voicemsg" Enumservice is used. This Enumservice actually has several Subtypes, and one of those is shown in the example. For each Subtype, an individual Registration Template must be submitted to IANA, so that an Enumservice with several Subtypes will have several corresponding IANA Registration Templates. This is to avoid any ambiguity of the relation between <subtype> and <urischeme> elements.
在上面的第三个IANA注册模板示例中，使用了“voicemsg”枚举服务。这个Enumservice实际上有几个子类型，示例中显示了其中一个。对于每个子类型，必须向IANA提交一个单独的注册模板，以便具有多个子类型的Enumservice将具有多个相应的IANA注册模板。这是为了避免<subtype>和<urischeme>元素之间的关系出现任何歧义。
This section lists the changes applied to the Enumservice registration process and the IANA registry definition, compared to RFC 3761.
与RFC 3761相比，本节列出了应用于Enumservice注册过程和IANA注册表定义的更改。
o While RFC 3761 required "Standards track or Experimental" RFCs for an Enumservice to be registered, this document mandates "Specification Required", which implies the use of a Designated Expert.
o 虽然RFC 3761要求注册Enumservice的“标准跟踪或实验”RFC，但本文件要求使用“所需规范”，这意味着需要指定专家。
o This document defines the classification of Enumservices. The IANA Registration Template has been complemented to contain a <class> element (Enumservice Class).
o 本文档定义了Enumservices的分类。IANA注册模板已得到补充，包含<class>元素（Enumservice类）。
o A new element <registrationdocs> (Enumservice Specification) has been added to the IANA Registration Template.
o IANA注册模板中添加了一个新元素<registrationdocs>（Enumservice规范）。
o The former field "Any other information that the author deems interesting" of the IANA Registration Template turned into the <additionalinfo> element (Further Information).
o IANA注册模板的前一个字段“作者认为有趣的任何其他信息”变成了<additionalinfo>元素（进一步信息）。
o The Enumservice "Name" field has been removed from the IANA Registration Template.
o Enumservice“名称”字段已从IANA注册模板中删除。
o The Registration Template is now a chunk of XML data, reflecting IANA's recent work to convert registries to XML.
o 注册模板现在是一块XML数据，反映了IANA最近将注册表转换为XML的工作。
Authors' Addresses
作者地址
Bernie Hoeneisen Ucom Standards Track Solutions GmbH CH-8000 Zuerich Switzerland
伯尼霍内森Ucom标准轨道解决方案有限公司CH-8000瑞士祖里希
Phone: +41 44 500 52 44
EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: http://www.ucom.ch/
Phone: +41 44 500 52 44
EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: http://www.ucom.ch/
Alexander Mayrhofer enum.at GmbH Karlsplatz 1/9 Wien A-1010 Austria
Alexander Mayrhofer enum.at GmbH卡尔斯普拉茨1/9维也纳A-1010奥地利
Phone: +43 1 5056416 34
EMail: alexander.mayrhofer@enum.at
URI: http://www.enum.at/
Phone: +43 1 5056416 34
EMail: alexander.mayrhofer@enum.at
URI: http://www.enum.at/
Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 USA
Jason Livingood Comcast有线通信一号Comcast中心美国宾夕法尼亚州费城肯尼迪大道1701号，邮编：19103
Phone: +1-215-286-7813
EMail: jason_livingood@cable.comcast.com
URI: http://www.comcast.com/
Phone: +1-215-286-7813
EMail: jason_livingood@cable.comcast.com
URI: http://www.comcast.com/