RFC3732 日本語訳
3732 Extensible Provisioning Protocol (EPP) Host Mapping. S.Hollenbeck. March 2004. (Format: TXT=57082 bytes) (Obsoleted by RFC4932) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Hollenbeck Request for Comments: 3732 VeriSign, Inc. Category: Standards Track March 2004
Hollenbeckがコメントのために要求するワーキンググループS.をネットワークでつないでください: 3732年のベリサインInc.カテゴリ: 2004年の標準化過程行進
Extensible Provisioning Protocol (EPP) Host Mapping
広げることができる食糧を供給するプロトコル(EPP)ホストマッピング
Status of this Memo
この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 Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.
このドキュメントは、インターネットの食糧を供給するのと管理のために共有された中央倉庫に保存されたホスト名を写像しながら、Extensible Provisioningプロトコル(EPP)について説明します。 XMLで指定されていて、マッピングはEPPコマンド構文とホスト名に適用される意味論を定義します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Relationship of Host Objects and Domain Objects . . . . 2 1.2. Conventions Used In This Document . . . . . . . . . . . 3 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Host Names. . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Client Identifiers. . . . . . . . . . . . . . . . . . . 3 2.3. Status Values . . . . . . . . . . . . . . . . . . . . . 3 2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . 5 2.5. IP Addresses. . . . . . . . . . . . . . . . . . . . . . 5 3. EPP Command Mapping. . . . . . . . . . . . . . . . . . . . . . 6 3.1. EPP Query Commands. . . . . . . . . . . . . . . . . . . 6 3.1.1. EPP <check> Command . . . . . . . . . . . . . . 6 3.1.2. EPP <info> Command. . . . . . . . . . . . . . . 8 3.1.3. EPP <transfer> Query Command. . . . . . . . . . 10 3.2. EPP Transform Commands. . . . . . . . . . . . . . . . . 11 3.2.1. EPP <create> Command. . . . . . . . . . . . . . 11 3.2.2. EPP <delete> Command. . . . . . . . . . . . . . 13 3.2.3. EPP <renew> Command . . . . . . . . . . . . . . 14 3.2.4. EPP <transfer> Command. . . . . . . . . . . . . 14 3.2.5. EPP <update> Command. . . . . . . . . . . . . . 15
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. ホストオブジェクトとドメインオブジェクト. . . . 2 1.2の関係。 コンベンションは本書では.3 2を使用しました。 オブジェクト属性. . . . . . . . . . . . . . . . . . . . . . 3 2.1。 名前をホスティングしてください。 . . . . . . . . . . . . . . . . . . . . . . 3 2.2. クライアント識別子。 . . . . . . . . . . . . . . . . . . 3 2.3. 状態値. . . . . . . . . . . . . . . . . . . . . 3 2.4。 日付と回. . . . . . . . . . . . . . . . . . . . 5 2.5。 IPアドレス。 . . . . . . . . . . . . . . . . . . . . . 5 3. EPPはマッピングを命令します。 . . . . . . . . . . . . . . . . . . . . . 6 3.1. EPPはコマンドについて質問します。 . . . . . . . . . . . . . . . . . . 6 3.1.1. EPP<チェック>命令. . . . . . . . . . . . . . 6 3.1.2。 EPP<インフォメーション>コマンド。 . . . . . . . . . . . . . . 8 3.1.3. EPP<転送>質問命令。 . . . . . . . . . 10 3.2. EPPはコマンドを変えます。 . . . . . . . . . . . . . . . . 11 3.2.1. EPP<は>コマンドを作成します。 . . . . . . . . . . . . . 11 3.2.2. EPP<は>コマンドを削除します。 . . . . . . . . . . . . . 13 3.2.3. EPP<は>コマンド. . . . . . . . . . . . . . 14 3.2.4を更新します。 EPP<転送>命令。 . . . . . . . . . . . . 14 3.2.5. EPP<アップデート>命令。 . . . . . . . . . . . . . 15
Hollenbeck Standards Track [Page 1] RFC 3732 EPP Host Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[1ページ]RFC3732EPPホスト
3.2.6. Offline Review of Requested Actions . . . . . . 17 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Internationalization Considerations . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 25 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Normative References. . . . . . . . . . . . . . . . . . 26 9.2. Informative References. . . . . . . . . . . . . . . . . 27 10. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 27 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28
3.2.6. 要求された動作. . . . . . 17 4のオフラインレビュー。 正式な構文. . . . . . . . . . . . . . . . . . . . . . . . 19 5。 国際化問題. . . . . . . . . . . . . 24 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 25 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 25 8。 承認。 . . . . . . . . . . . . . . . . . . . . . . 25 9. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. 引用規格。 . . . . . . . . . . . . . . . . . 26 9.2. 有益な参照。 . . . . . . . . . . . . . . . . 27 10. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . 27 11. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 28
1. Introduction
1. 序論
This document describes an Internet host 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 [XML] and XML Schema notation as described in [XMLS-1] and [XMLS- 2].
このドキュメントはExtensible Provisioningのバージョン1.0のために、プロトコル(EPP)を写像するインターネットホスト名について説明します。 このマッピングは、[XMLS-1]と[XMLS2]で説明されるように[XML]とXML Schema記法で説明されるようにExtensible Markup Language(XML)1.0を使用することで指定されます。
[RFC3730] 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.
[RFC3730]は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 Host Objects and Domain Objects
1.1. ホストオブジェクトとドメインオブジェクトの関係
This document assumes that host name objects have a subordinate relationship to a superordinate domain name object. For example, host name "ns1.example.com" has a subordinate relationship to domain name "example.com". EPP actions (such as object transfers) that do not preserve this relationship MUST be explicitly disallowed.
このドキュメントは、ホスト名オブジェクトには「スーパー-縦座標」ドメイン名オブジェクトとの下位の関係があると仮定します。 例えば、ホスト名前"ns1.example.com"には、ドメイン名"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 an internal host is subordinate or not relates to a domain within the
ホストが外部である、または内部であるかがホストが委譲目的に使用されている倉庫に関連します。 内部のホストが下位であるかどうかが中でドメインに関連します。
Hollenbeck Standards Track [Page 2] RFC 3732 EPP Host Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[2ページ]RFC3732EPPホスト
repository. For example, host ns1.example1.com is a subordinate host of domain example1.com, but it is a 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の下位のホストではなく、aです。example2.comにネームサーバとしてns1.example1.comは使用できます。 この場合、同じ倉庫の中の下位のホストの上で操作を治める規則を条件として内部のホストとしてns1.example1.comを扱わなければなりません。
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 is provided only to illustrate element relationships and is not a REQUIRED feature of this protocol.
例で「C:」 そして、プロトコルクライアントによって送られた台詞を表す、「S:」 系列はプロトコルサーバで戻りました。表す、刻み目と白いスペースは、例に提供しますが、要素関係を例証して、このプロトコルのREQUIREDの特徴ではありません。
2. Object Attributes
2. オブジェクト属性
An EPP host 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. Host Names
2.1. ホスト名
The syntax for host names described in this document MUST conform to [RFC952] 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 in the future as a result of progressing work in developing standards for internationalized host names.
[RFC1123]によってアップデートされるように本書では説明されたホスト名のための構文は[RFC952]に従わなければなりません。 この書くこと時点で、RFC3490[RFC3490]は、非ASCIIネームラベルを表すのに、あるASCIIネームラベルを使用するために規格について説明します。 仕事に進歩すること国際化しているホスト名の規格が開発するの結果、これらの順応要件は将来、変化するかもしれません。
2.2. Client Identifiers
2.2. クライアント識別子
All EPP clients are identified by a server-unique identifier. Client identifiers conform to the "clIDType" syntax described in [RFC3730].
すべてのEPPクライアントがサーバユニークな識別子によって特定されます。 クライアント識別子は[RFC3730]で説明された"clIDType"構文に従います。
2.3. Status Values
2.3. 状態値
A host object MUST always have at least one associated status value. Status values MAY be set only by the client that sponsors a host object and by the server on which the object resides. A client can change the status of a host object using the EPP <update> command. Each status value MAY be accompanied by a string of human-readable
ホストオブジェクトには、少なくとも1つの関連状態値がいつもなければなりません。 状態値はホストオブジェクトを後援するクライアントの近くとだけ、そして、オブジェクトが住んでいるサーバで設定されるかもしれません。 クライアントは、EPP<アップデート>命令を使用することでホストオブジェクトの状態を変えることができます。 各状態値は人間読み込み可能のストリングによって伴われるかもしれません。
Hollenbeck Standards Track [Page 3] RFC 3732 EPP Host Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[3ページ]RFC3732EPPホスト
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.
オブジェクトを削除するという要求を拒絶しなければなりません。
- clientUpdateProhibited, serverUpdateProhibited
- clientUpdateProhibited、serverUpdateProhibited
Requests to update the object (other than to remove this status) MUST be rejected.
オブジェクト(この状態を取り除くのを除いた)をアップデートするという要求を拒絶しなければなりません。
- linked
- リンクされます。
The host object has at least one active association with another object, such as a domain object. Servers SHOULD provide services to determine existing object associations.
ホストオブジェクトには、ドメインオブジェクトなどの別のオブジェクトとの少なくとも1つの活動的な協会があります。 サーバSHOULDは、既存のオブジェクト協会を決定するためにサービスを提供します。
- ok
- OK
This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.
これは未定の操作か禁止を全く持っていないオブジェクトのための正常な状態値です。 他の状態値を加えるか、または取り除くとき、サーバはこの値を設定して、取り除きます。
- pendingCreate, pendingDelete, pendingTransfer, pendingUpdate
- pendingCreate、pendingDelete、pendingTransfer、pendingUpdate
A transform command has been processed for the object (or in the case of a <transfer> command, for the host object's superordinate domain 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で有名です。
Hollenbeck Standards Track [Page 4] RFC 3732 EPP Host Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[4ページ]RFC3732EPPホスト
Transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status is set.
pendingCreate、pendingDelete、pendingTransfer、またはpendingUpdate状態が用意ができているとき、変形コマンドを拒絶しなければなりません。
When the requested action has been completed, the pendingCreate, pendingDelete, 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、pendingTransfer、またはpendingUpdate状態値を取り外さなければなりません。 操作が完了して、オブジェクトの状態が変化したというサービスメッセージを使用して、トランザクションにかかわるすべてのクライアントに通知しなければなりません。
"ok" status MAY only be combined with "linked" status.
「間違いありません、な」状態は「繋がっている」状態に結合されるだけであるかもしれません。
"linked" status MAY be combined with any status.
「繋がっている」状態はどんな状態にも結合されるかもしれません。
"pendingDelete" status MUST NOT be combined with either "clientDeleteProhibited" or "serverDeleteProhibited" status.
"clientDeleteProhibited"か"serverDeleteProhibited"状態のどちらかに"pendingDelete"状態を結合してはいけません。
"pendingUpdate" status MUST NOT be combined with either "clientUpdateProhibited" or "serverUpdateProhibited" status.
"clientUpdateProhibited"か"serverUpdateProhibited"状態のどちらかに"pendingUpdate"状態を結合してはいけません。
The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate status values MUST NOT be combined with each other.
pendingCreate、pendingDelete、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 [RFC3339] 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」を使用する拡張日付-時間書式と[RFC3339]で定義された「Z」キャラクタを使用しなければなりません。
2.5. IP Addresses
2.5. IPアドレス
The syntax for IPv4 addresses described in this document MUST conform to [RFC791]. The syntax for IPv6 addresses described in this document MUST conform to [RFC3513]. Practical considerations for publishing IPv6 address information in zone files are documented in [RFC1886], [RFC2874], and [RFC3152]. A server MAY reject IP addresses that have not been allocated for public use by IANA. When a host object is provisioned for use as a DNS name server, IP addresses SHOULD be required only as needed to generate DNS glue records.
本書では説明されたIPv4アドレスのための構文は[RFC791]に従わなければなりません。 本書では説明されたIPv6アドレスのための構文は[RFC3513]に従わなければなりません。 ゾーンファイルの出版IPv6アドレス情報のための実用的な問題は[RFC1886]、[RFC2874]、および[RFC3152]に記録されます。 サーバは公共の使用のためにIANAによって割り当てられていないIPアドレスを拒絶するかもしれません。 ホストオブジェクトが使用のために食糧を供給されたら、DNSネームサーバ、IPがSHOULDを扱うように、単にDNSが接着剤記録であると生成するのが必要であるように必要であってください。
Hollenbeck Standards Track [Page 5] RFC 3732 EPP Host Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[5ページ]RFC3732EPPホスト
3. EPP Command Mapping
3. EPPコマンドマッピング
A detailed description of the EPP syntax and semantics can be found in [RFC3730]. The command mappings described here are specifically for use in provisioning and managing Internet host names via EPP.
[RFC3730]でEPP構文と意味論の詳述を見つけることができます。 ここで説明されたコマンドマッピングは特にEPPを通してインターネットホスト名に食糧を供給して、管理することにおける使用のためのものです。
3.1. EPP Query Commands
3.1. EPP質問命令
EPP provides two commands to retrieve host information: <check> to determine if a host object can be provisioned within a repository, and <info> to retrieve detailed information associated with a host object.
EPPはホスト情報を検索する2つのコマンドを提供します: 詳細な情報を検索するために倉庫、および<インフォメーション>の中でホストオブジェクトに食糧を供給することができるかどうか決定する<チェック>はホストオブジェクトと交際しました。
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 <host:check> element that identifies the host namespace and the location of the host schema. The <host:check> element contains the following child elements:
標準のEPP指揮機関に加えて、<チェック>命令は<ホストを含まなければなりません: ホスト名前空間とホスト図式の位置を特定する>要素をチェックしてください。 <ホスト: チェック>要素は以下の子供要素を含んでいます:
- One or more <host:name> elements that contain the fully qualified names of the host 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd"> C: <command> C: <check> C: <host:check C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 C: host-1.0.xsd"> C: <host:name>ns1.example.com</host:name> C: <host:name>ns2.example.com</host:name> C: <host:name>ns3.example.com</host:name> C: </host:check> C: </check> C: <clTRID>ABC-12345</clTRID>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <チェック>C: <ホスト: Cをチェックしてください: xmlns: ホスト、= 「つぼ:ietf:params:xml:ナノ秒: 以下を-何1インチCも接待してください」 xsi: schemaLocation、= 「つぼ:ietf:params:xml:ナノ秒: -1.0にCを接待してください」 ホスト-1.0.xsd、「>C:」 <ホスト: 名前>ns1.example.com</ホスト: >をCと命名してください: <ホスト: 名前>ns2.example.com</ホスト: >をCと命名してください: <ホスト: 名前>ns3.example.com</ホスト: >をCと命名してください: </ホスト: >Cをチェックしてください: </チェック>C: <clTRID>ABC-12345</clTRID>。
Hollenbeck Standards Track [Page 6] RFC 3732 EPP Host Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[6ページ]RFC3732EPPホスト
C: </command> C:</epp>
C: </コマンド>C: </epp>。
When a <check> command has been processed successfully, the EPP <resData> element MUST contain a child <host:chkData> element that identifies the host namespace and the location of the host schema. The <host:chkData> element contains one or more <host:cd> elements that contain the following child elements:
首尾よく<チェック>命令を処理してあるとき、EPP<resData>要素は子供<ホストを含まなければなりません: ホスト名前空間とホスト図式の位置を特定するchkData>要素。 <ホスト: chkData>要素は1人以上の<ホスト: 以下の子供要素を含むcd>要素を含んでいます:
- A <host:name> element that contains the fully qualified name of the queried host 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 <host:reason> element that MAY be provided when an object can not be provisioned. If present, this element contains server-specific text to help explain why the object can not 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <host:chkData S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 S: host-1.0.xsd"> S: <host:cd> S: <host:name avail="1">ns1.example.com</host:name> S: </host:cd> S: <host:cd> S: <host:name avail="0">ns2.example2.com</host:name> S: <host:reason>In use</host:reason>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ホスト: chkData S: xmlns: ホスト、= 「つぼ:ietf:params:xml:ナノ秒: 以下を-何1インチSも接待してください」 xsi: schemaLocation、= 「つぼ:ietf:params:xml:ナノ秒: -1.0秒間、以下を接待してください」 ホスト-1.0.xsd、「>S:」 <ホスト: cd>S: <ホスト: 名前は役に立ちます。= 「1インチの>ns1.example.com</は: 名義の>Sを接待します」。 </ホスト: cd>S: <ホスト: cd>S: <ホスト: 名前は役に立ちます。= 「0インチの>ns2.example2.com</は: 名義の>Sを接待します」。 <ホスト: 理由>Inは</ホストを使用します: >を推論してください。
Hollenbeck Standards Track [Page 7] RFC 3732 EPP Host Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[7ページ]RFC3732EPPホスト
S: </host:cd> S: <host:cd> S: <host:name avail="1">ns3.example3.com</host:name> S: </host:cd> S: </host:chkData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: </ホスト: cd>S: <ホスト: cd>S: <ホスト: 名前は役に立ちます。= 「1インチの>ns3.example3.com</は: 名義の>Sを接待します」。 </ホスト: cd>S: </ホスト: chkData>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 <check> command can not 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 host object. In addition to the standard EPP command elements, the <info> command MUST contain a <host:info> element that identifies the host namespace and the location of the host schema. The <host:info> element contains the following child elements:
EPP<インフォメーション>コマンドは、ホストオブジェクトに関連している情報を検索するのに使用されます。 標準のEPP指揮機関に加えて、<インフォメーション>コマンドは<ホストを含まなければなりません: ホスト名前空間とホスト図式の位置を特定するインフォメーション>要素。 <ホスト: インフォメーション>要素は以下の子供要素を含んでいます:
- A <host:name> element that contains the fully qualified name of the host object for which information is requested.
- <ホスト: どの情報のためにホストオブジェクトの完全に修飾された名前を含む名前>要素が要求されています。
Example <info> command:
例の<インフォメーション>コマンド:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd"> C: <command> C: <info> C: <host:info C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 C: host-1.0.xsd"> C: <host:name>ns1.example.com</host:name> C: </host:info> C: </info> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <インフォメーション>C: <ホスト: インフォメーションC: xmlns: ホスト、= 「つぼ:ietf:params:xml:ナノ秒: 以下を-何1インチCも接待してください」 xsi: schemaLocation、= 「つぼ:ietf:params:xml:ナノ秒: -1.0にCを接待してください」 ホスト-1.0.xsd、「>C:」 <ホスト: 名前>ns1.example.com</ホスト: >をCと命名してください: </ホスト: インフォメーション>C: </インフォメーション>C: <clTRID>ABC-12345</clTRID>C: </コマンド>C: </epp>。
Hollenbeck Standards Track [Page 8] RFC 3732 EPP Host Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[8ページ]RFC3732EPPホスト
When an <info> command has been processed successfully, the EPP <resData> element MUST contain a child <host:infData> element that identifies the host namespace and the location of the host schema. The <host:infData> element contains the following child elements:
首尾よく<インフォメーション>コマンドを処理してあるとき、EPP<resData>要素は子供<ホストを含まなければなりません: ホスト名前空間とホスト図式の位置を特定するinfData>要素。 <ホスト: infData>要素は以下の子供要素を含んでいます:
- A <host:name> element that contains the fully qualified name of the host object.
- <ホスト: ホストオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- A <host:roid> element that contains the Repository Object IDentifier assigned to the host object when the object was created.
- <ホスト: オブジェクトが作成されたときホストオブジェクトに割り当てられたRepository Object IDentifierを含むroid>要素。
- One or more <host:status> elements that describe the status of the host object.
- 1人以上の<ホスト: ホストオブジェクトの状態について説明する状態>要素。
- Zero or more <host:addr> elements that contain the IP addresses associated with the host object.
- より多くの<ホスト: ゼロかアドレスが関連づけたIPを含むaddr>要素がホストと共に反対します。
- A <host:clID> element that contains the identifier of the sponsoring client.
- <ホスト: 後援しているクライアントの識別子を含むclID>要素。
- A <host:crID> element that contains the identifier of the client that created the host object.
- <ホスト: ホストオブジェクトを作成したクライアントの識別子を含むcrID>要素。
- A <host:crDate> element that contains the date and time of host object creation.
- <ホスト: ホストオブジェクト作成の日時を含むcrDate>要素。
- A <host:upID> element that contains the identifier of the client that last updated the host object. This element MUST NOT be present if the host object has never been modified.
- <ホスト: ホストオブジェクトをアップデートしたクライアントの識別子を含むupID>要素。 ホストオブジェクトが一度も変更されたことがないなら、この要素は存在しているはずがありません。
- A <host:upDate> element that contains the date and time of the most recent host object modification. This element MUST NOT be present if the host object has never been modified.
- <ホスト: 最新のホストオブジェクト修飾の日時を含むupDate>要素。 ホストオブジェクトが一度も変更されたことがないなら、この要素は存在しているはずがありません。
- A <host:trDate> element that contains the date and time of the most recent successful host object transfer. This element MUST NOT be provided if the host object has never been transferred. Note that host objects MUST NOT be transferred directly; host objects MUST be transferred implicitly when the host object's superordinate domain object is transferred. 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.
- <ホスト: 最新のうまくいっているホストオブジェクト転送の日時を含むtrDate>要素。 ホストオブジェクトを一度も移したことがないなら、この要素を提供してはいけません。 直接ホストオブジェクトを移してはいけないことに注意してください。 ホストオブジェクトの「スーパー-縦座標」ドメインオブジェクトがわたっているとき、それとなくホストオブジェクトを移さなければなりません。 ドメインオブジェクトを移すとき転送を被りやすいホストオブジェクトはドメインオブジェクトに実行されたEPP<インフォメーション>コマンドへの応答で記載されています。
Hollenbeck Standards Track [Page 9] RFC 3732 EPP Host Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[9ページ]RFC3732EPPホスト
Example <info> response:
例の<インフォメーション>応答:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <host:infData S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 S: host-1.0.xsd"> S: <host:name>ns1.example.com</host:name> S: <host:roid>NS1_EXAMPLE1-REP</host:roid> S: <host:status s="linked"/> S: <host:status s="clientUpdateProhibited"/> S: <host:addr ip="v4">192.0.2.2</host:addr> S: <host:addr ip="v4">192.0.2.29</host:addr> S: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr> S: <host:clID>ClientY</host:clID> S: <host:crID>ClientX</host:crID> S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate> S: <host:upID>ClientX</host:upID> S: <host:upDate>1999-12-03T09:00:00.0Z</host:upDate> S: <host:trDate>2000-04-08T09:00:00.0Z</host:trDate> S: </host: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:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ホスト: infData S: xmlns: ホスト、= 「つぼ:ietf:params:xml:ナノ秒: 以下を-何1インチSも接待してください」 xsi: schemaLocation、= 「つぼ:ietf:params:xml:ナノ秒: -1.0秒間、以下を接待してください」 ホスト-1.0.xsd、「>S:」 <ホスト: 名前>ns1.example.com</ホスト: >をSと命名してください: <ホスト: </ホスト: roid>NS1_EXAMPLE1-レップroid>S: <ホスト: 状態sは「リンク」/>Sと等しいです: <ホスト: 状態sは"clientUpdateProhibited"/>Sと等しいです: <は: addr ipを接待します。= 「v4">192.0.2.2</は: addr>Sを接待します」。 <は: addr ipを接待します。= 「v4">192.0.2.29</は: addr>Sを接待します」。 <ホスト: addr ipが等しい、「v6">、1080:、0:0:0、:、8:800:200、C: 417A</ホスト: addr>S:、」 <ホスト: clID>ClientY</ホスト: clID>S: <ホスト: crID>ClientX</ホスト: crID>S: <ホスト: crDate>1999-04-03T22:00:00.0Z</ホスト: crDate>S: <ホスト: upID>ClientX</ホスト: upID>S: <ホスト: >1999-12-03T09:00:00.0Z</ホストをアップデートしてください: >Sをアップデートしてください: <ホスト: trDate>2000-04-08T09:00:00.0Z</ホスト: trDate>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 can not be processed for any reason.
どんな理由でも<インフォメーション>コマンドを処理できないなら、EPP誤り応答を返さなければなりません。
3.1.3. EPP <transfer> Query Command
3.1.3. EPP<転送>質問命令
Transfer semantics do not directly apply to host objects, so there is no mapping defined for the EPP <transfer> query command.
転送意味論が直接ホストオブジェクトに適用されないので、EPP<転送>質問命令のために定義された写像がありません。
Hollenbeck Standards Track [Page 10] RFC 3732 EPP Host Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[10ページ]RFC3732EPPホスト
3.2. EPP Transform Commands
3.2. EPP変形コマンド
EPP provides three commands to transform host objects: <create> to create an instance of a host object, <delete> to delete an instance of a host object, and <update> to change information associated with a host object. This document does not define host object mappings for the EPP <renew> and <transfer> commands.
EPPはホストオブジェクトを変える3つのコマンドを提供します: <はホストオブジェクトのインスタンスを作成するために>を作成して、<は、ホストオブジェクト、および<アップデート>のインスタンスをホストオブジェクトに関連している変化情報に削除するために>を削除します。 EPP<が>と<転送>命令を取り替えるので、このドキュメントはホストオブジェクトマッピングを定義しません。
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.
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.
3.2.1. EPP <create> Command
3.2.1. EPP <create> Command
The EPP <create> command provides a transform operation that allows a client to create a host object. In addition to the standard EPP command elements, the <create> command MUST contain a <host:create> element that identifies the host namespace and the location of the host schema. The <host:create> element contains the following child elements:
The EPP <create> command provides a transform operation that allows a client to create a host object. In addition to the standard EPP command elements, the <create> command MUST contain a <host:create> element that identifies the host namespace and the location of the host schema. The <host:create> element contains the following child elements:
- A <host:name> element that contains the fully qualified name of the host object to be created.
- A <host:name> element that contains the fully qualified name of the host object to be created.
- Zero or more <host:addr> 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.
- Zero or more <host:addr> 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.
Hosts can be provisioned for use as name servers in the Domain Name System (DNS), described in [RFC1034] and [RFC1035]. Hosts provisioned as name servers might be subject to server operator policies that require or prohibit specification of IP addresses depending on the name of the host and the name space in which the server will be used as a name server. When provisioned for use as a name server, IP addresses are REQUIRED only as needed to produce DNS glue records. For example, if the server is authoritative for the
Hosts can be provisioned for use as name servers in the Domain Name System (DNS), described in [RFC1034] and [RFC1035]. Hosts provisioned as name servers might be subject to server operator policies that require or prohibit specification of IP addresses depending on the name of the host and the name space in which the server will be used as a name server. When provisioned for use as a name server, IP addresses are REQUIRED only as needed to produce DNS glue records. For example, if the server is authoritative for the
Hollenbeck Standards Track [Page 11] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 11] RFC 3732 EPP Host Mapping March 2004
"com" name space and the name of the server is "ns1.example.net", the server is not required to produce DNS glue records for the name server and IP addresses for the server are not required by the DNS.
"com" name space and the name of the server is "ns1.example.net", the server is not required to produce DNS glue records for the name server and IP addresses for the server are not required by the DNS.
If the host name exists in a name space for which the server is authoritative, then the superordinate domain of the host MUST be known to the server before the host object can be created.
If the host name exists in a name space for which the server is authoritative, then the superordinate domain of the host MUST be known to the server before the host object can be created.
Example <create> command:
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd"> C: <command> C: <create> C: <host:create C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 C: host-1.0.xsd"> C: <host:name>ns1.example.com</host:name> C: <host:addr ip="v4">192.0.2.2</host:addr> C: <host:addr ip="v4">192.0.2.29</host:addr> C: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr> C: </host:create> C: </create> 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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd"> C: <command> C: <create> C: <host:create C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 C: host-1.0.xsd"> C: <host:name>ns1.example.com</host:name> C: <host:addr ip="v4">192.0.2.2</host:addr> C: <host:addr ip="v4">192.0.2.29</host:addr> C: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr> C: </host:create> C: </create> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
When a <create> command has been processed successfully, the EPP <resData> element MUST contain a child <host:creData> element that identifies the host namespace and the location of the host schema. The <host:creData> element contains the following child elements:
When a <create> command has been processed successfully, the EPP <resData> element MUST contain a child <host:creData> element that identifies the host namespace and the location of the host schema. The <host:creData> element contains the following child elements:
- A <host:name> element that contains the fully qualified name of the host object.
- A <host:name> element that contains the fully qualified name of the host object.
- A <host:crDate> element that contains the date and time of host object creation.
- A <host:crDate> element that contains the date and time of host object creation.
Example <create> response:
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
Hollenbeck Standards Track [Page 12] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 12] RFC 3732 EPP Host Mapping March 2004
S: epp-1.0.xsd"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <host:creData S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 S: host-1.0.xsd"> S: <host:name>ns1.example.com</host:name> S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate> S: </host:creData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: epp-1.0.xsd"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <host:creData S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 S: host-1.0.xsd"> S: <host:name>ns1.example.com</host:name> S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate> S: </host:creData> 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 <create> command can not be processed for any reason.
An EPP error response MUST be returned if a <create> command can not be processed for any reason.
3.2.2. EPP <delete> Command
3.2.2. EPP <delete> Command
The EPP <delete> command provides a transform operation that allows a client to delete a host object. In addition to the standard EPP command elements, the <delete> command MUST contain a <host:delete> element that identifies the host namespace and the location of the host schema. The <host:delete> element contains the following child elements:
The EPP <delete> command provides a transform operation that allows a client to delete a host object. In addition to the standard EPP command elements, the <delete> command MUST contain a <host:delete> element that identifies the host namespace and the location of the host schema. The <host:delete> element contains the following child elements:
- A <host:name> element that contains the fully qualified name of the host object to be deleted.
- A <host:name> element that contains the fully qualified name of the host object to be deleted.
A host name object MUST NOT be deleted if the host object is associated with any other object. For example, if the host object is associated with a domain object, the host object MUST NOT be deleted until the existing association has been broken.
A host name object MUST NOT be deleted if the host object is associated with any other object. For example, if the host object is associated with a domain object, the host object MUST NOT be deleted until the existing association has been broken.
Example <delete> command:
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd">
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd">
Hollenbeck Standards Track [Page 13] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 13] RFC 3732 EPP Host Mapping March 2004
C: <command> C: <delete> C: <host:delete C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 C: host-1.0.xsd"> C: <host:name>ns1.example.com</host:name> C: </host:delete> C: </delete> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
C: <command> C: <delete> C: <host:delete C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 C: host-1.0.xsd"> C: <host:name>ns1.example.com</host:name> C: </host:delete> C: </delete> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
When a <delete> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.
When a <delete> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.
Example <delete> response:
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S: </response> S:</epp>
An EPP error response MUST be returned if a <delete> command can not be processed for any reason.
An EPP error response MUST be returned if a <delete> command can not be processed for any reason.
3.2.3. EPP <renew> Command
3.2.3. EPP <renew> Command
Renewal semantics do not apply to host objects, so there is no mapping defined for the EPP <renew> command.
Renewal semantics do not apply to host objects, so there is no mapping defined for the EPP <renew> command.
3.2.4. EPP <transfer> Command
3.2.4. EPP <transfer> Command
Transfer semantics do not directly apply to host objects, so there is no mapping defined for the EPP <transfer> command. Host objects are subordinate to an existing superordinate domain object, and as such they are subject to transfer when a domain object is transferred.
Transfer semantics do not directly apply to host objects, so there is no mapping defined for the EPP <transfer> command. Host objects are subordinate to an existing superordinate domain object, and as such they are subject to transfer when a domain object is transferred.
Hollenbeck Standards Track [Page 14] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 14] RFC 3732 EPP Host Mapping March 2004
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 host object. In addition to the standard EPP command elements, the <update> command MUST contain a <host:update> element that identifies the host namespace and the location of the host schema. The <host: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 host object. In addition to the standard EPP command elements, the <update> command MUST contain a <host:update> element that identifies the host namespace and the location of the host schema. The <host:update> element contains the following child elements:
- A <host:name> element that contains the fully qualified name of the host object to be updated.
- A <host:name> element that contains the fully qualified name of the host object to be updated.
- An OPTIONAL <host:add> element that contains attribute values to be added to the object.
- An OPTIONAL <host:add> element that contains attribute values to be added to the object.
- An OPTIONAL <host:rem> element that contains attribute values to be removed from the object.
- An OPTIONAL <host:rem> element that contains attribute values to be removed from the object.
- An OPTIONAL <host:chg> element that contains object attribute values to be changed.
- An OPTIONAL <host:chg> element that contains object attribute values to be changed.
At least one <host:add>, <host:rem>, or <host:chg> element MUST be provided. The <host:add> and <host:rem> elements contain the following child elements:
At least one <host:add>, <host:rem>, or <host:chg> element MUST be provided. The <host:add> and <host:rem> elements contain the following child elements:
- One or more <host:addr> elements that contain IP addresses to be associated with or removed from the host object. IP address restrictions described in the <create> command mapping apply here as well.
- One or more <host:addr> elements that contain IP addresses to be associated with or removed from the host object. IP address restrictions described in the <create> command mapping apply here as well.
- One or more <host:status> elements that contain status values to be associated with 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.
- One or more <host:status> elements that contain status values to be associated with 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 <host:chg> element contains the following child elements:
A <host:chg> element contains the following child elements:
- A <host:name> element that contains a new fully qualified host name by which the host object will be known.
- A <host:name> element that contains a new fully qualified host name by which the host object will be known.
Host name changes MAY require the addition or removal of IP addresses to be accepted by the server. IP address association MAY be subject to server policies for provisioning hosts as name servers.
Host name changes MAY require the addition or removal of IP addresses to be accepted by the server. IP address association MAY be subject to server policies for provisioning hosts as name servers.
Host name changes can have an impact on associated objects that refer to the host object. A host name change SHOULD NOT require additional updates of associated objects to preserve existing associations, with one exception: changing an external host object that has
Host name changes can have an impact on associated objects that refer to the host object. A host name change SHOULD NOT require additional updates of associated objects to preserve existing associations, with one exception: changing an external host object that has
Hollenbeck Standards Track [Page 15] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 15] RFC 3732 EPP Host Mapping March 2004
associations with objects that are sponsored by a different client. Attempts to update such hosts directly MUST fail with EPP error code 2305. The change can be provisioned by creating a new external host with a new name and needed new attributes and subsequently updating the other objects sponsored by the client.
associations with objects that are sponsored by a different client. Attempts to update such hosts directly MUST fail with EPP error code 2305. The change can be provisioned by creating a new external host with a new name and needed new attributes and subsequently updating the other objects sponsored by the client.
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd"> C: <command> C: <update> C: <host:update C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 C: host-1.0.xsd"> C: <host:name>ns1.example.com</host:name> C: <host:add> C: <host:addr ip="v4">192.0.2.22</host:addr> C: <host:status s="clientUpdateProhibited"/> C: </host:add> C: <host:rem> C: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr> C: </host:rem> C: <host:chg> C: <host:name>ns2.example.com</host:name> C: </host:chg> C: </host: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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 C: epp-1.0.xsd"> C: <command> C: <update> C: <host:update C: xmlns:host="urn:ietf:params:xml:ns:host-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 C: host-1.0.xsd"> C: <host:name>ns1.example.com</host:name> C: <host:add> C: <host:addr ip="v4">192.0.2.22</host:addr> C: <host:status s="clientUpdateProhibited"/> C: </host:add> C: <host:rem> C: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr> C: </host:rem> C: <host:chg> C: <host:name>ns2.example.com</host:name> C: </host:chg> C: </host: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.
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1000">
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1000">
Hollenbeck Standards Track [Page 16] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 16] RFC 3732 EPP Host Mapping March 2004
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: <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 could not be processed for any reason.
An EPP error response MUST be returned if an <update> command could not be processed for any reason.
3.2.6. Offline Review of Requested Actions
3.2.6. 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.
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <resData> S: <host:creData S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 S: host-1.0.xsd"> S: <host:name>ns1.example.com</host:name> S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate> S: </host:creData> S: </resData> S: <trID>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <resData> S: <host:creData S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 S: host-1.0.xsd"> S: <host:name>ns1.example.com</host:name> S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate> S: </host:creData> S: </resData> S: <trID>
Hollenbeck Standards Track [Page 17] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 17] RFC 3732 EPP Host Mapping March 2004
S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
The status of the host 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 by queuing a service message for retrieval via the <poll> command.
The status of the host 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 by queuing a service message for retrieval via the <poll> command.
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 <host:panData> element that identifies the host namespace and the location of the host schema. The <host: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 <host:panData> element that identifies the host namespace and the location of the host schema. The <host:panData> element contains the following child elements:
- A <host:name> element that contains the fully qualified name of the host object. The <host: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 <host:name> element that contains the fully qualified name of the host object. The <host: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 <host: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 <host: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 <host:paDate> element that contains the date and time describing when review of the requested action was completed.
- A <host: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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="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:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 S: epp-1.0.xsd"> S: <response> S: <result code="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>
Hollenbeck Standards Track [Page 18] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 18] RFC 3732 EPP Host Mapping March 2004
S: <resData> S: <host:panData S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 S: host-1.0.xsd"> S: <host:name paResult="1">ns1.example.com</host:name> S: <host:paTRID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </host:paTRID> S: <host:paDate>1999-04-04T22:00:00.0Z</host:paDate> S: </host:panData> S: </resData> S: <trID> S: <clTRID>BCD-23456</clTRID> S: <svTRID>65432-WXY</svTRID> S: </trID> S: </response> S:</epp>
S: <resData> S: <host:panData S: xmlns:host="urn:ietf:params:xml:ns:host-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0 S: host-1.0.xsd"> S: <host:name paResult="1">ns1.example.com</host:name> S: <host:paTRID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </host:paTRID> S: <host:paDate>1999-04-04T22:00:00.0Z</host:paDate> S: </host:panData> S: </resData> S: <trID> S: <clTRID>BCD-23456</clTRID> S: <svTRID>65432-WXY</svTRID> S: </trID> S: </response> S:</epp>
4. Formal Syntax
4. 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:host-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:host-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" schemaLocation="eppcom-1.0.xsd"/> <import namespace="urn:ietf:params:xml:ns:epp-1.0" schemaLocation="epp-1.0.xsd"/>
<!-- Import common element types. --> <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" schemaLocation="eppcom-1.0.xsd"/> <import namespace="urn:ietf:params:xml:ns:epp-1.0" schemaLocation="epp-1.0.xsd"/>
<annotation>
<annotation>
Hollenbeck Standards Track [Page 19] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 19] RFC 3732 EPP Host Mapping March 2004
<documentation> Extensible Provisioning Protocol v1.0 host provisioning schema. </documentation> </annotation>
<documentation> Extensible Provisioning Protocol v1.0 host provisioning schema. </documentation> </annotation>
<!-- Child elements found in EPP commands. --> <element name="check" type="host:mNameType"/> <element name="create" type="host:createType"/> <element name="delete" type="host:sNameType"/> <element name="info" type="host:sNameType"/> <element name="update" type="host:updateType"/>
<!-- Child elements found in EPP commands. --> <element name="check" type="host:mNameType"/> <element name="create" type="host:createType"/> <element name="delete" type="host:sNameType"/> <element name="info" type="host:sNameType"/> <element name="update" type="host:updateType"/>
<!-- Child elements of the <create> command. --> <complexType name="createType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="addr" type="host:addrType" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType>
<!-- Child elements of the <create> command. --> <complexType name="createType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="addr" type="host:addrType" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType>
<complexType name="addrType"> <simpleContent> <extension base="host:addrStringType"> <attribute name="ip" type="host:ipType" default="v4"/> </extension> </simpleContent> </complexType>
<complexType name="addrType"> <simpleContent> <extension base="host:addrStringType"> <attribute name="ip" type="host:ipType" default="v4"/> </extension> </simpleContent> </complexType>
<simpleType name="addrStringType"> <restriction base="token"> <minLength value="3"/> <maxLength value="45"/> </restriction> </simpleType>
<simpleType name="addrStringType"> <restriction base="token"> <minLength value="3"/> <maxLength value="45"/> </restriction> </simpleType>
<simpleType name="ipType"> <restriction base="token"> <enumeration value="v4"/> <enumeration value="v6"/> </restriction> </simpleType>
<simpleType name="ipType"> <restriction base="token"> <enumeration value="v4"/> <enumeration value="v6"/> </restriction> </simpleType>
Hollenbeck Standards Track [Page 20] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 20] RFC 3732 EPP Host Mapping March 2004
<!-- Child elements of the <delete> and <info> commands. --> <complexType name="sNameType"> <sequence> <element name="name" type="eppcom:labelType"/> </sequence> </complexType>
<!-- Child elements of the <delete> and <info> commands. --> <complexType name="sNameType"> <sequence> <element name="name" type="eppcom:labelType"/> </sequence> </complexType>
<!-- Child element of commands that accept multiple names. --> <complexType name="mNameType"> <sequence> <element name="name" type="eppcom:labelType" maxOccurs="unbounded"/> </sequence> </complexType> <!-- Child elements of the <update> command. --> <complexType name="updateType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="add" type="host:addRemType" minOccurs="0"/> <element name="rem" type="host:addRemType" minOccurs="0"/> <element name="chg" type="host:chgType" minOccurs="0"/> </sequence> </complexType>
<!-- Child element of commands that accept multiple names. --> <complexType name="mNameType"> <sequence> <element name="name" type="eppcom:labelType" maxOccurs="unbounded"/> </sequence> </complexType> <!-- Child elements of the <update> command. --> <complexType name="updateType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="add" type="host:addRemType" minOccurs="0"/> <element name="rem" type="host:addRemType" minOccurs="0"/> <element name="chg" type="host:chgType" minOccurs="0"/> </sequence> </complexType>
<!-- Data elements that can be added or removed. --> <complexType name="addRemType"> <sequence> <element name="addr" type="host:addrType" minOccurs="0" maxOccurs="unbounded"/> <element name="status" type="host:statusType" minOccurs="0" maxOccurs="7"/> </sequence> </complexType>
<!-- Data elements that can be added or removed. --> <complexType name="addRemType"> <sequence> <element name="addr" type="host:addrType" minOccurs="0" maxOccurs="unbounded"/> <element name="status" type="host:statusType" minOccurs="0" maxOccurs="7"/> </sequence> </complexType>
<!-- Data elements that can be changed. -->
<!-- Data elements that can be changed. -->
Hollenbeck Standards Track [Page 21] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 21] RFC 3732 EPP Host Mapping March 2004
<complexType name="chgType"> <sequence> <element name="name" type="eppcom:labelType"/> </sequence> </complexType>
<complexType name="chgType"> <sequence> <element name="name" type="eppcom:labelType"/> </sequence> </complexType>
<!-- Child response elements. --> <element name="chkData" type="host:chkDataType"/> <element name="creData" type="host:creDataType"/> <element name="infData" type="host:infDataType"/> <element name="panData" type="host:panDataType"/>
<!-- Child response elements. --> <element name="chkData" type="host:chkDataType"/> <element name="creData" type="host:creDataType"/> <element name="infData" type="host:infDataType"/> <element name="panData" type="host:panDataType"/>
<!-- <check> response elements. --> <complexType name="chkDataType"> <sequence> <element name="cd" type="host:checkType" maxOccurs="unbounded"/> </sequence> </complexType>
<!-- <check> response elements. --> <complexType name="chkDataType"> <sequence> <element name="cd" type="host:checkType" maxOccurs="unbounded"/> </sequence> </complexType>
<complexType name="checkType"> <sequence> <element name="name" type="host:checkNameType"/> <element name="reason" type="eppcom:reasonType" minOccurs="0"/> </sequence> </complexType>
<complexType name="checkType"> <sequence> <element name="name" type="host: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"/>
<!-- <create> response elements. --> <complexType name="creDataType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="crDate" type="dateTime"/>
Hollenbeck Standards Track [Page 22] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 22] RFC 3732 EPP Host Mapping March 2004
</sequence> </complexType>
</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="host:statusType" maxOccurs="7"/> <element name="addr" type="host:addrType" minOccurs="0" maxOccurs="unbounded"/> <element name="clID" type="eppcom:clIDType"/> <element name="crID" type="eppcom:clIDType"/> <element name="crDate" type="dateTime"/> <element name="upID" type="eppcom:clIDType" minOccurs="0"/> <element name="upDate" type="dateTime" minOccurs="0"/> <element name="trDate" 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="host:statusType" maxOccurs="7"/> <element name="addr" type="host:addrType" minOccurs="0" maxOccurs="unbounded"/> <element name="clID" type="eppcom:clIDType"/> <element name="crID" type="eppcom:clIDType"/> <element name="crDate" type="dateTime"/> <element name="upID" type="eppcom:clIDType" minOccurs="0"/> <element name="upDate" type="dateTime" minOccurs="0"/> <element name="trDate" type="dateTime" 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="host: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="host:statusValueType" use="required"/> <attribute name="lang" type="language" default="en"/> </extension> </simpleContent> </complexType>
<simpleType name="statusValueType"> <restriction base="token"> <enumeration value="clientDeleteProhibited"/> <enumeration value="clientUpdateProhibited"/> <enumeration value="linked"/> <enumeration value="ok"/> <enumeration value="pendingCreate"/>
<simpleType name="statusValueType"> <restriction base="token"> <enumeration value="clientDeleteProhibited"/> <enumeration value="clientUpdateProhibited"/> <enumeration value="linked"/> <enumeration value="ok"/> <enumeration value="pendingCreate"/>
Hollenbeck Standards Track [Page 23] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 23] RFC 3732 EPP Host Mapping March 2004
<enumeration value="pendingDelete"/> <enumeration value="pendingTransfer"/> <enumeration value="pendingUpdate"/> <enumeration value="serverDeleteProhibited"/> <enumeration value="serverUpdateProhibited"/> </restriction> </simpleType>
<enumeration value="pendingDelete"/> <enumeration value="pendingTransfer"/> <enumeration value="pendingUpdate"/> <enumeration value="serverDeleteProhibited"/> <enumeration value="serverUpdateProhibited"/> </restriction> </simpleType>
<!-- Pending action notification response elements. --> <complexType name="panDataType"> <sequence> <element name="name" type="host: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>
<!-- Pending action notification response elements. --> <complexType name="panDataType"> <sequence> <element name="name" type="host: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>
<!-- 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
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
Hollenbeck Standards Track [Page 24] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 24] RFC 3732 EPP Host Mapping March 2004
form using upper case "T" and "Z" characters defined in [RFC3339] 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.
form using upper case "T" and "Z" characters defined in [RFC3339] 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 host name syntax as specified in [RFC952] 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 host names.
This document requires host name syntax as specified in [RFC952] 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 host 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 host namespace:
Registration request for the host namespace:
URI: urn:ietf:params:xml:ns:host-1.0
URI: urn:ietf:params:xml:ns:host-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: None. Namespace URIs do not represent an XML specification.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the host XML schema:
Registration request for the host XML schema:
URI: urn:ietf:params:xml:schema:host-1.0
URI: urn:ietf:params:xml:schema:host-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
The object mapping described in this document does not provide any security services or introduce any additional considerations beyond those described by [RFC3730] and protocol layers used by EPP.
The object mapping described in this document does not provide any security services or introduce any additional considerations beyond those described by [RFC3730] 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
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
Hollenbeck Standards Track [Page 25] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 25] RFC 3732 EPP Host Mapping March 2004
of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions.
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 Chris Bason, Jordyn Buchanan, Dave Crocker, Anthony Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, and Rick Wesson.
Specific suggestions that have been incorporated into this document were provided by Chris Bason, Jordyn Buchanan, Dave Crocker, Anthony Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, and Rick Wesson.
9. References
9. References
9.1. Normative References
9.1. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC952] Harrenstien, K, Stahl, M. and E. Feinler, "DOD Internet Host Table Specification", RFC 952, October 1985.
[RFC952] Harrenstien, K, Stahl, M. and E. Feinler, "DOD Internet Host Table Specification", RFC 952, October 1985.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[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.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3513] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 3513, April 2003.
[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.
[RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
[RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
[XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation 6 October 2000.
[XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation 6 October 2000.
[XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures", W3C Recommendation 2 May 2001.
[XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures", W3C Recommendation 2 May 2001.
Hollenbeck Standards Track [Page 26] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 26] RFC 3732 EPP Host Mapping March 2004
[XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: Datatypes", W3C Recommendation 2 May 2001.
[XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: Datatypes", W3C Recommendation 2 May 2001.
9.2. Informative References
9.2. Informative References
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.
[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.
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.
[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.
10. Author's Address
10. Author's Address
Scott Hollenbeck VeriSign Global Registry Services 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Scott Hollenbeck VeriSign Global Registry Services 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
EMail: shollenbeck@verisign.com
EMail: shollenbeck@verisign.com
Hollenbeck Standards Track [Page 27] RFC 3732 EPP Host Mapping March 2004
Hollenbeck Standards Track [Page 27] RFC 3732 EPP Host Mapping March 2004
11. Full Copyright Statement
11. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Copyright (C) The Internet Society (2004). 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 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 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.
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.
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.
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.
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.
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.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Hollenbeck Standards Track [Page 28]
Hollenbeck Standards Track [Page 28]
一覧
スポンサーリンク