Internet Engineering Task Force (IETF) S. Hollenbeck
Request for Comments: 7451 Verisign Labs
Category: Informational February 2015
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Hollenbeck
Request for Comments: 7451 Verisign Labs
Category: Informational February 2015
ISSN: 2070-1721
Extension Registry for the Extensible Provisioning Protocol
可扩展配置协议的扩展注册表
Abstract
摘要
The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions.
可扩展资源调配协议（EPP）包括通过扩展协议来添加功能的功能。然而，它并没有描述如何管理这些扩展。本文档描述了EPP扩展的注册和管理过程，并指定了IANA注册表记录这些扩展的格式。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7451.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7451.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Extension Specification and Registration Procedure . . . . . 3
2.1. Extension Specification . . . . . . . . . . . . . . . . . 3
2.1.1. Designated Expert Evaluation Criteria . . . . . . . . 3
2.2. Registration Procedure . . . . . . . . . . . . . . . . . 4
2.2.1. Required Information . . . . . . . . . . . . . . . . 4
2.2.2. Registration Form . . . . . . . . . . . . . . . . . . 6
2.2.3. Registration Processing . . . . . . . . . . . . . . . 8
2.2.4. Updating Registry Entries . . . . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Normative References . . . . . . . . . . . . . . . . . . 11
5.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Extension Specification and Registration Procedure . . . . . 3
2.1. Extension Specification . . . . . . . . . . . . . . . . . 3
2.1.1. Designated Expert Evaluation Criteria . . . . . . . . 3
2.2. Registration Procedure . . . . . . . . . . . . . . . . . 4
2.2.1. Required Information . . . . . . . . . . . . . . . . 4
2.2.2. Registration Form . . . . . . . . . . . . . . . . . . 6
2.2.3. Registration Processing . . . . . . . . . . . . . . . 8
2.2.4. Updating Registry Entries . . . . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Normative References . . . . . . . . . . . . . . . . . . 11
5.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
Domain name registries implement a variety of operational and business models. The differences in these models make it impossible to develop a "one size fits all" provisioning protocol; the Extensible Provisioning Protocol [RFC5730] was designed to focus on a minimal set of common functionality with built-in extension capabilities that allow new features to be specified on an "as needed" basis. Guidelines for extending EPP are documented in RFC 3735 [RFC3735].
域名注册中心实施各种运营和业务模式。这些模型的差异使得开发“一刀切”的供应协议成为不可能；可扩展资源调配协议[RFC5730]旨在将重点放在具有内置扩展功能的最小通用功能集上，以允许在“需要时”指定新功能。扩展EPP的指南记录在RFC 3735[RFC3735]中。
RFCs 3735 and 5730 do not describe how extension development can be managed and coordinated. This has led to a situation in which server operators can develop different extensions to address similar needs, such as the provisioning of Value Added Tax (VAT) information. Clients then need to support multiple extensions that serve similar purposes, and interoperability suffers as a result.
RFC 3735和5730没有描述如何管理和协调扩展开发。这导致服务器运营商可以开发不同的扩展来满足类似的需求，例如提供增值税（VAT）信息。然后，客户机需要支持多个用于类似目的的扩展，因此互操作性受到影响。
An IANA registry can be used to help manage and coordinate the development of protocol extensions. This document describes an IANA registry that will be used to coordinate the development of EPP extensions.
IANA注册表可用于帮助管理和协调协议扩展的开发。本文档描述了将用于协调EPP扩展开发的IANA注册表。
This section describes the format of an IANA registry and the procedures used to populate and manage registry entries.
本节介绍IANA注册表的格式以及用于填充和管理注册表项的过程。
This registry uses the "Specification Required" policy described in RFC 5226 [RFC5226]. An English language version of the extension specification will be referenced from the registry, though non-English versions of the specification may also be provided. Note that Section 2.1 of RFC 3735 [RFC3735] provides specific guidelines for documenting EPP extensions.
此注册表使用RFC 5226[RFC5226]中描述的“所需规范”策略。将从注册表中引用扩展规范的英语版本，但也可能提供规范的非英语版本。请注意，RFC 3735[RFC3735]第2.1节提供了记录EPP扩展的具体指南。
Note that the "Specification Required" policy implies review by a "designated expert". Section 3 of RFC 5226 [RFC5226] describes the role of designated experts and the function they perform.
请注意，“所需规范”政策意味着由“指定专家”进行审查。RFC 5226[RFC5226]第3节描述了指定专家的角色及其履行的职能。
A high-level description of the role of the designated expert is described in Section 3.2 of RFC 5226 [RFC5226]. Specific guidelines for the appointment of designated experts and the evaluation of EPP extensions are provided here.
RFC 5226[RFC5226]第3.2节对指定专家的角色进行了详细说明。此处提供了指定专家任命和EPP扩展评估的具体指南。
The IESG should appoint a small pool of individuals (perhaps 3 - 5) to serve as designated experts, as described in Section 3.2 of RFC 5226 [RFC5226]. The pool should have a single administrative chair who is appointed by the IESG. The designated experts should use the existing eppext mailing list (eppext@ietf.org) for public discussion of registration requests. This implies that the mailing list should remain open after the work of the EPPEXT working group has concluded.
如RFC 5226[RFC5226]第3.2节所述，IESG应任命一小部分个人（可能3-5人）担任指定专家。游泳池应有一名由IESG任命的行政主席。指定专家应使用现有的eppext邮件列表(eppext@ietf.org)供公众讨论注册申请。这意味着，在EPPEXT工作组的工作结束后，邮件列表应保持开放。
Extensions should be evaluated for architectural soundness using the guidelines described in RFC 3735 [RFC3735], including the Security Considerations section of that document. Expert evaluation should explicitly include consideration of the privacy consequences of proposed extensions, and, at a minimum, ensure that any privacy considerations are fully documented in the relevant specification(s).
应使用RFC 3735[RFC3735]中所述的指南（包括该文件的安全注意事项部分）评估扩展的架构可靠性。专家评估应明确包括对拟议扩展的隐私后果的考虑，并至少确保在相关规范中充分记录任何隐私考虑。
The results of the evaluation should be shared via email with the registrant and the eppext mailing list. Issues discovered during the evaluation can be corrected by the registrant, and those corrections can be submitted to the designated experts until the designated experts explicitly decide to accept or reject the registration request. The designated experts must make an explicit decision and that decision must be shared via email with the registrant and the
评估结果应通过电子邮件与注册人和eppext邮件列表共享。在评估期间发现的问题可由注册人更正，这些更正可提交给指定专家，直到指定专家明确决定接受或拒绝注册请求。指定专家必须做出明确的决定，并且该决定必须通过电子邮件与注册人和
eppext mailing list. If the specification for an extension is an IETF Standards Track document, no review is required by the designated expert.
eppext邮件列表。如果扩展规范是IETF标准跟踪文件，则指定专家无需审查。
Designated experts should be permissive in their evaluation of requests to register extensions that have been implemented and deployed by at least one registry/registrar pair. This implies that it may indeed be possible to register multiple extensions that provide the same functionality. Requests to register extensions that have not been deployed should be evaluated with a goal of reducing functional duplication. A potential registrant who submits a request to register a new, un-deployed extension that includes similar functionality to an existing, registered extension should be made aware of the existing extension. The registrant should be asked to reconsider their request given the existence of a similar extension. Should they decline to do so, perceived similarity should not be a sufficient reason for rejection as long as all other requirements are met.
指定专家在评估至少由一对登记册/登记员实施和部署的登记扩展请求时应持宽容态度。这意味着可能确实可以注册提供相同功能的多个扩展。注册尚未部署的扩展的请求应以减少功能重复为目标进行评估。如果潜在注册人提交了注册新的未部署扩展的请求，该扩展包含与现有已注册扩展类似的功能，则应告知现有扩展。鉴于存在类似的延期，应要求注册人重新考虑其请求。如果他们拒绝这样做，只要满足所有其他要求，感知相似性不应成为拒绝的充分理由。
The registry contains information describing each registered extension. Registry entries are created and managed by sending forms to IANA that describe the extension and the operation to be performed on the registry entry.
注册表包含描述每个已注册扩展名的信息。通过向IANA发送表单来创建和管理注册表项，这些表单描述了扩展和对注册表项执行的操作。
Name of Extension: A case-insensitive, ASCII text string that contains the name of the extension specification. Non-ASCII representations of the extension name can be included in the "Notes" described below.
扩展名：不区分大小写的ASCII文本字符串，包含扩展规范的名称。扩展名的非ASCII表示可以包含在下面描述的“注释”中。
Document Status: The document status ("Informational", "Standards Track", etc.) of the specification document. For documents that are not RFCs, this will always be "Informational".
文档状态：规范文档的文档状态（“信息性”、“标准跟踪”等）。对于非RFC的文档，这将始终是“信息性的”。
Reference: A publicly available reference to the specification of this extension. This could be an RFC number or some other pointer to the document defining the extension.
参考：此扩展规范的公开参考。这可能是一个RFC编号或指向定义扩展名的文档的其他指针。
Registrant Name and Email Address: The name and email address of the person that is responsible for managing the registry entry. If the registration is of an IETF Standards Track document, this can simply be listed as "IESG, <iesg@ietf.org>".
注册人姓名和电子邮件地址：负责管理注册条目的人员的姓名和电子邮件地址。如果注册是IETF标准跟踪文件，则可以简单地将其列为“IESG<iesg@ietf.org>".
TLDs: A text string containing the top-level domain name (or domain names), including the preceding ".", for which the extension has been specified (e.g., ".org"). If there are multiple TLDs, they are given as a list of domain names separated by commas, (e.g. ".com", ".net"). Internationalized Domain Name (IDN) TLDs should be specified in A-label [RFC5890] format. If the extension is not associated with a specific top-level domain, the case-insensitive text string "Any" can be used to indicate that.
TLDs：包含顶级域名（或多个域名）的文本字符串，包括前面的“.”，已为其指定扩展名（例如“.org”）。如果有多个TLD，则它们将以逗号分隔的域名列表形式给出（例如“.com”、“.net”）。应以A标签[RFC5890]格式指定国际化域名（IDN）TLD。如果扩展未与特定的顶级域关联，则可以使用不区分大小写的文本字符串“Any”来表示该扩展。
IPR Disclosure: A pointer to any Intellectual Property Rights (IPR) disclosure document(s) related to this extension, or "None" may be used if there are no such disclosures. This can be an IPR disclosure filed with the IETF in accordance with RFC 3979 [RFC3979] as updated by RFC 4879 [RFC4879] if the extension is part of an IETF Contribution, or it can be other IPR disclosure documents identifying the claimed intellectual property rights and terms of use for extensions that are not part of an IETF Contribution.
知识产权披露：指向与本扩展相关的任何知识产权（IPR）披露文件的指针，如果没有此类披露，则可以使用“无”。如果扩展是IETF贡献的一部分，则可以是根据RFC 4879[RFC4879]更新的RFC 3979[RFC3979]向IETF提交的知识产权披露文件，也可以是识别不属于IETF贡献的声称知识产权和扩展使用条款的其他知识产权披露文件。
Status: Either "Active" or "Inactive". The "Active" status is used for extensions that are currently implemented and in use. The "Inactive" status is used for extensions that are not implemented or are otherwise not being used.
状态：“活动”或“非活动”。“活动”状态用于当前已实现和正在使用的扩展。“非活动”状态用于未实现或未使用的扩展。
Notes: Either "None" or other text that describes optional notes to be included with the registered extension. If the Status value is "Inactive", text should be included to describe how and when this state was reached.
备注：“无”或其他描述注册扩展中包含的可选备注的文本。如果状态值为“非活动”，则应包含文本，说明如何以及何时达到该状态。
The required information must be formatted consistently using the following registration form. Form field names and values may appear on the same line.
所需信息的格式必须一致，使用以下注册表。表单字段名称和值可能出现在同一行上。
-----BEGIN FORM-----
Name of Extension:
<text string> (quotes are optional)
-----BEGIN FORM-----
Name of Extension:
<text string> (quotes are optional)
Document Status: <document status>
Document Status: <document status>
Reference: <RFC number, URL, etc.>
Reference: <RFC number, URL, etc.>
Registrant Name and Email Address:
<registrant name>, <email address>
Registrant Name and Email Address:
<registrant name>, <email address>
TLDs: "Any"|<one or more TLD text strings separated by commas>
TLDs: "Any"|<one or more TLD text strings separated by commas>
IPR Disclosure: "None"|<URL>
IPR Disclosure: "None"|<URL>
Status: "Active"|"Inactive"
状态：“活动”|“不活动”
Notes: "None"|<optional text>
-----END FORM-----
Notes: "None"|<optional text>
-----END FORM-----
Example form with RFC specification:
带有RFC规范的示例表格：
-----BEGIN FORM-----
Name of Extension:
"An Extension RFC for the Extensible Provisioning Protocol (EPP)"
-----BEGIN FORM-----
Name of Extension:
"An Extension RFC for the Extensible Provisioning Protocol (EPP)"
Document Status: Standards Track
文档状态：标准跟踪
Reference: RFC XXXX
参考：RFC XXXX
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
TLDs：有吗
IPR Disclosure: None
知识产权披露：无
Status: Active
状态：活动
Notes: None
-----END FORM-----
Notes: None
-----END FORM-----
Example form with non-RFC specification:
非RFC规范的示例表格：
-----BEGIN FORM-----
Name of Extension:
"An Example Extension for the .example Top-Level Domain"
-----BEGIN FORM-----
Name of Extension:
"An Example Extension for the .example Top-Level Domain"
Document Status: Informational
文件状态：信息性
Reference:
http://www.example.com/html/example-epp-ext.txt
Reference:
http://www.example.com/html/example-epp-ext.txt
Registrant Name and Email Address: John Doe, jdoe@example.com
注册人姓名和电子邮件地址：John Doe，jdoe@example.com
TLDs: .example
TLD:。示例
IPR Disclosure:
http://www.example.com/ipr/example-epp-ext-ipr.html
IPR Disclosure:
http://www.example.com/ipr/example-epp-ext-ipr.html
Status: Active
状态：活动
Notes: None
-----END FORM-----
Notes: None
-----END FORM-----
Registrants should send each registration form to IANA with a single record for incorporation into the registry. Send the form via email to <iana@iana.org> or complete the online form found on the IANA web site. The subject line should indicate whether the enclosed form represents an insertion of a new record (indicated by the word "INSERT" in the subject line) or a replacement of an existing record (indicated by the word "MODIFY" in the subject line). At no time can a record be deleted from the registry. On receipt of the registration request, IANA will initiate review by the designated expert(s), who will evaluate the request using the criteria in Section 2.1.1 in consultation with the eppext mailing list.
登记人应将每份登记表连同一份记录一起发送给IANA，以便纳入登记册。通过电子邮件将表格发送至<iana@iana.org>或者填写IANA网站上的在线表格。主题行应指明所附表格是插入新记录（在主题行中用“插入”一词表示）还是替换现有记录（在主题行中用“修改”一词表示）。任何时候都不能从注册表中删除记录。收到注册请求后，IANA将启动指定专家的审查，该专家将使用第2.1.1节中的标准，并与eppext邮件列表协商，对请求进行评估。
When submitting changes to existing registry entries, include text in the "Notes" field of the registration form describing the change. Under normal circumstances, registry entries are only to be updated by the registrant. If the registrant becomes unavailable or otherwise unresponsive, the designated expert can submit a registration form to IANA to update the registrant information. Entries can change state from "Active" to "Inactive" and back again as long as state-change requests conform to the processing requirements identified in this document. In addition to entries that become "Inactive" due to a lack of implementation, entries for which a specification becomes consistently unavailable over time should be marked "Inactive" by the designated expert until the specification again becomes reliably available.
提交对现有注册表项的更改时，请在注册表的“备注”字段中包含描述更改的文本。在正常情况下，注册人只需更新注册条目。如果注册人不可用或无响应，指定专家可向IANA提交注册表格，以更新注册人信息。只要状态更改请求符合本文档中确定的处理要求，条目可以将状态从“活动”更改为“非活动”，然后再次更改。除了由于缺乏实施而变得“不活跃”的条目外，指定专家还应将规范随着时间的推移变得始终不可用的条目标记为“不活跃”，直到规范再次可靠可用。
IANA has created the "Extensions for the Extensible Provisioning Protocol (EPP)" registry to manage EPP extensions. This registry has its own heading on IANA's protocol listings. The information to be registered and the procedures to be followed in populating the registry are described in Section 2.
IANA已经创建了“可扩展资源调配协议（EPP）扩展”注册表来管理EPP扩展。该注册表在IANA的协议列表上有自己的标题。第2节介绍了注册信息和注册过程。
Name of registry: Extensions for the Extensible Provisioning Protocol (EPP)
注册表名称：可扩展资源调配协议（EPP）的扩展
Section at http://www.iana.org/protocols:
Registry Title: Extensions for the Extensible Provisioning
Protocol (EPP)
Registry Name: Extensions for the Extensible Provisioning
Protocol (EPP)
Registration Procedure: Specification Required
Reference: this document
Section at http://www.iana.org/protocols:
Registry Title: Extensions for the Extensible Provisioning
Protocol (EPP)
Registry Name: Extensions for the Extensible Provisioning
Protocol (EPP)
Registration Procedure: Specification Required
Reference: this document
Required information: See Section 2.2.1.
所需信息：见第2.2.1节。
Review process: "Specification Required" as described in RFC 5226 [RFC5226].
审查流程：RFC 5226[RFC5226]中所述的“所需规范”。
Size, format, and syntax of registry entries: See Section 2.2.1.
注册表项的大小、格式和语法：见第2.2.1节。
Initial assignments and reservations:
初始分配和保留：
-----BEGIN FORM-----
Name of Extension:
"Domain Registry Grace Period Mapping for the
Extensible Provisioning Protocol (EPP)"
-----BEGIN FORM-----
Name of Extension:
"Domain Registry Grace Period Mapping for the
Extensible Provisioning Protocol (EPP)"
Document Status: Standards Track
文档状态：标准跟踪
Reference: RFC 3915
参考：RFC 3915
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
TLDs：有吗
IPR Disclosure: None
知识产权披露：无
Status: Active
状态：活动
Notes: None
-----END FORM-----
Notes: None
-----END FORM-----
-----BEGIN FORM-----
Name of Extension:
"E.164 Number Mapping for the
Extensible Provisioning Protocol (EPP)"
-----BEGIN FORM-----
Name of Extension:
"E.164 Number Mapping for the
Extensible Provisioning Protocol (EPP)"
Document Status: Standards Track
文档状态：标准跟踪
Reference: RFC 4114
参考：RFC4114
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
TLDs：有吗
IPR Disclosure: None
知识产权披露：无
Status: Active
状态：活动
Notes: None
-----END FORM-----
Notes: None
-----END FORM-----
-----BEGIN FORM-----
Name of Extension:
"ENUM Validation Information Mapping for the
Extensible Provisioning Protocol"
-----BEGIN FORM-----
Name of Extension:
"ENUM Validation Information Mapping for the
Extensible Provisioning Protocol"
Document Status: Standards Track
文档状态：标准跟踪
Reference: RFC 5076
参考：RFC 5076
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
TLDs：有吗
IPR Disclosure: None
知识产权披露：无
Status: Active
状态：活动
Notes: None
-----END FORM-----
Notes: None
-----END FORM-----
-----BEGIN FORM-----
Name of Extension:
"Domain Name System (DNS) Security Extensions Mapping for the
Extensible Provisioning Protocol (EPP)"
-----BEGIN FORM-----
Name of Extension:
"Domain Name System (DNS) Security Extensions Mapping for the
Extensible Provisioning Protocol (EPP)"
Document Status: Standards Track
文档状态：标准跟踪
Reference: RFC 5910
参考：RFC 5910
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
TLDs：有吗
IPR Disclosure: None
知识产权披露：无
Status: Active
状态：活动
Notes: None
-----END FORM-----
Notes: None
-----END FORM-----
In addition, the form used to populate and manage the registry will be added to the table of Protocol Registration Forms maintained by IANA.
此外，用于填充和管理注册表的表格将添加到IANA维护的协议注册表格表中。
This document introduces no new security considerations to EPP. However, extensions should be evaluated according to the Security Considerations of RFC 3735 [RFC3735].
本文档未向EPP引入新的安全注意事项。但是，应根据RFC 3735[RFC3735]的安全考虑因素对扩展进行评估。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005, <http://www.rfc-editor.org/info/rfc3979>.
[RFC3979]Bradner，S.，“IETF技术中的知识产权”，BCP 79，RFC 3979，2005年3月<http://www.rfc-editor.org/info/rfc3979>.
[RFC4879] Narten, T., "Clarification of the Third Party Disclosure Procedure in RFC 3979", BCP 79, RFC 4879, April 2007, <http://www.rfc-editor.org/info/rfc4879>.
[RFC4879]Narten，T.，“RFC 3979中第三方披露程序的澄清”，BCP 79，RFC 4879，2007年4月<http://www.rfc-editor.org/info/rfc4879>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009, <http://www.rfc-editor.org/info/rfc5730>.
[RFC5730]Hollenbeck，S.，“可扩展资源调配协议（EPP）”，STD 69，RFC 5730，2009年8月<http://www.rfc-editor.org/info/rfc5730>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月<http://www.rfc-editor.org/info/rfc5890>.
[RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, March 2004, <http://www.rfc-editor.org/info/rfc3735>.
[RFC3735]Hollenbeck，S.，“扩展可扩展资源调配协议（EPP）的指南”，RFC 37352004年3月<http://www.rfc-editor.org/info/rfc3735>.
Acknowledgements
致谢
The information described in the registry is based on a suggestion posted to the provreg mailing list by Jay Daley in August 2013.
注册表中描述的信息基于Jay Daley于2013年8月发布到provreg邮件列表的建议。
Author's Address
作者地址
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 US
斯科特·霍伦贝克Verisign实验室12061美国弗吉尼亚州布鲁蒙特路莱斯顿20190
EMail: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/
EMail: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/