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

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

[要約] RFC 4931は、EPPドメイン名マッピングの拡張可能なプロビジョニングプロトコル（EPP）に関する規格です。このRFCの目的は、EPPを使用してドメイン名のマッピングを効率的かつ柔軟に行うための仕様を提供することです。

Network Working Group                                      S. Hollenbeck
Request for Comments: 4931                                VeriSign, Inc.
Obsoletes: 3731                                                 May 2007
Category: Standards Track

Extensible Provisioning Protocol (EPP) Domain Name Mapping

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

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

著作権（c）The IETF Trust（2007）。

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

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

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  . . . . . . . . . . . . . . . . . 21
       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  . . . . . . . . . . . . . . . . . . . . . . . . 31
   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 3731 . . . . . . . . . . . . . . . . 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 3731 [RFC3731].

このドキュメントでは、拡張可能なプロビジョニングプロトコル（EPP）のバージョン1.0のインターネットドメイン名マッピングについて説明します。このマッピングは、[w3c.rec-xml-20040204]で説明されている拡張可能なマークアップ言語（xml）1.0と[w3c.rec-xmlschema-20041028]および[w3c.rec-xmlschemaa-2-20041028]。このドキュメントは、RFC 3731 [RFC3731]を廃止します。

[RFC4930] 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.

[RFC4930]は、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仕様と例は、適合実装を開発するために提示されたキャラクターケースで解釈する必要があります。

1.1. Relationship of Domain Objects and Host Objects

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

The EPP mapping for host objects is described in [RFC4932]. 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マッピングは[RFC4932]で説明されています。このドキュメントは、ドメイン名オブジェクトが下位ホスト名オブジェクトと上位の関係を持っていることを前提としています。たとえば、ドメイン名「Example.com」には、ホスト名「ns1.example.com」との上位の関係があります。この関係を保存しないEPPアクション（オブジェクト転送など）は、明示的に許可されている必要があります。

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 name space 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はdomain example1.comの下位ホストですが、domain example2.comの下位ホストではありません。ns1.example1.comは、2.comの名前サーバーとして使用できます。この場合、NS1.example1.comは、同じリポジトリ内の下位ホストの運用を管理する規則を条件として、内部ホストとして扱われる必要があります。

Name server hosts for domain delegation can be specified as either 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.

ドメイン委任の名前サーバーホストは、既存のホストオブジェクトへの参照のいずれか、またはホストマシンを記述するドメイン属性として指定できます。サーバーオペレーターは、1つの名前サーバー仕様フォームを一貫して使用する必要があります。EPPグリーティングでホストオブジェクトのサポートを発表するサーバーオペレーターは、ドメイン属性が名前サーバーホストマシンを説明できるようにしてはなりません。ホストオブジェクトのサポートを発表しないサーバーオペレーターは、ドメイン属性が名前サーバーホストマシンを説明できるようにする必要があります。ドメイン属性を使用して名前サーバーホストマシンを記述する場合、DNS接着剤レコードを生成するために必要な場合にのみIPアドレスを必要とする必要があります。

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:

名前サーバーは、<ドメイン：ns>要素内で指定されています。この要素には、1つ以上の<domain：hostobj>要素または1つ以上の<ドメイン：hostattr>要素が含まれている必要があります。a <ドメイン：hostobj>要素には、既知の名前サーバーホストオブジェクトの完全に適格な名前が含まれています。a <ドメイン：hostattr>要素には、次の子要素が含まれています。

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

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

- 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 [RFC4932].

- ゼロ以上オプション<ドメイン：hostaddr>ホストに関連付けられるIPアドレスを含む要素。各要素には、IPアドレス形式を識別するための「IP」属性を含めることができます。属性値 "v4"は、IPv4アドレス形式に注意するために使用されます。属性値 "v6"は、IPv6アドレス形式に注意するために使用されます。「IP」属性が指定されていない場合、「V4」がデフォルトの属性値です。IPアドレスの構文要件は、EPPホストマッピング[RFC4932]のセクション2.5で説明されています。

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

domain emple.comのホストオブジェクト名サーバー要素：

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

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

domain embly.comのesmageホスト属性名サーバー要素：

   <domain:ns>
     <domain:hostAttr>
       <domain:hostName>ns1.example.com</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>ns1.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].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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：」を表し、プロトコルサーバーによって返される行を表します。例のインデントと空白は、要素の関係を説明するためにのみ提供されており、このプロトコルの必要な機能ではありません。

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

このドキュメントで説明されているドメイン名とホスト名の構文は、[RFC1123]で更新された[RFC0952]に準拠する必要があります。この執筆時点で、RFC 3490 [RFC3490]は、特定のASCII名ラベルを使用して非ASCII名ラベルを表す標準について説明しています。これらの適合要件は、国際化されたドメイン名の基準の開発における進歩の結果として変化する可能性があります。サーバーは、許容ドメイン名を特定のトップレベルドメイン、セカンドレベルのドメイン、またはサーバーが信頼できる他のドメインに制限する場合があります。これらの名前がDNSゾーンに保存されている場合に必要な後続のドットは暗黙的であり、ホストとドメイン名を交換するときは提供されてはなりません。

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 [RFC4930].

すべてのEPP接点は、サーバーユニーク識別子によって識別されます。連絡先識別子は、指定された最小長、指定された最大長、指定された形式の文字列です。接触識別子は、[RFC4930]で説明されている「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つの関連するステータス値が必要です。ステータス値は、ドメインオブジェクトを後援するクライアントと、オブジェクトが存在するサーバーによってのみ設定できます。クライアントは、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>コマンド。各ステータス値には、オブジェクトに適用されるステータスの理論的根拠を説明する人間が読める一連のテキストが添付される場合があります。

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.

クライアントは、サーバーによって設定されたステータス値を変更してはなりません。サーバーは、ローカルサーバーポリシーの対象となるクライアントによって設定されたステータス値を変更またはオーバーライドする場合があります。オブジェクトのステータスは、クライアントが開始したTransformコマンドまたはサーバーオペレーターが実行するアクションのいずれかの結果として変更される場合があります。

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.

オブジェクトを削除するリクエストは拒否する必要があります。

- clientHold, serverHold

- clienthold、serverhold

DNS delegation information MUST NOT be published for the object.

DNS委任情報は、オブジェクトに公開してはなりません。

- clientRenewProhibited, serverRenewProhibited

- clientrenewprohited、serverrenewprohited

Requests to renew the object MUST be rejected.

オブジェクトを更新するための要求は拒否する必要があります。

- clientTransferProhibited, serverTransferProhibited

- ClientTransferProhited、ServerTransferProhited

Requests to transfer the object MUST be rejected.

オブジェクトを転送するリクエストは拒否する必要があります。

- clientUpdateProhibited, serverUpdateProhibited

- clientUpdateProhited、serverUpdateProhited

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

オブジェクトを更新するリクエスト（このステータスを削除する以外）は拒否する必要があります。

- inactive

- 非活性低調気だるい

Delegation information has not been associated with the object.

委任情報はオブジェクトに関連付けられていません。

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

要求されたアクションが完了した場合、保留中の作成、保留中の、保留中、保留中の、保留中のトレンジ、または保留中のステータス値を削除する必要があります。トランザクションに関与するすべてのクライアントは、アクションが完了し、オブジェクトのステータスが変更されたというサービスメッセージを使用して通知する必要があります。

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

「OK」ステータスを他のステータスと組み合わせることはできません。

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

「保留中」のステータスを、「ClientDeleTeprohited」または「ServerDeleTeprohed」ステータスのいずれかと組み合わせることはできません。

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

「保留中の」ステータスを、「clientrenewprohited」または「serverrenewProhited」ステータスのいずれかと組み合わせることはできません。

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

「保留中」のステータスを、「ClientTransferProhited」または「ServerTransferProhited」ステータスのいずれかと組み合わせることはできません。

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

「保留中」のステータスを、「clientupdateProhited」または「serverUpdateProhited」ステータスのいずれかと組み合わせることはできません。

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

保留中の作成、保留中の、保留中の留置、保留中のトランファー、および保留中のステータス値を互いに組み合わせる必要はありません。

Other status combinations not expressly prohibited MAY be used.

明示的に禁止されていない他のステータスの組み合わせを使用することができます。

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

日付および時刻属性値は、グレゴリオカレンダーを使用して、ユニバーサル調整時間（UTC）で表す必要があります。[W3C.REC-XMLSCHEMA-2-20041028]で定義されている「T」および「Z」文字を使用した拡張日付の形式は、XMLスキーマが切り捨てられた日付のフォームをサポートしないため、日付時間値を表すために使用する必要がありますまたは小文字「t」および「z」文字。

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.

ドメイン名オブジェクトには、指定された有効期間がある場合があります。サーバーポリシーがドメインオブジェクトの妥当性期間をサポートする場合、ドメインオブジェクトが作成されたときに有効期間が定義され、epp <neled>または<cransfer>コマンドによって拡張される場合があります。サーバーポリシーの問題として、この仕様は、ドメインオブジェクトの有効期間の有効期限に伴うアクションを定義するものではありません。

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.

有効期間は、「ユニット」属性を使用して指定された適切なユニットとともに、数年または数か月で測定されます。「ユニット」属性の有効な値は、数年間「Y」、数か月間は「M」です。最小許容期間値は1（1）です。最大許容値は99小数です（99）。サーバーは、より低い最大値をサポートする場合があります。

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 [RFC4930]. The command mappings described here are specifically for use in provisioning and managing Internet domain names via EPP.

EPP構文とセマンティクスの詳細な説明は、[RFC4930]に記載されています。ここで説明するコマンドマッピングは、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>ドメインオブジェクトをリポジトリ内でプロビジョニングできるかどうか、<info>ドメインオブジェクトに関連付けられた詳細情報を取得し、ドメインオブジェクト転送ステータス情報を取得するために<転送>。

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>コマンドには、ドメイン名を識別する<ドメイン：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.

- A <ドメイン：名前>クエリドメインオブジェクトの完全に適格な名前を含む要素。この要素には、<Check>コマンドが完了した瞬間に、値がオブジェクトの可用性（プロビジョニングであるかどうか）を示す「Avail」属性を含める必要があります。「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).

- オブジェクトをプロビジョニングできないときに提供される可能性のあるオプションの<ドメイン：理由>要素。存在する場合、この要素にはサーバー固有のテキストが含まれており、オブジェクトをプロビジョニングできない理由を説明するのに役立ちます。このテキストは、以前にクライアントと交渉された応答言語で表現する必要があります。交渉された値が「EN」（英語）のデフォルト値以外のものである場合、言語を識別するためにオプションの「Lang」属性が存在する場合があります。

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エラー応答を返す必要があります。

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>コマンドは、ドメインオブジェクトに関連付けられた情報を取得するために使用されます。このコマンドへの応答は、クエリのクライアントの身元、許可情報の使用、および許可されていないクライアントに対するサーバーポリシーによって異なる場合があります。クエリクライアントがスポンサークライアントである場合、利用可能なすべての情報を返す必要があります。クエリクライアントがスポンサークライアントではなく、クライアントが有効な承認情報を提供する場合、利用可能なすべての情報を返す必要があります。クエリクライアントがスポンサークライアントではなく、クライアントが有効な承認情報を提供しない場合、サーバーポリシーはどのオプション要素が返されるかを決定します。

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コマンド要素に加えて、<情報>コマンドには、ドメイン名を識別する<ドメイン：情報>要素を含める必要があります。<ドメイン：情報>要素には、次の子要素が含まれています。

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

- A <ドメイン：名前>要素には、クエリにされるドメインオブジェクトの完全に適格な名前が含まれています。ドメインオブジェクトに関連するホストを説明する情報の返品を制御するために、オプションの「ホスト」属性を利用できます。「すべて」の値（デフォルト、不在の可能性がある）は、下位ホストと委任されたホストの両方を説明する情報を返します。「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.

- オプションの<ドメイン：authinfo>ドメインオブジェクトに関連付けられた認証情報またはドメインオブジェクトの登録者または関連する連絡先に関連付けられた承認情報を含む要素。与えられたauthinfoがドメインオブジェクト自体ではなく、登録者または連絡先オブジェクトに関連付けられている場合にのみ、登録者または連絡先オブジェクトを識別するために、オプションの「roid」属性を使用する必要があります。この要素が提供されていない場合、または承認情報が無効である場合、サーバーポリシーはコマンドが拒否されたかどうか、または応答情報がクライアントに返されるかどうかを決定します。

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>要素には、ドメイン名を識別する子<ドメイン：infdata>要素を含める必要があります。オプションではない要素を返す必要があります。オプションの要素は、クライアントの承認とサーバーポリシーに基づいて返されます。<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.

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

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

- ゼロ以上オプション<ドメイン：ステータス>ドメインに関連付けられた現在のステータス記述子を含む要素。

- 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つのオプション<ドメイン：登録者>要素と1つ以上のオプション<ドメイン：連絡先>ドメインオブジェクトに関連付けられた人間または組織のソーシャル情報オブジェクトの識別子を含む要素。

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

- ドメインオブジェクトに関連付けられている委任されたホストオブジェクトまたはホスト属性（名前サーバー）の完全に適格な名前を含むオプションの<ドメイン：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.

- ゼロ以上のオプション<ドメイン：ホスト>この上位ドメインオブジェクトの下に存在する下位ホストオブジェクトの完全に適格な名前を含む要素。

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

- ドメインオブジェクトを作成したクライアントの識別子を含むオプションの<ドメイン：CRID>要素。

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

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

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

- ドメインオブジェクトの登録期間の終了を識別する日付と時刻を含むオプションの<ドメイン：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.

- ドメインオブジェクトを最後に更新したクライアントの識別子を含むオプションの<ドメイン：upid>要素。ドメインが変更されていない場合、この要素を存在しないでください。

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

- 最新のドメインオブジェクト変更の日付と時刻を含むオプションの<ドメイン：更新>要素。ドメインオブジェクトが変更されていない場合、この要素を存在しないでください。

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

- 最新の成功したドメインオブジェクト転送の日付と時刻を含むオプションの<ドメイン：trdate>要素。ドメインオブジェクトが転送されていない場合は、この要素を提供してはなりません。

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

- ドメインオブジェクトに関連付けられた認証情報を含むオプションの<ドメイン：authinfo>要素。この要素は、クエリクライアントが現在のスポンサークライアントである場合、またはクライアントが有効な承認情報をコマンドに提供した場合にのみ返す必要があります。

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エラー応答を返す必要があります。

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 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>コマンドには、値「クエリ」を備えた「OP」属性と、ドメイン名を識別するA <ドメイン：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>要素には、ドメイン名を識別する子<ドメイン：TRNDATA>要素を含める必要があります。<ドメイン：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.

- <ドメイン：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.

- <ドメイン：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.

- A <ドメイン：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.

- <転送>コマンドが有効期間の変更を引き起こしたり、引き起こしたりした場合にドメインオブジェクトの妥当性期間の終了を含むオプションの<ドメイン：exdate>要素。

Example <transfer> query response:

例<cransfer>クエリ応答：

   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エラー応答を返す必要があります。

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>ドメインオブジェクトのインスタンスを削除する、<reing>ドメインオブジェクトの有効期間を拡張するには、<転送>ドメインオブジェクトのスポンサーシップの変更を管理し、<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 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.

通常、変換コマンドは処理され、リアルタイムで完了します。サーバーオペレーターはコマンドを受信および処理する場合がありますが、要求されたアクションを完了する前に人間またはサードパーティのレビューが必要な場合、要求されたアクションの完了を延期します。このような状況では、サーバーはクライアントに1001の応答コードを返して、コマンドが受信および処理されたことに注意する必要がありますが、要求されたアクションは保留中です。また、サーバーは、要求されたアクションの開始と完了を反映するために、コマンドの対象であるオブジェクトのステータスを管理する必要があります。アクションが完了すると、トランザクションに関与するすべてのクライアントに、アクションが完了し、オブジェクトのステータスが変更されたことを使用して、サービスメッセージを使用して通知する必要があります。

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>コマンドには、ドメイン名を識別する<ドメイン：create>要素を含める必要があります。<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.

- ドメインオブジェクトの初期登録期間を含むオプションの<ドメイン：周期>要素。サーバーは、クライアントによって指定されていない場合、デフォルトの初期登録期間を定義できます。

- 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 [RFC4933].

- オブジェクトまたは組織のソーシャル情報（連絡先）オブジェクトの識別子を含むオプションの<ドメイン：登録>要素は、オブジェクト登録者としてドメインオブジェクトに関連付けられています。このオブジェクト識別子は、連絡先オブジェクトがドメインオブジェクトに関連付けられる前に、サーバーに既知である必要があります。連絡先オブジェクトのEPPマッピングは[RFC4933]で説明されています。

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

- ゼロ以上オプション<ドメイン：連絡先>他の接触オブジェクトの識別子を含む要素がドメインオブジェクトに関連付けられます。連絡先オブジェクトがドメインオブジェクトに関連付けられる前に、コンタクトオブジェクト識別子がサーバーに既知である必要があります。

- 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.com</domain:hostObj>
   C:          <domain:hostObj>ns1.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>要素には、ドメイン名を識別する子<ドメイン：CREDATA>要素を含める必要があります。<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.

- ドメインオブジェクトの登録期間の終了を識別する日付と時刻を含むオプションの<ドメイン：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エラー応答を返す必要があります。

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>コマンドには、ドメイン名を識別する<ドメイン：delete>要素を含める必要があります。<ドメイン：delete>要素には、次の子要素が含まれています。

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

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

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 been either 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.

下位ホストオブジェクトがドメインオブジェクトに関連付けられている場合、ドメインオブジェクトを削除しないでください。たとえば、domain "embler.com"が存在し、ホストオブジェクト「ns1.example.com」も存在する場合、domain "example.com"はホスト「ns1.example.com」が削除されるか削除されるか削除されるべきではありません。別の上位ドメインに存在するように改名されました。サーバーは、<delete>コマンドが試行され、既存のオブジェクト関係のために障害がある場合に2305エラー応答コードを送信することにより、オブジェクト関係が存在することをクライアントに通知する必要があります。ドメインオブジェクトに関連付けられた委任および下位ホストオブジェクトは、ドメインオブジェクトの<info> queryコマンドを使用して決定できます。

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応答で応答する必要があります。

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エラー応答を返す必要があります。

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 <neled>コマンドは、クライアントがドメインオブジェクトの有効期間を延長できるようにする変換操作を提供します。標準のEPPコマンド要素に加えて、<neled>コマンドには、ドメイン名を識別する<ドメイン：更新>要素を含める必要があります。<ドメイン：更新>要素には、次の子要素が含まれています。

- 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>現在の有効期間が終了する日付を含む要素。この値により、繰り返される<lenine>コマンドが、予期せぬ成功しない更新を複数回らないようにします。

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

- ドメインオブジェクトの登録期間に追加されるユニットの数を含むオプションの<ドメイン：周期>要素。利用可能なユニットの数には、サーバーによって課される制限の対象となる場合があります。

Example <renew> command:

例<renine>コマンド：

   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:

<neled>コマンドが正常に処理された場合、EPP <Resdata>要素には、ドメイン名を識別する子<ドメイン：rendata>要素を含める必要があります。<ドメイン：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.

- ドメインオブジェクトの登録期間の終了を識別する日付と時刻を含むオプションの<ドメイン：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.

何らかの理由で<reine>コマンドを処理できない場合は、EPPエラー応答を返す必要があります。

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>コマンドには、ドメイン名を識別する<ドメイン：転送>要素を含める必要があります。<ドメイン：転送>要素には、次の子要素が含まれています。

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

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

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

- 転送プロセスの完了時にドメインオブジェクトの登録期間に追加されるユニットの数を含むオプションの<ドメイン：周期>要素。この要素は、転送が要求された場合にのみ使用でき、別の方法で使用する場合は無視する必要があります。利用可能なユニットの数には、サーバーによって課される制限の対象となる場合があります。

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

- A <ドメイン：authinfo>ドメインオブジェクトに関連付けられた認証情報またはドメインオブジェクトの登録者または関連する連絡先に関連付けられた承認情報を含む要素。与えられたauthinfoがドメインオブジェクト自体ではなく、登録者または連絡先オブジェクトに関連付けられている場合にのみ、登録者または連絡先オブジェクトを識別するために、オプションの「roid」属性を使用する必要があります。

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 [RFC4930].

すべてのEPP <Transfer>コマンドには、実行される転送操作を識別する「OP」属性を含める必要があります。すべての属性値の有効な値、定義、および承認は[RFC4930]で定義されています。

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.

ドメインオブジェクトの転送は、ドメインオブジェクトに従属するすべてのホストオブジェクトを暗黙的に転送する必要があります。たとえば、ドメインオブジェクト「Example.com」が転送され、ホストオブジェクト「NS1.example.com」が存在する場合、ホストオブジェクトは「Example.com」転送プロセスの一部として転送する必要があります。ドメインオブジェクトの転送時に転送されるホストオブジェクトは、ドメインオブジェクトで実行された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 <s resdata>要素には、ドメイン名を識別する子<ドメイン：trndata>要素を含める必要があります。<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エラー応答を返す必要があります。

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>コマンドには、ドメイン名を識別する<ドメイン：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.

- オプションの<ドメイン：add>要素は、オブジェクトに追加される属性値を含む要素です。

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

- オブジェクトから削除される属性値を含むオプションの<ドメイン：REM>要素。

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

- 変更されるオブジェクト属性値を含むオプションの<ドメイン：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つの<ドメイン：add>、<domain：rem>、または<domain：chg>要素が拡張されていない場合は、提供する必要があります。<update>拡張子が存在する場合、これらの要素はすべて省略される場合があります。<domain：add> and <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.

- ドメインオブジェクトに関連付けられた委任されたホストオブジェクトまたはホスト属性（名前サーバー）の完全に適格な名前を含むオプションの<ドメイン：ns>要素。ドメインに解像度サービスを提供します。ホストオブジェクトまたはホスト属性を指定するために使用される要素の説明については、セクション1.1を参照してください。ホストオブジェクトがドメインオブジェクトに関連付けられる前に、ホストオブジェクトをサーバーに把握する必要があります。ホスト属性が名前サーバーを指定するために使用される場合、削除されている名前サーバーを識別するために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.

- ゼロ以上<ドメイン：連絡先>ドメインオブジェクトに関連付けたり削除されたりする接触オブジェクトの識別子を含む要素。連絡先オブジェクトがドメインオブジェクトに関連付けられる前に、コンタクトオブジェクト識別子がサーバーに既知である必要があります。

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

- A <ドメイン：登録者>オブジェクト登録者としてドメインオブジェクトに関連付けられる人間または組織のソーシャル情報（連絡先）オブジェクトの識別子を含む要素。このオブジェクト識別子は、連絡先オブジェクトがドメインオブジェクトに関連付けられる前に、サーバーに既知である必要があります。空の要素を使用して、登録者情報を削除できます。

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

- <ドメイン：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応答で応答する必要があります。

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エラー応答を返す必要があります。

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

コマンドは、クライアントから受信される順序でサーバーによって処理されます。コマンドの領収書と処理を確認する即時の応答はサーバーによって生成されますが、サーバーオペレーターは、要求されたアクションを完了する前に、要求された変換コマンドのオフラインレビューを実行できます。このような状況では、サーバーからの応答は、変換コマンドが受信および処理されたことに明確に注意する必要がありますが、要求されたアクションは保留中です。対応するオブジェクトのステータスは、保留中のアクションの処理を明確に反映する必要があります。アクションのオフライン処理が完了した場合、サーバーはクライアントに通知する必要があります。

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.

この応答を返した後のドメインオブジェクトのステータスには、「保留中の作成」を含める必要があります。サーバーオペレーターは、オフラインでリクエストを確認し、<poll>コマンドを介して検索のサービスメッセージをキューイングするか、バンド外のメカニズムを使用してクライアントにリクエストを通知することにより、レビューの結果をクライアントに通知します。

The service message MUST contain text in the <response>, <msgQ>, <msg> element that describes the notification. 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:

サービスメッセージには、通知を記述する<応答>、<sgq>、<sg>要素にテキストを含める必要があります。さらに、epp <resdata>要素には、ドメイン名を識別する子<ドメイン：pandata>要素を含める必要があります。<ドメイン：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.

- A <ドメイン：名前>ドメインオブジェクトの完全に適格な名前を含む要素。<domain：name>要素には、必要な「Paresult」属性が含まれています。正のブール値は、リクエストが承認および完了したことを示しています。負のブール値は、要求が拒否され、要求されたアクションが実行されていないことを示しています。

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

- A <ドメイン：Patrid>クライアントトランザクション識別子とサーバートランザクション識別子を含む要素は、コマンドを処理するための元の応答で返されました。クライアントトランザクション識別子はオプションであり、クライアントが元の<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登録目的でスキーマの開始と終了に注意するために使用されます。

   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.

<！ - <cransfer>コマンドの子要素。

   -->
   <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？>宣言で「エンコード」属性を使用して他の文字エンコーディングを特定して使用するための規定が含まれていますが、UTF-8の使用は、サポートの互換性が存在するパーサーエンコードが存在する環境で推奨されます。

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を介して提示されたすべての日付値は、グレゴリオカレンダーを使用して普遍的な調整時間で表現する必要があります。XMLスキーマでは、タイムゾーン識別子を使用してゼロ子午線からのオフセットを示すことができますが、このオプションはEPPで使用してはなりません。[W3C.REC-XMLSCHEMA-2-20041028]で定義されている「T」および「Z」文字を使用した拡張日付の形式は、XMLスキーマが切り捨てられた日付のフォームをサポートしないため、日付時間値を表すために使用する必要がありますまたは小文字「t」および「z」文字。

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.

URI：urn：ietf：params：xml：ns：domain-1.0登録者の連絡先：このドキュメントの「著者アドレス」セクションを参照してください。

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で説明されている許可情報は、ドメインオブジェクトを作成するために必要です。この情報は、コマンドを実行するためのクライアント許可を決定する追加の手段として、一部のクエリおよび転送操作で使用されます。許可情報を不注意な開示から保護しないと、不正な譲渡操作と不正な情報リリースが発生する可能性があります。クライアントとサーバーの両方が、プライバシーサービスを提供するために、認可情報が高品質の暗号化メカニズムと交換されることを確認する必要があります。

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

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

8. Acknowledgements

8. 謝辞

This document was originally written as an individual submission Internet-Draft. The PROVREG working group later adopted it as a working group document and provided many invaluable comments and suggested improvements. The author wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions.

このドキュメントは、もともと個別の提出インターネットドラフトとして書かれていました。Provregワーキンググループは後にワーキンググループの文書としてそれを採用し、多くの貴重なコメントを提供し、改善を提案しました。著者は、WGチェアのエドワード・ルイスとJaap Akkerhuisのプロセスと編集上の貢献の努力を認めたいと考えています。

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。、および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月。

[RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 4930, May 2007.

[RFC4930] Hollenbeck、S。、「拡張可能なプロビジョニングプロトコル（EPP）」、RFC 4930、2007年5月。

[RFC4932] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", RFC 4932, May 2007.

[RFC4932] Hollenbeck、S。、「拡張可能なプロビジョニングプロトコル（EPP）ホストマッピング」、RFC 4932、2007年5月。

[RFC4933] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", RFC 4933, May 2007.

[RFC4933] Hollenbeck、S。、「拡張可能なプロビジョニングプロトコル（EPP）コンタクトマッピング」、RFC 4933、2007年5月。

[W3C.REC-xml-20040204] Maler, E., Yergeau, F., Paoli, J., Bray, T., and C. Sperberg-McQueen, "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] Maler、E.、Yergeau、F.、Paoli、J.、Bray、T。、およびC. Sperberg-Mcqueen、 "拡張可能なマークアップ言語（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] Thompson, H., Maloney, M., 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] Thompson、H.、Maloney、M.、Mendelsohn、N.、および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] Biron, P. and A. Malhotra, "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] Biron、P。およびA. Malhotra、「XML Schema Part 2：DataTypes Second Edition」、World Wide Webコンソーシアムの推奨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。および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。、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。

[RFC3731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 3731, March 2004.

[RFC3731] Hollenbeck、S。、「拡張可能なプロビジョニングプロトコル（EPP）ドメイン名マッピング」、RFC 3731、2004年3月。

Appendix A. Changes from RFC 3731

付録A. RFC 3731からの変更

1. Minor reformatting as a result of converting I-D source format from nroff to XML.

1. NROFFからXMLにI-Dソース形式を変換した結果としてのマイナーな再フォーマット。

2. Removed this text from Section 2.3:

2. セクション2.3からこのテキストを削除しました：

"With one exception, transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status is set. The only exception is that a <transfer> command to approve, reject, or cancel a transfer MAY be processed while an object is in "pendingTransfer" status."

「1つの例外を除いて、保留中の作成、保留中、保留中の、保留中、保留中のトランファー、または保留中のステータスが設定された場合、変換コマンドを拒否する必要があります。唯一の例外は、a <転送>コマンドを承認、拒否、またはキャンセルすることです。オブジェクトは「保留中のトランファー」ステータスにあります。

3. Changed text in Section 3.1.3 from "A <domain:acID> element that contains the identifier of the client that SHOULD act upon the transfer request" to "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".

3. セクション3.1.3のテキストは、「A <ドメイン：酸>転送要求に基づいて行動する必要があるクライアントの識別子を含む「酸>要素」に変更しました。保留中の転送要求。他のすべてのステータスタイプについて、値は、指定されたアクションをとったクライアントを識別します」。

4. Changed text in Section 3.2.5 (old Section 3.2.1.4) from "At least one <domain:add>, <domain:rem>, or <domain:chg> element MUST be provided." to "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."

4. セクション3.2.5（古いセクション3.2.1.4）のテキストを「少なくとも1つの<ドメイン：add>、<domain：rem>、または<domain：chg>要素を提供する必要がある」からテキストを変更しました。「少なくとも1つの<ドメイン：add>、<domain：rem>、または<domain：chg>要素が拡張されていない場合は提供する必要があります。。」

5. Renumbered old Section 3.2.6 to new Section 3.3.

5. 古いセクション3.2.6に変更された新しいセクション3.3。

6. Changed text in Section 3.3 (old Section 3.2.6) from this:

6. これからセクション3.3（古いセクション3.2.6）のテキストを変更しました。

"The server operator reviews the request offline, and informs the client of the outcome of the review by queuing a service message for retrieval via the <poll> command."

「サーバーオペレーターは、オフラインでリクエストを確認し、<poll>コマンドを介して検索のためにサービスメッセージをキューイングすることにより、レビューの結果をクライアントに通知します。」

to this:

これに：

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

「サーバーオペレーターは、オフラインでリクエストを確認し、<poll>コマンドを介して検索のサービスメッセージをキューイングするか、バンド外のメカニズムを使用してクライアントにリクエストを通知することにより、クライアントにレビューの結果をクライアントに通知します。。」

7. Removed text describing use of the XML Schema schemaLocation attribute. This is an optional attribute that doesn't need to be mandated for use in EPP.

7. XMLスキーマスキーマロケーション属性の使用を説明するテキストを削除しました。これは、EPPで使用するために義務付けられる必要のないオプションの属性です。

8. Removed references to RFC 3339 and replaced them with references to the W3C XML Schema specification.

8. RFC 3339への参照を削除し、W3C XMLスキーマ仕様への参照に置き換えました。

9. Updated EPP and XML references.

9. EPPおよびXML参照を更新しました。

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

Full Copyright Statement

完全な著作権声明

著作権（c）The IETF Trust（2007）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。