summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3915.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3915.txt')
-rw-r--r--doc/rfc/rfc3915.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc3915.txt b/doc/rfc/rfc3915.txt
new file mode 100644
index 0000000..5892e1f
--- /dev/null
+++ b/doc/rfc/rfc3915.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+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)
+
+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.
+
+Copyright Notice
+
+ Copyright (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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 1]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 2]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+1. Introduction
+
+ 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]).
+
+ 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.
+
+ 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.
+
+ 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:
+
+ 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 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 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.
+
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 3]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ 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.
+
+ 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.
+
+1.1. Conventions Used 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].
+
+ 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.
+
+ 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.
+
+2. Redemption Grace Period State Diagram
+
+ The Redemption Grace Period (RGP) involves several domain state
+ transitions as a domain name moves through the redemption process:
+
+ 1. A domain is initially in the EPP "ok" status, or some other
+ status that allows processing of the EPP <delete> command.
+
+ 2. A <delete> command is received and processed for the domain name.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 4]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ 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.
+
+ 6. The domain name returns to the redemption period state (state 3)
+ if a restore report is not received.
+
+ 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.
+
+ 8. The redemption period elapses before a <restore> request is
+ received.
+
+ 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.
+
+ 10. The domain name is purged once the pending delete period elapses.
+
+ 11. The domain name is available for re-registration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 5]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ Figure 1: RGP State Diagram
+
+ |
+ 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)|
+ | |
+ +----------------------+
+
+3. Object Attributes
+
+ This extension adds additional elements to the EPP domain name
+ mapping [2]. Only new element descriptions are described here.
+
+3.1. Status Values
+
+ 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.
+
+ 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.
+
+
+
+
+Hollenbeck Standards Track [Page 6]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ 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.
+
+ 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.
+
+ pendingRestore: This status value is used to describe a domain that
+ is in the process of being restored after being in the
+ redemptionPeriod state.
+
+ 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].
+
+3.2. Registration Data and Supporting Information
+
+ 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.
+
+ 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.
+
+3.3. Dates and Times
+
+ 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.
+
+
+
+Hollenbeck Standards Track [Page 7]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+3.4. Client Statements
+
+ 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.
+
+4. EPP Command Mapping
+
+ 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.
+
+4.1. EPP Query Commands
+
+ 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.
+
+4.1.1. EPP <check> Command
+
+ This extension does not add any elements to the EPP <check> command
+ or <check> response described in the EPP domain mapping [2].
+
+4.1.2. EPP <info> Command
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 8]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ Example <info> response for "addPeriod" status:
+
+ 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>
+
+
+
+Hollenbeck Standards Track [Page 9]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ S: </response>
+ S:</epp>
+
+ Example <info> response for "redemptionPeriod" status:
+
+ 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"/>
+
+
+
+Hollenbeck Standards Track [Page 10]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ 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):
+
+ 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):
+
+ 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>
+
+4.1.3. EPP <transfer> Command
+
+ This extension does not add any elements to the EPP <transfer>
+ command or <transfer> response described in the EPP domain mapping
+ [2].
+
+4.2. EPP Transform Commands
+
+ 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.
+
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 11]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+4.2.1. EPP <create> Command
+
+ This extension does not add any elements to the EPP <create> command
+ or <create> response described in the EPP domain mapping [2].
+
+4.2.2. EPP <delete> Command
+
+ This extension does not add any elements to the EPP <delete> command
+ or <delete> response described in the EPP domain mapping [2].
+
+4.2.3. EPP <renew> Command
+
+ This extension does not add any elements to the EPP <renew> command
+ or <renew> response described in the EPP domain mapping [2].
+
+4.2.4. EPP <transfer> Command
+
+ This extension does not add any elements to the EPP <transfer>
+ command or <transfer> response described in the EPP domain mapping
+ [2].
+
+4.2.5. EPP <update> Command
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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>
+
+
+
+
+Hollenbeck Standards Track [Page 12]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ 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.
+
+ 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.
+
+ The <rgp:report> element contains the following child elements:
+
+ - 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.
+
+ - 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.
+
+ - An <rgp:delTime> element that contains the date and time when the
+ domain name delete request was sent to the server.
+
+ - An <rgp:resTime> element that contains the date and time when the
+ original <rgp:restore> command was sent to the server.
+
+ - An <rgp:resReason> element that contains a brief explanation of
+ the reason for restoring the domain name.
+
+ - 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.
+
+ - 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.
+
+
+
+
+Hollenbeck Standards Track [Page 13]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ - 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.
+
+ More detailed information describing the information required to be
+ provided in a restore report is available from ICANN.
+
+ Example <update> command without a restore report:
+
+ 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:
+
+ 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">
+
+
+
+Hollenbeck Standards Track [Page 14]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ 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.
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 15]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ Example "restore request" <update> response:
+
+ S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+ S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
+ S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
+ S: epp-1.0.xsd">
+ S: <response>
+ S: <result code="1000">
+ S: <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.
+
+5. 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.
+
+ 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">
+
+
+
+
+Hollenbeck Standards Track [Page 16]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ <annotation>
+ <documentation>
+ Extensible Provisioning Protocol v1.0
+ domain name extension schema for registry grace period
+ processing.
+ </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"/>
+
+
+
+Hollenbeck Standards Track [Page 17]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ <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>
+
+ <!--
+
+
+
+Hollenbeck Standards Track [Page 18]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+ 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
+
+6. 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 [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.
+
+ 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.
+
+
+
+Hollenbeck Standards Track [Page 19]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+7. IANA Considerations
+
+ 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.
+
+ 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.
+
+ Registration request for the registry grace period XML schema:
+
+ 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.
+
+8. Security Considerations
+
+ 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.
+
+ 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.
+
+9. Acknowledgements
+
+ 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.
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 20]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+10. References
+
+10.1. Normative References
+
+ [1] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC
+ 3730, March 2004.
+
+ [2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain
+ Name Mapping", RFC 3731, March 2004.
+
+ [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>.
+
+ [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/>.
+
+ [5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
+ REC-xmlschema-2, May 2001, <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.
+
+ [7] Klyne, G. and C. Newman, "Date and Time on the Internet:
+ Timestamps", RFC 3339, July 2002.
+
+ [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
+ 2004.
+
+10.2. Informative References
+
+ [9] Harrenstien, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC
+ 954, October 1985.
+
+ [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
+ 63, RFC 3629, November 2003.
+
+ [11] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
+ RFC 2781, February 2000.
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 21]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+Author's Address
+
+ Scott Hollenbeck
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ US
+
+ EMail: shollenbeck@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 22]
+
+RFC 3915 EPP Grace Period Mapping September 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ 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.
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Hollenbeck Standards Track [Page 23]
+