RFC4931 日本語訳
4931 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S.Hollenbeck. May 2007. (Format: TXT=88729 bytes) (Obsoletes RFC3731) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Hollenbeck Request for Comments: 4931 VeriSign, Inc. Obsoletes: 3731 May 2007 Category: Standards Track
Hollenbeckがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4931 ベリサインInc.は以下を時代遅れにします。 3731 2007年5月のカテゴリ: 標準化過程
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントは、インターネットの食糧を供給するのと管理のために共有された中央倉庫に保存されたドメイン名を写像しながら、Extensible Provisioningプロトコル(EPP)について説明します。 XMLで指定されていて、マッピングはEPPコマンド構文とドメイン名に適用される意味論を定義します。 このドキュメントはRFC3731を時代遅れにします。
Hollenbeck Standards Track [Page 1] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[1ページ]RFC4931EPPドメイン名
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 ドメインオブジェクトとホストオブジェクト. . . . . 3 1.2の関係。 コンベンションは本書では.5 2を使用しました。 オブジェクト属性. . . . . . . . . . . . . . . . . . . . . . 5 2.1。 ドメインとホスト名. . . . . . . . . . . . . . . . . . 5 2.2。 接触とクライアント識別子. . . . . . . . . . . . . . 5 2.3。 状態値. . . . . . . . . . . . . . . . . . . . . . 5 2.4。 日付と回. . . . . . . . . . . . . . . . . . . . . 7 2.5。 有効期間. . . . . . . . . . . . . . . . . . . . . 8 2.6。 承認情報. . . . . . . . . . . . . . . . 8 2.7。 他のDNSリソース記録属性. . . . . . . . . . . 8 3。 EPPはマッピング. . . . . . . . . . . . . . . . . . . . . 9 3.1を命令します。 EPPは.1にコマンド. . . . . . . . . . . . . . . . . . . . 9 3.1について質問します。 EPP<チェック>命令. . . . . . . . . . . . . . . . . 9 3.1.2。 EPP<インフォメーション>コマンド. . . . . . . . . . . . . . . . . . 11 3.1.3。 EPP<転送>質問命令. . . . . . . . . . . . . 15 3.2。 EPPは.1にコマンド. . . . . . . . . . . . . . . . . . 17 3.2を変えます。 EPP<は>コマンド. . . . . . . . . . . . . . . . . 18 3.2.2を作成します。 EPP<は>コマンド. . . . . . . . . . . . . . . . . 20 3.2.3を削除します。 EPP<は>コマンド. . . . . . . . . . . . . . . . . 21 3.2.4を更新します。 EPP<転送>命令. . . . . . . . . . . . . . . . 23 3.2.5。 EPP<アップデート>命令. . . . . . . . . . . . . . . . . 25 3.3。 要求された動作. . . . . . . . . . . 28 4のオフラインレビュー。 正式な構文. . . . . . . . . . . . . . . . . . . . . . . . 31 5。 国際化問題. . . . . . . . . . . . . 40 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 40 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 41 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 41 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 42 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 42 9.2。 RFC3731.44からの有益な参照. . . . . . . . . . . . . . . . . . 43付録A.変化
Hollenbeck Standards Track [Page 2] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[2ページ]RFC4931EPPドメイン名
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].
このドキュメントはExtensible Provisioningのバージョン1.0のために、プロトコル(EPP)を写像するインターネットドメイン名について説明します。 このマッピングは、拡張マークアップ言語の[W3C. REC-xmlschema-1-20041028]で説明されるように[W3C. REC-xml-20040204]とXML Schema記法で説明される(XML)1.0と[W3C. REC-xmlschema-2-20041028]を使用することで指定されます。 このドキュメントはRFC3731[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.
「スーパー-縦座標」ドメイン名オブジェクトが全く存在しない倉庫でホスト名オブジェクトを作成できます。 例えば、".example"のDNSドメインをホストへ代表として派遣することができるように".example"倉庫でホスト名前"ns1.example.com"を作成できます。 ホストの名前がホストが委譲目的に使用されている倉庫の名前スペースに属さないので、そのようなホストはこの仕様で「外部」のホストとして記述されています。
Whether a host is external or internal relates to the repository in which the host is being used for delegation purposes. Whether or not an internal host is subordinate relates to a domain within the repository. For example, host ns1.example1.com is a subordinate host of domain example1.com, but it is not a subordinate host of domain example2.com. ns1.example1.com can be used as a name server for example2.com. In this case, ns1.example1.com MUST be treated as an internal host, subject to the rules governing operations on subordinate hosts within the same repository.
ホストが外部である、または内部であるかがホストが委譲目的に使用されている倉庫に関連します。 内部のホストが下位であるかどうかが倉庫の中でドメインに関連します。 例えば、ホストns1.example1.comはドメインexample1.comの下位のホストですが、それはドメインexample2.comの下位のホストではありません。example2.comにネームサーバとしてns1.example1.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
既存のホストオブジェクトの参照として、または、ホスト・マシンについて説明するドメイン属性としてドメイン委譲のためのネームサーバホストを指定できます。 サーバオペレータは1つのネームサーバを使用しなければなりません。
Hollenbeck Standards Track [Page 3] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[3ページ]RFC4931EPPドメイン名
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.
仕様書、一貫して。 EPP挨拶でホストオブジェクトのサポートを発表するサーバオペレータはドメイン属性にネームサーバホスト・マシンについて説明させてはいけません。 ホストオブジェクトのサポートを発表しないサーバオペレータはドメイン属性にネームサーバホスト・マシンについて説明させなければなりません。 ドメイン属性が使用されているときには、ネームサーバホスト・マシン、IPアドレスSHOULDについて説明するのに、必要に応じてだけDNSが接着剤記録であると生成するのを必要であってください。
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:
ネームサーバは<ドメイン: ナノ秒中に指定されます。>要素。 この要素は1つ以上の<ドメインを含まなければなりません: 1つ以上の<ドメイン: hostObj>要素かhostAttr>要素。 <ドメイン: hostObj>要素は知られているネームサーバホストオブジェクトの完全に修飾された名前を含んでいます。 <ドメイン: hostAttr>要素は以下の子供要素を含んでいます:
- A <domain:hostName> element that contains the fully qualified name
of a host.
- <ドメイン: ホストの完全に修飾された名前を含むhostName>要素。
- 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].
- より多くのOPTIONAL<ドメイン: ゼロかホストに関連づけられるべきIPアドレスを含むhostAddr>要素。 各要素はIPアドレス形式を特定する"ip"属性を含むかもしれません。 値を結果と考えてください。「v4"はIPv4アドレス形式に注意するのが使用されます」。 値を結果と考えてください。「v6"はIPv6アドレス形式に注意するのが使用されます」。 "ip"属性が指定されないなら、「v4"は省略時の属性値です」。 IPアドレス構文要件はEPPホストマッピング[RFC4932]のセクション2.5で説明されます。
Example host object name server elements for domain example.com:
ドメインexample.comへの例のホストオブジェクト名サーバ要素:
<domain:ns>
<domain:hostObj>ns1.example.com</domain:hostObj>
<domain:hostObj>ns1.example.net</domain:hostObj>
</domain:ns>
<ドメイン: ナノ秒><ドメイン: hostObj>ns1.example.com</ドメイン: hostObj><ドメイン: hostObj>ns1.example.net</ドメイン: hostObj></ドメイン: ナノ秒>。
Example host attribute name server elements for domain example.com:
ドメインexample.comへの例のホスト属性ネームサーバ要素:
<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>
<ドメイン: ><ドメイン: hostAttr><ドメイン: hostName>ns1.example.com</ドメイン: hostName><ドメイン: ナノ秒hostAddr ipは「v4">192.0.2」と等しいです; 2</ドメイン: hostAddr><ドメイン: hostAddr ipが等しい、「v6">、1080:、0:0:0、:、8:800:200、C: 417A</ドメイン: hostAddr></ドメイン: hostAttr><ドメイン: hostAttr><ドメイン: ホスト名>ns1.example.net</ドメイン: ホスト名></ドメイン: hostAttr></ドメイン: ナノ秒>、」
Hollenbeck Standards Track [Page 4] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[4ページ]RFC4931EPPドメイン名
1.2. Conventions Used in This Document
1.2. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this protocol.
例で「C:」 そして、プロトコルクライアントによって送られた台詞を表す、「S:」 系列はプロトコルサーバで戻りました。表す、刻み目と余白は、例に提供しますが、要素関係を例証して、このプロトコルのREQUIREDの特徴ではありません。
2. Object Attributes
2. オブジェクト属性
An EPP domain object has attributes and associated values that can be viewed and modified by the sponsoring client or the server. This section describes each attribute type in detail. The formal syntax for the attribute values described here can be found in the "Formal Syntax" section of this document and in the appropriate normative references.
EPPドメインオブジェクトには、後援しているクライアントかサーバで見て、変更できる属性と関連値があります。このセクションは詳細に各属性タイプを説明します。 このドキュメントの「正式な構文」セクションと適切な引用規格でここで説明された属性値のための正式な構文を見つけることができます。
2.1. Domain and Host Names
2.1. ドメインとホスト名
The syntax for domain and host names described in this document MUST conform to [RFC0952] 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]に従わなければなりません。 この書くこと時点で、RFC3490[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を使用することでドメインオブジェクトの状態を変えることができます。
Hollenbeck Standards Track [Page 5] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[5ページ]RFC4931EPPドメイン名
<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.
<アップデート>命令。 各状態値はオブジェクトに適用された状態に原理について説明する人間読み込み可能なテキストのストリングによって伴われるかもしれません。
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.
クライアントはサーバによって設定された状態値を変更してはいけません。サーバが変わったかもしれませんか、またはオーバーライド状態値はクライアントでローカルサーバ方針を条件としてセットしました。 オブジェクトの状態はクライアントによって開始された変形コマンドかサーバオペレータによって実行された動作のどちらかの結果、変化するかもしれません。
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
- clientDeleteProhibited、serverDeleteProhibited
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
- clientRenewProhibited、serverRenewProhibited
Requests to renew the object MUST be rejected.
オブジェクトを取り替えるという要求を拒絶しなければなりません。
- clientTransferProhibited, serverTransferProhibited
- clientTransferProhibited、serverTransferProhibited
Requests to transfer the object MUST be rejected.
オブジェクトを移すという要求を拒絶しなければなりません。
- clientUpdateProhibited, serverUpdateProhibited
- clientUpdateProhibited、serverUpdateProhibited
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.
これは未定の操作か禁止を全く持っていないオブジェクトのための正常な状態値です。 他の状態値を加えるか、または取り除くとき、サーバはこの値を設定して、取り除きます。
Hollenbeck Standards Track [Page 6] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[6ページ]RFC4931EPPドメイン名
- pendingCreate, pendingDelete, pendingRenew, pendingTransfer,
pendingUpdate
- pendingCreate、pendingDelete、pendingRenew、pendingTransfer、pendingUpdate
A transform command has been processed for the object, but the
action has not been completed by the server. Server operators can
delay action completion for a variety of reasons, such as to allow
for human review or third-party action. A transform command that
is processed, but whose requested action is pending, is noted with
response code 1001.
オブジェクトのために変形コマンドを処理してありますが、操作はサーバで完了していません。サーバオペレータはさまざまな理由で動作完成を遅らせることができます、人間のレビューか第三者動作を考慮するようなもの。 処理されて、要求された動きだけが未定である変形コマンドは応答コード1001で有名です。
When the requested action has been completed, the pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status value MUST be removed. All clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed.
要求された操作が完了したとき、pendingCreate、pendingDelete、pendingRenew、pendingTransfer、またはpendingUpdate状態値を取り外さなければなりません。 操作が完了して、オブジェクトの状態が変化したというサービスメッセージを使用して、トランザクションにかかわるすべてのクライアントに通知しなければなりません。
"ok" status MUST NOT be combined with any other status.
「間違いありません、な」状態をいかなる他の状態にも結合してはいけません。
"pendingDelete" status MUST NOT be combined with either "clientDeleteProhibited" or "serverDeleteProhibited" status.
"clientDeleteProhibited"か"serverDeleteProhibited"状態のどちらかに"pendingDelete"状態を結合してはいけません。
"pendingRenew" status MUST NOT be combined with either "clientRenewProhibited" or "serverRenewProhibited" status.
"clientRenewProhibited"か"serverRenewProhibited"状態のどちらかに"pendingRenew"状態を結合してはいけません。
"pendingTransfer" status MUST NOT be combined with either "clientTransferProhibited" or "serverTransferProhibited" status.
"clientTransferProhibited"か"serverTransferProhibited"状態のどちらかに"pendingTransfer"状態を結合してはいけません。
"pendingUpdate" status MUST NOT be combined with either "clientUpdateProhibited" or "serverUpdateProhibited" status.
"clientUpdateProhibited"か"serverUpdateProhibited"状態のどちらかに"pendingUpdate"状態を結合してはいけません。
The pendingCreate, pendingDelete, pendingRenew, pendingTransfer, and pendingUpdate status values MUST NOT be combined with each other.
pendingCreate、pendingDelete、pendingRenew、pendingTransfer、およびpendingUpdate状態値を互いに結合してはいけません。
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.
グレゴリオ暦を使用して、Universal Coordinated Time(UTC)に日時の属性値を表さなければなりません。 XML図式が、端が欠けている日付-時間がフォームか小文字「T」と「Z」キャラクタであるとサポートしないとき日付時間的価値を表すのに大文字「T」を使用する拡張日付-時間書式と[W3C. REC-xmlschema-2-20041028]で定義された「Z」キャラクタを使用しなければなりません。
Hollenbeck Standards Track [Page 7] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[7ページ]RFC4931EPPドメイン名
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によって広げられて、<が>を取り替えるということであるかもしれないなら<転送>命令です。 サーバ方針の問題には、この仕様は、ドメインオブジェクトの有効期間の満了が持っていかれるために動作を定義しません。
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 Schemaプロセッサはデータ定義のこのメソッドで基本の構文合法化タスクを実行できます、構文解析とプロトコルプロセッサについて必要である構文をチェックする仕事のあいまいさと量を減少させて。 プロトコルに関する追加構文解析、解釈を課すので中古、そして、合法化要件がプロセッサであったなら、不透明なものへの集合体データが結ぶ食糧を供給するのと拡大メソッドは可能な、しかし、そのようなメソッドSHOULD NOTです。
Hollenbeck Standards Track [Page 8] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[8ページ]RFC4931EPPドメイン名
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.
[RFC4930]でEPP構文と意味論の詳述を見つけることができます。 ここで説明されたコマンドマッピングは特に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つのコマンドを提供します: 倉庫の中でドメインオブジェクトに食糧を供給することができるかどうか決定する<チェック>、ドメインオブジェクトに関連している詳細な情報を検索する<インフォメーション>、および<は、ドメインオブジェクト転送状態情報を検索するために>を移します。
3.1.1. EPP <check> Command
3.1.1. EPP<チェック>命令
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<チェック>命令は、倉庫の中でオブジェクトに食糧を供給することができるかどうか決定するのに使用されます。 それはクライアントが、<を使用することでオブジェクトに食糧を供給する成否が結局オブジェクト食糧を供給する要件がサーバ方針の問題であるので>コマンドを作成すると予期できるヒントを提供します。
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指揮機関に加えて、<チェック>命令は<ドメインを含まなければなりません: ドメイン名前空間を特定する>要素をチェックしてください。 <ドメイン: チェック>要素は以下の子供要素を含んでいます:
- One or more <domain:name> elements that contain the fully
qualified names of the domain objects to be queried.
- 1つ以上の<ドメイン: ドメインの完全に修飾された名前を含む>要素をオブジェクトと命名して、質問されてください。
Example <check> 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: <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>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>C:」 <コマンド>C: <チェック>C: <ドメイン: Cをチェックしてください: xmlns: ドメイン=、「つぼ:ietf:params: xml:ナノ秒:ドメイン1インチの>C:」 <ドメイン: 名前>example.com</ドメイン: >をCと命名してください: <ドメイン: 名前>example.net</ドメイン: >をCと命名してください: <ドメイン: 名前>example.org</ドメイン: >をCと命名してください: </ドメイン: >Cをチェックしてください: </チェック>C: <clTRID>ABC-12345</clTRID>C: </コマンド>C: </epp>。
Hollenbeck Standards Track [Page 9] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[9ページ]RFC4931EPPドメイン名
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:
首尾よく<チェック>命令を処理してあるとき、EPP<resData>要素は子供<ドメインを含まなければなりません: ドメイン名前空間を特定するchkData>要素。 <ドメイン: chkData>要素は1つ以上の<ドメイン: 以下の子供要素を含むcd>要素を含んでいます:
- 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.
- <ドメイン: 質問されたドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。 この要素が値がオブジェクトの有用性を示す「利益」属性を含まなければならない、(それに食糧を供給することができる、)、現在、<チェック>命令は完成しました。 「1インチか「本当」が、オブジェクトに食糧を供給することができることを意味する」値。 「0インチか「誤ること」が、オブジェクトに食糧を供給することができないことを意味する」値。
- 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).
- OPTIONAL<ドメイン: オブジェクトに食糧を供給することができないとき提供されるかもしれない>要素を推論してください。 存在しているなら、この要素はなぜオブジェクトに食糧を供給することができないかを説明するのを助けるサーバ特有のテキストを含んでいます。 以前にクライアントと交渉された応答言語で本稿を表さなければなりません。 OPTIONAL"lang"属性は、交渉された値が「アン」(イギリスの)のデフォルト値以外の何かであるなら言語を特定するために存在しているかもしれません。
Example <check> 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: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: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ドメイン: chkData S: xmlns: ドメイン=、「つぼ:ietf:params: xml:ナノ秒:ドメイン1インチの>S:」 <ドメイン: cd>S: <ドメイン: 利益を命名してください、= 「1インチの>example.com</ドメイン: >をSと命名してください」 </ドメイン: cd>S: <ドメイン: cd>S: <ドメイン: 利益を命名してください、= 「0インチの>example.net</ドメイン: >をSと命名してください」 <ドメイン: >Inが</ドメインを使用する理由: >Sを推論してください: </ドメイン: cd>S: <ドメイン: cd>S: <ドメイン: 利益を命名してください、= 「1インチの>example.org</ドメイン: >をSと命名してください」 </ドメイン: cd>S: </ドメイン: chkData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>。
Hollenbeck Standards Track [Page 10] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[10ページ]RFC4931EPPドメイン名
S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: <svTRID>54322-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
An EPP error response MUST be returned if a <check> command cannot be processed for any reason.
どんな理由でも<チェック>命令を処理できないなら、EPP誤り応答を返さなければなりません。
3.1.2. EPP <info> Command
3.1.2. EPP<インフォメーション>コマンド
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<インフォメーション>コマンドは、ドメインオブジェクトに関連している情報を検索するのに使用されます。 質問しているクライアントのアイデンティティ、承認情報の使用、および権限のないクライアントに向かったサーバ方針によって、このコマンドへの応答は異なるかもしれません。 質問しているクライアントが後援しているクライアントであるなら、すべての入手可能な情報を返さなければなりません。 質問しているクライアントが後援しているクライアントではありませんが、クライアントが有効な承認情報を提供するなら、すべての入手可能な情報を返さなければなりません。 質問しているクライアントが後援しているクライアントでなく、またクライアントが有効な承認情報を提供しないなら、サーバ方針は、どのOPTIONAL要素が返されるかを決定します。
In addition to the standard EPP command elements, the <info> command MUST contain a <domain:info> element that identifies the domain namespace. The <domain:info> element contains the following child elements:
標準のEPP指揮機関に加えて、<インフォメーション>コマンドは<ドメインを含まなければなりません: ドメイン名前空間を特定するインフォメーション>要素。 <ドメイン: インフォメーション>要素は以下の子供要素を含んでいます:
- 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.
- <ドメイン: 質問されるべきドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。 ホストについて説明する情報の属性が利用可能であるOPTIONAL「ホスト」コントロール復帰はドメインオブジェクトに関連しました。 「すべて」(欠けるかもしれないデフォルト)の値は下位のものと同様に代表として派遣されたホストについて説明する情報を返します。 "del"の値は説明が代表として派遣しただけである情報にホストを返します。 「潜水艦」の値は下位のホストだけについて説明する情報を返します。 「なにも」の値は代表として派遣されたか下位のホストについて説明する情報を全く返しません。
- An OPTIONAL <domain:authInfo> element that contains authorization
information associated with the domain object or authorization
information associated with the domain object's registrant or
associated contacts. An OPTIONAL "roid" attribute MUST be used to
identify the registrant or contact object if and only if the given
authInfo is associated with a registrant or contact object, and
not the domain object itself. If this element is not provided or
if the authorization information is invalid, server policy
determines if the command is rejected or if response information
will be returned to the client.
- OPTIONAL<ドメイン: ドメインオブジェクトに関連している承認情報か承認情報を含むauthInfo>要素がドメインオブジェクトの記入者か関連接触と交際しました。 そして、記入者か接触オブジェクトを特定するのにOPTIONAL"roid"属性を使用しなければならない、与えられたauthInfoがドメインではなく、記入者か接触オブジェクトに関連している場合にだけ、それ自体で反対してください。 この要素が提供されないか、または承認情報が無効であるなら、サーバ方針は、コマンドが拒絶されるかどうか、または応答情報がクライアントに返されるかどうか決定します。
Hollenbeck Standards Track [Page 11] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[11ページ]RFC4931EPPドメイン名
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>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>C:」 <コマンド>C: <インフォメーション>C: <ドメイン: インフォメーションC: xmlns: ドメイン=、「つぼ:ietf:params: xml:ナノ秒:ドメイン1インチの>C:」 <ドメイン: 名前ホストが等しい、「すべて、「>example.com</ドメイン: >をCと命名してください」 </ドメイン: インフォメーション>C: </インフォメーション>C: <clTRID>ABC-12345</clTRID>C: </コマンド>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>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>C:」 <コマンド>C: <インフォメーション>C: <ドメイン: インフォメーションC: xmlns: ドメイン=、「つぼ:ietf:params: xml:ナノ秒:ドメイン1インチの>C:」 <ドメイン: 名前ホストが等しい、「すべて、「>example.com</ドメイン: >をCと命名してください」 <ドメイン: authInfo>C: <ドメイン: pw>2fooBAR</ドメイン: pw>C: </ドメイン: authInfo>C: </ドメイン: インフォメーション>C: </インフォメーション>C: <clTRID>ABC-12345</clTRID>C: </コマンド>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:
首尾よく<インフォメーション>コマンドを処理してあるとき、EPP<resData>要素は子供<ドメインを含まなければなりません: ドメイン名前空間を特定するinfData>要素。 それはOPTIONAL MUSTではありません。要素、返してください。 クライアント承認とサーバ方針に基づいてOPTIONAL要素を返します。 <ドメイン: infData>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object.
- <ドメイン: ドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- A <domain:roid> element that contains the Repository Object
IDentifier assigned to the domain object when the object was
created.
- <ドメイン: オブジェクトが作成されたときドメインオブジェクトに割り当てられたRepository Object IDentifierを含むroid>要素。
Hollenbeck Standards Track [Page 12] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[12ページ]RFC4931EPPドメイン名
- Zero or more OPTIONAL <domain:status> elements that contain the
current status descriptors associated with the domain.
- より多くのOPTIONAL<ドメイン: ゼロかドメインに関連している現在の状態記述子を含む状態>要素。
- If supported by the server, one OPTIONAL <domain:registrant>
element and one or more OPTIONAL <domain:contact> elements that
contain identifiers for the human or organizational social
information objects associated with the domain object.
- 1つのOPTIONAL<ドメイン: 記入者>要素と1つ以上のOPTIONAL<ドメイン: サーバによってサポートされるなら、ドメインオブジェクトに関連している人間の、または、組織的な社会情報オブジェクトのための識別子を含む>要素に連絡してください。
- An OPTIONAL <domain:ns> element that contains the fully qualified
names of the delegated host objects or host attributes (name
servers) associated with the domain object. See Section 1.1 for a
description of the elements used to specify host objects or host
attributes.
- OPTIONAL<ドメイン: ドメインオブジェクトに関連づけられて、代表として派遣されたホストオブジェクトの完全に修飾された名前を含む>要素かホストが結果と考える(ネームサーバ)ナノ秒。 要素の記述のためのセクション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.
- より多くのOPTIONAL<ドメイン: ゼロか存在する下位のホストオブジェクトの完全に修飾された名前を含むホスト>要素がこの「スーパー-縦座標」ドメインの下で反対します。
- A <domain:clID> element that contains the identifier of the
sponsoring client.
- <ドメイン: 後援しているクライアントの識別子を含むclID>要素。
- An OPTIONAL <domain:crID> element that contains the identifier of
the client that created the domain object.
- OPTIONAL<ドメイン: ドメインオブジェクトを作成したクライアントの識別子を含むcrID>要素。
- An OPTIONAL <domain:crDate> element that contains the date and
time of domain object creation.
- OPTIONAL<ドメイン: ドメインオブジェクト作成の日時を含むcrDate>要素。
- An OPTIONAL <domain:exDate> element that contains the date and
time identifying the end of the domain object's registration
period.
- OPTIONAL<ドメイン: ドメインオブジェクトの登録の期間の終わりを特定する日時を含むexDate>要素。
- An OPTIONAL <domain:upID> element that contains the identifier of
the client that last updated the domain object. This element MUST
NOT be present if the domain has never been modified.
- OPTIONAL<ドメイン: ドメインオブジェクトをアップデートしたクライアントの識別子を含む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.
- OPTIONAL<ドメイン: 最新のドメインオブジェクト修飾の日時を含むupDate>要素。 ドメインオブジェクトが一度も変更されたことがないなら、この要素は存在しているはずがありません。
- An OPTIONAL <domain:trDate> element that contains the date and
time of the most recent successful domain object transfer. This
element MUST NOT be provided if the domain object has never been
transferred.
- OPTIONAL<ドメイン: 最新のうまくいっているドメインオブジェクト転送の日時を含むtrDate>要素。 ドメインオブジェクトを一度も移したことがないなら、この要素を提供してはいけません。
Hollenbeck Standards Track [Page 13] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[13ページ]RFC4931EPPドメイン名
- An OPTIONAL <domain:authInfo> element that contains authorization
information associated with the domain object. This element MUST
only be returned if the querying client is the current sponsoring
client, or if the client supplied valid authorization information
with the command.
- OPTIONAL<ドメイン: 承認情報を含む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>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ドメイン: infData S: xmlns: ドメイン=、「つぼ:ietf:params: xml:ナノ秒:ドメイン1インチの>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: roid>EXAMPLE1-レップ</ドメイン: roid>S: <ドメイン: 状態sは「OK」/>Sと等しいです: <ドメイン: 記入者>jd1234</ドメイン: 記入者>S: <ドメイン: タイプ=に連絡してください、「アドミン、「>sh8013</ドメイン: >Sに連絡してください」 <ドメイン: タイプ=に連絡してください、「科学技術、「>sh8013</ドメイン: >Sに連絡してください」 <ドメイン: ナノ秒>S: <ドメイン: hostObj>ns1.example.com</ドメイン: hostObj>S: <ドメイン: hostObj>ns1.example.net</ドメイン: hostObj>S: </ドメイン: ナノ秒>S: <ドメイン: ホスト>ns1.example.com</ドメイン: >Sを接待してください: <ドメイン: ホスト>ns2.example.com</ドメイン: >Sを接待してください: <ドメイン: clID>ClientX</ドメイン: clID>S: <ドメイン: crID>ClientY</ドメイン: crID>S: <ドメイン: crDate>1999-04-03T22:00:00.0Z</ドメイン: crDate>S: <ドメイン: upID>ClientX</ドメイン: upID>S: <ドメイン: >1999-12-03T09:00:00.0Z</ドメインをアップデートしてください: >Sをアップデートしてください: <ドメイン: exDate>2005-04-03T22:00:00.0Z</ドメイン: exDate>S: <ドメイン: trDate>2000-04-08T09:00:00.0Z</ドメイン: trDate>S: <ドメイン: authInfo>S: <ドメイン: pw>2fooBAR</ドメイン: pw>S: </ドメイン: authInfo>S: </ドメイン: infData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54322-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
Hollenbeck Standards Track [Page 14] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[14ページ]RFC4931EPPドメイン名
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>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ドメイン: infData S: xmlns: ドメイン=、「つぼ:ietf:params: xml:ナノ秒:ドメイン1インチの>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: roid>EXAMPLE1-レップ</ドメイン: roid>S: <ドメイン: clID>ClientX</ドメイン: clID>S: </ドメイン: infData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54322-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
An EPP error response MUST be returned if an <info> command cannot be processed for any reason.
どんな理由でも<インフォメーション>コマンドを処理できないなら、EPP誤り応答を返さなければなりません。
3.1.3. EPP <transfer> Query Command
3.1.3. EPP<転送>質問命令
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<転送>命令はクライアントが未定の、そして、完成した転送要求のリアルタイムの状態を決定できる質問操作を提供します。 標準のEPP指揮機関に加えて、<転送>命令は値の「質問」、および<ドメインがある「オプアート」属性を含まなければなりません: ドメイン名前空間を特定する>要素を移してください。 <ドメイン: 転送>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object to be queried.
- <ドメイン: 質問されるべきドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- 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
- OPTIONAL<ドメイン: ドメインオブジェクトに関連している承認情報か承認情報を含むauthInfo>要素がドメインオブジェクトの記入者か関連接触と交際しました。 そしてそして、記入者か接触オブジェクトを特定するのにOPTIONAL"roid"属性を使用しなければならない、与えられたauthInfoが記入者か接触に関連している場合にだけ反対してください。
Hollenbeck Standards Track [Page 15] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[15ページ]RFC4931EPPドメイン名
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.
ドメインオブジェクト自体でない。 この要素が提供されないか、または承認情報が無効であるなら、サーバ方針は、コマンドが拒絶されるかどうか、または応答情報がクライアントに返されるかどうか決定します。
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>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>C:」 <コマンド>C: <転送オプアート=、「質問、「>C:」 <ドメイン: 転送C: xmlns: ドメイン=、「つぼ:ietf:params: xml:ナノ秒:ドメイン1インチの>C:」 <ドメイン: 名前>example.com</ドメイン: >をCと命名してください: <ドメイン: authInfo>C: <ドメイン: pw roidが等しい、「JD1234-レップ、「>2fooBAR</ドメイン: pw>C:、」 </ドメイン: authInfo>C: </ドメイン: >Cを移してください: </転送>C: <clTRID>ABC-12345</clTRID>C: </コマンド>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:
首尾よく<転送>質問命令を処理してあるとき、EPP<resData>要素は子供<ドメインを含まなければなりません: ドメイン名前空間を特定するtrnData>要素。 <ドメイン: trnData>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object.
- <ドメイン: ドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- 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.
- <ドメイン: オブジェクト転送を要求したクライアントの識別子を含む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.
- <ドメイン: SHOULDがPENDING転送要求に演じるクライアントの識別子を含むacID>要素。 他のすべての状態タイプのために、値は示された行動を取ったクライアントを特定します。
Hollenbeck Standards Track [Page 16] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[16ページ]RFC4931EPPドメイン名
- 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.
- <ドメイン: 必要であるか完成した応答の日時を含むacDate>要素。 PENDING要求のために、値は日時をサーバで自動化された応答行動を取る前に応答を必要とする特定します。他のすべての状態タイプのために、値は要求が終了した日時を特定します。
- 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.
- OPTIONAL<ドメイン: <転送>命令が有効期間に変化を引き起こすか、または引き起こすならドメインオブジェクトの有効期間の終わりを含むexDate>要素。
Example <transfer> query response:
例の<転送>質問応答:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>example.com</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>ClientX</domain:reID> S: <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate> S: <domain:acID>ClientY</domain:acID> S: <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate> S: <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ドメイン: trnData S: xmlns: ドメイン=、「つぼ:ietf:params: xml:ナノ秒:ドメイン1インチの>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: </ドメインまでtrStatus>: trStatus>S: <ドメイン: reID>ClientX</ドメイン: reID>S: <ドメイン: reDate>2000-06-06T22:00:00.0Z</ドメイン: reDate>S: <ドメイン: 酸の>ClientY</ドメイン: 酸の>S: <ドメイン: acDate>2000-06-11T22:00:00.0Z</ドメイン: acDate>S: <ドメイン: exDate>2002-09-08T22:00:00.0Z</ドメイン: exDate>S: </ドメイン: trnData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54322-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
An EPP error response MUST be returned if a <transfer> query command cannot be processed for any reason.
どんな理由でも<転送>質問命令を処理できないなら、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つのコマンドを提供します: <はドメインオブジェクトのインスタンスを作成するために>を作成して、<はドメインオブジェクトのインスタンスを削除するために>を削除して、<は、ドメインオブジェクト(ドメインオブジェクトスポンサーシップ変化、および<アップデート>を情報がドメインオブジェクトに関連づけた変化に管理する<転送>)の有効期間を延ばすために>を取り替えます。
Hollenbeck Standards Track [Page 17] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[17ページ]RFC4931EPPドメイン名
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<は>コマンドを作成します。
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<はコマンドがクライアントがドメインオブジェクトを作成できる変換操作を供給する>を作成します。 標準のEPPに加えて指揮機関、<は>を作成します。コマンドは<ドメインを含まなければなりません: ドメイン名前空間を特定する>要素を作成してください。 <ドメイン: >を作成してください。要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object to be created.
- <ドメイン: 作成されるべきドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- An OPTIONAL <domain:period> element that contains the initial
registration period of the domain object. A server MAY define a
default initial registration period if not specified by the
client.
- OPTIONAL<ドメイン: ドメインオブジェクトの新規登録の期間を含む期間の>要素。 クライアントによって指定されないなら、サーバはデフォルト新規登録の期間を定義するかもしれません。
- 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.
- OPTIONAL<ドメイン: 代表として派遣されたホストオブジェクトの完全に修飾された名前を含む>要素かドメインに関連しているホスト属性(ネームサーバ)が反対するナノ秒はドメインのための解決サービスを提供します。 要素の記述のためのセクション1.1が以前はよくホストオブジェクトかホスト属性を指定していたのを確実にしてください。 ホストオブジェクトをドメインオブジェクトに関連づけることができる前にホストオブジェクトをサーバに知っていなければなりません。
- 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].
- OPTIONAL<ドメイン: オブジェクト記入者としてドメインオブジェクトに関連している人間の、または、組織的な社会情報(接触)オブジェクトのために識別子を含む記入者>要素。 接触オブジェクトをドメインオブジェクトに関連づけることができる前にこのオブジェクト識別子をサーバに知っていなければなりません。 オブジェクトを接触に写像するEPPは[RFC4933]で説明されます。
Hollenbeck Standards Track [Page 18] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[18ページ]RFC4931EPPドメイン名
- 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.
- より多くのOPTIONAL<ドメイン: ゼロか関連している他の接触オブジェクトのための識別子を含む連絡>要素がドメインで反対します。 接触オブジェクトをドメインオブジェクトに関連づけることができる前に連絡オブジェクト識別子をサーバに知っていなければなりません。
- 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.
- <ドメイン: ドメインオブジェクトに関連づけられるべき承認情報を含むauthInfo>要素。 このマッピングはパスワードベースの認証機構を含んでいますが、図式は、新しいメカニズムが新しいschemasで定義されるのを許容します。
Example <create> 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: <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>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>C:」 <コマンド>C: <は>Cを作成します: <ドメイン: Cを作成してください: xmlns: ドメイン=、「つぼ:ietf:params: xml:ナノ秒:ドメイン1インチの>C:」 <ドメイン: 名前>example.com</ドメイン: >をCと命名してください: <ドメイン: 期間の単位=、「y、「>2</ドメイン: 期間の>C:、」 <ドメイン: ナノ秒>C: <ドメイン: hostObj>ns1.example.com</ドメイン: hostObj>C: <ドメイン: hostObj>ns1.example.net</ドメイン: hostObj>C: </ドメイン: ナノ秒>C: <ドメイン: 記入者>jd1234</ドメイン: 記入者>C: <ドメイン: タイプ=に連絡してください、「アドミン、「>sh8013</ドメイン: >Cに連絡してください」 <ドメイン: タイプ=に連絡してください、「科学技術、「>sh8013</ドメイン: >Cに連絡してください」 <ドメイン: authInfo>C: <ドメイン: pw>2fooBAR</ドメイン: pw>C: </ドメイン: authInfo>C: </ドメイン: >Cを作成してください: </は>Cを作成します: <clTRID>ABC-12345</clTRID>C: </コマンド>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:
EPP<resData>要素は子供<ドメインを含まなければなりません: 首尾よく<がいつ>コマンドを作成するか処理してあって、ドメイン名前空間を特定するcreData>要素。 <ドメイン: creData>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object.
- <ドメイン: ドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- A <domain:crDate> element that contains the date and time of
domain object creation.
- <ドメイン: ドメインオブジェクト作成の日時を含むcrDate>要素。
Hollenbeck Standards Track [Page 19] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[19ページ]RFC4931EPPドメイン名
- An OPTIONAL <domain:exDate> element that contains the date and
time identifying the end of the domain object's registration
period.
- OPTIONAL<ドメイン: ドメインオブジェクトの登録の期間の終わりを特定する日時を含むexDate>要素。
Example <create> 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: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>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ドメイン: creData S: xmlns: ドメイン=、「つぼ:ietf:params: xml:ナノ秒:ドメイン1インチの>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: crDate>1999-04-03T22:00:00.0Z</ドメイン: crDate>S: <ドメイン: exDate>2001-04-03T22:00:00.0Z</ドメイン: exDate>S: </ドメイン: creData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54321-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
An EPP error response MUST be returned if a <create> command cannot be processed for any reason.
<が>コマンドを作成するなら、どんな理由でも、応答を返さなければならないEPP誤りを処理できません。
3.2.2. EPP <delete> Command
3.2.2. EPP<は>コマンドを削除します。
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<はコマンドがクライアントがドメインオブジェクトを削除できる変換操作を供給する>を削除します。 標準のEPPに加えて指揮機関、<は>を削除します。コマンドは<ドメインを含まなければなりません: ドメイン名前空間を特定する>要素を削除してください。 <ドメイン: >を削除してください。要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object to be deleted.
- <ドメイン: 削除されるべきドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
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
ドメイン、SHOULD NOTはオブジェクトが関連している削除されましたが、下位のホストがドメインオブジェクトであったなら反対します。 例えば、ドメイン"example.com"が存在していて、また、ホストオブジェクト"ns1.example.com"が存在していて、次に、ドメインが"example.com"であるというSHOULD NOTであるなら、ホスト"ns1.example.com"が異なった「スーパー-縦座標」ドメインに存在するように削除されるか、または改名されるまで、削除されてください。 SHOULDが2305年の誤り応答コードにいつを送るオブジェクト関係が生きさせるクライアントに通知するサーバ
Hollenbeck Standards Track [Page 20] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[20ページ]RFC4931EPPドメイン名
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.
<は既存のオブジェクト関係のため試みられた>コマンドを削除して、失敗します。 ドメインオブジェクトに関連している代表として派遣されて下位のホストオブジェクトは、ドメインオブジェクトに<インフォメーション>質問コマンドを使用することで決定できます。
Example <delete> 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: <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>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>C:」 <コマンド>C: <は>Cを削除します: <ドメイン: Cを削除してください: xmlns: ドメイン=、「つぼ:ietf:params: xml:ナノ秒:ドメイン1インチの>C:」 <ドメイン: 名前>example.com</ドメイン: >をCと命名してください: </ドメイン: >Cを削除してください: </は>Cを削除します: <clTRID>ABC-12345</clTRID>C: </コマンド>C: </epp>。
When a <delete> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.
首尾よく<がいつ>コマンドを削除するか処理してあって、サーバはEPP応答で<resData>要素なしで反応しなければなりません。
Example <delete> 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: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54321-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
An EPP error response MUST be returned if a <delete> command cannot be processed for any reason.
<が>コマンドを削除するなら、どんな理由でも、応答を返さなければならないEPP誤りを処理できません。
3.2.3. EPP <renew> Command
3.2.3. EPP<は>コマンドを更新します。
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
<が取り替えるEPPはクライアントがドメインオブジェクトの有効期間を延ばすことができる変換操作を提供します>が、命令する。 標準のEPPに加えて、指揮機関、<はコマンドが取り替えなければならない>を取り替えます。
Hollenbeck Standards Track [Page 21] RFC 4931 EPP Domain Name Mapping May 2007
2007年5月を写像するHollenbeck標準化過程[21ページ]RFC4931EPPドメイン名
contain a <domain:renew> element that identifies the domain namespace. The <domain:renew> element contains the following child elements:
<ドメインを含んでください: ドメイン名前空間を特定する>要素を取り替えてください。 <ドメイン: 更新してください。>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object whose validity period is to be extended.
- <ドメイン: 有効期間が延ばされることになっているドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- 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 <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.
- 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.
- 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:
Example <renew> 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: <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>
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:
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:
- A <domain:name> element that contains the fully qualified name of
the domain object.
- A <domain:name> element that contains the fully qualified name of the domain object.
- An OPTIONAL <domain:exDate> element that contains the date and
time identifying the end of the domain object's registration
period.
- An OPTIONAL <domain:exDate> element that contains the date and time identifying the end of the domain object's registration period.
Hollenbeck Standards Track [Page 22] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 22] RFC 4931 EPP Domain Name Mapping May 2007
Example <renew> response:
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>
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.
An EPP error response MUST be returned if a <renew> command cannot be processed for any reason.
3.2.4. EPP <transfer> Command
3.2.4. EPP <transfer> Command
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:
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:
- A <domain:name> element that contains the fully qualified name of
the domain object for which a transfer request is to be created,
approved, rejected, or cancelled.
- A <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.
- 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.
Hollenbeck Standards Track [Page 23] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 23] RFC 4931 EPP Domain Name Mapping May 2007
- 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 <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.
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].
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].
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.
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 <transfer> request command:
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>
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.
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.
Hollenbeck Standards Track [Page 24] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 24] RFC 4931 EPP Domain Name Mapping May 2007
Example <transfer> response:
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>
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.
An EPP error response MUST be returned if a <transfer> command can not be processed for any reason.
3.2.5. EPP <update> Command
3.2.5. EPP <update> Command
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:
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:
- A <domain:name> element that contains the fully qualified name of
the domain object to be updated.
- A <domain:name> element that contains the fully qualified name of the domain object to be updated.
- An OPTIONAL <domain:add> element that contains attribute values to
be added to the object.
- An OPTIONAL <domain:add> element that contains attribute values to be added to the object.
- An OPTIONAL <domain:rem> element that contains attribute values to
be removed from the object.
- An OPTIONAL <domain:rem> element that contains attribute values to be removed from the object.
Hollenbeck Standards Track [Page 25] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 25] RFC 4931 EPP Domain Name Mapping May 2007
- An OPTIONAL <domain:chg> element that contains object attribute
values to be changed.
- An OPTIONAL <domain:chg> element that contains object attribute values to be changed.
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:
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:
- 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.
- 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.
- 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: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.
- 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 <domain:chg> element contains the following child elements:
- 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 <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 <domain:authInfo> element that contains authorization
information associated with the domain object. This mapping
includes a password-based authentication mechanism, but the schema
allows new mechanisms to be defined in new schemas. A <domain:
null> element can be used within the <domain:authInfo> element to
remove authorization information.
- A <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.
Hollenbeck Standards Track [Page 26] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 26] RFC 4931 EPP Domain Name Mapping May 2007
Example <update> command:
Example <update> 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: <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>
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.
When an <update> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.
Hollenbeck Standards Track [Page 27] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 27] RFC 4931 EPP Domain Name Mapping May 2007
Example <update> response:
Example <update> 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: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S: </response> S:</epp>
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.
An EPP error response MUST be returned if an <update> command cannot be processed for any reason.
3.3. Offline Review of Requested Actions
3.3. Offline Review of Requested Actions
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.
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.
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.
Hollenbeck Standards Track [Page 28] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 28] RFC 4931 EPP Domain Name Mapping May 2007
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>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <resData> S: <domain:creData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>example.com</domain:name> S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> S: <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate> S: </domain:creData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S: </response> S:</epp>
The status of the domain object after returning this response MUST include "pendingCreate". The server operator reviews the request offline, and informs the client of the outcome of the review either by queuing a service message for retrieval via the <poll> command or by using an out-of-band mechanism to inform the client of the request.
The status of the domain object after returning this response MUST include "pendingCreate". The server operator reviews the request offline, and informs the client of the outcome of the review either by queuing a service message for retrieval via the <poll> command or by using an out-of-band mechanism to inform the client of the request.
The service message MUST contain text 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:
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:
- 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> 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: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 <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.
Hollenbeck Standards Track [Page 29] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 29] RFC 4931 EPP Domain Name Mapping May 2007
- A <domain:paDate> element that contains the date and time
describing when review of the requested action was completed.
- A <domain:paDate> element that contains the date and time describing when review of the requested action was completed.
Example "review completed" service message:
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>
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>
Hollenbeck Standards Track [Page 30] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 30] RFC 4931 EPP Domain Name Mapping May 2007
4. Formal Syntax
4. Formal Syntax
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.
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.
BEGIN <?xml version="1.0" encoding="UTF-8"?>
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">
<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"/>
<!-- 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>
<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">
<!-- 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">
Hollenbeck Standards Track [Page 31] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 31] RFC 4931 EPP Domain Name Mapping May 2007
<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>
<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>
<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="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>
<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="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. -->
Hollenbeck Standards Track [Page 32] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 32] RFC 4931 EPP Domain Name Mapping May 2007
<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="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>
<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>
<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>
<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>
<!-- 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>
Hollenbeck Standards Track [Page 33] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 33] RFC 4931 EPP Domain Name Mapping May 2007
<element name="name" type="eppcom:labelType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<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>
<!-- 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>
<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>
<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 <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.
<!-- Child elements of the <transfer> command.
Hollenbeck Standards Track [Page 34] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 34] RFC 4931 EPP Domain Name Mapping May 2007
-->
<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>
--> <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>
<!-- 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 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"
<!-- Data elements that can be changed. --> <complexType name="chgType"> <sequence> <element name="registrant" type="domain:clIDChgType" minOccurs="0"/> <element name="authInfo" type="domain:authInfoChgType"
Hollenbeck Standards Track [Page 35] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 35] RFC 4931 EPP Domain Name Mapping May 2007
minOccurs="0"/>
</sequence>
</complexType>
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 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>
<!-- 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"/>
<!-- 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>
<!-- <check> response elements. --> <complexType name="chkDataType"> <sequence> <element name="cd" type="domain:checkType" maxOccurs="unbounded"/> </sequence> </complexType>
<complexType name="checkType">
<complexType name="checkType">
Hollenbeck Standards Track [Page 36] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 36] RFC 4931 EPP Domain Name Mapping May 2007
<sequence>
<element name="name" type="domain:checkNameType"/>
<element name="reason" type="eppcom:reasonType"
minOccurs="0"/>
</sequence>
</complexType>
<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>
<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>
<!-- <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"/>
<!-- <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"/>
Hollenbeck Standards Track [Page 37] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 37] RFC 4931 EPP Domain Name Mapping May 2007
<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>
<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>
<!-- 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"/>
<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"/>
Hollenbeck Standards Track [Page 38] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 38] RFC 4931 EPP Domain Name Mapping May 2007
<enumeration value="serverTransferProhibited"/>
<enumeration value="serverUpdateProhibited"/>
</restriction>
</simpleType>
<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>
<!-- 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>
<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>
<!-- <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"
<!-- <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"
Hollenbeck Standards Track [Page 39] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 39] RFC 4931 EPP Domain Name Mapping May 2007
minOccurs="0"/>
</sequence>
</complexType>
minOccurs="0"/> </sequence> </complexType>
<!-- End of schema. --> </schema> END
<!-- End of schema. --> </schema> END
5. Internationalization Considerations
5. Internationalization Considerations
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 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.
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.
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.
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.
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.
6. IANA Considerations
6. IANA Considerations
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.
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.
Registration request for the domain namespace:
Registration request for the domain namespace:
URI: urn:ietf:params:xml:ns:domain-1.0
URI: urn:ietf:params:xml:ns:domain-1.0
Hollenbeck Standards Track [Page 40] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 40] RFC 4931 EPP Domain Name Mapping May 2007
Registrant Contact: See the "Author's Address" section of this document.
Registrant Contact: See the "Author's Address" section of this document.
XML: None. Namespace URIs do not represent an XML specification.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the domain XML schema:
Registration request for the domain XML schema:
URI: urn:ietf:params:xml:schema:domain-1.0
URI: urn:ietf:params:xml:schema:domain-1.0
Registrant Contact: See the "Author's Address" section of this document.
Registrant Contact: See the "Author's Address" section of this document.
XML: See the "Formal Syntax" section of this document.
XML: See the "Formal Syntax" section of this document.
7. Security Considerations
7. Security Considerations
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.
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.
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.
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.
8. Acknowledgements
8. Acknowledgements
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.
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.
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.
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.
Hollenbeck Standards Track [Page 41] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 41] RFC 4931 EPP Domain Name Mapping May 2007
9. References
9. References
9.1. Normative References
9.1. Normative References
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
RFC 4930, May 2007.
[RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 4930, May 2007.
[RFC4932] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Host Mapping", RFC 4932, May 2007.
[RFC4932] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", RFC 4932, May 2007.
[RFC4933] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", RFC 4933, May 2007.
[RFC4933] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", RFC 4933, May 2007.
[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., 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-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., 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-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. 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>.
Hollenbeck Standards Track [Page 42] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 42] RFC 4931 EPP Domain Name Mapping May 2007
9.2. Informative References
9.2. Informative References
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, February 2000.
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", RFC 3731, March 2004.
[RFC3731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 3731, March 2004.
Hollenbeck Standards Track [Page 43] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 43] RFC 4931 EPP Domain Name Mapping May 2007
Appendix A. Changes from RFC 3731
Appendix A. Changes from RFC 3731
1. Minor reformatting as a result of converting I-D source format
from nroff to XML.
1. Minor reformatting as a result of converting I-D source format from nroff to XML.
2. Removed this text from Section 2.3:
2. Removed this text from Section 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."
"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."
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. 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".
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. 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."
5. Renumbered old Section 3.2.6 to new Section 3.3.
5. Renumbered old Section 3.2.6 to new Section 3.3.
6. Changed text in Section 3.3 (old Section 3.2.6) from this:
6. Changed text in Section 3.3 (old Section 3.2.6) from this:
"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."
"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."
to this:
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."
"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."
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. 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.
8. Removed references to RFC 3339 and replaced them with references
to the W3C XML Schema specification.
8. Removed references to RFC 3339 and replaced them with references to the W3C XML Schema specification.
Hollenbeck Standards Track [Page 44] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 44] RFC 4931 EPP Domain Name Mapping May 2007
9. Updated EPP and XML references.
9. Updated EPP and XML references.
Author's Address
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
EMail: shollenbeck@verisign.com
Hollenbeck Standards Track [Page 45] RFC 4931 EPP Domain Name Mapping May 2007
Hollenbeck Standards Track [Page 45] RFC 4931 EPP Domain Name Mapping May 2007
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
Copyright (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.
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.
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.
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.
Intellectual Property
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Hollenbeck Standards Track [Page 46]
Hollenbeck標準化過程[46ページ]
一覧
スポンサーリンク
