RFC 9038 - Extensible Provisioning Protocol (EPP) Unhandled Namespaces 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9038.html
タイトル : RFC 9038 - 拡張可能プロビジョニングプロトコル（EPP）未処理の名前空間
翻訳編集 : 自動生成

[要約] RFC 9038は、Extensible Provisioning Protocol (EPP) で扱われない名前空間の取り扱いに関する規定を提供します。この文書の目的は、EPPの拡張性を高め、異なる名前空間を効率的に処理する方法を定義することです。主に、ドメイン名やその他のインターネットリソースの登録・管理システムで利用されます。

Internet Engineering Task Force (IETF)                          J. Gould
Request for Comments: 9038                                VeriSign, Inc.
Category: Standards Track                                    M. Casanova
ISSN: 2070-1721                                                   SWITCH
                                                                May 2021

Extensible Provisioning Protocol (EPP) Unhandled Namespaces

拡張可能プロビジョニングプロトコル（EPP）未処理の名前空間

Abstract

概要

The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs, and an "unhandled namespace" is one that is associated with a service not supported by the client. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs and that maintains compliance with the negotiated services defined in RFC 5730.

RFC 5730で定義されているような拡張プロビジョニングプロトコル（EPP）は、セッション中に管理されるオブジェクトおよびセッション中に使用されるオブジェクト拡張子を決定するためのメソッドを含む。サービスはネームスペースURIを使用して識別され、「未処理の名前空間」はクライアントによってサポートされていないサービスに関連付けられているものです。このドキュメントでは、サーバーが未処理の名前空間URIに関連した情報を返すことができ、RFC 5730で定義されているネゴシエートされたサービスへの準拠を維持するための操作方法を定義します。

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 7841.

この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9038.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9038で入手できます。

著作権表示

著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
     1.1.  Conventions Used in This Document
   2.  Unhandled Namespaces
   3.  Use of EPP <extValue> for Unhandled Namespace Data
     3.1.  Unhandled Object-Level Extension
     3.2.  Unhandled Command-Response Extension
   4.  Signaling Client and Server Support
   5.  Usage with General EPP Responses
   6.  Usage with Poll-Message EPP Responses
   7.  Implementation Considerations
     7.1.  Client Implementation Considerations
     7.2.  Server Implementation Considerations
   8.  IANA Considerations
     8.1.  XML Namespace
     8.2.  EPP Extension Registry
   9.  Security Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

The Extensible Provisioning Protocol (EPP), as defined in [RFC5730], includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs. How should the server handle service data that needs to be returned in the response when the client does not support the required service namespace URI, which is referred to as an "unhandled namespace"? An unhandled namespace is a significant issue for the processing of the poll messages described in [RFC5730], since poll messages are inserted by the server prior to knowing the supported client services, and the client needs to be capable of processing all poll messages. Returning an unhandled namespace poll message is not compliant with the negotiated services defined in [RFC5730], and returning an error makes the unhandled namespace poll message a poison message by halting the processing of the poll queue. An unhandled namespace is also an issue for general EPP responses when the server has information that it cannot return to the client due to the client's supported services. The server should be able to return unhandled namespace information that the client can process later. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs and that maintains compliance with the negotiated services defined in [RFC5730].

[RFC5730]で定義されているように、拡張可能プロビジョニングプロトコル（EPP）は、セッション中に管理されるオブジェクトとセッション中に使用されるオブジェクト拡張子を決定するためのクライアントとサーバーのためのメソッドを含む。サービスはネームスペースURIを使用して識別されます。クライアントが必要なサービスネームスペースURIをサポートしていない場合は、サーバーが応答内で返される必要があるサービスデータをどのように処理してください。これは、「未処理の名前空間」と呼ばれますか？未処理のネームスペースは、サポートされているクライアントサービスを知る前にサーバーによって挿入され、クライアントがすべてのポーリングメッセージを処理できる必要があるため、[RFC5730]で説明されているポーリングメッセージの処理にとって重要な問題です。未処理のネームスペースポーリングメッセージを返すことは[RFC5730]で定義されたネゴシエートされたサービスに準拠しておらず、エラーを返すと、未処理のネームスペースポーリングにポーリングキューの処理を停止してPoiseメッセージが有効になります。未処理のネームスペースは、サーバーがクライアントのサポートされているサービスのためにクライアントに戻ることができないという情報を持っている場合の一般的なEPP応答にも問題です。サーバーは、クライアントが後で処理できることができる未処理の名前空間情報を返すことができなければなりません。このドキュメントでは、サーバーが未処理の名前空間URIに関連した情報を返すことができ、[RFC5730]で定義されたネゴシエートされたサービスに準拠している情報を維持するための操作方法を定義します。

1.1. Conventions Used in This Document

1.1. この文書で使用されている規約

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

XML [W3C.REC-xml11-20060816] is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.

XML [W3C.REC-XML11-20060816]は大文字と小文字を区別します。特に記載されていない限り、この文書に記載されているXML仕様および例は、適合的な実施を開発するために提示された文字の場合で解釈されなければならない。

In examples, "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not required features of this protocol.

例では、 "s："はプロトコルサーバーによって返された行を表します。例のインデントと空きスペースは、要素の関係を説明するためだけに提供されており、このプロトコルの必須の機能ではありません。

The examples reference XML namespace prefixes that are used for the associated XML namespaces. Implementations MUST NOT depend on the example XML namespaces and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. The example namespace prefixes used and their associated XML namespaces include:

XMLネームスペースに使用されるXMLネームスペースプレフィックスを参照してください。実装は例のXMLネームスペースに依存してはならず、代わりにXML文書を解釈して出力するために適切なネームスペース対応のXMLパーサーとシリアライザを使用してください。使用される名前空間プレフィックスの例とそれに関連付けられているXMLネームスペースは次のとおりです。

   changePoll:  urn:ietf:params:xml:ns:changePoll-1.0

   domain:  urn:ietf:params:xml:ns:domain-1.0

   secDNS:  urn:ietf:params:xml:ns:secDNS-1.1

In the template example XML, placeholder content is represented by the following variables:

テンプレートの例XMLでは、プレースホルダのコンテンツは次の変数で表されます。

[NAMESPACE-XML]: XML content associated with a login service namespace URI. An example is the <domain:infData> element content in [RFC5731].

[Namespace-XML]：ログインサービスの名前空間URIに関連付けられているXMLコンテンツ。例は[RFC5731]の<domain：infdata>要素内容です。

[NAMESPACE-URI]: XML namespace URI associated with the [NAMESPACE-XML] XML content. An example is "urn:ietf:params:xml:ns:domain-1.0" in [RFC5731].

[namespace-uri]：[Namespace-XML] XMLコンテンツに関連付けられているXML名前空間URI。例は「rfc5731」の "urn：ietf：params：xml：ns：domain-1.0"です。

2. Unhandled Namespaces

2. 未処理の名前空間

An unhandled namespace is an XML namespace that is associated with a response extension that is not included in the client-specified EPP login services of [RFC5730]. The EPP login services consist of the set of XML namespace URIs included in the <objURI> or <extURI> elements of the EPP <login> command [RFC5730]. The services supported by the server are included in the <objURI> and <extURI> elements of the EPP <greeting> [RFC5730], which should be a superset of the login services included in the EPP <login> command. A server may have information associated with a specific namespace that it needs to return in the response to a client. The unhandled namespaces problem exists when the server has information that it needs to return to the client, but the namespace of the information is not supported by the client based on the negotiated EPP <login> command services.

未処理の名前空間は、[RFC5730]のクライアント指定されたEPPログインサービスに含まれていない応答拡張に関連付けられているXMLネームスペースです。EPPログインサービスは、epp <login>コマンド[RFC5730]の<objuri>または<exturi>要素に含まれているXMLネームスペースURIのセットで構成されています。サーバーでサポートされているサービスは、EPP <Greeting> [RFC5730]の<objuri>と<exturi>要素に含まれています。これは、epp <login>コマンドに含まれるログインサービスのスーパーセットになる必要があります。サーバーは、クライアントへの応答を返す必要がある特定のネームスペースに関連付けられている情報を持つことができます。サーバーにクライアントに戻る必要があることが必要な場合は、未処理の名前空間の問題が存在しますが、情報のネームスペースはネゴシエートされたEPP <login>コマンドサービスに基づいてクライアントによってサポートされていません。

3. Use of EPP <extValue> for Unhandled Namespace Data

3. 未処理のネームスペースデータのためのEPP <extValue>の使用

In [RFC5730], the <extValue> element is used to provide additional error diagnostic information, including the <value> element that identifies the client-provided element that caused a server error condition and the <reason> element containing the human-readable message that describes the reason for the error. This operational practice extends the use of the <extValue> element for the purpose of returning unhandled namespace information in a successful response.

[RFC5730]では、<extValue>要素は、サーバーエラー状態と、<reason>要素を識別する<value>要素を含む追加のエラー診断情報を提供して、人間が読めるメッセージを含む<value>要素を提供します。それはエラーの理由を説明しています。この運用慣行は、成功した応答で未処理の名前空間情報を返すことを目的として、<extValue>要素の使用を拡張します。

When a server has data to return to the client that the client does not support based on the login services, the server MAY return a successful response with the data for each unsupported namespace moved into an <extValue> element [RFC5730]. The unhandled namespace will not cause an error response, but the unhandled namespace data will instead be moved to an <extValue> element, along with a reason why the unhandled namespace data could not be included in the appropriate location of the response. The <extValue> element will not be processed by the XML processor. The <extValue> element contains the following child elements:

サーバーに、クライアントがログインサービスに基づいてサポートされていないクライアントに戻るデータがある場合、サーバーは<extValue>要素[RFC5730]に移動した各サポートされていないネームスペースのデータで正常な応答を返します。未処理のネームスペースはエラー応答を引き起こしませんが、未処理のネームスペースデータは<extValue>要素に移動され、未処理の名前空間データが適切な応答の場所に含めることができなかった理由とともに、<extValue>要素に移動します。<extValue>要素はXMLプロセッサによって処理されません。<extValue>要素には、次の子要素が含まれています。

<value>: Contains a child element with the unhandled namespace XML. The unhandled namespace MUST be declared in the child element or any containing element, including the root element. XML processing of the <value> element is disabled by the XML schema in [RFC5730], so the information can safely be returned in the <value> element.

<value>：未処理のネームスペースXMLを持つ子要素を含みます。未処理の名前空間は、子要素またはルート要素を含む任意の包含要素で宣言されている必要があります。<value>要素のXML処理は[RFC5730]でXMLスキーマによって無効になっているため、<value>要素に安全に返されます。

<reason>: A formatted, human-readable message that indicates the reason the unhandled namespace data was not returned in the appropriate location of the response. The formatted reason SHOULD follow the Augmented Backus-Naur Form (ABNF) grammar [RFC5234] format: NAMESPACE-URI " not in login services", where NAMESPACE-URI is the unhandled XML namespace like "urn:ietf:params:xml:ns:domain-1.0" in [RFC5731].

<理由>：未処理のネームスペースデータが応答の適切な場所に返されなかった理由を示すフォーマットされた、人間が読めるメッセージ。フォーマットされた理由は、拡張された背景 - Naur形式（ABNF）GRAMMAR [RFC5234]フォーマット：namespace-uri「ログインサービスではない」、namespace-uriは "urn：ietf：params：xml：ns）です。：[RFC5731]でDOMAIN-1.0 "。

This document applies to the handling of unsupported namespaces for object-level extensions and command-response extensions [RFC3735]. This document does not apply to the handling of unsupported namespaces for protocol-level extensions or authentication-information extensions [RFC3735]. Refer to the following sections on how to handle an unsupported object-level extension namespace or an unsupported command-response extension namespace.

このドキュメントは、オブジェクトレベルの拡張子とコマンド - Response Extensionsのサポートされていないネームスペースの処理に適用されます[RFC3735]。このドキュメントは、プロトコルレベルの拡張子または認証情報拡張[RFC3735]のサポートされていない名前空間の処理には適用されません。サポートされていないオブジェクトレベルの拡張ネームスペースまたはサポートされていないコマンド応答拡張ネームスペースを処理する方法については、次のセクションを参照してください。

3.1. Unhandled Object-Level Extension

3.1. 未処理のオブジェクトレベルの拡張子

An object-level extension in [RFC5730] is a child element of the <resData> element. If the client does not handle the namespace of the object-level extension, then the <resData> element is removed and its object-level extension child element is moved into an <extValue> <value> element [RFC5730], with the namespace URI included in the corresponding <extValue> <reason> element. The response becomes a general EPP response without the <resData> element.

[RFC5730]のオブジェクトレベルの拡張子は、<restata>要素の子要素です。クライアントがオブジェクトレベルの拡張子のネームスペースを処理しない場合、<resdata>要素は削除され、そのオブジェクトレベルの拡張子子要素が<extValue> <value>要素[RFC5730]に移動され、ネームスペースURIを使用して対応する<extValue> <reason>要素に含まれています。応答は<restata>要素なしの一般的なEPP応答になります。

Below is a template response for a supported object-level extension. The [NAMESPACE-XML] variable represents the object-level extension XML.

以下は、サポートされているオブジェクトレベルの拡張子のテンプレート応答です。[namespace-xml]変数は、オブジェクトレベルの拡張XMLを表します。

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:      <msg>Command completed successfully</msg>
   S:    </result>
   S:    <resData>
   S:      [NAMESPACE-XML]
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

Below is a template for an unhandled namespace response for an unsupported object-level extension. The [NAMESPACE-XML] variable represents the object-level extension XML, and the [NAMESPACE-URI] variable represents the object-level extension XML namespace URI.

以下は、サポートされていないオブジェクトレベルの拡張子に対する未処理の名前空間応答のテンプレートです。[namespace-xml]変数はオブジェクトレベルの拡張XMLを表し、[namespace-uri]変数はオブジェクトレベルの拡張XMLネームスペースURIを表します。

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:      <msg>Command completed successfully</msg>
   S:      <extValue>
   S:        <value>
   S:          [NAMESPACE-XML]
   S:        </value>
   S:        <reason>
   S:          [NAMESPACE-URI] not in login services
   S:        </reason>
   S:      </extValue>
   S:    </result>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

The EPP response is converted from an object response to a general EPP response by the server when the client does not support the object-level extension namespace URI.

EPP応答は、クライアントがオブジェクトレベルの拡張ネームスペースURIをサポートしていないときに、オブジェクト応答からサーバーによって一般的なEPPレスポンスに変換されます。

Below is an example of a <transfer> query response (see Section 3.1.3 of [RFC5731]) converted into an unhandled namespace response.

以下は、未処理の名前空間応答に変換された<転送>クエリ応答（[RFC5731のセクション3.1.3を参照）の例です。

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:      <msg>Command completed successfully</msg>
   S:      <extValue>
   S:        <value>
   S:          <domain:trnData
   S:            xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:            <domain:name>example.com</domain:name>
   S:            <domain:trStatus>pending</domain:trStatus>
   S:            <domain:reID>ClientX</domain:reID>
   S:            <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate>
   S:            <domain:acID>ClientY</domain:acID>
   S:            <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate>
   S:            <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
   S:          </domain:trnData>
   S:        </value>
   S:        <reason>
   S:          urn:ietf:params:xml:ns:domain-1.0 not in login services
   S:        </reason>
   S:      </extValue>
   S:    </result>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

3.2. Unhandled Command-Response Extension

3.2. 未処理のコマンド - 応答拡張

A command-response extension in [RFC5730] is a child element of the <extension> element. If the client does not handle the namespace of the command-response extension, the command-response child element is moved into an <extValue> <value> element [RFC5730], with the namespace URI included in the corresponding <extValue> <reason> element. Afterwards, if there are no additional command-response child elements, the <extension> element MUST be removed.

[RFC5730]のコマンド応答拡張は、<拡張機能>要素の子要素です。クライアントがコマンド - 応答拡張の名前空間を処理しない場合、コマンド応答子要素は<extValue> <value>要素[RFC5730]に移動し、対応する<extValue> <理由>に含まれるネームスペースURIが含まれています。素子。その後、追加のコマンド応答子要素がない場合は、<拡張機能>要素を削除する必要があります。

Below is a template response for a supported command-response extension. The [NAMESPACE-XML] variable represents the command-response extension XML.

以下は、サポートされているコマンド応答拡張のテンプレート応答です。[namespace-xml]変数は、コマンド応答拡張XMLを表します。

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:      <msg>Command completed successfully</msg>
   S:    </result>
   S:    <extension>
   S:      [NAMESPACE-XML]
   S:    </extension>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

Below is a template of an unhandled namespace response for an unsupported command-response extension. The [NAMESPACE-XML] variable represents the command-response extension XML, and the [NAMESPACE-URI] variable represents the command-response extension XML namespace URI.

以下は、サポートされていないコマンド応答拡張のための未処理の名前空間応答のテンプレートです。[namespace-xml]変数はコマンド応答拡張XMLを表し、[namespace-uri]変数はコマンド応答拡張XMLネームスペースURIを表します。

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1000">
   S:      <msg>Command completed successfully</msg>
   S:      <extValue>
   S:        <value>
   S:         [NAMESPACE-XML]
   S:        </value>
   S:        <reason>
   S:          [NAMESPACE-URI] not in login services
   S:        </reason>
   S:      </extValue>
   S:    </result>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

The EPP response is converted to an unhandled namespace response by moving the unhandled command-response extension from under the <extension> to an <extValue> element.

EPP応答は、未処理のコマンド応答拡張を<拡張機能>の下から<extValue>要素に移動させることによって、未処理の名前空間応答に変換されます。

Below is example of the Delegation Signer (DS) Data Interface <info> response (see Section 5.1.2 of [RFC5910]) converted to an unhandled namespace response.

以下は、未処理のネームスペース応答に変換された委任署名者（DS）データインターフェイス<info>応答の例です（[RFC5910のセクション5.1.2）。

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   S:  <response>
   S:    <result code="1000">
   S:      <msg>Command completed successfully</msg>
   S:      <extValue>
   S:        <value>
   S:          <secDNS:infData
   S:            xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
   S:            <secDNS:dsData>
   S:              <secDNS:keyTag>12345</secDNS:keyTag>
   S:              <secDNS:alg>3</secDNS:alg>
   S:              <secDNS:digestType>1</secDNS:digestType>
   S:              <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
   S:            </secDNS:dsData>
   S:          </secDNS:infData>
   S:        </value>
   S:        <reason>
   S:          urn:ietf:params:xml:ns:secDNS-1.1 not in login services
   S:        </reason>
   S:      </extValue>
   S:    </result>
   S:    <resData>
   S:      <domain:infData
   S:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:name>example.com</domain:name>
   S:        <domain:roid>EXAMPLE1-REP</domain:roid>
   S:        <domain:status s="ok"/>
   S:        <domain:registrant>jd1234</domain:registrant>
   S:        <domain:contact type="admin">sh8013</domain:contact>
   S:        <domain:contact type="tech">sh8013</domain:contact>
   S:        <domain:ns>
   S:          <domain:hostObj>ns1.example.com</domain:hostObj>
   S:          <domain:hostObj>ns2.example.com</domain:hostObj>
   S:        </domain:ns>
   S:        <domain:host>ns1.example.com</domain:host>
   S:        <domain:host>ns2.example.com</domain:host>
   S:        <domain:clID>ClientX</domain:clID>
   S:        <domain:crID>ClientY</domain:crID>
   S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
   S:        <domain:upID>ClientX</domain:upID>
   S:        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
   S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
   S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
   S:        <domain:authInfo>
   S:          <domain:pw>2fooBAR</domain:pw>
   S:        </domain:authInfo>
   S:      </domain:infData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

4. Signaling Client and Server Support

4. シグナリングクライアントとサーバーのサポート

This document does not define new EPP protocol elements but rather specifies an operational practice using the existing EPP protocol, where the client and the server can signal support for the operational practice using a namespace URI in the login and greeting extension services. The namespace URI "urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0" is used to signal support for the operational practice. The client includes the namespace URI in an <svcExtension> <extURI> element of the <login> command [RFC5730]. The server includes the namespace URI in an <svcExtension> <extURI> element of the greeting [RFC5730].

この文書は新しいEPPプロトコル要素を定義していませんが、むしろ既存のEPPプロトコルを使用した運用方法を指定します。ここで、クライアントとサーバーは、ログインおよびグリーティング・エクステンション・サービスのネームスペースURIを使用して運用慣行のサポートをサポートできます。ネームスペースURI "urn：ietf：params：xml：ns：unhandled-namespaces-1.0"は、操作方法のサポートをシグナリングするために使用されます。クライアントには、<login> command [rfc5730]の<svcextension> <exturi>要素の名前空間URIが含まれています。サーバーには、グリーティングの<SVCExtension> <exturi>要素の名前空間URIが含まれています[RFC5730]。

A client that receives the namespace URI in the server's greeting extension services can expect the following supported behavior by the server:

サーバーのグリーティング・エクステンション・サービス内のネームスペースURIを受信するクライアントは、サーバーによる次のサポートされている動作を期待できます。

* support unhandled namespace object-level extensions and command-response extensions in EPP poll messages, per Section 6

* EPPポーリングメッセージ内の未処理の名前空間オブジェクトレベルの拡張機能とコマンド応答拡張機能をサポートします。

* support the option of unhandled namespace command-response extensions in general EPP responses, per Section 5

* セクション5ごとに、一般的なEPP応答の未処理の名前空間コマンド - 応答拡張機能のオプションをサポートします。

A server that receives the namespace URI in the client's <login> command extension services can expect the following supported behavior by the client:

クライアントの<login>コマンド拡張サービスでネームスペースURIを受信するサーバーは、クライアントによる次のサポートされている動作を期待できます。

* support monitoring the EPP poll messages and general EPP responses for unhandled namespaces

* 未処理ネームスペースに対するEPPポーリングメッセージと一般的なEPP応答の監視のサポート

5. Usage with General EPP Responses

5. 一般的なEPPレスポンスによる使用

The unhandled namespace approach defined in Section 3 MAY be used for a general EPP response to an EPP command. A general EPP response includes any EPP response that is not a poll message. The use of the unhandled namespace approach for poll-message EPP responses is defined in Section 6. The server MAY exclude the unhandled namespace information in the general EPP response or MAY include it using the unhandled namespace approach.

セクション3で定義されている未処理の名前空間アプローチは、EPPコマンドに対する一般的なEPP応答に使用されることがあります。一般的なEPPレスポンスには、ポーリングメッセージではないEPPレスポンスが含まれます。Poll-Message EPP応答に対する未処理の名前空間アプローチの使用はセクション6で定義されています。サーバーは、一般的なEPPレスポンスで未処理の名前空間情報を除外することも、未処理の名前空間アプローチを使用することもできます。

The unhandled namespace approach for general EPP responses SHOULD only be applicable to command-response extensions, defined in Section 3.2, since the server SHOULD NOT accept an object-level EPP command if the client did not include the object-level namespace URI in the login services. An object-level EPP response extension is returned when the server successfully executes an object-level EPP command extension. The server MAY return an unhandled object-level extension to the client, as defined in Section 3.1.

一般的なEPP応答の未処理のネームスペースアプローチは、クライアントにオブジェクトレベルの名前空間URIが含まれていない場合は、セクション3.2で定義されているコマンド応答拡張機能のみが、ログインでオブジェクトレベルの名前空間URIを含めないでください。サービスサーバーがオブジェクトレベルのEPPコマンド拡張を正常に実行したときに、オブジェクトレベルのEPP応答拡張が返されます。セクション3.1で定義されているように、サーバーは未処理のオブジェクトレベルの拡張子をクライアントに返すことがあります。

Returning domain name Redemption Grace Period (RGP) data, based on [RFC3915], provides an example of applying the unhandled namespace approach for a general EPP response. If the client does not include the "urn:ietf:params:xml:ns:rgp-1.0" namespace URI in the login services and the domain <info> response of a domain name does have RGP information, the server MAY exclude the <rgp:infData> element from the EPP response or MAY include it under the <extValue> element, per Section 3.2.

[RFC3915]に基づくドメイン名償還猶予期間（RGP）データを返すと、一般的なEPP応答に対して未処理の名前空間アプローチを適用する例を示します。ログインサービスの「urn：ietf：params：xml：ns：rgp-1.0」の名前空間URIとドメイン名の<info>応答には、RGP情報があります。rgp：infdata> EPP応答からの要素またはセクション3.2の<extvalue>要素の下に含めることができます。

Below is an example of a domain name <info> response [RFC5731] converted to an unhandled <rgp:infData> element (see Section 4.1.1 of [RFC3915]) included under an <extValue> element:

以下は、ドメイン名<info>応答[RFC5731]の例です。<extvalue>要素の下に含まれる未処理の<rgp：infdata>要素（RFC3915]のセクション4.1.1を参照）に変換されます。

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
   S:     epp-1.0.xsd">
   S:  <response>
   S:    <result code="1000">
   S:      <msg>Command completed successfully</msg>
   S:      <extValue>
   S:        <value>
   S:          <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
   S:           xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
   S:           rgp-1.0.xsd">
   S:            <rgp:rgpStatus s="redemptionPeriod"/>
   S:          </rgp:infData>
   S:        </value>
   S:        <reason>
   S:          urn:ietf:params:xml:ns:rgp-1.0 not in login services
   S:        </reason>
   S:      </extValue>
   S:    </result>
   S:    <resData>
   S:      <domain:infData
   S:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
   S:        xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
   S:        domain-1.0.xsd">
   S:        <domain:name>example.com</domain:name>
   S:        <domain:roid>EXAMPLE1-REP</domain:roid>
   S:        <domain:status s="pendingDelete"/>
   S:        <domain:registrant>jd1234</domain:registrant>
   S:        <domain:contact type="admin">sh8013</domain:contact>
   S:        <domain:contact type="tech">sh8013</domain:contact>
   S:        <domain:ns>
   S:          <domain:hostObj>ns1.example.com</domain:hostObj>
   S:          <domain:hostObj>ns1.example.net</domain:hostObj>
   S:        </domain:ns>
   S:        <domain:host>ns1.example.com</domain:host>
   S:        <domain:host>ns2.example.com</domain:host>
   S:        <domain:clID>ClientX</domain:clID>
   S:        <domain:crID>ClientY</domain:crID>
   S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
   S:        <domain:upID>ClientX</domain:upID>
   S:        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
   S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
   S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
   S:        <domain:authInfo>
   S:          <domain:pw>2fooBAR</domain:pw>
   S:        </domain:authInfo>
   S:      </domain:infData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

6. Usage with Poll-Message EPP Responses

6. Poll-Message EPPレスポンスを使用した使用

The unhandled namespace approach, defined in Section 3, MUST be used if there is unhandled namespace information included in a <poll> response. The server inserts poll messages into the client's poll queue independent of knowing the supported client login services; therefore, there may be unhandled object-level extensions and command-response extensions included in a client's poll queue. In [RFC5730], the <poll> command is used by the client to retrieve and acknowledge poll messages that have been inserted by the server. The <poll> response is an EPP response that includes the <msgQ> element that provides poll queue metadata about the message. The unhandled namespace approach, defined in Section 3, is used for an unhandled object-level extension and for each of the unhandled command-response extensions attached to the <poll> response. The resulting <poll> response MAY have either or both the object-level extension or command-response extensions moved to <extValue> elements, as defined in Section 3.

<Poll> Responseに含まれる未処理のネームスペース情報が含まれている場合は、セクション3で定義されている未処理の名前空間アプローチを使用する必要があります。サーバーは、サポートされているクライアントのログインサービスを知ることによって、ポーリングメッセージをクライアントのポーリングキューに挿入します。したがって、クライアントのポーリングキューに含まれる未処理のオブジェクトレベルの拡張機能とコマンド応答拡張機能がある可能性があります。 [RFC5730]では、<poll>コマンドはクライアントによってサーバーによって挿入されたポーリングメッセージを取得して確認します。 <poll>応答は、メッセージに関するポーリングキューメタデータを提供する<msgq>要素を含むEPP応答です。セクション3で定義されていない未処理の名前空間アプローチは、未処理のオブジェクトレベルの拡張子と、<poll>応答に添付されている未処理のコマンドレスポンス拡張機能ごとに使用されます。結果の<poll>応答は、セクション3で定義されているように、オブジェクトレベルの拡張機能またはコマンド応答拡張機能のいずれかまたは両方を持つことができます。

The change poll message, as defined in Section 3.1.2 of [RFC8590], which is an extension of any EPP object, is an example of applying the unhandled namespace approach for <poll> responses. Below are examples of converting the domain name <info> response example in Section 3.1.2 of [RFC8590] to an unhandled namespace response. The object that will be used in the examples is a domain name object [RFC5731].

任意のEPPオブジェクトの拡張である[RFC8590]のセクション3.1.2で定義されているように、変更ポーリングメッセージは、<poll>応答に未処理の名前空間アプローチを適用する例です。以下は、ドメイン名<info>応答の例を[RFC8590]のセクション3.1.2の未処理の名前空間応答に変換する例です。例で使用されるオブジェクトは、ドメイン名オブジェクト[RFC5731]です。

Below is a domain name <info> <poll> response [RFC5731] with the unhandled <changePoll:changeData> element [RFC8590] included under an <extValue> element.

以下はドメイン名<info> <poll>応答[RFC5731]で、<extValue>要素の下に含まれています。

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1301">
   S:      <msg lang="en-US">
   S:        Command completed successfully; ack to dequeue</msg>
   S:      <extValue>
   S:        <value>
   S:          <changePoll:changeData
   S:           xmlns:changePoll="urn:ietf:params:xml:ns:changePoll-1.0"
   S:           state="after">
   S:            <changePoll:operation>update</changePoll:operation>
   S:            <changePoll:date>
   S:              2013-10-22T14:25:57.0Z</changePoll:date>
   S:            <changePoll:svTRID>12345-XYZ</changePoll:svTRID>
   S:            <changePoll:who>URS Admin</changePoll:who>
   S:            <changePoll:caseId type="urs">urs123
   S:            </changePoll:caseId>
   S:            <changePoll:reason>URS Lock</changePoll:reason>
   S:          </changePoll:changeData>
   S:        </value>
   S:        <reason>
   S:        urn:ietf:params:xml:ns:changePoll-1.0 not in login services
   S:        </reason>
   S:      </extValue>
   S:    </result>
   S:    <msgQ count="201" id="1">
   S:      <qDate>2013-10-22T14:25:57.0Z</qDate>
   S:      <msg>Registry initiated update of domain.</msg>
   S:    </msgQ>
   S:    <resData>
   S:      <domain:infData
   S:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:name>domain.example</domain:name>
   S:        <domain:roid>EXAMPLE1-REP</domain:roid>
   S:        <domain:status s="ok"/>
   S:        <domain:registrant>jd1234</domain:registrant>
   S:        <domain:contact type="admin">sh8013</domain:contact>
   S:        <domain:contact type="tech">sh8013</domain:contact>
   S:        <domain:clID>ClientX</domain:clID>
   S:        <domain:crID>ClientY</domain:crID>
   S:        <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
   S:        <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>
   S:      </domain:infData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

Below is an unhandled domain name <info> <poll> response [RFC5731] and the unhandled <changePoll:changeData> element [RFC8590] included under an <extValue> element.

以下は、未処理のドメイン名<info> <poll>応答[RFC5731]と未処理の<changepoll：changeedata>要素[RFC8590]を含みます。<extvalue>要素の下に含まれています。

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   S:  <response>
   S:    <result code="1301">
   S:      <msg>Command completed successfully; ack to dequeue</msg>
   S:      <extValue>
   S:        <value>
   S:          <domain:infData
   S:            xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:            <domain:name>domain.example</domain:name>
   S:            <domain:roid>EXAMPLE1-REP</domain:roid>
   S:            <domain:status s="ok"/>
   S:            <domain:registrant>jd1234</domain:registrant>
   S:            <domain:contact type="admin">sh8013</domain:contact>
   S:            <domain:contact type="tech">sh8013</domain:contact>
   S:            <domain:clID>ClientX</domain:clID>
   S:            <domain:crID>ClientY</domain:crID>
   S:            <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
   S:            <domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>
   S:          </domain:infData>
   S:        </value>
   S:        <reason>
   S:          urn:ietf:params:xml:ns:domain-1.0 not in login services
   S:        </reason>
   S:      </extValue>
   S:      <extValue>
   S:        <value>
   S:          <changePoll:changeData
   S:            xmlns:changePoll=
   S:              "urn:ietf:params:xml:ns:changePoll-1.0"
   S:            state="after">
   S:            <changePoll:operation>update</changePoll:operation>
   S:            <changePoll:date>
   S:              2013-10-22T14:25:57.0Z</changePoll:date>
   S:            <changePoll:svTRID>12345-XYZ</changePoll:svTRID>
   S:            <changePoll:who>URS Admin</changePoll:who>
   S:            <changePoll:caseId type="urs">urs123
   S:            </changePoll:caseId>
   S:            <changePoll:reason>URS Lock</changePoll:reason>
   S:          </changePoll:changeData>
   S:        </value>
   S:        <reason>
   S:        urn:ietf:params:xml:ns:changePoll-1.0 not in login services
   S:        </reason>
   S:      </extValue>
   S:    </result>
   S:    <msgQ count="201" id="1">
   S:      <qDate>2013-10-22T14:25:57.0Z</qDate>
   S:      <msg>Registry initiated update of domain.</msg>
   S:    </msgQ>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

7. Implementation Considerations

7. 実装に関する考慮事項

There are implementation considerations for the client and the server to help address the risk of the client ignoring unhandled namespace information included in an EPP response that is needed to meet technical, policy, or legal requirements.

クライアントとサーバーの実装に関する考慮事項は、技術、ポリシー、または法的要件を満たすために必要なEPPの対応に含まれている未処理の名前空間情報を無視してクライアントのリスクを取り扱うのに役立ちます。

7.1. Client Implementation Considerations

7.1. クライアント実装に関する考慮事項

To reduce the likelihood of a client receiving unhandled namespace information, the client should consider implementing the following:

クライアントが未処理の名前空間情報を受信する可能性を減らすために、クライアントは次の実装を検討する必要があります。

1. Ensure that the client presents the complete set of what it supports when presenting its login services. If there are gaps between the services supported by the client and the login services included in the login command, the client may receive unhandled namespace information that the client could have supported.

1. クライアントが、ログインサービスを提示するときにそれがサポートしているものの完全なセットを提示していることを確認してください。クライアントでサポートされているサービスとloginコマンドに含まれているログインサービスとの間にギャップがある場合、クライアントはクライアントがサポートしている可能性がある未処理の名前空間情報を受信することがあります。

2. Support all of the services included in the server greeting services that may be included in an EPP response, including the <poll> responses. The client should evaluate the gaps between the greeting services and the login services provided in the login command to identify extensions that need to be supported.

2. <poll>応答を含むEPPの応答に含めることができるサーバーグリーティングサービスに含まれるすべてのサービスをサポートします。クライアントは、グリーティングサービスとログインコマンドで提供されているログインサービスとの間のギャップを評価して、サポートする必要がある拡張機能を識別する必要があります。

3. Proactively monitor for unhandled namespace information in the EPP responses by looking for the inclusion of the <extValue> element in successful responses, record the unsupported namespace included in the <reason> element, and record the unhandled namespace information included in the <value> element for later processing. The unhandled namespace should be implemented by the client to ensure that information is processed fully in future EPP responses.

3. <extValue>要素を成功した<extValue>要素を含めることで、<reason>要素に含まれるサポートされていないネームスペースを記録し、<value>要素に含まれる未処理のネームスペース情報を記録し、<extValue>要素を記録し、記録しています。後で処理するために。未処理の名前空間は、将来のEPP応答で情報が完全に処理されるようにクライアントによって実装されるべきです。

7.2. Server Implementation Considerations

7.2. サーバー実装に関する考慮事項

To assist the clients in recognizing unhandled namespaces, the server should consider implementing the following:

未処理の名前空間を認識してクライアントが支援するために、サーバーは次のような実装を検討する必要があります。

1. Monitor for returning unhandled namespace information to clients and report it to the clients out of band to EPP, so the clients can add support for the unhandled namespaces.

1. 未処理の名前空間情報をクライアントに返すための監視とそれを帯域外へのクライアントにEPPに報告するため、クライアントは未処理の名前空間のサポートを追加できます。

2. Look for the unhandled namespace support in the login services when returning optional unhandled namespace information in general EPP responses.

2. 一般的なEPP応答でオプションの未処理の名前空間情報を返すときに、ログインサービスの未処理の名前空間サポートを探します。

8. IANA Considerations

8. IANAの考慮事項

8.1. XML Namespace

8.1. XMLネームスペース

This document uses URNs to describe XML namespaces conforming to a registry mechanism described in [RFC3688]. The following URI assignment has been made by IANA.

この文書はURNを使用して、[RFC3688]に記載されているレジストリメカニズムに準拠したXML名前空間を記述します。次のURIの課題がIANAによって行われました。

URI: urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0 Registrant Contact: IESG XML: None. Namespace URIs do not represent an XML specification.

URI：URN：IETF：PARAMS：XML：NS：epp：unhandled-namespaces-1.0登録者連絡先：IESG XML：None。ネームスペースURIはXML仕様を表していません。

8.2. EPP Extension Registry

8.2. EPP拡張レジストリ

The EPP operational practice described in this document has been registered by IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in [RFC7451]. The details of the registration are as follows:

この文書に記載されているEPPの運用慣行は、[RFC7451]に記載されている「拡張可能プロビジョニングプロトコル（EPP）」レジストリの「拡張機能」のIANAによって登録されています。登録の詳細は次のとおりです。

   Name of Extension:  "Extensible Provisioning Protocol (EPP) Unhandled
      Namespaces"
   Document Status:  Standards Track
   Reference:  RFC 9038
   Registrant:  IETF, <iesg@ietf.org>
   TLDs:  Any
   IPR Disclosure:  None
   Status:  Active
   Notes:  None

9. Security Considerations

9. セキュリティに関する考慮事項

This document does not provide any security services beyond those described by EPP [RFC5730] and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well. Since the unhandled namespace content is XML that is not processed in the first pass by the XML parser, the client SHOULD validate the XML when the content is processed to protect against the inclusion of malicious content.

この文書では、EPP [RFC5730]で説明されているものを超えてセキュリティサービスは提供されていません。これらの他の仕様に記載されているセキュリティ上の考慮事項は、この仕様にも適用されます。未処理のネームスペースのコンテンツはXMLパーサーによって最初のパスで処理されていないXMLであるため、クライアントは、悪質なコンテンツを含めることから保護するためにコンテンツが処理されるときにXMLを検証する必要があります。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC3688] Mealling、M.、 "The IETF XMLレジストリ"、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https：//www.rfc-editor.org/info/rfc3688>。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。

[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, <https://www.rfc-editor.org/info/rfc5730>.

[RFC5730] Hollenbeck、S.、「Extensible Provisioning Protocol（EPP）」、STD 69、RFC 5730、DOI 10.17487 / RFC5730、2009年8月、<https：//www.rfc-editor.org/info/rfc5730>。

[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, <https://www.rfc-editor.org/info/rfc5731>.

[RFC5731] Hollenbeck、S。、「拡張可能なプロビジョニングプロトコル（EPP）ドメイン名マッピング」、STD 69、RFC 5731、DOI 10.17487 / RFC5731、2009年8月、<https://www.rfc-editor.org/info/rfc5731>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

[W3C.REC-xml11-20060816] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", World Wide Web Consortium Recommendation REC-xml11-20060816, 16 August 2006, <https://www.w3.org/TR/2006/REC-xml11-20060816>.

[W3C.REC-XML11-20060816] Bray、T.、Paoli、J.、Sperberg-McQueen、M.、Maler、E.、Yergeau、F.、J. Cowan、 "Extensible Markup Language（XML）1.1）（2006年8月16日、<https://www.w3.org/tr/2006/Rec-xml11-20060816>を参照してください）」、第2版）」、「ワールドワイドウェブコンソーシアム勧告Rec-XML 11-20060816」

10.2. Informative References

10.2. 参考引用

[RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, DOI 10.17487/RFC3735, March 2004, <https://www.rfc-editor.org/info/rfc3735>.

[RFC3735] Hollenbeck、S.、「拡張可能プロビジョニングプロトコル（EPP）」、RFC 3735、DOI 10.17487 / RFC3735、2004年3月、<https：//www.rfc-editor.org/info/rfc3735>。

[RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", RFC 3915, DOI 10.17487/RFC3915, September 2004, <https://www.rfc-editor.org/info/rfc3915>.

[RFC3915] Hollenbeck、S。、「拡張プロビジョニングプロトコル（EPP）のドメインレジストリ猶予期間マッピング（EPP）」、RFC 3915、DOI 10.17487 / RFC3915、2004年9月、<https：//www.rfc-editor.org/info/RFC3915>。

[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, DOI 10.17487/RFC5910, May 2010, <https://www.rfc-editor.org/info/rfc5910>.

[RFC5910] Gould、J.およびS.Hollenbeck、「ドメインネームシステム（DNS）セキュリティ拡張（EPP）」、RFC 5910、DOI 10.17487 / RFC5910、2010年5月、<https：// www。rfc-editor.org/info/rfc5910>。

[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, February 2015, <https://www.rfc-editor.org/info/rfc7451>.

[RFC7451] Hollenbeck、S。、「拡張プロビジョニングプロトコルの拡張レジストリ」、RFC 7451、DOI 10.17487 / RFC7451、2015年2月、<https：//www.rfc-editor.org/info/rfc7451>。

[RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the Extensible Provisioning Protocol (EPP)", RFC 8590, DOI 10.17487/RFC8590, May 2019, <https://www.rfc-editor.org/info/rfc8590>.

[RFC8590] Gould、J.およびK. Feher、RFC 8590、DOI 10.17487 / RFC8590、RFC8590、<https://www.rfc-editor.org/情報/ RFC8590>。

Acknowledgements

謝辞

The authors wish to thank the following people for their feedback and suggestions: Thomas Corte, Scott Hollenbeck, Patrick Mevzek, and Marcel Parodi.

著者らは、彼らのフィードバックと提案のために次の人々に感謝したいと思います：Thomas Corte、Scott Hollenbeck、Patrick Mevzek、そしてMarcel Parodi。

Authors' Addresses

著者の住所

James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 United States of America

James Gould Verisign、Inc。12061 BlueMont Way Reston、VA 20190アメリカ合衆国

   Email: jgould@verisign.com
   URI:   http://www.verisign.com

Martin Casanova SWITCH P.O. Box CH-8021 Zurich Switzerland

Martin CasanovaスイッチP.O.ボックスCH-8021チューリッヒスイス連邦共和国

   Email: martin.casanova@switch.ch
   URI:   http://www.switch.ch