RFC4932 日本語訳

4932 Extensible Provisioning Protocol (EPP) Host Mapping. S.Hollenbeck. May 2007. (Format: TXT=57623 bytes) (Obsoletes RFC3732) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文

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

Hollenbeckがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4932 ベリサインInc.は以下を時代遅れにします。 3732 2007年5月のカテゴリ: 標準化過程

          Extensible Provisioning Protocol (EPP) Host 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 host names
   stored in a shared central repository.  Specified in XML, the mapping
   defines EPP command syntax and semantics as applied to host names.
   This document obsoletes RFC 3732.

このドキュメントは、インターネットの食糧を供給するのと管理のために共有された中央倉庫に保存されたホスト名を写像しながら、Extensible Provisioningプロトコル(EPP)について説明します。 XMLで指定されていて、マッピングはEPPコマンド構文とホスト名に適用される意味論を定義します。 このドキュメントはRFC3732を時代遅れにします。

Hollenbeck                  Standards Track                     [Page 1]

RFC 4932                    EPP Host Mapping                    May 2007

2007年5月を写像するHollenbeck標準化過程[1ページ]RFC4932EPPホスト

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Relationship of Host Objects and Domain Objects  . . . . .  3
     1.2.  Conventions Used in This Document  . . . . . . . . . . . .  4
   2.  Object Attributes  . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Host Names . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Client Identifiers . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Status Values  . . . . . . . . . . . . . . . . . . . . . .  4
     2.4.  Dates and Times  . . . . . . . . . . . . . . . . . . . . .  6
     2.5.  IP Addresses . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  EPP Command Mapping  . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  EPP Query Commands . . . . . . . . . . . . . . . . . . . .  7
       3.1.1.  EPP <check> Command  . . . . . . . . . . . . . . . . .  7
       3.1.2.  EPP <info> Command . . . . . . . . . . . . . . . . . .  9
       3.1.3.  EPP <transfer> Query Command . . . . . . . . . . . . . 11
     3.2.  EPP Transform Commands . . . . . . . . . . . . . . . . . . 11
       3.2.1.  EPP <create> Command . . . . . . . . . . . . . . . . . 12
       3.2.2.  EPP <delete> Command . . . . . . . . . . . . . . . . . 13
       3.2.3.  EPP <renew> Command  . . . . . . . . . . . . . . . . . 15
       3.2.4.  EPP <transfer> Command . . . . . . . . . . . . . . . . 15
       3.2.5.  EPP <update> Command . . . . . . . . . . . . . . . . . 15
     3.3.  Offline Review of Requested Actions  . . . . . . . . . . . 17
   4.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 19
   5.  Internationalization Considerations  . . . . . . . . . . . . . 24
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 27
   Appendix A.  Changes from RFC 3732 . . . . . . . . . . . . . . . . 28

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 ホストオブジェクトとドメインオブジェクト. . . . . 3 1.2の関係。 コンベンションは本書では.4 2を使用しました。 オブジェクト属性. . . . . . . . . . . . . . . . . . . . . . 4 2.1。 名前. . . . . . . . . . . . . . . . . . . . . . . . 4 2.2をホスティングしてください。 クライアント識別子. . . . . . . . . . . . . . . . . . . . 4 2.3。 状態値. . . . . . . . . . . . . . . . . . . . . . 4 2.4。 日付と回. . . . . . . . . . . . . . . . . . . . . 6 2.5。 IPは.6 3を扱います。 EPPはマッピング. . . . . . . . . . . . . . . . . . . . . 7 3.1を命令します。 EPPは.1にコマンド. . . . . . . . . . . . . . . . . . . . 7 3.1について質問します。 EPP<チェック>命令. . . . . . . . . . . . . . . . . 7 3.1.2。 EPP<インフォメーション>コマンド. . . . . . . . . . . . . . . . . . 9 3.1.3。 EPP<転送>質問命令. . . . . . . . . . . . . 11 3.2。 EPPは.1にコマンド. . . . . . . . . . . . . . . . . . 11 3.2を変えます。 EPP<は>コマンド. . . . . . . . . . . . . . . . . 12 3.2.2を作成します。 EPP<は>コマンド. . . . . . . . . . . . . . . . . 13 3.2.3を削除します。 EPP<は>コマンド. . . . . . . . . . . . . . . . . 15 3.2.4を更新します。 EPP<転送>命令. . . . . . . . . . . . . . . . 15 3.2.5。 EPP<アップデート>命令. . . . . . . . . . . . . . . . . 15 3.3。 要求された動作. . . . . . . . . . . 17 4のオフラインレビュー。 正式な構文. . . . . . . . . . . . . . . . . . . . . . . . 19 5。 国際化問題. . . . . . . . . . . . . 24 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 25 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 25 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 26 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 26 9.2。 RFC3732.28からの有益な参照. . . . . . . . . . . . . . . . . . 27付録A.変化

Hollenbeck                  Standards Track                     [Page 2]

RFC 4932                    EPP Host Mapping                    May 2007

2007年5月を写像するHollenbeck標準化過程[2ページ]RFC4932EPPホスト

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 [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 3732 [RFC3732].

このドキュメントはExtensible Provisioningのバージョン1.0のために、プロトコル(EPP)を写像するインターネットホスト名について説明します。 このマッピングは、拡張マークアップ言語の[W3C. REC-xmlschema-1-20041028]で説明されるように[W3C. REC-xml-20040204]とXML Schema記法で説明される(XML)1.0と[W3C. REC-xmlschema-2-20041028]を使用することで指定されます。 このドキュメントはRFC3732[RFC3732]を時代遅れにします。

   [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 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 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を扱わなければなりません。

Hollenbeck                  Standards Track                     [Page 3]

RFC 4932                    EPP Host Mapping                    May 2007

2007年5月を写像するHollenbeck標準化過程[3ページ]RFC4932EPPホスト

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 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
   [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 in the future as a result of progressing work in
   developing standards for internationalized host names.

[RFC1123]によってアップデートされるように本書では説明されたホスト名のための構文は[RFC0952]に従わなければなりません。 この書くこと時点で、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 [RFC4930].

すべてのEPPクライアントがサーバユニークな識別子によって特定されます。 クライアント識別子は[RFC4930]で説明された"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
   text that describes the rationale for the status applied to the
   object.

ホストオブジェクトには、少なくとも1つの関連状態値がいつもなければなりません。 状態値はホストオブジェクトを後援するクライアントの近くとだけ、そして、オブジェクトが住んでいるサーバで設定されるかもしれません。 クライアントは、EPP<アップデート>命令を使用することでホストオブジェクトの状態を変えることができます。 各状態値はオブジェクトに適用された状態に原理について説明する人間読み込み可能なテキストのストリングによって伴われるかもしれません。

Hollenbeck                  Standards Track                     [Page 4]

RFC 4932                    EPP Host Mapping                    May 2007

2007年5月を写像するHollenbeck標準化過程[4ページ]RFC4932EPPホスト

   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.

オブジェクト(またはホストオブジェクトの「スーパー-縦座標」ドメインオブジェクトのための<転送>命令の場合で)のために変形コマンドを処理してありますが、操作はサーバで完了していません。サーバオペレータはさまざまな理由で動作完成を遅らせることができます、人間のレビューか3番目のパーティー動作を考慮するようなもの。 処理されて、要求された動きだけが未定である変形コマンドは応答コード1001で有名です。

Hollenbeck                  Standards Track                     [Page 5]

RFC 4932                    EPP Host Mapping                    May 2007

2007年5月を写像するHollenbeck標準化過程[5ページ]RFC4932EPPホスト

   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
   [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」キャラクタを使用しなければなりません。

2.5.  IP Addresses

2.5. IPアドレス

   The syntax for IPv4 addresses described in this document MUST conform
   to [RFC0791].  The syntax for IPv6 addresses described in this
   document MUST conform to [RFC4291].  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アドレスのための構文は[RFC0791]に従わなければなりません。 本書では説明されたIPv6アドレスのための構文は[RFC4291]に従わなければなりません。 ゾーンファイルの出版IPv6アドレス情報のための実用的な問題は[RFC1886]、[RFC2874]、および[RFC3152]に記録されます。 サーバは公共の使用のためにIANAによって割り当てられていないIPアドレスを拒絶するかもしれません。 ホストオブジェクトが使用のために食糧を供給されたら、DNSネームサーバ、IPがSHOULDを扱うように、単にDNSが接着剤記録であると生成するのが必要であるように必要であってください。

Hollenbeck                  Standards Track                     [Page 6]

RFC 4932                    EPP Host Mapping                    May 2007

2007年5月を写像するHollenbeck標準化過程[6ページ]RFC4932EPPホスト

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 host names via EPP.

[RFC4930]で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.  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:  <command>
   C:    <check>
   C:      <host:check
   C:       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
   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:  </command>
   C:</epp>

C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1インチの>C:」 <コマンド>C: <チェック>C: <ホスト: Cをチェックしてください: xmlns: ホスト、= 「つぼ:ietf:params:xml:ナノ秒: >Cを-何1インチも接待してください」 <ホスト: 名前>ns1.example.com</ホスト: >をCと命名してください: <ホスト: 名前>ns2.example.com</ホスト: >をCと命名してください: <ホスト: 名前>ns3.example.com</ホスト: >をCと命名してください: </ホスト: >Cをチェックしてください: </チェック>C: <clTRID>ABC-12345</clTRID>C: </コマンド>C: </epp>。

Hollenbeck                  Standards Track                     [Page 7]

RFC 4932                    EPP Host Mapping                    May 2007

2007年5月を写像するHollenbeck標準化過程[7ページ]RFC4932EPPホスト

   When a <check> command has been processed successfully, the EPP
   <resData> element MUST contain a child <host:chkData> element that
   identifies the host namespace.  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
      cannot be provisioned.

- <ホスト: 質問されたホストオブジェクトの完全に修飾された名前を含む要素と>を命名してください。 この要素が値がオブジェクトの有用性を示す「利益」属性を含まなければならない、(それに食糧を供給することができる、)、現在、<チェック>命令は完成しました。 「1インチか「本当」が、オブジェクトに食糧を供給することができることを意味する」値。 「0インチか「誤ること」が、オブジェクトに食糧を供給することができないことを意味する」値。

   -  An OPTIONAL <host: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:      <host:chkData
   S:       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
   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:        </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: <?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:ナノ秒: >Sを-何1インチも接待してください」 <ホスト: cd>S: <ホスト: 名前は役に立ちます。= 「1インチの>ns1.example.com</は: 名義の>Sを接待します」。 </ホスト: cd>S: <ホスト: cd>S: <ホスト: 名前は役に立ちます。= 「0インチの>ns2.example2.com</は: 名義の>Sを接待します」。 <ホスト: >Inが</ホストを使用する理由: >Sを推論してください: </ホスト: cd>S: <ホスト: cd>S: <ホスト: 名前は役に立ちます。= 「1インチの>ns3.example3.com</は: 名義の>Sを接待します」。 </ホスト: cd>S: </ホスト: chkData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>。

Hollenbeck                  Standards Track                     [Page 8]

RFC 4932                    EPP Host Mapping                    May 2007

2007年5月を写像するHollenbeck標準化過程[8ページ]RFC4932EPPホスト

   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 host object.  In addition to the standard EPP command
   elements, the <info> command MUST contain a <host:info> element that
   identifies the host namespace.  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:  <command>
   C:    <info>
   C:      <host:info
   C:       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
   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:ナノ秒:epp-1インチの>C:」 <コマンド>C: <インフォメーション>C: <ホスト: インフォメーションC: xmlns: ホスト、= 「つぼ:ietf:params:xml:ナノ秒: >Cを-何1インチも接待してください」 <ホスト: 名前>ns1.example.com</ホスト: >を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 <host:infData> element that
   identifies the host namespace.  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>要素。

Hollenbeck                  Standards Track                     [Page 9]

RFC 4932                    EPP Host Mapping                    May 2007

2007年5月を写像するHollenbeck標準化過程[9ページ]RFC4932EPPホスト

   -  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<インフォメーション>コマンドへの応答で記載されています。

   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:  <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:        <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: <?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:ナノ秒: >Sを-何1インチも接待してください」 <ホスト: 名前>ns1.example.com</ホスト: >をSと命名してください: <ホスト: </ホスト: roid>NS1_EXAMPLE1-レップroid>S: <ホスト: 状態sは「リンク」/>Sと等しいです: <ホスト: 状態sは"clientUpdateProhibited"/>と等しいです。

Hollenbeck                  Standards Track                    [Page 10]

RFC 4932                    EPP Host Mapping                    May 2007

2007年5月を写像するHollenbeck標準化過程[10ページ]RFC4932EPPホスト

   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: <は: 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 cannot 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<転送>質問命令のために定義された写像がありません。

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.

通常処理されていて、リアルタイムで終了したコマンドを変えてください。 サーバオペレータは受信するかもしれません、そして、要求された操作が完了できる前に変換が人間であるなら要求された操作を完了しながら命令しますが、延期するプロセスか第三者レビューが必要です。 そのような状況で、サーバは、コマンドを受け取られて、処理してありますが、要求された動きが未定であることに注意するために1001年の応答コードをクライアントに返さなければなりません。 また、サーバは開始を反映するコマンドの対象と要求された動作の完成であるオブジェクトの状態を管理しなければなりません。 操作がいったん完了すると、操作が完了して、オブジェクトの状態が変化したというサービスメッセージを使用して、トランザクションにかかわるすべてのクライアントに通知しなければなりません。

Hollenbeck                  Standards Track                    [Page 11]

RFC 4932                    EPP Host Mapping                    May 2007

2007年5月を写像するHollenbeck標準化過程[11ページ]RFC4932EPPホスト

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 host object.  In addition to the standard EPP
   command elements, the <create> command MUST contain a <host:create>
   element that identifies the host namespace.  The <host:create>
   element contains the following child elements:

EPP<はコマンドがクライアントがホストオブジェクトを作成できる変換操作を供給する>を作成します。 標準のEPPに加えて指揮機関、<は>を作成します。コマンドは<ホストを含まなければなりません: ホスト名前空間を特定する>要素を作成してください。 <ホスト: >を作成してください。要素は以下の子供要素を含んでいます:

   -  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

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

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 "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:  <command>
   C:    <create>
   C:      <host:create
   C:       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
   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:<?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: <host:create C: xmlns:host="urn:ietf:params:xml:ns:host-1.0"> 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>

Hollenbeck                  Standards Track                    [Page 12]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 12] RFC 4932 EPP Host Mapping May 2007

   C:    </create>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

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.  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. 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:  <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:        <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:<?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: <host:creData S: xmlns:host="urn:ietf:params:xml:ns:host-1.0"> 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 cannot
   be processed for any reason.

An EPP error response MUST be returned if a <create> command cannot 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.  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. The <host:delete> element contains the following child elements:

Hollenbeck                  Standards Track                    [Page 13]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 13] RFC 4932 EPP Host Mapping May 2007

   -  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 SHOULD 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 SHOULD NOT be
   deleted until the existing association has been broken.  Deleting a
   host object without first breaking existing associations can cause
   DNS resolution failure for domain objects that refer to the deleted
   host object.

A host name object SHOULD 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 SHOULD NOT be deleted until the existing association has been broken. Deleting a host object without first breaking existing associations can cause DNS resolution failure for domain objects that refer to the deleted host object.

   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:  <command>
   C:    <delete>
   C:      <host:delete
   C:       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
   C:        <host:name>ns1.example.com</host:name>
   C:      </host:delete>
   C:    </delete>
   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: <delete> C: <host:delete C: xmlns:host="urn:ietf:params:xml:ns:host-1.0"> 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:  <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 a <delete> command cannot
   be processed for any reason.

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

Hollenbeck                  Standards Track                    [Page 14]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 14] RFC 4932 EPP Host Mapping May 2007

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.

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.  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. 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 if the command is not being extended.  All of these elements
   MAY be omitted if an <update> extension is present.  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 if the command is not being extended. All of these elements MAY be omitted if an <update> extension is present. 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.

Hollenbeck                  Standards Track                    [Page 15]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 15] RFC 4932 EPP Host Mapping May 2007

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

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 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:  <command>
   C:    <update>
   C:      <host:update
   C:       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
   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: <command> C: <update> C: <host:update C: xmlns:host="urn:ietf:params:xml:ns:host-1.0"> 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.

Hollenbeck                  Standards Track                    [Page 16]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 16] RFC 4932 EPP Host 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 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.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.

   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:      <host:creData
   S:       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
   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:<?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: <host:creData S: xmlns:host="urn:ietf:params:xml:ns:host-1.0"> S: <host:name>ns1.example.com</host:name> S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate> S: </host:creData> S: </resData>

Hollenbeck                  Standards Track                    [Page 17]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 17] RFC 4932 EPP Host Mapping May 2007

   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

S: <trID> 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 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 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 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 <host:panData> element that
   identifies the host namespace.  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. 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:  <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: <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 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 18] RFC 4932 EPP Host Mapping May 2007

   S:    <resData>
   S:      <host:panData
   S:       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
   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: <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"/>
    <import namespace="urn:ietf:params:xml:ns:epp-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"/>

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

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

Hollenbeck                  Standards Track                    [Page 19]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 19] RFC 4932 EPP Host Mapping May 2007

    </annotation>

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

   <!--
   Child elements of the <delete> and <info> commands.
   -->

<!-- Child elements of the <delete> and <info> commands. -->

Hollenbeck                  Standards Track                    [Page 20]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 20] RFC 4932 EPP Host Mapping May 2007

    <complexType name="sNameType">
      <sequence>
        <element name="name" type="eppcom:labelType"/>
      </sequence>
    </complexType>

<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.
   -->
    <complexType name="chgType">
      <sequence>
        <element name="name" type="eppcom:labelType"/>

<!-- Data elements that can be changed. --> <complexType name="chgType"> <sequence> <element name="name" type="eppcom:labelType"/>

Hollenbeck                  Standards Track                    [Page 21]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 21] RFC 4932 EPP Host Mapping May 2007

      </sequence>
    </complexType>

</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"/>
      </sequence>
    </complexType>

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

Hollenbeck                  Standards Track                    [Page 22]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 22] RFC 4932 EPP Host Mapping May 2007

   <!--
   <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"/>
        <enumeration value="pendingDelete"/>
        <enumeration value="pendingTransfer"/>
        <enumeration value="pendingUpdate"/>

<simpleType name="statusValueType"> <restriction base="token"> <enumeration value="clientDeleteProhibited"/> <enumeration value="clientUpdateProhibited"/> <enumeration value="linked"/> <enumeration value="ok"/> <enumeration value="pendingCreate"/> <enumeration value="pendingDelete"/> <enumeration value="pendingTransfer"/> <enumeration value="pendingUpdate"/>

Hollenbeck                  Standards Track                    [Page 23]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 23] RFC 4932 EPP Host Mapping May 2007

        <enumeration value="serverDeleteProhibited"/>
        <enumeration value="serverUpdateProhibited"/>
      </restriction>
    </simpleType>

<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
   form using upper case "T" and "Z" characters defined in

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

Hollenbeck                  Standards Track                    [Page 24]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 24] RFC 4932 EPP Host Mapping May 2007

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

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

This document requires 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 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 [RFC4930] 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 [RFC4930] and protocol layers used by EPP.

Hollenbeck                  Standards Track                    [Page 25]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 25] RFC 4932 EPP Host Mapping May 2007

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

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

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

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

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

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

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

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

Hollenbeck                  Standards Track                    [Page 26]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 26] RFC 4932 EPP Host Mapping May 2007

   [W3C.REC-xml-20040204]
              Yergeau, F., Maler, E., Sperberg-McQueen, C., Bray, T.,
              and J. Paoli, "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] Yergeau, F., Maler, E., Sperberg-McQueen, C., Bray, T., and J. Paoli, "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>.

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.

   [RFC3732]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Host Mapping", RFC 3732, March 2004.

[RFC3732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", RFC 3732, March 2004.

Hollenbeck                  Standards Track                    [Page 27]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 27] RFC 4932 EPP Host Mapping May 2007

Appendix A.  Changes from RFC 3732

Appendix A. Changes from RFC 3732

   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:

       "Transform commands MUST be rejected when a pendingCreate,
       pendingDelete, pendingTransfer, or pendingUpdate status is set."

"Transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status is set."

   3.  Changed text in Section 3.2.2 from this:

3. Changed text in Section 3.2.2 from this:

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

       to this:

to this:

       "A host name object SHOULD 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 SHOULD
       NOT be deleted until the existing association has been broken.
       Deleting a host object without first breaking existing
       associations can cause DNS resolution failure for domain objects
       that refer to the deleted host object."

"A host name object SHOULD 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 SHOULD NOT be deleted until the existing association has been broken. Deleting a host object without first breaking existing associations can cause DNS resolution failure for domain objects that refer to the deleted host object."

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

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

Hollenbeck                  Standards Track                    [Page 28]

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 28] RFC 4932 EPP Host Mapping May 2007

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

6. 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 references to RFC 3339 and replaced them with references
       to the W3C XML Schema specification.

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

   8.  Replaced references to RFC 3513 with references to RFC 4291.

8. Replaced references to RFC 3513 with references to RFC 4291.

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

RFC 4932                    EPP Host Mapping                    May 2007

Hollenbeck Standards Track [Page 29] RFC 4932 EPP Host 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.

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

Hollenbeck Standards Track [Page 30]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

<COL> テーブルの縦列(縦方向)の属性をまとめて指定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る