RFC 5731 - Extensible Provisioning Protocol (EPP) Domain Name Mapping 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5731
タイトル : RFC 5731 - 拡張可能なプロビジョニングプロトコル（EPP）ドメイン名マッピング
翻訳編集 : 自動生成

[要約] RFC 5731は、ドメイン名登録管理プロトコル「EPP」において、ドメイン名エントリ（登録期間、ステータス、ネームサーバー、認証情報など）を操作するための詳細なマッピング仕様を定義しています。世界中のドメイン名レジストリサービスにおいて、一貫した方法でドメインライフサイクルを管理するための標準的なXMLデータ構造を規定しています（RFC 4931の後継）。

Network Working Group                                      S. Hollenbeck
Request for Comments: 5731                                VeriSign, Inc.
STD: 69                                                      August 2009
Obsoletes: 4931
Category: Standards Track

Extensible Provisioning Protocol (EPP) Domain Name Mapping

拡張可能なプロビジョニングプロトコル（EPP）ドメイン名マッピング

Abstract

概要

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931.

このドキュメントでは、共有中央リポジトリに保存されているインターネットドメイン名のプロビジョニングと管理のための拡張可能なプロビジョニングプロトコル（EPP）マッピングについて説明します。XMLで指定されたマッピングは、ドメイン名に適用されるEPPコマンドの構文とセマンティクスを定義します。このドキュメントは、RFC 4931を廃止します。

Status of This Memo

本文書の状態

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。

Table of Contents

   1. Introduction ....................................................3
      1.1. Relationship of Domain Objects and Host Objects ............3
      1.2. Conventions Used in This Document ..........................5
   2. Object Attributes ...............................................5
      2.1. Domain and Host Names ......................................5
      2.2. Contact and Client Identifiers .............................5
      2.3. Status Values ..............................................5
      2.4. Dates and Times ............................................7
      2.5. Validity Periods ...........................................8
      2.6. Authorization Information ..................................8
      2.7. Other DNS Resource Record Attributes .......................8
   3. EPP Command Mapping .............................................9
      3.1. EPP Query Commands .........................................9
           3.1.1. EPP <check> Command .................................9
           3.1.2. EPP <info> Command .................................11
           3.1.3. EPP <transfer> Query Command .......................15
      3.2. EPP Transform Commands ....................................17
           3.2.1. EPP <create> Command ...............................18
           3.2.2. EPP <delete> Command ...............................20
           3.2.3. EPP <renew> Command ................................22
           3.2.4. EPP <transfer> Command .............................23
           3.2.5. EPP <update> Command ...............................25
      3.3. Offline Review of Requested Actions .......................28
   4. Formal Syntax ..................................................30
   5. Internationalization Considerations ............................40
   6. IANA Considerations ............................................40
   7. Security Considerations ........................................41
   8. Acknowledgements ...............................................41
   9. References .....................................................42
      9.1. Normative References ......................................42
      9.2. Informative References ....................................43
   Appendix A.  Changes from RFC 4931 ................................44

1. Introduction

1. はじめに

This document describes an Internet domain name mapping for version 1.0 of the Extensible Provisioning Protocol (EPP). This mapping is specified using the Extensible Markup Language (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. This document obsoletes RFC 4931 [RFC4931].

このドキュメントでは、拡張可能なプロビジョニングプロトコル（EPP）のバージョン1.0のインターネットドメイン名マッピングについて説明します。このマッピングは、[W3C.REC-XML-20040204]で説明されている拡張可能なマークアップ言語（XML）1.0と[W3C.REC-XMLSCHEMA-20041028]および[W3C.REC-XMLSCHEMAAで説明されているXMLスキーマ表記を使用して指定されています。-2-20041028]。このドキュメントは、RFC 4931 [RFC4931]を廃止します。

[RFC5730] provides a complete description of EPP command and response structures. A thorough understanding of the base protocol specification is necessary to understand the mapping described in this document.

[RFC5730]は、EPPコマンドと応答構造の完全な説明を提供します。このドキュメントに記載されているマッピングを理解するには、ベースプロトコル仕様を完全に理解する必要があります。

XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation.

XMLは大文字と小文字を区別します。特に明記されていない限り、適合する実装を開発するために、本文書で提供されるXML仕様および例は示された文字の大小関係のまま解釈しなければなりません (MUST)。

1.1. Relationship of Domain Objects and Host Objects

1.1. ドメインオブジェクトとホストオブジェクトの関係

The EPP mapping for host objects is described in [RFC5732]. This document assumes that domain name objects have a superordinate relationship to subordinate host name objects. For example, domain name "example.com" has a superordinate relationship to host name "ns1.example.com". EPP actions (such as object transfers) that do not preserve this relationship MUST be explicitly disallowed.

ホストオブジェクトのEPPマッピングは [RFC5732] で説明されています。本文書は、ドメイン名オブジェクトが下位のホスト名オブジェクトに対して上位の関係を持つことを想定しています。例えば、ドメイン名「example.com」はホスト名「ns1.example.com」に対して上位の関係を持ちます。この関係を維持しないEPPアクション（オブジェクト転送など）は、明示的に禁止されなければなりません (MUST)。

A host name object can be created in a repository for which no superordinate domain name object exists. For example, host name "ns1.example.com" can be created in the ".example" repository so that DNS domains in ".example" can be delegated to the host. Such hosts are described as "external" hosts in this specification since the name of the host does not belong to the namespace of the repository in which the host is being used for delegation purposes.

ホスト名オブジェクトは、上位ドメイン名オブジェクトが存在しないリポジトリに作成できます。たとえば、ホスト名「ns1.example.com」は、「.example」リポジトリで作成できるように、「.example」をホストに委任できるようにすることができます。このようなホストは、ホストの名前が委任目的で使用されているリポジトリの名前空間に属していないため、この仕様の「外部」ホストと説明されています。

Whether a host is external or internal relates to the repository in which the host is being used for delegation purposes. Whether or not an internal host is subordinate relates to a domain within the repository. For example, host ns1.example1.com is a subordinate host of domain example1.com, but it is not a subordinate host of domain example2.com. ns1.example1.com can be used as a name server for example2.com. In this case, ns1.example1.com MUST be treated as an internal host, subject to the rules governing operations on subordinate hosts within the same repository.

ホストが外部であるか内部であるかは、ホストが委任目的で使用されているリポジトリに関連します。内部ホストが下位であるかどうかは、リポジトリ内のドメインに関連します。例えば、ホスト ns1.example1.com はドメイン example1.com の下位ホストですが、ドメイン example2.com の下位ホストではありません。ns1.example1.com は example2.com のネームサーバとして使用できます。この場合、ns1.example1.com は、同じリポジトリ内の下位ホストに対する操作を規定する規則に従い、内部ホストとして扱われなければなりません (MUST)。

Name server hosts for domain delegation can be specified either as references to existing host objects or as domain attributes that describe a host machine. A server operator MUST use one name server specification form consistently. A server operator that announces support for host objects in an EPP greeting MUST NOT allow domain attributes to describe a name server host machine. A server operator that does not announce support for host objects MUST allow domain attributes to describe a name server host machine. When domain attributes are used to describe a name server host machine, IP addresses SHOULD be required only as needed to generate DNS glue records.

ドメイン委任のためのネームサーバホストは、既存のホストオブジェクトへの参照として指定するか、ホストマシンを記述するドメイン属性として指定するかのいずれかが可能です。サーバ事業者は、いずれか一方のネームサーバ指定形式を一貫して使用しなければなりません (MUST)。EPPグリーティングでホストオブジェクトのサポートを通知するサーバ事業者は、ドメイン属性がネームサーバホストマシンを記述することを許可してはなりません (MUST NOT)。ホストオブジェクトのサポートを通知しないサーバ事業者は、ドメイン属性がネームサーバホストマシンを記述することを許可しなければなりません (MUST)。ドメイン属性を使用してネームサーバホストマシンを記述する場合、IPアドレスはDNSグルーレコードを生成するために必要な場合にのみ要求すべきです (SHOULD)。

Name servers are specified within a <domain:ns> element. This element MUST contain one or more <domain:hostObj> elements or one or more <domain:hostAttr> elements. A <domain:hostObj> element contains the fully qualified name of a known name server host object. A <domain:hostAttr> element contains the following child elements:

ネームサーバは <domain:ns> 要素内で指定されます。この要素には、1つ以上の <domain:hostObj> 要素、または1つ以上の <domain:hostAttr> 要素が含まれていなければなりません (MUST)。<domain:hostObj> 要素には、既知のネームサーバホストオブジェクトの完全修飾名が含まれます。<domain:hostAttr> 要素には、以下の小要素が含まれます。

- A <domain:hostName> element that contains the fully qualified name of a host.

- A <ドメイン：ホスト名>ホストの完全な資格のある名前を含む要素。

- Zero or more OPTIONAL <domain:hostAddr> elements that contain the IP addresses to be associated with the host. Each element MAY contain an "ip" attribute to identify the IP address format. Attribute value "v4" is used to note IPv4 address format. Attribute value "v6" is used to note IPv6 address format. If the "ip" attribute is not specified, "v4" is the default attribute value. IP address syntax requirements are described in Section 2.5 of the EPP host mapping [RFC5732].

- ホストに関連付けるIPアドレスを含む、0個以上の任意 (OPTIONAL) の <domain:hostAddr> 要素。各要素は、IPアドレスフォーマットを識別するための「ip」属性を含んでもよい (MAY)。属性値「v4」はIPv4アドレスフォーマットを示すために使用されます。属性値「v6」はIPv6アドレスフォーマットを示すために使用されます。「ip」属性が指定されない場合、「v4」がデフォルトの属性値です。IPアドレス構文の要件は、EPPホストマッピング [RFC5732] のセクション2.5で説明されています。

Example host-object name server elements for domain example.com:

domain emple.comのhost-object name server要素：

   <domain:ns>
     <domain:hostObj>ns1.example.net</domain:hostObj>
     <domain:hostObj>ns2.example.net</domain:hostObj>
   </domain:ns>

Example host-attribute name server elements for domain example.com:

domain emple.comのhost-aTtribute name server要素：

   <domain:ns>
     <domain:hostAttr>
       <domain:hostName>ns1.example.net</domain:hostName>
       <domain:hostAddr
        ip="v4">192.0.2.2</domain:hostAddr>
       <domain:hostAddr
        ip="v6">1080:0:0:0:8:800:200C:417A</domain:hostAddr>
     </domain:hostAttr>
     <domain:hostAttr>
       <domain:hostName>ns2.example.net</domain:hostName>
     </domain:hostAttr>
   </domain:ns>

1.2. Conventions Used in This Document

1.2. このドキュメントで使用されている規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、[RFC2119] で説明されているように解釈されるものとします。

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

例において、「C:」はプロトコルクライアントから送信された行を表し、「S:」はプロトコルサーバから返された行を表します。例におけるインデントや空白は要素の関係を示すためにのみ提供されており、本プロトコルの必須 (REQUIRED) 機能ではありません。

2. Object Attributes

2. オブジェクト属性

An EPP domain object has attributes and associated values that can be viewed and modified by the sponsoring client or the server. This section describes each attribute type in detail. The formal syntax for the attribute values described here can be found in the "Formal Syntax" section of this document and in the appropriate normative references.

EPPドメインオブジェクトには、スポンサークライアントまたはサーバーが表示および変更できる属性と関連する値があります。このセクションでは、各属性タイプについて詳しく説明します。ここで説明する属性値の正式な構文は、このドキュメントの「正式な構文」セクションと適切な規範的参照にあります。

2.1. Domain and Host Names

2.1. ドメイン名とホスト名

The syntax for domain and host names described in this document MUST conform to [RFC0952] and [RFC1123]. At the time of this writing, RFC 3490 [RFC3490] describes a standard to use certain ASCII name labels to represent non-ASCII name labels. These conformance requirements might change as a result of progressing work in developing standards for internationalized domain names. A server MAY restrict allowable domain names to a particular top-level domain, second-level domain, or other domain for which the server is authoritative. The trailing dot required when these names are stored in a DNS zone is implicit and MUST NOT be provided when exchanging host and domain names.

本文書で説明されているドメイン名およびホスト名の構文は、[RFC0952] および [RFC1123] に準拠しなければなりません (MUST)。執筆時点で、RFC 3490 [RFC3490] は非ASCII名ラベルを表すために特定のASCII名ラベルを使用する標準を記述しています。これらの適合要件は、国際化ドメイン名の標準開発の進展に伴って変更される可能性があります。サーバは、許容可能なドメイン名を、特定のトップレベルドメイン、セカンドレベルドメイン、またはサーバが権威を持つその他のドメインに制限してもよい (MAY)。これらの名前がDNSゾーンに格納される際に必要とされる末尾のドットは暗黙的であり、ホスト名およびドメイン名を交換する際には提供してはなりません (MUST NOT)。

2.2. Contact and Client Identifiers

2.2. 連絡先とクライアントの識別子

All EPP contacts are identified by a server-unique identifier. Contact identifiers are character strings with a specified minimum length, a specified maximum length, and a specified format. Contact identifiers use the "clIDType" client identifier syntax described in [RFC5730].

すべてのEPP接点は、サーバーユニーク識別子によって識別されます。連絡先識別子は、指定された最小長、指定された最大長、指定された形式の文字文字列です。接触識別子は、[RFC5730]で説明されている「clIDType」クライアント識別子構文を使用します。

2.3. Status Values

2.3. ステータス値

A domain object MUST always have at least one associated status value. Status values can be set only by the client that sponsors a domain object and by the server on which the object resides. A client can change the status of a domain object using the EPP

ドメインオブジェクトには、常に少なくとも1つの関連付けられたステータス値が存在しなければなりません (MUST)。ステータス値は、ドメインオブジェクトを管理（スポンサー）するクライアント、およびオブジェクトが存在するサーバによってのみ設定できます。クライアントは、EPP

<update> command. Each status value MAY be accompanied by a string of human-readable text that describes the rationale for the status applied to the object.

<update> コマンドを使用してドメインオブジェクトのステータスを変更できます。各ステータス値には、オブジェクトに適用されたステータスの根拠を説明する、人間が読めるテキスト文字列が付随してもよい (MAY)。

A client MUST NOT alter status values set by the server. A server MAY alter or override status values set by a client, subject to local server policies. The status of an object MAY change as a result of either a client-initiated transform command or an action performed by a server operator.

クライアントは、サーバによって設定されたステータス値を変更してはなりません (MUST NOT)。サーバは、ローカルサーバポリシーに従い、クライアントによって設定されたステータス値を変更または上書きしてもよい (MAY)。オブジェクトのステータスは、クライアント主導の変換コマンド、またはサーバオペレータによって実行されるアクションのいずれかの結果として変更されてもよい (MAY)。

Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". Status values that do not begin with either "client" or "server" are server-managed.

クライアントが追加または削除できるステータス値には、「クライアント」が付いています。サーバーによって追加または削除できる対応するステータス値には、「サーバー」が付いています。「クライアント」または「サーバー」のいずれでも始まらないステータス値は、サーバー管理されています。

Status Value Descriptions:

ステータス値の説明：

- clientDeleteProhibited, serverDeleteProhibited

- clientDeleTeproquited、serverdeleTeprohited

Requests to delete the object MUST be rejected.

オブジェクトを削除する要求は拒否しなければなりません (MUST)。

- clientHold, serverHold

- clientHold、serverHold

DNS delegation information MUST NOT be published for the object.

オブジェクトに対するDNS委任情報を公開してはなりません (MUST NOT)。

- clientRenewProhibited, serverRenewProhibited

- clientrenewprohited、serverrenewprohited

Requests to renew the object MUST be rejected.

オブジェクトを更新（renew）する要求は拒否しなければなりません (MUST)。

- clientTransferProhibited, serverTransferProhibited

- ClientTransferProhited、ServerTransferProhited

Requests to transfer the object MUST be rejected.

オブジェクトを転送（transfer）する要求は拒否しなければなりません (MUST)。

- clientUpdateProhibited, serverUpdateProhibited

- ClientDateProhited、serverUpdateProhited

Requests to update the object (other than to remove this status) MUST be rejected.

（このステータスを削除すること以外の）オブジェクトを更新（update）する要求は拒否しなければなりません (MUST)。

- inactive

- 非活性

Delegation information has not been associated with the object. This is the default status when a domain object is first created and there are no associated host objects for the DNS delegation. This status can also be set by the server when all host-object associations are removed.

委任情報はオブジェクトに関連付けられていません。これは、ドメインオブジェクトが最初に作成された場合のデフォルトステータスであり、DNS委任に関連するホストオブジェクトがありません。このステータスは、すべてのホストオブジェクトアソシエーションが削除されたときにサーバーによって設定することもできます。

- ok

- Ok

This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.

これは、保留中の操作または禁止がないオブジェクトの通常のステータス値です。この値は、他のステータス値が追加または削除されるため、サーバーによって設定され、削除されます。

- pendingCreate, pendingDelete, pendingRenew, pendingTransfer, pendingUpdate

- 保留中、保留中、保留中の、保留中の、保留中の、保留中、保留中

A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action. A transform command that is processed, but whose requested action is pending, is noted with response code 1001.

オブジェクトの変換コマンドが処理されましたが、アクションはサーバーによって完了していません。サーバーオペレーターは、人間のレビューやサードパーティのアクションを可能にするなど、さまざまな理由でアクションの完了を遅らせることができます。処理されたが、要求されたアクションが保留中の変換コマンドは、応答コード1001で注目されます。

When the requested action has been completed, the pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status value MUST be removed. All clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed.

要求されたアクションが完了した際、pendingCreate、pendingDelete、pendingRenew、pendingTransfer、または pendingUpdate ステータス値を削除しなければなりません (MUST)。トランザクションに関与したすべてのクライアントに対し、アクションが完了したことおよびオブジェクトのステータスが変更されたことをサービスメッセージを使用して通知しなければなりません (MUST)。

"ok" status MUST NOT be combined with any other status.

『ok』ステータスを他のいかなるステータスと組み合わせてはなりません (MUST NOT)。

"pendingDelete" status MUST NOT be combined with either "clientDeleteProhibited" or "serverDeleteProhibited" status.

『pendingDelete』ステータスを、『clientDeleteProhibited』または『serverDeleteProhibited』ステータスのいずれかと組み合わせてはなりません (MUST NOT)。

"pendingRenew" status MUST NOT be combined with either "clientRenewProhibited" or "serverRenewProhibited" status.

『pendingRenew』ステータスを、『clientRenewProhibited』または『serverRenewProhibited』ステータスのいずれかと組み合わせてはなりません (MUST NOT)。

"pendingTransfer" status MUST NOT be combined with either "clientTransferProhibited" or "serverTransferProhibited" status.

『pendingTransfer』ステータスを、『clientTransferProhibited』または『serverTransferProhibited』ステータスのいずれかと組み合わせてはなりません (MUST NOT)。

"pendingUpdate" status MUST NOT be combined with either "clientUpdateProhibited" or "serverUpdateProhibited" status.

『pendingUpdate』ステータスを、『clientUpdateProhibited』または『serverUpdateProhibited』ステータスのいずれかと組み合わせてはなりません (MUST NOT)。

The pendingCreate, pendingDelete, pendingRenew, pendingTransfer, and pendingUpdate status values MUST NOT be combined with each other.

pendingCreate、pendingDelete、pendingRenew、pendingTransfer、および pendingUpdate の各ステータス値を互いに組み合わせてはなりません (MUST NOT)。

Other status combinations not expressly prohibited MAY be used.

明示的に禁止されていない他のステータスの組み合わせを使用してもよい (MAY)。

2.4. Dates and Times

2.4. 日付と時刻

Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar. The extended date-time form using upper case "T" and "Z" characters defined in

日付および時刻の属性値は、グレゴリオ暦を使用し協定世界時（UTC）で表現しなければなりません (MUST)。

[W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time values, as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters.

XML Schemaは省略された日時形式や小文字の「t」および「z」文字をサポートしていないため、日時値を表現するには [W3C.REC-xmlschema-2-20041028] で定義されている大文字の「T」および「Z」文字を使用した拡張日時形式を使用しなければなりません (MUST)。

2.5. Validity Periods

2.5. 有効期間

A domain name object MAY have a specified validity period. If server policy supports domain-object validity periods, the validity period is defined when a domain object is created, and it MAY be extended by the EPP <renew> or <transfer> commands. As a matter of server policy, this specification does not define actions to be taken upon expiration of a domain object's validity period.

ドメイン名オブジェクトには、指定された有効期間が存在してもよい (MAY)。サーバポリシーがドメインオブジェクトの有効期間をサポートしている場合、有効期間はドメインオブジェクトの作成時に定義され、EPP <renew> または <transfer> コマンドによって延長されてもよい (MAY)。サーバポリシーの問題として、本仕様ではドメインオブジェクトの有効期間満了時に実行すべきアクションを定義しません。

Validity periods are measured in years or months with the appropriate units specified using the "unit" attribute. Valid values for the "unit" attribute are "y" for years and "m" for months. The minimum allowable period value is one (1). The maximum allowable value is ninety-nine decimal (99). A server MAY support a lower maximum value.

有効期間は年または月単位で測定され、「unit」属性を使用して適切な単位が指定されます。「unit」属性の有効な値は、年を表す「y」および月を表す「m」です。許容される最小期間値は1（1）です。許容される最大値は10進数で99（99）です。サーバは、これより小さい最大値をサポートしてもよい (MAY)。

2.6. Authorization Information

2.6. 許可情報

Authorization information is associated with domain objects to facilitate transfer operations. Authorization information is assigned when a domain object is created, and it might be updated in the future. This specification describes password-based authorization information, though other mechanisms are possible.

許可情報は、転送操作を容易にするためにドメインオブジェクトに関連付けられています。承認情報は、ドメインオブジェクトが作成されたときに割り当てられ、将来更新される可能性があります。この仕様では、パスワードベースの認証情報について説明しますが、他のメカニズムは可能です。

2.7. Other DNS Resource Record Attributes

2.7. その他のDNSリソースレコード属性

While the DNS allows many resource record types to be associated with a domain, this mapping only explicitly specifies elements that describe resource records used for domain delegation and resolution. Facilities to provision other domain-related resource record types can be developed by extending this mapping.

DNSでは、多くのリソースレコードタイプをドメインに関連付けることができますが、このマッピングは、ドメインの委任と解像度に使用されるリソースレコードを説明する要素のみを明示的に指定します。他のドメイン関連のリソースレコードタイプを提供する設備は、このマッピングを拡張することで開発できます。

The provisioning method described in this mapping separates discrete data elements by data type. This method of data definition allows XML Schema processors to perform basic syntax-validation tasks, reducing ambiguity and the amount of parsing and syntax-checking work required of protocol processors. Provisioning and extension methods that aggregate data into opaque strings are possible, but such methods should not be used because they impose additional parsing, interpretation, and validation requirements on protocol processors.

このマッピングで説明されているプロビジョニング方法は、データ型によって離散データ要素を分離します。このデータ定義の方法により、XMLスキーマプロセッサは基本的な構文検証タスクを実行でき、曖昧さとプロトコルプロセッサに必要な解析および構文チェック作業の量を減らします。データを不透明な文字列に集約するプロビジョニングと拡張方法は可能ですが、プロトコルプロセッサに追加の解析、解釈、および検証要件を課すため、そのような方法は使用しないでください。

3. EPP Command Mapping

3. EPPコマンドマッピング

A detailed description of the EPP syntax and semantics can be found in [RFC5730]. The command mappings described here are specifically for use in provisioning and managing Internet domain names via EPP.

EPP構文とセマンティクスの詳細な説明は、[RFC5730]に記載されています。ここで説明するコマンドマッピングは、EPPを介したインターネットドメイン名のプロビジョニングと管理に特に使用するためのものです。

3.1. EPP Query Commands

3.1. EPPクエリコマンド

EPP provides three commands to retrieve domain information: <check> to determine if a domain object can be provisioned within a repository, <info> to retrieve detailed information associated with a domain object, and <transfer> to retrieve domain-object transfer status information.

EPPはドメイン情報を取得するための3つのコマンドを提供します：<Check>ドメインオブジェクトをリポジトリ内でプロビジョニングできるかどうか、<情報>ドメインオブジェクトに関連付けられた詳細情報を取得し、<転送>ドメインオブジェクト転送ステータス情報を取得する。

3.1.1. EPP <check> Command

3.1.1. EPP <Check>コマンド

The EPP <check> command is used to determine if an object can be provisioned within a repository. It provides a hint that allows a client to anticipate the success or failure of provisioning an object using the <create> command, as object-provisioning requirements are ultimately a matter of server policy.

EPP <Check>コマンドは、オブジェクトをリポジトリ内でプロビジョニングできるかどうかを判断するために使用されます。オブジェクトプロビジョンの要件は最終的にはサーバーポリシーの問題であるため、クライアントが<create>コマンドを使用してオブジェクトのプロビジョニングの成功または失敗を予測できるようにするヒントを提供します。

In addition to the standard EPP command elements, the <check> command MUST contain a <domain:check> element that identifies the domain namespace. The <domain:check> element contains the following child elements:

標準的なEPPコマンド要素に加えて、<check> コマンドにはドメイン名前空間を識別する <domain:check> 要素が含まれていなければなりません (MUST)。<domain:check> 要素には、以下の小要素が含まれます。

- One or more <domain:name> elements that contain the fully qualified names of the domain objects to be queried.

- 1つ以上の<ドメイン：name> queriedするドメインオブジェクトの完全に適格な名前を含む要素。

Example <check> command:

例<Check>コマンド：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <check>
   C:      <domain:check
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:name>example.net</domain:name>
   C:        <domain:name>example.org</domain:name>
   C:      </domain:check>
   C:    </check>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>
   When a <check> command has been processed successfully, the EPP
   <resData> element MUST contain a child <domain:chkData> element that
   identifies the domain namespace.  The <domain:chkData> element
   contains one or more <domain:cd> elements that contain the following
   child elements:

- A <domain:name> element that contains the fully qualified name of the queried domain object. This element MUST contain an "avail" attribute whose value indicates object availability (can it be provisioned or not) at the moment the <check> command was completed. A value of "1" or "true" means that the object can be provisioned. A value of "0" or "false" means that the object can not be provisioned.

- 照会されたドメインオブジェクトの完全修飾名を含む <domain:name> 要素。この要素には、<check> コマンドが完了した時点でのオブジェクトの利用可能性（プロビジョニング可能かどうか）を示す「avail」属性が含まれていなければなりません (MUST)。「1」または「true」の値は、オブジェクトをプロビジョニングできることを意味します。「0」または「false」の値は、オブジェクトをプロビジョニングできないことを意味します。

- An OPTIONAL <domain:reason> element that MAY be provided when an object cannot be provisioned. If present, this element contains server-specific text to help explain why the object cannot be provisioned. This text MUST be represented in the response language previously negotiated with the client; an OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en" (English).

- オブジェクトをプロビジョニングできない場合に提供されてもよい (MAY)、任意 (OPTIONAL) の <domain:reason> 要素。存在する場合、この要素にはオブジェクトをプロビジョニングできない理由の説明に役立つサーバ固有のテキストが含まれます。このテキストは、事前にクライアントとネゴシエートされた応答言語で表現されなければならず (MUST)、ネゴシエートされた値がデフォルト値である「en」（英語）以外である場合、言語を識別するために任意 (OPTIONAL) の「lang」属性が存在してもよい (MAY)。

Example <check> response:

例<Check>応答：

   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:      <domain:chkData
   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:cd>
   S:          <domain:name avail="1">example.com</domain:name>
   S:        </domain:cd>
   S:        <domain:cd>
   S:          <domain:name avail="0">example.net</domain:name>
   S:          <domain:reason>In use</domain:reason>
   S:        </domain:cd>
   S:        <domain:cd>
   S:          <domain:name avail="1">example.org</domain:name>
   S:        </domain:cd>
   S:      </domain:chkData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

An EPP error response MUST be returned if a <check> command cannot be processed for any reason.

何らかの理由で <check> コマンドを処理できない場合、EPPエラー応答を返さなければなりません (MUST)。

3.1.2. EPP <info> Command

3.1.2. epp <info>コマンド

The EPP <info> command is used to retrieve information associated with a domain object. The response to this command MAY vary depending on the identity of the querying client, use of authorization information, and server policy towards unauthorized clients. If the querying client is the sponsoring client, all available information MUST be returned. If the querying client is not the sponsoring client but the client provides valid authorization information, all available information MUST be returned. If the querying client is not the sponsoring client and the client does not provide valid authorization information, server policy determines which OPTIONAL elements are returned.

EPP <info> コマンドは、ドメインオブジェクトに関連付けられた情報を取得するために使用されます。このコマンドに対する応答は、照会クライアントの身元、認証情報の使用、および非認可クライアントに対するサーバポリシーに応じて異なってもよい (MAY)。照会クライアントがスポンサークライアントである場合、利用可能なすべての情報を返さなければなりません (MUST)。照会クライアントがスポンサークライアントではないものの有効な認証情報を提供した場合、利用可能なすべての情報を返さなければなりません (MUST)。照会クライアントがスポンサークライアントではなく、有効な認証情報も提供しない場合、どの任意 (OPTIONAL) の要素を返すかはサーバポリシーによって決定されます。

In addition to the standard EPP command elements, the <info> command MUST contain a <domain:info> element that identifies the domain namespace. The <domain:info> element contains the following child elements:

標準的なEPPコマンド要素に加えて、<info> コマンドにはドメイン名前空間を識別する <domain:info> 要素が含まれていなければなりません (MUST)。<domain:info> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object to be queried. An OPTIONAL "hosts" attribute is available to control return of information describing hosts related to the domain object. A value of "all" (the default, which MAY be absent) returns information describing both subordinate and delegated hosts. A value of "del" returns information describing only delegated hosts. A value of "sub" returns information describing only subordinate hosts. A value of "none" returns no information describing delegated or subordinate hosts.

- 照会対象のドメインオブジェクトの完全修飾名を含む <domain:name> 要素。ドメインオブジェクトに関連するホストを記述する情報の返却を制御するために、任意 (OPTIONAL) の「hosts」属性を利用できます。「all」の値（デフォルトであり、省略されてもよい (MAY)）は、下位ホストと委任ホストの両方を記述する情報を返します。「del」の値は委任ホストのみを記述する情報を返します。「sub」の値は下位ホストのみを記述する情報を返します。「none」の値は、委任ホストまたは下位ホストを記述する情報を一切返しません。

- An OPTIONAL <domain:authInfo> element that contains authorization information associated with the domain object or authorization information associated with the domain object's registrant or associated contacts. An OPTIONAL "roid" attribute MUST be used to identify the registrant or contact object if and only if the given authInfo is associated with a registrant or contact object, and not the domain object itself. If this element is not provided or if the authorization information is invalid, server policy determines if the command is rejected or if response information will be returned to the client.

- ドメインオブジェクトに関連付けられた認証情報、またはドメインオブジェクトの登録者もしくは関連する連絡先に関連付けられた認証情報を含む、任意 (OPTIONAL) の <domain:authInfo> 要素。指定されたauthInfoがドメインオブジェクト自体ではなく登録者または連絡先オブジェクトに関連付けられている場合に限り、登録者または連絡先オブジェクトを識別するために任意 (OPTIONAL) の「roid」属性を使用しなければなりません (MUST)。この要素が提供されない場合、または認証情報が無効である場合、コマンドを拒否するかクライアントに応答情報を返すかはサーバポリシーによって決定されます。

Example <info> command without authorization information:

例<情報>許可情報なしのコマンド：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <info>
   C:      <domain:info
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name hosts="all">example.com</domain:name>
   C:      </domain:info>
   C:    </info>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

Example <info> command with authorization information:

承認情報を備えた例<情報>コマンド：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <info>
   C:      <domain:info
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name hosts="all">example.com</domain:name>
   C:        <domain:authInfo>
   C:          <domain:pw>2fooBAR</domain:pw>
   C:        </domain:authInfo>
   C:      </domain:info>
   C:    </info>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

When an <info> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:infData> element that identifies the domain namespace. Elements that are not OPTIONAL MUST be returned; OPTIONAL elements are returned based on client authorization and server policy. The <domain:infData> element contains the following child elements:

<info> コマンドが正常に処理された場合、EPP <resData> 要素にはドメイン名前空間を識別する小 <domain:infData> 要素が含まれていなければなりません (MUST)。任意 (OPTIONAL) でない要素は返さなければならず (MUST)、任意 (OPTIONAL) の要素はクライアントの権限およびサーバポリシーに基づいて返されます。<domain:infData> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object.

- A <ドメイン：名前>ドメインオブジェクトの完全に適格な名前を含む要素。

- A <domain:roid> element that contains the Repository Object IDentifier assigned to the domain object when the object was created.

- a <ドメイン：roid>オブジェクトが作成されたときにドメインオブジェクトに割り当てられたリポジトリオブジェクト識別子を含む要素。

- Zero or more OPTIONAL <domain:status> elements that contain the current status descriptors associated with the domain.

- ドメインに関連付けられた現在のステータス記述子を含む、0個以上の任意 (OPTIONAL) の <domain:status> 要素。

- If supported by the server, one OPTIONAL <domain:registrant> element and one or more OPTIONAL <domain:contact> elements that contain identifiers for the human or organizational social information objects associated with the domain object.

- サーバによってサポートされている場合、ドメインオブジェクトに関連付けられた個人または組織の社会情報オブジェクトの識別子を含む、1個の任意 (OPTIONAL) の <domain:registrant> 要素、および1個以上の任意 (OPTIONAL) の <domain:contact> 要素。

- An OPTIONAL <domain:ns> element that contains the fully qualified names of the delegated host objects or host attributes (name servers) associated with the domain object. See Section 1.1 for a description of the elements used to specify host objects or host attributes.

- ドメインオブジェクトに関連付けられた委任ホストオブジェクトまたはホスト属性（ネームサーバ）の完全修飾名を含む、任意 (OPTIONAL) の <domain:ns> 要素。ホストオブジェクトまたはホスト属性を指定するために使用される要素の説明については、セクション1.1を参照してください。

- Zero or more OPTIONAL <domain:host> elements that contain the fully qualified names of the subordinate host objects that exist under this superordinate domain object.

- この上位ドメインオブジェクトの下に存在する下位ホストオブジェクトの完全修飾名を含む、0個以上の任意 (OPTIONAL) の <domain:host> 要素。

- A <domain:clID> element that contains the identifier of the sponsoring client.

- A <ドメイン：clID>スポンサークライアントの識別子を含む要素。

- An OPTIONAL <domain:crID> element that contains the identifier of the client that created the domain object.

- ドメインオブジェクトを作成したクライアントの識別子を含む、任意 (OPTIONAL) の <domain:crID> 要素。

- An OPTIONAL <domain:crDate> element that contains the date and time of domain object creation.

- ドメインオブジェクトが作成された日時を含む、任意 (OPTIONAL) の <domain:crDate> 要素。

- An OPTIONAL <domain:exDate> element that contains the date and time identifying the end of the domain object's registration period.

- ドメインオブジェクトの登録期間の終了を識別する日時を含む、任意 (OPTIONAL) の <domain:exDate> 要素。

- An OPTIONAL <domain:upID> element that contains the identifier of the client that last updated the domain object. This element MUST NOT be present if the domain has never been modified.

- ドメインオブジェクトを最後に更新したクライアントの識別子を含む、任意 (OPTIONAL) の <domain:upID> 要素。ドメインが一度も変更されていない場合、この要素が存在してはなりません (MUST NOT)。

- An OPTIONAL <domain:upDate> element that contains the date and time of the most recent domain-object modification. This element MUST NOT be present if the domain object has never been modified.

- 最新のドメインオブジェクト変更の日時を含む、任意 (OPTIONAL) の <domain:upDate> 要素。ドメインオブジェクトが一度も変更されていない場合、この要素が存在してはなりません (MUST NOT)。

- An OPTIONAL <domain:trDate> element that contains the date and time of the most recent successful domain-object transfer. This element MUST NOT be provided if the domain object has never been transferred.

- 最新のドメインオブジェクト転送が成功した日時を含む、任意 (OPTIONAL) の <domain:trDate> 要素。ドメインオブジェクトが一度も転送されていない場合、この要素を提供してはなりません (MUST NOT)。

- An OPTIONAL <domain:authInfo> element that contains authorization information associated with the domain object. This element MUST only be returned if the querying client is the current sponsoring client or if the client supplied valid authorization information with the command.

- ドメインオブジェクトに関連付けられた認証情報を含む、任意 (OPTIONAL) の <domain:authInfo> 要素。この要素は、照会クライアントが現在のスポンサークライアントである場合、またはクライアントがコマンドとともに有効な認証情報を提供した場合にのみ返さなければなりません (MUST)。

Example <info> response for an authorized client:

承認されたクライアントの例<情報>応答：

   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:      <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>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>
   A server with a different information-return policy MAY provide less
   information in a response.

Example <info> response for an unauthorized client:

不正なクライアントの例<情報>応答：

   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:      <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:clID>ClientX</domain:clID>
   S:      </domain:infData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

An EPP error response MUST be returned if an <info> command cannot be processed for any reason.

何らかの理由で <info> コマンドを処理できない場合、EPPエラー応答を返さなければなりません (MUST)。

3.1.3. EPP <transfer> Query Command

3.1.3. EPP <Transfer>クエリコマンド

The EPP <transfer> command provides a query operation that allows a client to determine the real-time status of pending and completed transfer requests. In addition to the standard EPP command elements, the <transfer> command MUST contain an "op" attribute with value "query", and a <domain:transfer> element that identifies the domain namespace. The <domain:transfer> element contains the following child elements:

EPP <transfer> コマンドは、クライアントが保留中および完了した転送要求のリアルタイムステータスを判断できるようにする照会操作を提供します。標準的なEPPコマンド要素に加えて、<transfer> コマンドには値「query」を持つ「op」属性、およびドメイン名前空間を識別する <domain:transfer> 要素が含まれていなければなりません (MUST)。<domain:transfer> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object to be queried.

- a <ドメイン：名前>要素には、クエリになるドメインオブジェクトの完全に適格な名前が含まれています。

Example <transfer> query command:

例<転送>クエリコマンド：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <transfer op="query">
   C:      <domain:transfer
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:authInfo>
   C:          <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
   C:        </domain:authInfo>
   C:      </domain:transfer>
   C:    </transfer>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

When a <transfer> query command has been processed successfully, the EPP <resData> element MUST contain a child <domain:trnData> element that identifies the domain namespace. The <domain:trnData> element contains the following child elements:

<transfer> クエリコマンドが正常に処理された場合、EPP <resData> 要素にはドメイン名前空間を識別する小 <domain:trnData> 要素が含まれていなければなりません (MUST)。<domain:trnData> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object.

- A <ドメイン：名前>ドメインオブジェクトの完全に適格な名前を含む要素。

- A <domain:trStatus> element that contains the state of the most recent transfer request.

- a <ドメイン：trStatus>最新の転送要求の状態を含む要素。

- A <domain:reID> element that contains the identifier of the client that requested the object transfer.

- A <ドメイン：reID>オブジェクト転送を要求したクライアントの識別子を含む要素。

- A <domain:reDate> element that contains the date and time that the transfer was requested.

- A <ドメイン：reDate>転送が要求された日時を含む要素。

- A <domain:acID> element that contains the identifier of the client that SHOULD act upon a PENDING transfer request. For all other status types, the value identifies the client that took the indicated action.

- 保留中の転送要求に対して対応すべき (SHOULD) クライアントの識別子を含む <domain:acID> 要素。他のすべてのステータスタイプについて、この値は示されたアクションを実行したクライアントを識別します。

- A <domain:acDate> element that contains the date and time of a required or completed response. For a PENDING request, the value identifies the date and time by which a response is required before an automated response action will be taken by the server. For all other status types, the value identifies the date and time when the request was completed.

- A <ドメイン：acDate>要素は、必要または完了した応答の日付と時刻を含む要素です。保留中の要求の場合、値は、サーバーが自動化された応答アクションを実行する前に応答が必要な日時を識別します。他のすべてのステータスタイプについて、値はリクエストが完了した日付と時刻を識別します。

- An OPTIONAL <domain:exDate> element that contains the end of the domain object's validity period if the <transfer> command caused or causes a change in the validity period.

- <transfer> コマンドによって有効期間の変更が生じた場合、または生じる場合に、ドメインオブジェクトの有効期間の終了日時を含む、任意 (OPTIONAL) の <domain:exDate> 要素。

Example <transfer> query response:

例<転送>クエリ応答：

   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:      <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:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

An EPP error response MUST be returned if a <transfer> query command cannot be processed for any reason.

何らかの理由で <transfer> クエリコマンドを処理できない場合、EPPエラー応答を返さなければなりません (MUST)。

3.2. EPP Transform Commands

3.2. EPP変換コマンド

EPP provides five commands to transform domain objects: <create> to create an instance of a domain object, <delete> to delete an instance of a domain object, <renew> to extend the validity period of a domain object, <transfer> to manage domain object sponsorship changes, and <update> to change information associated with a domain object.

EPPは、ドメインオブジェクトを変換する5つのコマンドを提供します。<create>ドメインオブジェクトのインスタンスを作成します。<delete>ドメインオブジェクトのインスタンスを削除するには、ドメインオブジェクトの有効期間を拡張するには、<転送>ドメインオブジェクトのスポンサーシップの変更を管理し、<update>にしてドメインオブジェクトに関連付けられた情報を変更します。

Transform commands are typically processed and completed in real time. Server operators MAY receive and process transform commands but defer completing the requested action if human or third-party review is required before the requested action can be completed. In such situations the server MUST return a 1001 response code to the client to note that the command has been received and processed but that the requested action is pending. The server MUST also manage the status of the object that is the subject of the command to reflect the initiation and completion of the requested action. Once the action has been completed, all clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed. Other notification methods MAY be used in addition to the required service message.

変換コマンドは通常、リアルタイムで処理され完了します。ただし、要求されたアクションを完了する前に人間または第三者によるレビューが必要な場合、サーバ事業者はコマンドを受信して処理しつつも、要求されたアクションの完了を延期してもよい (MAY)。このような状況では、サーバはクライアントに1001応答コードを返し、コマンドが受信され処理されたものの要求されたアクションが保留中であることを通知しなければなりません (MUST)。サーバはまた、要求されたアクションの開始と完了を反映するために、コマンドの対象であるオブジェクトのステータスを管理しなければなりません (MUST)。アクションが完了した時点で、トランザクションに関与したすべてのクライアントに対し、アクションが完了したことおよびオブジェクトのステータスが変更されたことをサービスメッセージを使用して通知しなければなりません (MUST)。必須のサービスメッセージに加えて、他の通知方法を使用してもよい (MAY)。

Server operators SHOULD confirm that a client is authorized to perform a transform command on a given object. Any attempt to transform an object by an unauthorized client MUST be rejected, and the server MUST return a 2201 response code to the client to note that the client lacks privileges to execute the requested command.

サーバ事業者は、クライアントが所与のオブジェクトに対して変換コマンドを実行する権限を持っていることを確認すべきです (SHOULD)。権限のないクライアントによるオブジェクト変換の試みは拒否しなければならず (MUST)、サーバはクライアントに対して、要求されたコマンドを実行する特権が不足していることを示す2201応答コードを返さなければなりません (MUST)。

3.2.1. EPP <create> Command

3.2.1. epp <create>コマンド

The EPP <create> command provides a transform operation that allows a client to create a domain object. In addition to the standard EPP command elements, the <create> command MUST contain a <domain:create> element that identifies the domain namespace. The <domain:create> element contains the following child elements:

EPP <create> コマンドは、クライアントがドメインオブジェクトを作成できるようにする変換操作を提供します。標準的なEPPコマンド要素に加えて、<create> コマンドにはドメイン名前空間を識別する <domain:create> 要素が含まれていなければなりません (MUST)。<domain:create> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object to be created.

- A <ドメイン：名前>作成するドメインオブジェクトの完全に適格な名前を含む要素。

- An OPTIONAL <domain:period> element that contains the initial registration period of the domain object. A server MAY define a default initial registration period if not specified by the client.

- ドメインオブジェクトの初期登録期間を含む、任意 (OPTIONAL) の <domain:period> 要素。クライアントによって指定されていない場合、サーバはデフォルトの初期登録期間を定義してもよい (MAY)。

- An OPTIONAL <domain:registrant> element that contains the identifier for the human or organizational social information (contact) object to be associated with the domain object as the object registrant. This object identifier MUST be known to the server before the contact object can be associated with the domain object. The EPP mapping for contact objects is described in [RFC5733].

- オブジェクト登録者としてドメインオブジェクトに関連付けられる、個人または組織の社会情報（連絡先）オブジェクトの識別子を含む、任意 (OPTIONAL) の <domain:registrant> 要素。連絡先オブジェクトをドメインオブジェクトに関連付けるには、事前にこのオブジェクト識別子がサーバに認知されていなければなりません (MUST)。連絡先オブジェクトのEPPマッピングは [RFC5733] で説明されています。

- Zero or more OPTIONAL <domain:contact> elements that contain the identifiers for other contact objects to be associated with the domain object. Contact object identifiers MUST be known to the server before the contact object can be associated with the domain object.

- ドメインオブジェクトに関連付けられる他の連絡先オブジェクトの識別子を含む、0個以上の任意 (OPTIONAL) の <domain:contact> 要素。連絡先オブジェクトをドメインオブジェクトに関連付けるには、事前に連絡先オブジェクト識別子がサーバに認知されていなければなりません (MUST)。

- A <domain:authInfo> element that contains authorization information to be associated with the domain object. This mapping includes a password-based authentication mechanism, but the schema allows new mechanisms to be defined in new schemas.

- A <ドメイン：authInfo>ドメインオブジェクトに関連付けられる認証情報を含む要素。このマッピングにはパスワードベースの認証メカニズムが含まれていますが、スキーマにより新しいスキーマで新しいメカニズムを定義できます。

Example <create> command:

例<create>コマンド：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <create>
   C:      <domain:create
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:period unit="y">2</domain:period>
   C:        <domain:ns>
   C:          <domain:hostObj>ns1.example.net</domain:hostObj>
   C:          <domain:hostObj>ns2.example.net</domain:hostObj>
   C:        </domain:ns>
   C:        <domain:registrant>jd1234</domain:registrant>
   C:        <domain:contact type="admin">sh8013</domain:contact>
   C:        <domain:contact type="tech">sh8013</domain:contact>
   C:        <domain:authInfo>
   C:          <domain:pw>2fooBAR</domain:pw>
   C:        </domain:authInfo>
   C:      </domain:create>
   C:    </create>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

When a <create> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:creData> element that identifies the domain namespace. The <domain:creData> element contains the following child elements:

<create> コマンドが正常に処理された場合、EPP <resData> 要素にはドメイン名前空間を識別する小 <domain:creData> 要素が含まれていなければなりません (MUST)。<domain:creData> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object.

- A <ドメイン：名前>ドメインオブジェクトの完全に適格な名前を含む要素。

- A <domain:crDate> element that contains the date and time of domain object creation.

- a <ドメイン：crDate>ドメインオブジェクト作成の日付と時刻を含む要素。

- An OPTIONAL <domain:exDate> element that contains the date and time identifying the end of the domain object's registration period.

- ドメインオブジェクトの登録期間の終了を識別する日時を含む、任意 (OPTIONAL) の <domain:exDate> 要素。

Example <create> response:

例<create>応答：

   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:      <domain:creData
   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:name>example.com</domain:name>
   S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
   S:        <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate>
   S:      </domain:creData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

An EPP error response MUST be returned if a <create> command cannot be processed for any reason.

何らかの理由で <create> コマンドを処理できない場合、EPPエラー応答を返さなければなりません (MUST)。

3.2.2. EPP <delete> Command

3.2.2. epp <delete>コマンド

The EPP <delete> command provides a transform operation that allows a client to delete a domain object. In addition to the standard EPP command elements, the <delete> command MUST contain a <domain:delete> element that identifies the domain namespace. The <domain:delete> element contains the following child elements:

EPP <delete> コマンドは、クライアントがドメインオブジェクトを削除できるようにする変換操作を提供します。標準的なEPPコマンド要素に加えて、<delete> コマンドにはドメイン名前空間を識別する <domain:delete> 要素が含まれていなければなりません (MUST)。<domain:delete> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object to be deleted.

- A <ドメイン：名前>削除するドメインオブジェクトの完全に適格な名前を含む要素。

A domain object SHOULD NOT be deleted if subordinate host objects are associated with the domain object. For example, if domain "example.com" exists and host object "ns1.example.com" also exists, then domain "example.com" SHOULD NOT be deleted until host "ns1.example.com" has either been deleted or renamed to exist in a different superordinate domain. A server SHOULD notify clients that object relationships exist by sending a 2305 error response code when a <delete> command is attempted and fails due to existing object relationships. Delegated and subordinate host objects associated with a domain object can be determined using the <info> query command for the domain object.

下位ホストオブジェクトがドメインオブジェクトに関連付けられている場合、そのドメインオブジェクトを削除すべきではありません (SHOULD NOT)。例えば、ドメイン「example.com」が存在し、ホストオブジェクト「ns1.example.com」も存在する場合、ホスト「ns1.example.com」が削除されるか別の上位ドメインに存在するように名前変更されるまでは、ドメイン「example.com」を削除すべきではありません (SHOULD NOT)。<delete> コマンドが試行され既存のオブジェクト関係のために失敗した場合、サーバは2305エラー応答コードを送信することにより、オブジェクト関係が存在することをクライアントに通知すべきです (SHOULD)。ドメインオブジェクトに関連付けられた委任ホストオブジェクトおよび下位ホストオブジェクトは、ドメインオブジェクトに対する <info> クエリコマンドを使用して判断できます。

Example <delete> command:

例<delete>コマンド：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <delete>
   C:      <domain:delete
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:      </domain:delete>
   C:    </delete>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

When a <delete> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.

<delete> コマンドが正常に処理された場合、サーバは <resData> 要素を含まないEPP応答で応答しなければなりません (MUST)。

Example <delete> response:

例<delete>応答：

   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:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

An EPP error response MUST be returned if a <delete> command cannot be processed for any reason.

何らかの理由で <delete> コマンドを処理できない場合、EPPエラー応答を返さなければなりません (MUST)。

3.2.3. EPP <renew> Command

3.2.3. epp <neled>コマンド

The EPP <renew> command provides a transform operation that allows a client to extend the validity period of a domain object. In addition to the standard EPP command elements, the <renew> command MUST contain a <domain:renew> element that identifies the domain namespace. The <domain:renew> element contains the following child elements:

EPP <renew> コマンドは、クライアントがドメインオブジェクトの有効期間を延長できるようにする変換操作を提供します。標準的なEPPコマンド要素に加えて、<renew> コマンドにはドメイン名前空間を識別する <domain:renew> 要素が含まれていなければなりません (MUST)。<domain:renew> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object whose validity period is to be extended.

- A <ドメイン：名前>有効期間が拡張されるドメインオブジェクトの完全に適格な名前を含む要素。

- A <domain:curExpDate> element that contains the date on which the current validity period ends. This value ensures that repeated <renew> commands do not result in multiple, unanticipated successful renewals.

- A <ドメイン：curExpDate>現在の有効期間が終了する日付を含む要素。この値により、繰り返される<lenew>コマンドが複数の予期せぬ成功した更新につながることができません。

- An OPTIONAL <domain:period> element that contains the number of units to be added to the registration period of the domain object. The number of units available MAY be subject to limits imposed by the server.

- ドメインオブジェクトの登録期間に追加する単位数を含む、任意 (OPTIONAL) の <domain:period> 要素。利用可能な単位数は、サーバによって課される制限に従ってもよい (MAY)。

Example <renew> command:

例<neled>コマンド：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <renew>
   C:      <domain:renew
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:curExpDate>2000-04-03</domain:curExpDate>
   C:        <domain:period unit="y">5</domain:period>
   C:      </domain:renew>
   C:    </renew>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

When a <renew> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:renData> element that identifies the domain namespace. The <domain:renData> element contains the following child elements:

<renew> コマンドが正常に処理された場合、EPP <resData> 要素にはドメイン名前空間を識別する小 <domain:renData> 要素が含まれていなければなりません (MUST)。<domain:renData> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object.

- A <ドメイン：名前>ドメインオブジェクトの完全に適格な名前を含む要素。

- An OPTIONAL <domain:exDate> element that contains the date and time identifying the end of the domain object's registration period.

- ドメインオブジェクトの登録期間の終了を識別する日時を含む、任意 (OPTIONAL) の <domain:exDate> 要素。

Example <renew> response:

例<更新>応答：

   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:      <domain:renData
   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:name>example.com</domain:name>
   S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
   S:      </domain:renData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

An EPP error response MUST be returned if a <renew> command cannot be processed for any reason.

何らかの理由で <renew> コマンドを処理できない場合、EPPエラー応答を返さなければなりません (MUST)。

3.2.4. EPP <transfer> Command

3.2.4. EPP <Transfer>コマンド

The EPP <transfer> command provides a transform operation that allows a client to manage requests to transfer the sponsorship of a domain object. In addition to the standard EPP command elements, the <transfer> command MUST contain a <domain:transfer> element that identifies the domain namespace. The <domain:transfer> element contains the following child elements:

EPP <transfer> コマンドは、クライアントがドメインオブジェクトのスポンサーシップを転送する要求を管理できるようにする変換操作を提供します。標準的なEPPコマンド要素に加えて、<transfer> コマンドにはドメイン名前空間を識別する <domain:transfer> 要素が含まれていなければなりません (MUST)。<domain:transfer> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object for which a transfer request is to be created, approved, rejected, or cancelled.

- A <ドメイン：名前>転送要求が作成、承認、拒否、またはキャンセルされるドメインオブジェクトの完全に適格な名前を含む要素。

- An OPTIONAL <domain:period> element that contains the number of units to be added to the registration period of the domain object at completion of the transfer process. This element can only be used when a transfer is requested, and it MUST be ignored if used otherwise. The number of units available MAY be subject to limits imposed by the server.

- 転送プロセスの完了時にドメインオブジェクトの登録期間に追加する単位数を含む、任意 (OPTIONAL) の <domain:period> 要素。この要素は転送が要求された場合にのみ使用でき、それ以外で使用された場合は無視しなければなりません (MUST)。利用可能な単位数は、サーバによって課される制限に従ってもよい (MAY)。

- A <domain:authInfo> element that contains authorization information associated with the domain object or authorization information associated with the domain object's registrant or associated contacts. An OPTIONAL "roid" attribute MUST be used to identify the registrant or contact object if and only if the given authInfo is associated with a registrant or contact object, and not the domain object itself.

- ドメインオブジェクトに関連付けられた認証情報、またはドメインオブジェクトの登録者もしくは関連する連絡先に関連付けられた認証情報を含む <domain:authInfo> 要素。指定されたauthInfoがドメインオブジェクト自体ではなく登録者または連絡先オブジェクトに関連付けられている場合に限り、登録者または連絡先オブジェクトを識別するために任意 (OPTIONAL) の「roid」属性を使用しなければなりません (MUST)。

Every EPP <transfer> command MUST contain an "op" attribute that identifies the transfer operation to be performed. Valid values, definitions, and authorizations for all attribute values are defined in [RFC5730].

すべてのEPP <transfer> コマンドには、実行すべき転送操作を識別する「op」属性が含まれていなければなりません (MUST)。すべての属性値に対する有効な値、定義、および権限は [RFC5730] で定義されています。

Transfer of a domain object MUST implicitly transfer all host objects that are subordinate to the domain object. For example, if domain object "example.com" is transferred and host object "ns1.example.com" exists, the host object MUST be transferred as part of the "example.com" transfer process. Host objects that are subject to transfer when transferring a domain object are listed in the response to an EPP <info> command performed on the domain object.

ドメインオブジェクトの転送は、そのドメインオブジェクトに従属するすべてのホストオブジェクトを暗黙的に転送しなければなりません (MUST)。例えば、ドメインオブジェクト「example.com」が転送され、ホストオブジェクト「ns1.example.com」が存在する場合、そのホストオブジェクトは「example.com」の転送プロセスの一環として転送しなければなりません (MUST)。ドメインオブジェクトの転送時に転送対象となるホストオブジェクトは、そのドメインオブジェクトに対して実行されたEPP <info> コマンドへの応答に一覧表示されます。

Example <transfer> request command:

例<転送>要求コマンド：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <transfer op="request">
   C:      <domain:transfer
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:period unit="y">1</domain:period>
   C:        <domain:authInfo>
   C:          <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
   C:        </domain:authInfo>
   C:      </domain:transfer>
   C:    </transfer>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

When a <transfer> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:trnData> element that identifies the domain namespace. The <domain:trnData> element contains the same child elements defined for a transfer query response.

<transfer> コマンドが正常に処理された場合、EPP <resData> 要素にはドメイン名前空間を識別する小 <domain:trnData> 要素が含まれていなければなりません (MUST)。<domain:trnData> 要素には、転送クエリ応答に対して定義されているものと同じ小要素が含まれます。

Example <transfer> response:

例<転送>応答：

   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="1001">
   S:      <msg>Command completed successfully; action pending</msg>
   S:    </result>
   S:    <resData>
   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-08T22:00:00.0Z</domain:reDate>
   S:        <domain:acID>ClientY</domain:acID>
   S:        <domain:acDate>2000-06-13T22:00:00.0Z</domain:acDate>
   S:        <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
   S:      </domain:trnData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

An EPP error response MUST be returned if a <transfer> command can not be processed for any reason.

何らかの理由で <transfer> コマンドを処理できない場合、EPPエラー応答を返さなければなりません (MUST)。

3.2.5. EPP <update> Command

3.2.5. epp <update>コマンド

The EPP <update> command provides a transform operation that allows a client to modify the attributes of a domain object. In addition to the standard EPP command elements, the <update> command MUST contain a <domain:update> element that identifies the domain namespace. The <domain:update> element contains the following child elements:

EPP <update> コマンドは、クライアントがドメインオブジェクトの属性を変更できるようにする変換操作を提供します。標準的なEPPコマンド要素に加えて、<update> コマンドにはドメイン名前空間を識別する <domain:update> 要素が含まれていなければなりません (MUST)。<domain:update> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object to be updated.

- A <ドメイン：名前>更新するドメインオブジェクトの完全に適格な名前を含む要素。

- An OPTIONAL <domain:add> element that contains attribute values to be added to the object.

- オブジェクトに追加する属性値を含む、任意 (OPTIONAL) の <domain:add> 要素。

- An OPTIONAL <domain:rem> element that contains attribute values to be removed from the object.

- オブジェクトから削除する属性値を含む、任意 (OPTIONAL) の <domain:rem> 要素。

- An OPTIONAL <domain:chg> element that contains object attribute values to be changed.

- 変更するオブジェクト属性値を含む、任意 (OPTIONAL) の <domain:chg> 要素。

At least one <domain:add>, <domain:rem>, or <domain:chg> element MUST be provided if the command is not being extended. All of these elements MAY be omitted if an <update> extension is present. The <domain:add> and <domain:rem> elements contain the following child elements:

コマンドが拡張されていない場合、少なくとも1つの <domain:add>、<domain:rem>、または <domain:chg> 要素を提供しなければなりません (MUST)。<update> 拡張が存在する場合、これらの要素をすべて省略してもよい (MAY)。<domain:add> および <domain:rem> 要素には、以下の小要素が含まれます。

- An OPTIONAL <domain:ns> element that contains the fully qualified names of the delegated host objects or host attributes (name servers) associated with the domain object to provide resolution services for the domain; see Section 1.1 for a description of the elements used to specify host objects or host attributes. A host object MUST be known to the server before the host object can be associated with a domain object. If host attributes are used to specify name servers, note that IP address elements are not needed to identify a name server that is being removed. IP address elements can safely be absent or ignored in this situation.

- ドメインの名前解決サービスを提供するためにドメインオブジェクトに関連付けられた、委任ホストオブジェクトまたはホスト属性（ネームサーバ）の完全修飾名を含む、任意 (OPTIONAL) の <domain:ns> 要素。ホストオブジェクトまたはホスト属性を指定するために使用される要素の説明については、セクション1.1を参照してください。ホストオブジェクトをドメインオブジェクトに関連付けるには、事前にそのホストオブジェクトがサーバに認知されていなければなりません (MUST)。ネームサーバの指定にホスト属性が使用されている場合、削除対象のネームサーバを識別するためにIPアドレス要素は不要であることに注意してください。この状況では、IPアドレス要素が存在しないか無視されても問題ありません。

- Zero or more <domain:contact> elements that contain the identifiers for contact objects to be associated with or removed from the domain object. Contact object identifiers MUST be known to the server before the contact object can be associated with the domain object.

- ドメインオブジェクトに関連付ける、またはドメインオブジェクトから削除する連絡先オブジェクトの識別子を含む、0個以上の <domain:contact> 要素。連絡先オブジェクトをドメインオブジェクトに関連付けるには、事前に連絡先オブジェクト識別子がサーバに認知されていなければなりません (MUST)。

- Zero or more <domain:status> elements that contain status values to be applied to or removed from the object. When specifying a value to be removed, only the attribute value is significant; element text is not required to match a value for removal.

- ゼロ以上<ドメイン：ステータス>オブジェクトに適用または削除されるステータス値を含む要素。削除する値を指定する場合、属性値のみが重要です。削除の値を一致させるために要素テキストは必要ありません。

A <domain:chg> element contains the following child elements:

a <ドメイン：chg>要素には、次の子要素が含まれています。

- A <domain:registrant> element that contains the identifier for the human or organizational social information (contact) object to be associated with the domain object as the object registrant. This object identifier MUST be known to the server before the contact object can be associated with the domain object. An empty element can be used to remove registrant information.

- オブジェクト登録者としてドメインオブジェクトに関連付けられる、個人または組織の社会情報（連絡先）オブジェクトの識別子を含む <domain:registrant> 要素。連絡先オブジェクトをドメインオブジェクトに関連付けるには、事前にこのオブジェクト識別子がサーバに認知されていなければなりません (MUST)。登録者情報を削除するために空の要素を使用できます。

- A <domain:authInfo> element that contains authorization information associated with the domain object. This mapping includes a password-based authentication mechanism, but the schema allows new mechanisms to be defined in new schemas. A <domain: null> element can be used within the <domain:authInfo> element to remove authorization information.

- a <ドメイン：authInfo>ドメインオブジェクトに関連付けられた認証情報を含む要素。このマッピングにはパスワードベースの認証メカニズムが含まれていますが、スキーマにより新しいスキーマで新しいメカニズムを定義できます。a <ドメイン：null>要素を<domain：authInfo>要素内で使用して、認証情報を削除できます。

Example <update> command:

例<update>コマンド：

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <update>
   C:      <domain:update
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:add>
   C:          <domain:ns>
   C:            <domain:hostObj>ns2.example.com</domain:hostObj>
   C:          </domain:ns>
   C:          <domain:contact type="tech">mak21</domain:contact>
   C:          <domain:status s="clientHold"
   C:           lang="en">Payment overdue.</domain:status>
   C:        </domain:add>
   C:        <domain:rem>
   C:          <domain:ns>
   C:            <domain:hostObj>ns1.example.com</domain:hostObj>
   C:          </domain:ns>
   C:          <domain:contact type="tech">sh8013</domain:contact>
   C:          <domain:status s="clientUpdateProhibited"/>
   C:        </domain:rem>
   C:        <domain:chg>
   C:          <domain:registrant>sh8013</domain:registrant>
   C:          <domain:authInfo>
   C:            <domain:pw>2BARfoo</domain:pw>
   C:          </domain:authInfo>
   C:        </domain:chg>
   C:      </domain:update>
   C:    </update>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

When an <update> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.

<update> コマンドが正常に処理された場合、サーバは <resData> 要素を含まないEPP応答で応答しなければなりません (MUST)。

Example <update> response:

例<update>応答：

   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:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

An EPP error response MUST be returned if an <update> command cannot be processed for any reason.

何らかの理由で <update> コマンドを処理できない場合、EPPエラー応答を返さなければなりません (MUST)。

3.3. Offline Review of Requested Actions

3.3. 要求されたアクションのオフラインレビュー

Commands are processed by a server in the order they are received from a client. Though an immediate response confirming receipt and processing of the command is produced by the server, a server operator MAY perform an offline review of requested transform commands before completing the requested action. In such situations, the response from the server MUST clearly note that the transform command has been received and processed but that the requested action is pending. The status of the corresponding object MUST clearly reflect processing of the pending action. The server MUST notify the client when offline processing of the action has been completed.

コマンドは、クライアントから受信された順序でサーバによって処理されます。コマンドの受信および処理を確認する即時応答がサーバによって生成されますが、要求されたアクションを完了する前に、サーバ事業者は要求された変換コマンドのオフラインレビューを実行してもよい (MAY)。このような状況では、サーバからの応答は、変換コマンドが受信され処理されたものの要求されたアクションが保留中であることを明確に示さなければなりません (MUST)。対応するオブジェクトのステータスは、保留中のアクションの処理中であることを明確に反映しなければなりません (MUST)。サーバは、アクションのオフライン処理が完了した時点でクライアントに通知しなければなりません (MUST)。

Examples describing a <create> command that requires offline review are included here. Note the result code and message returned in response to the <create> command.

オフラインのレビューを必要とする<create>コマンドを説明する例は、ここに含まれています。<create>コマンドに応じて返された結果コードとメッセージに注意してください。

   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="1001">
   S:      <msg>Command completed successfully; action pending</msg>
   S:    </result>
   S:    <resData>
   S:      <domain:creData
   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:name>example.com</domain:name>
   S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
   S:        <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate>
   S:      </domain:creData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>
   The status of the domain object after returning this response MUST
   include "pendingCreate".  The server operator reviews the request
   offline, and informs the client of the outcome of the review either
   by queuing a service message for retrieval via the <poll> command or
   by using an out-of-band mechanism to inform the client of the
   request.

The service message MUST contain text that describes the notification in the child <msg> element of the response <msgQ> element. In addition, the EPP <resData> element MUST contain a child <domain: panData> element that identifies the domain namespace. The <domain: panData> element contains the following child elements:

サービスメッセージには、応答 <msgQ> 要素の小 <msg> 要素に通知内容を説明するテキストが含まれていなければなりません (MUST)。さらに、EPP <resData> 要素にはドメイン名前空間を識別する小 <domain:panData> 要素が含まれていなければなりません (MUST)。<domain:panData> 要素には、以下の小要素が含まれます。

- A <domain:name> element that contains the fully qualified name of the domain object. The <domain:name> element contains a REQUIRED "paResult" attribute. A positive boolean value indicates that the request has been approved and completed. A negative boolean value indicates that the request has been denied and the requested action has not been taken.

- ドメインオブジェクトの完全修飾名を含む <domain:name> 要素。<domain:name> 要素には、必須 (REQUIRED) の「paResult」属性が含まれます。正の真偽値（true）は要求が承認され完了したことを示します。負の真偽値（false）は要求が拒否され要求されたアクションが実行されなかったことを示します。

- A <domain:paTRID> element that contains the client transaction identifier and server transaction identifier returned with the original response to process the command. The client transaction identifier is OPTIONAL and will only be returned if the client provided an identifier with the original <create> command.

- コマンドを処理するための元の応答とともに返されたクライアントトランザクション識別子およびサーバトランザクション識別子を含む <domain:paTRID> 要素。クライアントトランザクション識別子は任意 (OPTIONAL) であり、クライアントが元の <create> コマンドで識別子を提供した場合にのみ返されます。

- A <domain:paDate> element that contains the date and time describing when review of the requested action was completed.

- A <ドメイン：paDate>要求されたアクションのレビューが完了した時期を説明する日付と時刻を含む要素。

Example "review completed" service message:

例「完了した」サービスメッセージの例：

   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:    </result>
   S:    <msgQ count="5" id="12345">
   S:      <qDate>1999-04-04T22:01:00.0Z</qDate>
   S:      <msg>Pending action completed successfully.</msg>
   S:    </msgQ>
   S:    <resData>
   S:      <domain:panData
   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   S:        <domain:name paResult="1">example.com</domain:name>
   S:        <domain:paTRID>
   S:          <clTRID>ABC-12345</clTRID>
   S:          <svTRID>54321-XYZ</svTRID>
   S:        </domain:paTRID>
   S:        <domain:paDate>1999-04-04T22:00:00.0Z</domain:paDate>
   S:      </domain:panData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>BCD-23456</clTRID>
   S:      <svTRID>65432-WXY</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

4. Formal Syntax

4. 正式な構文

An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.

EPPオブジェクトマッピングは、XMLスキーマ表記で指定されています。ここに示されている正式な構文は、EPP XMLインスタンスの自動検証に適したオブジェクトマッピングの完全なスキーマ表現です。開始タグとエンドタグはスキーマの一部ではありません。それらは、URI登録目的でスキーマの開始と終了に注意するために使用されます。

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

次の条件が満たされていれば、変更を加えた、または修正なしの有無にかかわらず、ソースおよびバイナリ形式での再配布と使用が許可されます。

o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

o ソースコードの再配布は、上記の著作権通知、この条件リスト、および次の免責事項を保持する必要があります。

o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

o バイナリ形式の再配布は、上記の著作権通知、この条件リスト、および分布に提供されたドキュメントおよび/またはその他の資料の次の免責事項を再現する必要があります。

o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.

o インターネット社会、IETFまたはIETFトラストの名前も、特定の貢献者の名前も、特定の事前の書面による許可なしにこのソフトウェアから派生した製品を支持または宣伝するために使用できません。

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

本ソフトウェアは著作権者および貢献者によって「現状のまま」提供されており、商品性および特定目的への適合性の黙示の保証を含め、明示的または黙示的ないかなる保証も否認されます。いかなる場合においても、著作権者または貢献者は、理由の如何を問わず、また契約、厳格責任、不法行為（過失またはその他を含む）を問わずいかなる責任論に基づくものであれ、本ソフトウェアの使用から生じるいかなる直接損害、間接損害、付随的損害、特別損害、懲罰的損害、または派生的損害（代替商品またはサービスの調達、使用、データ、または利益の損失、あるいは業務の中断を含みますが、これらに限定されません）に対しても、たとえそのような損害の可能性を事前に知らされていたとしても、一切責任を負わないものとします (SHALL)。

   BEGIN
   <?xml version="1.0" encoding="UTF-8"?>

   <schema targetNamespace="urn:ietf:params:xml:ns:domain-1.0"
        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
        xmlns:host="urn:ietf:params:xml:ns:host-1.0"
        xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
        xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
        xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">

   <!--
   Import common element types.
   -->
   <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
   <import namespace="urn:ietf:params:xml:ns:epp-1.0"/>
   <import namespace="urn:ietf:params:xml:ns:host-1.0"/>

   <annotation>
    <documentation>
      Extensible Provisioning Protocol v1.0
      domain provisioning schema.
    </documentation>
   </annotation>

   <!--
   Child elements found in EPP commands.
   -->
   <element name="check" type="domain:mNameType"/>
   <element name="create" type="domain:createType"/>
   <element name="delete" type="domain:sNameType"/>
   <element name="info" type="domain:infoType"/>
   <element name="renew" type="domain:renewType"/>
   <element name="transfer" type="domain:transferType"/>
   <element name="update" type="domain:updateType"/>
   <!--
   Child elements of the <create> command.
   -->
   <complexType name="createType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
      <element name="period" type="domain:periodType"
       minOccurs="0"/>
      <element name="ns" type="domain:nsType"

       minOccurs="0"/>
      <element name="registrant" type="eppcom:clIDType"
       minOccurs="0"/>
      <element name="contact" type="domain:contactType"
       minOccurs="0" maxOccurs="unbounded"/>
      <element name="authInfo" type="domain:authInfoType"/>
    </sequence>
   </complexType>

   <complexType name="periodType">
    <simpleContent>
      <extension base="domain:pLimitType">
        <attribute name="unit" type="domain:pUnitType"
         use="required"/>
      </extension>
    </simpleContent>
   </complexType>

   <simpleType name="pLimitType">
    <restriction base="unsignedShort">
      <minInclusive value="1"/>
      <maxInclusive value="99"/>
    </restriction>
   </simpleType>

   <simpleType name="pUnitType">
    <restriction base="token">
      <enumeration value="y"/>
      <enumeration value="m"/>
    </restriction>
   </simpleType>

   <complexType name="nsType">
    <choice>
      <element name="hostObj" type="eppcom:labelType"
       maxOccurs="unbounded"/>
      <element name="hostAttr" type="domain:hostAttrType"
       maxOccurs="unbounded"/>
    </choice>
   </complexType>
   <!--
   Name servers are either host objects or attributes.
   -->

   <complexType name="hostAttrType">
    <sequence>
      <element name="hostName" type="eppcom:labelType"/>
      <element name="hostAddr" type="host:addrType"

       minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
   </complexType>
   <!--
   If attributes, addresses are optional and follow the
   structure defined in the host mapping.
   -->

   <complexType name="contactType">
    <simpleContent>
      <extension base="eppcom:clIDType">
        <attribute name="type" type="domain:contactAttrType"/>
      </extension>
    </simpleContent>
   </complexType>

   <simpleType name="contactAttrType">
    <restriction base="token">
      <enumeration value="admin"/>
      <enumeration value="billing"/>
      <enumeration value="tech"/>
    </restriction>
   </simpleType>

   <complexType name="authInfoType">
    <choice>
      <element name="pw" type="eppcom:pwAuthInfoType"/>
      <element name="ext" type="eppcom:extAuthInfoType"/>
    </choice>
   </complexType>

   <!--
   Child element of commands that require a single name.
   -->
   <complexType name="sNameType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
    </sequence>
   </complexType>
   <!--
   Child element of commands that accept multiple names.
   -->
   <complexType name="mNameType">
    <sequence>
      <element name="name" type="eppcom:labelType"
       maxOccurs="unbounded"/>
    </sequence>
   </complexType>

   <!--
   Child elements of the <info> command.
   -->
   <complexType name="infoType">
    <sequence>
      <element name="name" type="domain:infoNameType"/>
      <element name="authInfo" type="domain:authInfoType"
       minOccurs="0"/>
    </sequence>
   </complexType>

   <complexType name="infoNameType">
    <simpleContent>
      <extension base = "eppcom:labelType">
        <attribute name="hosts" type="domain:hostsType"
         default="all"/>
      </extension>
    </simpleContent>
   </complexType>

   <simpleType name="hostsType">
    <restriction base="token">
      <enumeration value="all"/>
      <enumeration value="del"/>
      <enumeration value="none"/>
      <enumeration value="sub"/>
    </restriction>
   </simpleType>

   <!--
   Child elements of the <renew> command.
   -->
   <complexType name="renewType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
      <element name="curExpDate" type="date"/>
      <element name="period" type="domain:periodType"
       minOccurs="0"/>
    </sequence>
   </complexType>

   <!--
   Child elements of the <transfer> command.
   -->
   <complexType name="transferType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
      <element name="period" type="domain:periodType"

       minOccurs="0"/>
      <element name="authInfo" type="domain:authInfoType"
       minOccurs="0"/>
    </sequence>
   </complexType>

   <!--
   Child elements of the <update> command.
   -->
   <complexType name="updateType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
      <element name="add" type="domain:addRemType"
       minOccurs="0"/>
      <element name="rem" type="domain:addRemType"
       minOccurs="0"/>
      <element name="chg" type="domain:chgType"
       minOccurs="0"/>
    </sequence>
   </complexType>

   <!--
   Data elements that can be added or removed.
   -->
   <complexType name="addRemType">
    <sequence>
      <element name="ns" type="domain:nsType"
       minOccurs="0"/>
      <element name="contact" type="domain:contactType"
       minOccurs="0" maxOccurs="unbounded"/>
      <element name="status" type="domain:statusType"
       minOccurs="0" maxOccurs="11"/>
    </sequence>
   </complexType>

   <!--
   Data elements that can be changed.
   -->
   <complexType name="chgType">
    <sequence>
      <element name="registrant" type="domain:clIDChgType"
       minOccurs="0"/>
      <element name="authInfo" type="domain:authInfoChgType"
       minOccurs="0"/>
    </sequence>
   </complexType>

   <!--
   Allow the registrant value to be nullified by changing the
   minLength restriction to "0".
   -->
   <simpleType name="clIDChgType">
    <restriction base="token">
      <minLength value="0"/>
      <maxLength value="16"/>
    </restriction>
   </simpleType>

   <!--
   Allow the authInfo value to be nullified by including an
   empty element within the choice.
   -->
   <complexType name="authInfoChgType">
    <choice>
      <element name="pw" type="eppcom:pwAuthInfoType"/>
      <element name="ext" type="eppcom:extAuthInfoType"/>
      <element name="null"/>
    </choice>
   </complexType>

   <!--
   Child response elements.
   -->
   <element name="chkData" type="domain:chkDataType"/>
   <element name="creData" type="domain:creDataType"/>
   <element name="infData" type="domain:infDataType"/>
   <element name="panData" type="domain:panDataType"/>
   <element name="renData" type="domain:renDataType"/>
   <element name="trnData" type="domain:trnDataType"/>

   <!--
   <check> response elements.
   -->
   <complexType name="chkDataType">
    <sequence>
      <element name="cd" type="domain:checkType"
       maxOccurs="unbounded"/>
    </sequence>
   </complexType>

   <complexType name="checkType">
    <sequence>
      <element name="name" type="domain:checkNameType"/>
      <element name="reason" type="eppcom:reasonType"
       minOccurs="0"/>

    </sequence>
   </complexType>

   <complexType name="checkNameType">
    <simpleContent>
      <extension base="eppcom:labelType">
        <attribute name="avail" type="boolean"
         use="required"/>
      </extension>
    </simpleContent>
   </complexType>

   <!--
   <create> response elements.
   -->
   <complexType name="creDataType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
      <element name="crDate" type="dateTime"/>
      <element name="exDate" type="dateTime"
       minOccurs="0"/>
    </sequence>
   </complexType>

   <!--
   <info> response elements.
   -->

   <complexType name="infDataType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
      <element name="roid" type="eppcom:roidType"/>
      <element name="status" type="domain:statusType"
       minOccurs="0" maxOccurs="11"/>
      <element name="registrant" type="eppcom:clIDType"
       minOccurs="0"/>
      <element name="contact" type="domain:contactType"
       minOccurs="0" maxOccurs="unbounded"/>
      <element name="ns" type="domain:nsType"
       minOccurs="0"/>
      <element name="host" type="eppcom:labelType"
       minOccurs="0" maxOccurs="unbounded"/>
      <element name="clID" type="eppcom:clIDType"/>
      <element name="crID" type="eppcom:clIDType"
       minOccurs="0"/>
      <element name="crDate" type="dateTime"
       minOccurs="0"/>
      <element name="upID" type="eppcom:clIDType"

       minOccurs="0"/>
      <element name="upDate" type="dateTime"
       minOccurs="0"/>
      <element name="exDate" type="dateTime"
       minOccurs="0"/>
      <element name="trDate" type="dateTime"
       minOccurs="0"/>
      <element name="authInfo" type="domain:authInfoType"
       minOccurs="0"/>
    </sequence>
   </complexType>

   <!--
   Status is a combination of attributes and an optional
   human-readable message that may be expressed in languages other
   than English.
   -->
   <complexType name="statusType">
    <simpleContent>
      <extension base="normalizedString">
        <attribute name="s" type="domain:statusValueType"
         use="required"/>
        <attribute name="lang" type="language"
         default="en"/>
      </extension>
    </simpleContent>
   </complexType>

   <simpleType name="statusValueType">
    <restriction base="token">
      <enumeration value="clientDeleteProhibited"/>
      <enumeration value="clientHold"/>
      <enumeration value="clientRenewProhibited"/>
      <enumeration value="clientTransferProhibited"/>
      <enumeration value="clientUpdateProhibited"/>
      <enumeration value="inactive"/>
      <enumeration value="ok"/>
      <enumeration value="pendingCreate"/>
      <enumeration value="pendingDelete"/>
      <enumeration value="pendingRenew"/>
      <enumeration value="pendingTransfer"/>
      <enumeration value="pendingUpdate"/>
      <enumeration value="serverDeleteProhibited"/>
      <enumeration value="serverHold"/>
      <enumeration value="serverRenewProhibited"/>
      <enumeration value="serverTransferProhibited"/>
      <enumeration value="serverUpdateProhibited"/>
    </restriction>

</simpleType>

   <!--
   Pending action notification response elements.
   -->
   <complexType name="panDataType">
    <sequence>
      <element name="name" type="domain:paNameType"/>
      <element name="paTRID" type="epp:trIDType"/>
      <element name="paDate" type="dateTime"/>
    </sequence>
   </complexType>

   <complexType name="paNameType">
    <simpleContent>
      <extension base="eppcom:labelType">
        <attribute name="paResult" type="boolean"
         use="required"/>
      </extension>
    </simpleContent>
   </complexType>

   <!--
   <renew> response elements.
   -->
   <complexType name="renDataType">
   <sequence>
    <element name="name" type="eppcom:labelType"/>
    <element name="exDate" type="dateTime"
     minOccurs="0"/>
   </sequence>
   </complexType>

   <!--
   <transfer> response elements.
   -->
   <complexType name="trnDataType">
   <sequence>
    <element name="name" type="eppcom:labelType"/>
    <element name="trStatus" type="eppcom:trStatusType"/>
    <element name="reID" type="eppcom:clIDType"/>
    <element name="reDate" type="dateTime"/>
    <element name="acID" type="eppcom:clIDType"/>
    <element name="acDate" type="dateTime"/>
    <element name="exDate" type="dateTime"
     minOccurs="0"/>
   </sequence>
   </complexType>

</schema> END

<！ - スキーマの終わり。 - > </schema> end

5. Internationalization Considerations

5. 国際化の考慮事項

EPP is represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists.

EPPはXMLで表現され、Unicode文字セットおよびUTF-8を含むそのよりコンパクトな表現を使用した情報エンコーディングのネイティブサポートを提供します。適合するXMLプロセッサは、UTF-8とUTF-16の両方を認識します [RFC2781]。XMLには <?xml?> 宣言内の「encoding」属性を使用して他の文字エンコーディングを識別し使用する規定が含まれていますが、パーサーのエンコーディングサポートの非互換性が存在する環境ではUTF-8の使用が推奨されます (RECOMMENDED)。

All date-time values presented via EPP MUST be expressed in Universal Coordinated Time using the Gregorian calendar. XML Schema allows use of time zone identifiers to indicate offsets from the zero meridian, but this option MUST NOT be used with EPP. The extended date-time form using upper case "T" and "Z" characters, defined in [W3C.REC-xmlschema-2-20041028], MUST be used to represent date-time values, as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters.

EPP経由で提示されるすべての日時値は、グレゴリオ暦を使用し協定世界時で表現しなければなりません (MUST)。XML Schemaでは本初子午線からのオフセットを示すためにタイムゾーン識別子の使用が許可されていますが、このオプションはEPPで使用してはなりません (MUST NOT)。XML Schemaは省略された日時形式や小文字の「t」および「z」文字をサポートしていないため、日時値を表現するには [W3C.REC-xmlschema-2-20041028] で定義されている大文字の「T」および「Z」文字を使用した拡張日時形式を使用しなければなりません (MUST)。

This document requires domain and host name syntax as specified in [RFC0952] as updated by [RFC1123]. At the time of this writing, RFC 3490 [RFC3490] describes a standard to use certain ASCII name labels to represent non-ASCII name labels. These conformance requirements might change as a result of progressing work in developing standards for internationalized domain names.

このドキュメントには、[RFC1123]で更新された[RFC0952]で指定されているドメインとホスト名の構文が必要です。この執筆時点で、RFC 3490 [RFC3490]は、特定のASCII名ラベルを使用して非ASCII名ラベルを表す標準について説明しています。これらの適合要件は、国際化されたドメイン名の基準の開発における進歩の結果として変化する可能性があります。

6. IANA Considerations

6. IANAの考慮事項

This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Two URI assignments have been registered by the IANA.

このドキュメントでは、URNSを使用して、[RFC3688]に記載されているレジストリメカニズムに準拠したXMLネームスペースとXMLスキーマを記述します。2つのURI割り当てがIANAによって登録されています。

Registration request for the domain namespace:

ドメインネームスペースの登録リクエスト：

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

Registrant Contact: See the "Author's Address" section of this document.

登録者の連絡先：このドキュメントの「著者のアドレス」セクションを参照してください。

XML: None. Namespace URIs do not represent an XML specification.

XML：なし。名前空間URIはXML仕様を表していません。

Registration request for the domain XML schema:

ドメインXMLスキーマの登録要求：

      URI: urn:ietf:params:xml:schema:domain-1.0

Registrant Contact: See the "Author's Address" section of this document.

登録者の連絡先：このドキュメントの「著者のアドレス」セクションを参照してください。

XML: See the "Formal Syntax" section of this document.

XML：このドキュメントの「正式な構文」セクションを参照してください。

7. Security Considerations

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

Authorization information as described in Section 2.6 is REQUIRED to create a domain object. This information is used in some query and transfer operations as an additional means of determining client authorization to perform the command. Failure to protect authorization information from inadvertent disclosure can result in unauthorized transfer operations and unauthorized information release. Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption mechanisms to provide privacy services.

ドメインオブジェクトを作成するには、セクション2.6で説明されている認証情報が必須です (REQUIRED)。この情報は、コマンドを実行するクライアントの権限を判断する追加の手段として、一部の照会および転送操作で使用されます。認証情報が不用意に開示されないよう保護することを怠ると、不正な転送操作や不正な情報漏洩につながる可能性があります。プライバシーサービスを提供するために、クライアントとサーバの両方は、認証情報が高水準の暗号化メカニズムによって保管および交換されることを保証しなければなりません (MUST)。

The object mapping described in this document does not provide any other security services or introduce any additional considerations beyond those described by [RFC5730] or those caused by the protocol layers used by EPP.

このドキュメントで説明されているオブジェクトマッピングは、他のセキュリティサービスを提供したり、[RFC5730]で説明されているものを超えたり、EPPで使用されているプロトコル層によって引き起こされたものを超えて追加の考慮事項を導入したりしません。

8. Acknowledgements

8. 謝辞

RFC 3731 is a product of the PROVREG working group, which suggested improvements and provided many invaluable comments. The author wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions. RFC 4931 and this document are individual submissions, based on the work done in RFC 3731.

RFC 3731はProvregワーキンググループの製品であり、改善を提案し、多くの非常に貴重なコメントを提供しました。著者は、WGチェアのエドワード・ルイスとJaap Akkerhuisのプロセスと編集上の貢献の努力を認めたいと考えています。RFC 4931およびこのドキュメントは、RFC 3731で行われた作業に基づいた個別の提出物です。

Specific suggestions that have been incorporated into this document were provided by Joe Abley, Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, Asbjorn Steira, Bruce Tonkin, and Rick Wesson.

この文書に組み込まれた具体的な提案は、ジョー・エイブリー、クリス・バソン、エリック・ブルナー・ウィリアムズ、ジョーディン・ブキャナン、デイブ・クロッカー、アイシャ・ダマラジュ、アンソニー・エデン、シア・エル・ショック、クラウス・マロルニー、ダン・マンリー、マイケル・ミューリングによって提供されました。Mevzek、Asbjorn Steira、Bruce Tonkin、Rick Wesson。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.

[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler、「DODインターネットホストテーブル仕様」、RFC 952、1985年10月。

[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

[RFC1123] Braden, R.、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner, S.、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[RFC3688] Mealling, M.、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。

[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009.

[RFC5730] Hollenbeck, S.、「拡張可能なプロビジョニングプロトコル（EPP）」、STD 69、RFC 5730、2009年8月。

[RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, August 2009.

[RFC5732] Hollenbeck, S.、「拡張可能なプロビジョニングプロトコル（EPP）ホストマッピング」、STD 69、RFC 5732、2009年8月。

[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, August 2009.

[RFC5733] Hollenbeck, S.、「拡張可能なプロビジョニングプロトコル（EPP）コンタクトマッピング」、STD 69、RFC 5733、2009年8月。

[W3C.REC-xml-20040204] Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J., and T. Bray, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.

[W3C.REC-xml-20040204] Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J., and T. Bray、「拡張可能なマークアップ言語（XML）1.0（第3版）」、World Wide Web Consortium FirstEdition REC-XML-20040204、2004年2月、<http://www.w3.org/TR/2004/REC-xml-20040204>。

[W3C.REC-xmlschema-1-20041028] Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.

[W3C.REC-xmlschema-1-20041028] Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech、「XML Schema Part 1：Structures Second Edition」、World Wide Web Consortiumの推奨REC-XMLSCHEMA-1-20041028、2004年10月、<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>。

[W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

[W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron、「XML Schema Part 2：DataTypes Second Edition」、World Wide Web Consortiumの推奨REC-XMLSCHEMA-20041028、2004年10月、<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>。

9.2. Informative References

9.2. 参考引用

[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.

[RFC2781] Hoffman, P. and F. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。

[RFC4931] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 4931, May 2007.

[RFC4931] Hollenbeck, S.、「拡張可能なプロビジョニングプロトコル（EPP）ドメイン名マッピング」、RFC 4931、2007年5月。

Appendix A. Changes from RFC 4931

付録A. RFC 4931からの変更

1. Changed "This document obsoletes RFC 3731" to "This document obsoletes RFC 4931".

1. 「このドキュメントが廃止されたRFC 3731」を「このドキュメントは、RFC 4931」を「廃止」に変更しました。

2. Replaced references to RFC 3731 with references to 4931.

2. RFC 3731への参照を4931への参照に置き換えました。

3. Replaced references to RFC 4930 with references to 5730.

3. RFC 4930への参照を5730への参照に置き換えました。

4. Replaced references to RFC 4932 with references to 5732.

4. RFC 4932への参照を5732への参照に置き換えました。

5. Replaced references to RFC 4933 with references to 5733.

5. RFC 4933への参照を5733への参照に置き換えました。

6. Updated description of inactive status in Section 2.3.

6. セクション2.3の非アクティブステータスの更新された説明。

7. Fixed example host names in the Section 1.1 and Section 3.2.1 examples.

7. セクション1.1およびセクション3.2.1の例のホスト名の例を修正しました。

8. Changed "but such methods SHOULD NOT be used" to "but such methods should not be used" in Section 2.7.

8. セクション2.7において、「but such methods SHOULD NOT be used」（ただしそのような方法は使用すべきではありません (SHOULD NOT)）を「but such methods should not be used」に変更しました。

9. Added "Other notification methods MAY be used in addition to the required service message" in Section 3.2.

9. セクション3.2において、「Other notification methods MAY be used in addition to the required service message」（必要なサービスメッセージに加えて、他の通知方法を使用してもよい (MAY)）を追加しました。

10. Added 2201 response code text in Section 3.2.

10. セクション3.2に2201応答コードテキストが追加されました。

11. Added BSD license text to XML schema section.

11. XMLスキーマセクションにBSDライセンステキストを追加しました。

Author's Address

著者の連絡先

Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US

Scott Hollenbeck VeriSign、Inc。21345 Ridgetop Circle Dulles、VA 20166-6503 US

   EMail: shollenbeck@verisign.com