[要約] RFC 3915は、EPP（Extensible Provisioning Protocol）のためのドメイン登録グレース期間マッピングに関する規格です。このRFCの目的は、EPPを使用してドメイン登録を行う際のグレース期間の処理方法を定義することです。
Network Working Group S. Hollenbeck
Request for Comments: 3915 VeriSign, Inc.
Category: Standards Track September 2004
Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
拡張可能なプロビジョニングプロトコル（EPP）のドメインレジストリグレース期間マッピング
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing.
このドキュメントでは、割り当てられた名前と数字（ICANN）についてインターネットコーポレーションによって定義された「GRACE期間」ポリシーの対象となるドメイン名システム（DNS）ドメイン名の管理のための拡張可能なプロビジョニングプロトコル（EPP）拡張マッピングについて説明します。プロトコルアクションが実行された後、プロトコルアクションを逆転または取り消すことができるようにするために、プロトコルアクションを逆転またはその他の方法で取り消すことができます。XMLで指定されたこのマッピングは、EPPドメイン名マッピングを拡張して、GRACE期間の処理に必要な追加機能を提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used In This Document. . . . . . . . . . . . 4
2. Redemption Grace Period State Diagram . . . . . . . . . . . . 4
3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Status Values . . . . . . . . . . . . . . . . . . . . . 6
3.2. Registration Data and Supporting Information . . . . . . 7
3.3. Dates and Times . . . . . . . . . . . . . . . . . . . . 7
3.4. Client Statements . . . . . . . . . . . . . . . . . . . 8
4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 8
4.1 EPP Query Commands . . . . . . . . . . . . . . . . . . . 8
4.1.1. EPP <check> Command . . . . . . . . . . . . . . 8
4.1.2. EPP <info> Command . . . . . . . . . . . . . . . 8
4.1.3. EPP <transfer> Command . . . . . . . . . . . . . 11
4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 11
4.2.1. EPP <create> Command . . . . . . . . . . . . . . 12
4.2.2. EPP <delete> Command . . . . . . . . . . . . . . 12
4.2.3. EPP <renew> Command . . . . . . . . . . . . . . 12
4.2.4. EPP <transfer> Command . . . . . . . . . . . . . 12
4.2.5. EPP <update> Command . . . . . . . . . . . . . . 12
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Internationalization Considerations . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23
This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) described in RFC 3730 [1]. This mapping, an extension of the domain name mapping described in RFC 3731 [2], is specified using the Extensible Markup Language (XML) 1.0 [3] and XML Schema notation ([4], [5]).
このドキュメントでは、RFC 3730 [1]に記載されている拡張プロビジョニングプロトコル（EPP）のバージョン1.0の拡張マッピングについて説明します。RFC 3731 [2]で説明されているドメイン名マッピングの拡張機能であるこのマッピングは、拡張可能なマークアップ言語（XML）1.0 [3]およびXMLスキーマ表記（[4]、[5]）を使用して指定されています。
The EPP core protocol specification [1] 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.
EPPコアプロトコル仕様[1]は、EPPコマンドと応答構造の完全な説明を提供します。このドキュメントに記載されているマッピングを理解するには、ベースプロトコル仕様を完全に理解する必要があります。
Over the course of several months in 2002, The Internet Corporation for Assigned Names and Numbers (ICANN) developed an implementation proposal to provide a "grace period" for Domain Name System (DNS) domain name recovery (or redemption) before a domain name is purged from the repository of the authoritative registry for the domain name. This mapping extends the EPP domain <update> command to initiate the redemption process for a domain name that has entered the Redemption Grace Period (RGP) and it extends the EPP domain <info> response to identify the status of domains that have entered various grace periods defined by ICANN policy.
2002年の数か月の間に、割り当てられた名前と数字（ICANN）のインターネット企業は、ドメイン名が前にドメイン名システム（DNS）ドメイン名の回復（またはredい）に「GRACE期間」を提供する実装提案を開発しました。ドメイン名の権威あるレジストリのリポジトリからパージされました。このマッピングは、EPPドメイン<update>コマンドを拡張して、redいグレース期間（RGP）に入ったドメイン名のredいプロセスを開始し、さまざまな恵みに入ったドメインのステータスを識別するためにEPPドメイン<情報>応答を拡張しますICANNポリシーで定義された期間。
In March 2003, ICANN published a task force report describing other domain registry grace periods related to EPP operations. This mapping describes extension status values to note the grace periods described in the report, including:
2003年3月、ICANNは、EPP操作に関連する他のドメインレジストリグレース期間を説明するタスクフォースレポートを公開しました。このマッピングは、次のことを含むレポートに記載されている猶予期間に注意するための拡張ステータス値を説明しています。
o An "add grace period" after the initial registration of a domain name. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the registration.
o ドメイン名の最初の登録後の「グレース期間を追加」。この期間中にドメイン名がレジストラによって削除された場合、レジストリは登録の費用に対してレジストラにクレジットを提供します。
o An "auto-renew grace period" after a domain name registration period expires and is extended (renewed) automatically by the registry. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.
o ドメイン名の登録期間が失効し、レジストリによって自動的に延長（更新）される後の「自動更新期間」。この期間中にドメイン名がレジストラによって削除された場合、レジストリは更新のコストについてレジストラにクレジットを提供します。
o A "renew grace period" after a domain name registration period is explicitly extended (renewed) by the registrar. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.
o ドメイン名の登録期間後の「恵み期間を更新」は、レジストラによって明示的に拡張（更新）されます。この期間中にドメイン名がレジストラによって削除された場合、レジストリは更新のコストについてレジストラにクレジットを提供します。
o A "transfer grace period" after the successful transfer of domain name registration sponsorship from one registrar to another registrar. If the domain name is deleted by the new sponsoring registrar during this period, the registry provides a credit to the registrar for the cost of the transfer.
o ドメイン名の登録スポンサーシップがあるレジストラから別のレジストラへの転送が成功した後の「猶予期間」。この期間中にドメイン名が新しいスポンサーレジストラによって削除された場合、レジストリは転送コストについてレジストラにクレジットを提供します。
Each grace period exists for a specific period of time that is typically measured in days. The duration of each grace period is a matter of registry operational policy that is not addressed in this document.
各恵み期間は、通常、日数で測定される特定の期間に存在します。各猶予期間の期間は、このドキュメントでは対処されていないレジストリ運用ポリシーの問題です。
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 BCP 14, RFC 2119 [6].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [6]に記載されているように解釈される。
In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples is provided only to illustrate element relationships and is not a REQUIRED feature of this specification.
例では、「C：」はプロトコルクライアントから送信された行と「S：」を表し、プロトコルサーバーによって返される行を表します。例のインデントと白スペースは、要素の関係を説明するためにのみ提供されており、この仕様に必要な機能ではありません。
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仕様と例は、適合実装を開発するために提示されたキャラクターケースで解釈する必要があります。
The Redemption Grace Period (RGP) involves several domain state transitions as a domain name moves through the redemption process:
Redemption Grace期間（RGP）には、ドメイン名が償還プロセスを介して移動するため、いくつかのドメイン状態遷移が含まれます。
1. A domain is initially in the EPP "ok" status, or some other status that allows processing of the EPP <delete> command.
1. ドメインは、最初はEPP「OK」ステータス、またはEPP <Delete>コマンドの処理を許可するその他のステータスにあります。
2. A <delete> command is received and processed for the domain name.
2. <delete>コマンドが受信され、ドメイン名が処理されます。
3. RGP begins once the <delete> command is processed successfully. The EPP status changes to "pendingDelete", and the RGP status is initialized to "redemptionPeriod". The domain remains in this state until either a <restore> operation is requested or the redemption period elapses.
3. <delete>コマンドが正常に処理されると、RGPが開始されます。EPPステータスは「PendingDelete」に変更され、RGPステータスは「RedemptionPeriod」に初期化されます。ドメインは、<復元>操作が要求されるか、償還期間が経過するまで、この状態のままです。
4. A <restore> operation can be requested using the extended EPP <update> command. Go to step 8 if the redemption period elapses before a <restore> request is received.
4. extended EPP <update>コマンドを使用して、<restore>操作を要求できます。<turtore>リクエストを受信する前に償還期間が経過する場合は、ステップ8に移動します。
5. If the <restore> is successful, the Registry waits to receive a restore report from the registrar for a period of time defined by the Registry. The EPP status remains "pendingDelete" and the RGP status changes to "pendingRestore". While this extension defines a method to deliver a restore report via EPP, an out-of-band mechanism (such as a web site) can also be used to deliver restore reports.
5. <restore>が成功した場合、レジストリはレジストリによって定義された期間、レジストラから復元レポートを受信するのを待ちます。EPPステータスは「保留中」のままであり、RGPステータスは「Pendentrestore」に変更されます。この拡張機能は、EPPを介して復元レポートを提供する方法を定義しますが、バンド外のメカニズム（Webサイトなど）を使用して復元レポートを提供することもできます。
6. The domain name returns to the redemption period state (state 3) if a restore report is not received.
6. ドメイン名は、復元レポートが受信されていない場合、redemption期間状態（状態3）に戻ります。
7. If a restore report is received the EPP status returns to "ok" (or whatever it was prior to processing the <delete> command), and the RGP status is removed completely.
7. 復元レポートを受信した場合、EPPステータスは「OK」（または<delete>コマンドを処理する前に）に戻り、RGPステータスが完全に削除されます。
8. The redemption period elapses before a <restore> request is received.
8. <retore>リクエストが受信される前に、償還期間が経過します。
9. The EPP status remains "pendingDelete" and the RGP status changes to "pendingDelete". The domain name remains in this state for a period of time defined by the Registry.
9. EPPのステータスは「保留中」のままであり、RGPステータスは「保留中」に変更されます。ドメイン名は、レジストリによって定義された一定期間、この状態のままです。
10. The domain name is purged once the pending delete period elapses.
10. 保留中の削除期間が経過すると、ドメイン名がパージされます。
11. The domain name is available for re-registration.
11. ドメイン名は再登録に利用できます。
Figure 1: RGP State Diagram
図1：RGP状態図
|
v
+----------------------+ (2) +----------------------+
|EPP: ok (1)| <delete> |EPP: pendingDelete (3)|
|RGP: N/A |--------->|RGP: redemptionPeriod |
+----------------------+ +----------------------+
^ (4) | ^ |
| <restore> | | No (8) |
| +-----------+ | <restore> |
| | | |
| v | v
| +----------------------+ | +----------------------+
| |EPP: pendingDelete (5)| | |EPP: pendingDelete (9)|
| |RGP: pendingRestore |---------+ |RGP: pendingDelete |
| +----------------------+ Report +----------------------+
| | not (6) |
| (7) | Received Purge (10) |
| Report Received | |
+--------------------+ v
+----------------------+
| Purged (11)|
| |
+----------------------+
This extension adds additional elements to the EPP domain name mapping [2]. Only new element descriptions are described here.
この拡張機能は、EPPドメイン名マッピング[2]に追加の要素を追加します。ここでは、新しい要素の説明のみが説明されています。
This extension defines new status values to represent the different states that a domain name can be in as a result of grace period processing. These are:
この拡張機能は、猶予期間の処理の結果としてドメイン名が存在する可能性があるさまざまな状態を表すために、新しいステータス値を定義します。これらは：
addPeriod: This grace period is provided after the initial registration of a domain name. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the registration.
AddPeriod：この猶予期間は、ドメイン名の最初の登録後に提供されます。この期間中にドメイン名がレジストラによって削除された場合、レジストリは登録の費用に対してレジストラにクレジットを提供します。
autoRenewPeriod: This grace period is provided after a domain name registration period expires and is extended (renewed) automatically by the registry. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.
AutorEnewPeriod：この恵み期間は、ドメイン名登録期間が失効し、レジストリによって自動的に延長（更新）された後に提供されます。この期間中にドメイン名がレジストラによって削除された場合、レジストリは更新のコストについてレジストラにクレジットを提供します。
renewPeriod: This grace period is provided after a domain name registration period is explicitly extended (renewed) by the registrar. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.
更新期間：この猶予期間は、レジストラによってドメイン名登録期間が明示的に拡張（更新）された後に提供されます。この期間中にドメイン名がレジストラによって削除された場合、レジストリは更新のコストについてレジストラにクレジットを提供します。
transferPeriod: This grace period is provided after the successful transfer of domain name registration sponsorship from one registrar to another registrar. If the domain name is deleted by the new sponsoring registrar during this period, the registry provides a credit to the registrar for the cost of the transfer.
TransferPeriod：この猶予期間は、あるレジストラから別のレジストラへのドメイン名登録スポンサーシップの転送が成功した後に提供されます。この期間中にドメイン名が新しいスポンサーレジストラによって削除された場合、レジストリは転送コストについてレジストラにクレジットを提供します。
redemptionPeriod: This status value is used to describe a domain for which a <delete> command has been received, but the domain has not yet been purged because an opportunity exists to restore the domain and abort the deletion process.
RedemptionPeriod：このステータス値は、<delete>コマンドが受信されたドメインを記述するために使用されますが、ドメインを回復して削除プロセスを中止する機会が存在するため、ドメインはまだ削除されていません。
pendingRestore: This status value is used to describe a domain that is in the process of being restored after being in the redemptionPeriod state.
Pendentrestore：このステータス値は、redemptionperiod状態になった後に復元されているドメインを記述するために使用されます。
pendingDelete: This status value is used to describe a domain that has entered the purge processing state after completing the redemptionPeriod state. A domain in this status MUST also be in the pendingDelete status described in the EPP domain mapping [2].
PendingDelete：このステータス値は、RedemptionPeriod状態を完了した後にパージ処理状態に入ったドメインを記述するために使用されます。このステータスのドメインは、EPPドメインマッピング[2]に記載されている保留中のステータスにもある必要があります。
This extension allows a client to provide copies of registration data (whois [9] data, for example) and supporting information in a restore report as required by the RGP process. No specific format is required by this extension; both free text and XML markup MAY be used.
この拡張機能により、クライアントは登録データのコピー（WHOIS [9]データなど）を提供し、RGPプロセスで必要とされる復元レポートで情報をサポートすることができます。この拡張機能では特定の形式は必要ありません。無料のテキストとXMLマークアップの両方を使用できます。
Operators of servers that provide registration data might find it useful to provide grace period status values in their responses to client queries. This information can be useful to people who want to understand the operations that can be performed on a domain name at any give time.
登録データを提供するサーバーのオペレーターは、クライアントクエリへの応答に恵み期間のステータス値を提供することが有用であると判断する場合があります。この情報は、任意の時間にドメイン名で実行できる操作を理解したい人に役立ちます。
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 RFC 3339 [7] MUST be used to represent date-time values as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters.
日付および時刻属性値は、グレゴリオカレンダーを使用して、ユニバーサル調整時間（UTC）で表す必要があります。XMLスキーマが切り捨てられた日付時間または小文字「T」をサポートしていないため、RFC 3339 [7]で定義されている「T」および「Z」文字を使用して、日付時間値を表すために使用する必要があります。および「Z」文字。
The RGP process requires a client to make two statements regarding the data included in a restore report. No specific format is required by this extension; both free text and XML markup MAY be used. English is the default language used within the statements, but other languages MAY be used.
RGPプロセスでは、クライアントが復元レポートに含まれるデータに関する2つのステートメントを作成する必要があります。この拡張機能では特定の形式は必要ありません。無料のテキストとXMLマークアップの両方を使用できます。英語はステートメント内で使用されるデフォルト言語ですが、他の言語が使用される場合があります。
A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [1]. The command mappings described here are specifically for use in implementing redemption grace period processes via EPP.
EPP構文とセマンティクスの詳細な説明は、EPPコアプロトコル仕様[1]に記載されています。ここで説明するコマンドマッピングは、EPPを介したredいのグレース期間プロセスの実装に特に使用するためです。
EPP provides three commands to retrieve object information: <check> to determine if an object is known to the server, <info> to retrieve detailed information associated with an object, and <transfer> to retrieve object transfer status information.
EPPは、オブジェクト情報を取得するための3つのコマンドを提供します。<check>オブジェクトがサーバーに既知であるかどうかを判断し、<情報>オブジェクトに関連付けられた詳細情報を取得し、<転送>オブジェクト転送ステータス情報を取得します。
This extension does not add any elements to the EPP <check> command or <check> response described in the EPP domain mapping [2].
この拡張機能は、EPPドメインマッピング[2]で説明されているEPP <Check>コマンドまたは<Check>応答に要素を追加しません。
This extension does not add any elements to the EPP <info> command described in the EPP domain mapping [2]. Additional elements are defined for the <info> response.
この拡張機能は、EPPドメインマッピング[2]で説明されているEPP <info>コマンドに要素を追加しません。追加の要素は、<情報>応答に対して定義されています。
When an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in [2]. In addition, the EPP <extension> element MUST contain a child <rgp:infData> element that identifies the registry grace period namespace and the location of the registry grace period schema. The <rgp:infData> element contains a single <rgp:rgpStatus> element that contains a single attribute "s" whose value describes the current grace period status of the domain. Possible status values are described in section Section 3.1.
<info>コマンドが正常に処理された場合、[2]で説明されているように、EPP <resdata>要素には子要素を含める必要があります。さらに、epp <extension>要素には、レジストリグレースの名前空間とレジストリグレース期間スキーマの位置を識別する子<rgp：infdata>要素を含める必要があります。<rgp：infdata>要素には、ドメインの現在の猶予期間を記述する値「s」を含む単一の<rgp：rgpstatus>要素が含まれています。可能なステータス値については、セクション3.1で説明します。
Example <info> response for "addPeriod" status:
「AddPeriod」ステータスの例<情報>応答：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/>
S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact>
S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: <domain:hostObj>ns1.example.net</domain:hostObj>
S: </domain:ns>
S: <domain:host>ns1.example.com</domain:host>
S: <domain:host>ns2.example.com</domain:host>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientX</domain:crID>
S: <domain:crDate>2003-11-26T22:00:00.0Z</domain:crDate>
S: <domain:exDate>2005-11-26T22:00:00.0Z</domain:exDate>
S: <domain:authInfo>
S: <domain:pw>2fooBAR</domain:pw>
S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
S: rgp-1.0.xsd">
S: <rgp:rgpStatus s="addPeriod"/>
S: </rgp:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Example <info> response for "redemptionPeriod" status:
例<情報>「redemptionperiod」ステータスの応答：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S: domain-1.0.xsd">
S: <domain:name>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="pendingDelete"/>
S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact>
S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: <domain:hostObj>ns1.example.net</domain:hostObj>
S: </domain:ns>
S: <domain:host>ns1.example.com</domain:host>
S: <domain:host>ns2.example.com</domain:host>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientY</domain:crID>
S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S: <domain:upID>ClientX</domain:upID>
S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S: <domain:authInfo>
S: <domain:pw>2fooBAR</domain:pw>
S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
S: rgp-1.0.xsd">
S: <rgp:rgpStatus s="redemptionPeriod"/>
S: </rgp:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Example <info> response extension for "pendingRestore" status (note that only the extension element changes from the first example):
例<infoRedRestore」ステータスの応答拡張機能（拡張要素のみが最初の例から変更されることに注意してください）：
S:<extension>
S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
S: rgp-1.0.xsd">
S: <rgp:rgpStatus s="pendingRestore"/>
S: </rgp:infData>
S:</extension>
Example <info> response extension for "pendingDelete" status (note that only the extension element changes from the first example):
例<情報>「pandingdelete」ステータスの応答拡張機能（拡張要素のみが最初の例から変更されることに注意してください）：
S:<extension>
S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
S: rgp-1.0.xsd">
S: <rgp:rgpStatus s="pendingDelete"/>
S: </rgp:infData>
S:</extension>
This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP domain mapping [2].
この拡張機能は、EPPドメインマッピング[2]で説明されているEPP <Transfer>コマンドまたは<転送>応答に要素を追加しません。
EPP provides five commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes, and <update> to change information associated with an object.
EPPはオブジェクトを変換するための5つのコマンドを提供します：<create>オブジェクトのインスタンスを作成するには、<delete>オブジェクトのインスタンスを削除し、オブジェクトの有効期間を拡張するために<reing>、オブジェクトスポンサーシップの変更を管理するために<転送>、および<update>オブジェクトに関連付けられた情報を変更します。
This extension does not add any elements to the EPP <create> command or <create> response described in the EPP domain mapping [2].
この拡張機能は、EPPドメインマッピング[2]で説明されているEPP <create>コマンドまたは<create>応答に要素を追加しません。
This extension does not add any elements to the EPP <delete> command or <delete> response described in the EPP domain mapping [2].
この拡張機能は、EPPドメインマッピング[2]で説明されているEPP <delete>コマンドまたは<delete>応答に要素を追加しません。
This extension does not add any elements to the EPP <renew> command or <renew> response described in the EPP domain mapping [2].
この拡張機能は、EPPドメインマッピング[2]で説明されているEPP <neled>コマンドまたは<reine>応答に要素を追加しません。
This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP domain mapping [2].
この拡張機能は、EPPドメインマッピング[2]で説明されているEPP <Transfer>コマンドまたは<転送>応答に要素を追加しません。
This extension defines additional elements to extend the EPP <update> command and response described in the EPP domain mapping [2] for redemption grace period processing.
この拡張機能は、redemption grace期間処理のためにEPPドメインマッピング[2]で説明されているEPP <update>コマンドと応答を拡張するための追加要素を定義します。
The EPP <update> command provides a transform operation that allows a client to change the state of a domain object. The registry grace period extension modifies base update processing to support redemption of domain names for which a <delete> command has been processed, but the name has not yet been purged.
EPP <update>コマンドは、クライアントがドメインオブジェクトの状態を変更できるようにする変換操作を提供します。レジストリグレース期間拡張は、ベースアップデート処理を変更して、<delete>コマンドが処理されたドメイン名の償還をサポートしますが、名前はまだ削除されていません。
Section 3.2.5 of the EPP domain mapping describes the elements that have to be specified within an <update> command. The requirement to provide at least one <domain:add>, <domain:rem>, or <domain:chg> element is updated by this extension such that at least one empty <domain:add>, <domain:rem>, or <domain:chg> element MUST be present if this extension is specified within an <update> command. This requirement is updated to disallow the possibility of modifying a domain object as part of redemption grace period recovery processing.
EPPドメインマッピングのセクション3.2.5では、<update>コマンド内で指定する必要がある要素について説明します。少なくとも1つの<ドメイン：add>、<domain：rem>、または<domain：chg>要素を提供するための要件は、少なくとも1つの空の<ドメイン：add>、<domain：rem>、または<ドメイン：chg>この拡張子が<update>コマンド内で指定されている場合は、存在する必要があります。この要件は、償還猶予期間回復処理の一部としてドメインオブジェクトを変更する可能性を否定するために更新されます。
In addition to the EPP command elements described in the EPP domain mapping [2], the <update> command MUST contain an <extension> element. The <extension> element MUST contain a child <rgp:update> element that identifies the registry grace period namespace and the location of the registry grace period schema. The <rgp:update> element contains a single <rgp:restore> element that contains an OPTIONAL <rgp:report> element that MAY be used to deliver a redemption grace period restore report.
EPPドメインマッピング[2]で説明されているEPPコマンド要素に加えて、<update>コマンドには<extension>要素を含める必要があります。<extension>要素には、レジストリグレースピリオドネームスペースとレジストリグレース期間スキーマの位置を識別する子供<rgp：update>要素を含める必要があります。<rgp：update>要素には、オプションの<rgp：rgp：report>要素が含まれる単一の<rgp：restore>要素が含まれています。
The <rgp:restore> element contains a REQUIRED "op" attribute that describes the redemption grace period operation being requested. Two values are defined: "request" is used to identify a restore request that does not include a restore report, and "report" is used to identify a restore request that contains a restore report. A report MAY be submitted more than once if corrections are required. If the value of the "op" attribute is "request" an <rgp:report> element MUST NOT be present. If the value of the "op" attribute is "report" an <rgp:report> element MUST be present.
<rgp：restore>要素には、要求されているredemption grace期間操作を記述する必要な「op」属性が含まれています。2つの値が定義されています。「リクエスト」は、復元レポートを含まない復元要求を識別するために使用され、「レポート」は復元レポートを含む復元要求を識別するために使用されます。修正が必要な場合は、レポートを複数回提出できます。「op」属性の値が「要求」である場合、<rgp：レポート>要素が存在しないでください。「op」属性の値が「レポート」である場合、<rgp：レポート>要素が存在する必要があります。
The <rgp:report> element contains the following child elements:
<RGP：レポート>要素には、次の子要素が含まれています。
- An <rgp:preData> element that contains a copy of the registration data that existed for the domain name prior to the domain name being deleted. This element MAY contain both text and XML markup.
- <rgp：predata>ドメイン名が削除される前にドメイン名に存在する登録データのコピーを含む要素。この要素には、テキストとXMLマークアップの両方が含まれる場合があります。
- An <rgp:postData> element that contains a copy of the registration data that exists for the domain name at the time the restore report is submitted. This element MAY contain both text and XML markup.
- <rgp：postdata>復元レポートが送信された時点でドメイン名に存在する登録データのコピーを含む要素。この要素には、テキストとXMLマークアップの両方が含まれる場合があります。
- An <rgp:delTime> element that contains the date and time when the domain name delete request was sent to the server.
- <rgp：deltime>ドメイン名の削除要求がサーバーに送信された日付と時刻が含まれる要素。
- An <rgp:resTime> element that contains the date and time when the original <rgp:restore> command was sent to the server.
- <rgp：Restime>要素には、元の<RGP：Restore>コマンドがサーバーに送信された日付と時刻が含まれています。
- An <rgp:resReason> element that contains a brief explanation of the reason for restoring the domain name.
- <rgp：resreason>ドメイン名を復元する理由の簡単な説明を含む要素。
- An <rgp:statement> element that contains a text statement that the client has not restored the domain name in order to assume the rights to use or sell the domain name for itself or for any third party. Supporting information related to this statement MAY be supplied in the <rgp:other> element described below. An OPTIONAL "lang" attribute MAY be present to identify the language if English (value "en") is not used to represent the statement.
- <rgp：statement>クライアントがドメイン名を復元していないというテキストステートメントが含まれている要素は、それ自体または第三者にドメイン名を使用または販売する権利を想定しています。このステートメントに関連するサポート情報は、以下で説明する<RGP：その他>要素で提供される場合があります。英語（value "en"）がステートメントを表すために使用されない場合、言語を識別するためにオプションの「lang」属性が存在する場合があります。
- A second <rgp:statement> element that contains a text statement that the information in the restore report is factual to the best of the client's knowledge. An OPTIONAL "lang" attribute MAY be present to identify the language if English (value "en") is not used to represent the statement.
- 復元レポートの情報は、クライアントの知識の最大限の事実であるというテキストステートメントを含む2番目の<RGP：ステートメント>要素。英語（value "en"）がステートメントを表すために使用されない場合、言語を識別するためにオプションの「lang」属性が存在する場合があります。
- An OPTIONAL <rgp:other> element that contains any information needed to support the statements provided by the client. This element MAY contain both text and XML markup.
- クライアントが提供するステートメントをサポートするために必要な情報を含むオプションの<RGP：その他>要素。この要素には、テキストとXMLマークアップの両方が含まれる場合があります。
More detailed information describing the information required to be provided in a restore report is available from ICANN.
復元レポートで提供される必要がある情報を説明する詳細情報は、ICANNから入手できます。
Example <update> command without a restore report:
復元レポートなしの例<update>コマンド：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
C: <domain:name>example.com</domain:name>
C: <domain:chg/>
C: </domain:update>
C: </update>
C: <extension>
C: <rgp:update xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
C: rgp-1.0.xsd">
C: <rgp:restore op="request"/>
C: </rgp:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <update> command with a restore report:
復元レポート付きの例<update>コマンド：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C: domain-1.0.xsd">
C: <domain:name>example.com</domain:name>
C: <domain:chg/>
C: </domain:update>
C: </update>
C: <extension>
C: <rgp:update xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
C: rgp-1.0.xsd">
C: <rgp:restore op="report">
C: <rgp:report>
C: <rgp:preData>Pre-delete registration data goes here.
C: Both XML and free text are allowed.</rgp:preData>
C: <rgp:postData>Post-restore registration data goes here.
C: Both XML and free text are allowed.</rgp:postData>
C: <rgp:delTime>2003-07-10T22:00:00.0Z</rgp:delTime>
C: <rgp:resTime>2003-07-20T22:00:00.0Z</rgp:resTime>
C: <rgp:resReason>Registrant error.</rgp:resReason>
C: <rgp:statement>This registrar has not restored the
C: Registered Name in order to assume the rights to use
C: or sell the Registered Name for itself or for any
C: third party.</rgp:statement>
C: <rgp:statement>The information in this report is
C: true to best of this registrar's knowledge, and this
C: registrar acknowledges that intentionally supplying
C: false information in this report shall constitute an
C: incurable material breach of the
C: Registry-Registrar Agreement.</rgp:statement>
C: <rgp:other>Supporting information goes
C: here.</rgp:other>
C: </rgp:report>
C: </rgp:restore>
C: </rgp:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an extended <update> command without a restore report has been processed successfully, the EPP response is as described in the EPP domain mapping [2] except that an extension element is added to describe grace period status as a result of processing the <update> command. The extension element contains a single child element (<upData>) that itself contains a single child element (<rgpStatus>) that contains a single attribute "s" whose value MUST be "pendingRestore" if the <restore> request has been accepted.
復元レポートのない拡張<update>コマンドが正常に処理された場合、EPP応答はEPPドメインマッピング[2]に記載されているとおりです。>コマンド。拡張要素には、単一の子要素（<updata>）が含まれています。これには、<復元>要求が受け入れられた場合、値が「pendrestore」でなければならない単一の属性「s」が含まれる単一の子要素（<rgpstatus>）が含まれます。
Example "restore request" <update> response:
例「リクエストの復元」<update>応答：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1000">
S: <msg lang="en">Command completed successfully</msg>
S: </result>
S: <extension>
S: <rgp:upData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
S: rgp-1.0.xsd">
S: <rgp:rgpStatus s="pendingRestore"/>
S: </rgp:upData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
When an extended <update> command with a restore report has been processed successfully, the EPP response is as described in the EPP domain mapping [2] with no registry grace period extension. Registry grace period extension is not required because acceptance of the restore report completes redemption grace period processing.
復元レポートを使用した拡張<update>コマンドが正常に処理された場合、EPP応答は、レジストリグレース期間拡張なしでEPPドメインマッピング[2]で説明されているとおりです。復元レポートを受け入れると償還猶予期間処理が完了するため、レジストリグレース期間の拡張は必要ありません。
An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.
EPPオブジェクトマッピングは、XMLスキーマ表記で指定されています。ここで紹介する正式な構文は、EPP XMLインスタンスの自動検証に適したオブジェクトマッピングの完全なスキーマ表現です。開始タグとエンドタグはスキーマの一部ではありません。それらは、URI登録目的でスキーマの開始と終了に注意するために使用されます。
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:rgp-1.0"
xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<annotation> <documentation> Extensible Provisioning Protocol v1.0 domain name extension schema for registry grace period processing. </documentation> </annotation>
<Annotation> <Documentation>拡張可能なプロビジョニングプロトコルv1.0ドメイン名拡張スキーマレジストリグレース期間処理。</documentation> </annotation>
<!--
Child elements found in EPP commands.
-->
<element name="update" type="rgp:updateType"/>
<!--
Child elements of the <update> command for the
redemption grace period.
-->
<complexType name="updateType">
<sequence>
<element name="restore" type="rgp:restoreType"/>
</sequence>
</complexType>
<complexType name="restoreType">
<sequence>
<element name="report" type="rgp:reportType"
minOccurs="0"/>
</sequence>
<attribute name="op" type="rgp:rgpOpType" use="required"/>
</complexType>
<!--
New redemption grace period operations can be defined
by adding to this enumeration.
-->
<simpleType name="rgpOpType">
<restriction base="token">
<enumeration value="request"/>
<enumeration value="report"/>
</restriction>
</simpleType>
<complexType name="reportType">
<sequence>
<element name="preData" type="rgp:mixedType"/>
<element name="postData" type="rgp:mixedType"/>
<element name="delTime" type="dateTime"/>
<element name="resTime" type="dateTime"/>
<element name="resReason" type="rgp:reportTextType"/>
<element name="statement" type="rgp:reportTextType"
maxOccurs="2"/>
<element name="other" type="rgp:mixedType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="mixedType">
<complexContent mixed="true">
<restriction base="anyType">
<sequence>
<any processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</restriction>
</complexContent>
</complexType>
<complexType name="reportTextType">
<complexContent mixed="true">
<restriction base="anyType">
<sequence>
<any processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="lang" type="language" default="en"/>
</restriction>
</complexContent>
</complexType>
<!--
Child response elements.
-->
<element name="infData" type="rgp:respDataType"/>
<element name="upData" type="rgp:respDataType"/>
<!--
Response elements.
-->
<complexType name="respDataType">
<sequence>
<element name="rgpStatus" type="rgp:statusType"
maxOccurs="unbounded"/>
</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="rgp:statusValueType"
use="required"/>
<attribute name="lang" type="language" default="en"/>
</extension>
</simpleContent>
</complexType>
<simpleType name="statusValueType">
<restriction base="token">
<enumeration value="addPeriod"/>
<enumeration value="autoRenewPeriod"/>
<enumeration value="renewPeriod"/>
<enumeration value="transferPeriod"/>
<enumeration value="pendingDelete"/>
<enumeration value="pendingRestore"/>
<enumeration value="redemptionPeriod"/>
</restriction>
</simpleType>
<!-- End of schema. --> </schema> END
<！ - スキーマの終わり。 - > </schema> end
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 [10]. Conformant XML processors recognize both UTF-8 and UTF-16 [11]. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists.
EPPはXMLで表されており、Unicode文字セットとUTF-8を含むよりコンパクトな表現を使用して、エンコード情報のネイティブサポートを提供します[10]。コンフォーマントXMLプロセッサは、UTF-8とUTF-16の両方を認識しています[11]。XMLには、<？xml？>宣言で「エンコード」属性を使用して他の文字エンコーディングを特定して使用するための規定が含まれていますが、UTF-8の使用は、サポートの互換性が存在するパーサーエンコードが存在する環境で推奨されます。
As an extension of the EPP domain mapping [2], the elements, element content, attributes, and attribute values described in this document MUST inherit the internationalization conventions used to represent higher-layer domain and core protocol structures present in an XML instance that includes this extension.
EPPドメインマッピング[2]の拡張として、このドキュメントで説明されている要素、要素コンテンツ、属性、および属性値は、XMLインスタンスに存在する高層ドメインおよびコアプロトコル構造を表すために使用される国際化条約を継承する必要があります。この拡張機能。
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in RFC 3688 [8]. Two URI assignments were requested and have been registered by the IANA.
このドキュメントでは、URNSを使用して、RFC 3688 [8]に記載されているレジストリメカニズムに準拠したXMLネームスペースとXMLスキーマを記述します。2つのURI割り当てが要求され、IANAによって登録されました。
Registration request for the registry grace period namespace:
レジストリグレース期間名空間の登録要求：
URI: urn:ietf:params:xml:ns:rgp-1.0
Registrant Contact: See the "Author's Address" section of this document.
登録者の連絡先：このドキュメントの「著者のアドレス」セクションを参照してください。
XML: None. Namespace URIs do not represent an XML specification.
XML：なし。名前空間URIはXML仕様を表していません。
Registration request for the registry grace period XML schema:
レジストリグレース期間XMLスキーマの登録要求：
URI: urn:ietf:params:xml:schema:rgp-1.0
Registrant Contact: See the "Author's Address" section of this document.
登録者の連絡先：このドキュメントの「著者のアドレス」セクションを参照してください。
XML: See the "Formal Syntax" section of this document.
XML：このドキュメントの「正式な構文」セクションを参照してください。
The mapping extensions described in this document do not provide any security services beyond those described by EPP [1], the EPP domain name mapping [2], and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well.
このドキュメントで説明されているマッピング拡張機能は、EPP [1]、EPPドメイン名マッピング[2]、およびEPPで使用されるプロトコルレイヤーで説明されているものを超えたセキュリティサービスを提供しません。これらの他の仕様で説明されているセキュリティ上の考慮事項は、この仕様にも適用されます。
As with other domain object updates, redemption of a deleted domain object MUST be restricted to the sponsoring client as authenticated using the mechanisms described in sections 2.9.1.1 and 7 of RFC 3730 [1]. Any attempt to recover a deleted domain object by any client other than the sponsoring client MUST be rejected with an appropriate EPP authorization error.
他のドメインオブジェクトの更新と同様に、削除されたドメインオブジェクトの償還は、RFC 3730のセクション2.9.1.1および7で説明されているメカニズムを使用して認証されたスポンサークライアントに制限する必要があります[1]。スポンサークライアント以外のクライアントによって削除されたドメインオブジェクトを回復しようとする試みは、適切なEPP認証エラーで拒否される必要があります。
The author would like to thank the following people who have provided significant contributions to the development of this document:
著者は、この文書の開発に多大な貢献を提供してくれた以下の人々に感謝したいと思います。
James Gould, Antony Perkov, and Janusz Sienkiewicz.
ジェームズ・グールド、アントニー・パーコフ、およびヤヌス・シエンキヴィッチ。
[1] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
[1] Hollenbeck、S。、「拡張可能なプロビジョニングプロトコル（EPP）」、RFC 3730、2004年3月。
[2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 3731, March 2004.
[2] Hollenbeck、S。、「拡張可能なプロビジョニングプロトコル（EPP）ドメイン名マッピング」、RFC 3731、2004年3月。
[3] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[3] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C。、およびE. Maler、「拡張可能なマークアップ言語（XML）1.0（2番目のED）」、W3C Rec-XML、2000年10月、<http：// wwww.w3.org/tr/rec-xml>。
[4] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.
[4] トンプソン、H。、ビーチ、D。、マロニー、M。、およびN.メンデルソン、「XMLスキーマパート1：構造」、W3C REC-XMLSCHEMA-1、2001年5月、<http://www.w3.org/TR/XMLSCHEMA-1/>。
[5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
[5] Biron、P。and A. Malhotra、「XML Schema Part 2：DataTypes」、W3C REC-XMLSCHEMA-2、2001年5月、<http://www.w3.org/tr/xmlschema-2/>。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[7] Klyne、G。and C. Newman、「インターネット上の日時：タイムスタンプ」、RFC 3339、2002年7月。
[8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[8] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[9] Harrenstien, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
[9] Harrenstien、K.、Stahl、M。、およびE. Feinler、「Nicname/Whois」、RFC 954、1985年10月。
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[10] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[11] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[11] Hoffman、P。and F. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
Author's Address
著者の連絡先
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Scott Hollenbeck Verisign、Inc。21345 Ridgetop Circle Dulles、VA 20166-6503 US
EMail: shollenbeck@verisign.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。