[要約] RFC 7451は、Extensible Provisioning Protocol（EPP）の拡張レジストリに関する規格です。その目的は、EPPの拡張機能の一貫性と互換性を確保し、拡張機能の登録と管理を効率化することです。
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.
Extensible Provisioning Protocol（EPP）には、プロトコルを拡張して機能を追加する機能が含まれています。ただし、これらの拡張機能の管理方法については説明していません。このドキュメントでは、EPPへの拡張の登録と管理の手順を説明し、IANAレジストリがそれらの拡張を記録するための形式を指定します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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].
ドメイン名レジストリは、さまざまな運用モデルとビジネスモデルを実装しています。これらのモデルの違いにより、「1つのサイズですべてに対応する」プロビジョニングプロトコルを開発することができません。 Extensible Provisioning Protocol [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]で説明されている "Specification Required"ポリシーを使用します。英語版以外の拡張仕様が提供される場合もありますが、拡張仕様の英語版がレジストリから参照されます。 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 mailing list. If the specification for an extension is an IETF Standards Track document, no review is required by the designated expert.
評価の結果は、登録者およびeppextメーリングリストと電子メールで共有する必要があります。評価中に発見された問題は登録者が修正でき、指定された専門家が登録要求を明示的に受け入れるか拒否するかを決定するまで、それらの修正を指定された専門家に送信できます。指定された専門家は明示的な決定を行う必要があり、その決定は登録者およびeppextメーリングリストと電子メールで共有する必要があります。拡張の仕様がIETF Standards Trackドキュメントの場合、指定された専門家によるレビューは必要ありません。
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.
指定された専門家は、少なくとも1つのレジストリ/レジストラペアによって実装および展開された拡張機能を登録する要求の評価を許容する必要があります。これは、同じ機能を提供する複数の拡張機能を実際に登録できる可能性があることを意味します。デプロイされていない拡張機能を登録するリクエストは、機能の重複を減らすことを目的として評価する必要があります。登録済みの既存の拡張機能と同様の機能を含む、デプロイされていない新しい拡張機能を登録するリクエストを送信する潜在的な登録者は、既存の拡張機能を知っておく必要があります。登録者は、同様の拡張が存在することを前提として、要求を再検討するよう求められる必要があります。彼らがそうすることを拒否した場合、他のすべての要件が満たされている限り、類似性の認識は拒否の十分な理由にはなりません。
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.
TLD：拡張子が指定されている先行する「。」を含むトップレベルドメイン名（または複数のドメイン名）を含むテキスト文字列（例：「.org」）。複数のTLDがある場合、それらはカンマで区切られたドメイン名のリストとして提供されます（例：「.com」、「。net」）。国際化ドメイン名（IDN）TLDは、Aラベル[RFC5890]形式で指定する必要があります。拡張機能が特定のトップレベルドメインに関連付けられていない場合は、大文字と小文字を区別しないテキスト文字列「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開示：この拡張機能に関連する知的財産権（IPR）開示ドキュメントへのポインタ、またはそのような開示がない場合は「なし」を使用できます。これは、拡張子がIETFコントリビューションの一部である場合、RFC 4879 [RFC4879]によって更新され、RFC 3979 [RFC3979]に従ってIETFに提出されたIPR開示であるか、または主張された知的財産権を識別する他のIPR開示文書である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)
Document Status: <document status>
Reference: <RFC number, URL, etc.>
Registrant Name and Email Address:
<registrant name>, <email address>
TLDs: "Any"|<one or more TLD text strings separated by commas>
IPR Disclosure: "None"|<URL>
Status: "Active"|"Inactive"
ステータス：「アクティブ」|「非アクティブ」
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)"
Document Status: Standards Track
ドキュメントのステータス：標準化過程
Reference: RFC XXXX
リファレンス：RFC XXXX
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
TLD：任意
IPR Disclosure: None
IPR開示：なし
Status: Active
ステータス：アクティブ
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"
Document Status: Informational
ドキュメントのステータス：情報
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：.example
IPR Disclosure:
http://www.example.com/ipr/example-epp-ext-ipr.html
Status: Active
ステータス：アクティブ
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.
登録者は、各登録フォームを1つのレコードとともにIANAに送信して、レジストリに組み込む必要があります。フォームを電子メールで<iana@iana.org>に送信するか、IANA Webサイトにあるオンラインフォームに記入します。件名は、囲まれたフォームが新しいレコードの挿入（件名の「INSERT」という単語で示される）または既存のレコードの置換（件名の「MODIFY」という単語で示される）を表すかどうかを示す必要があります。レジストリからレコードを削除することはできません。登録リクエストを受け取ると、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.
既存のレジストリエントリに変更を送信する場合は、登録フォームの[Notes]フィールドに変更を説明するテキストを含めてください。通常の状況では、レジストリエントリは登録者によってのみ更新されます。登録者が利用できなくなったり応答しなくなったりした場合、指定された専門家は登録フォームを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拡張を管理するための「Extensions for the Extensible Provisioning Protocol（EPP）」レジストリを作成しました。このレジストリには、IANAのプロトコルリストに関する独自の見出しがあります。登録する情報、およびレジストリに入力する際に従う手順については、セクション2で説明します。
Name of registry: Extensions for the Extensible Provisioning Protocol (EPP)
レジストリの名前：Extensible Provisioning Protocol（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
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)"
Document Status: Standards Track
ドキュメントのステータス：標準化過程
Reference: RFC 3915
リファレンス：RFC 3915
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
TLD：任意
IPR Disclosure: None
IPR開示：なし
Status: Active
ステータス：アクティブ
Notes: None
-----END FORM-----
-----BEGIN FORM-----
Name of Extension:
"E.164 Number Mapping for the
Extensible Provisioning Protocol (EPP)"
Document Status: Standards Track
ドキュメントのステータス：標準化過程
Reference: RFC 4114
リファレンス：RFC 4114
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
TLDs: Any
TLD：任意
IPR Disclosure: None
IPR開示：なし
Status: Active
ステータス：アクティブ
Notes: None
-----END FORM-----
-----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>
TLDs: Any
TLD：任意
IPR Disclosure: None
IPR開示：なし
Status: Active
ステータス：アクティブ
Notes: None
-----END FORM-----
-----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>
TLDs: Any
TLD：任意
IPR Disclosure: None
IPR開示：なし
Status: Active
ステータス：アクティブ
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。、「Clarification of the Third Party Disclosure Procedure in 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、「RFCで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。、「Extensible Provisioning Protocol（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。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年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。、「Extensible Provisioning Protocol（EPP）を拡張するためのガイドライン」、RFC 3735、2004年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.
レジストリに記載されている情報は、2013年8月にJay Daleyがprovregメーリングリストに投稿した提案に基づいています。
Author's Address
著者のアドレス
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 US
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston、VA 20190 US
EMail: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/