Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
Extracted elements (22)
A restore report MAY be submitted more than once if corrections are required. This allows registrars to fix errors in previously submitted reports without restarting the entire redemption process.
When a restore report (op='report') is accepted, no registry grace period extension is included in the EPP response. This is because acceptance of the restore report completes redemption grace period processing, making further RGP status signaling unnecessary.
While the 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. This provides operational flexibility for registries that prefer non-EPP reporting channels.
A domain in the RGP 'pendingDelete' status MUST also be in the 'pendingDelete' status described in the EPP domain mapping (RFC 3731).
Date and time attribute values MUST be represented in UTC using the Gregorian calendar, and the extended date-time form using upper case 'T' and 'Z' characters defined in RFC 3339 MUST be used to represent date-time values.
For the extended <update> command supporting RGP, at least one empty <domain:add>, <domain:rem>, or <domain:chg> element MUST be present if this extension is specified. This prevents modifying a domain object simultaneously with redemption grace period recovery processing.
If the 'op' attribute is 'request', an <rgp:report> element MUST NOT be present. If the 'op' attribute is 'report', an <rgp:report> element MUST be present.
The response to a successful restore request (op='request') MUST include an extension element containing <rgp:upData> with an <rgp:rgpStatus> element whose 's' attribute value MUST be 'pendingRestore'.
The <update> command for RGP MUST contain an <extension> element with a child <rgp:update> element, which in turn contains a single <rgp:restore> element with a REQUIRED 'op' attribute of either 'request' or 'report'.
Use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists. Elements, content, attributes, and attribute values in this extension MUST inherit the internationalization conventions of the higher-layer domain and core protocol structures.
When an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in RFC 3731, and the EPP <extension> element MUST contain a child <rgp:infData> element identifying the registry grace period namespace and schema location.
XML is case sensitive, and unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation.
Seven RGP status values are defined: addPeriod, autoRenewPeriod, renewPeriod, transferPeriod, redemptionPeriod, pendingRestore, and pendingDelete. These are conveyed in the 's' attribute of the <rgp:rgpStatus> element and represent the current grace period state of a domain name.
The addPeriod status is granted after initial registration; autoRenewPeriod after automatic renewal; renewPeriod after explicit renewal; and transferPeriod after a successful sponsorship transfer. In each case, if the registrar deletes the domain during the grace period, the registry provides a credit for the cost of the operation.
The <rgp:infData> element returned in an <info> response contains a single <rgp:rgpStatus> element with a required 's' attribute whose value is one of the seven defined grace period status values. This conveys current grace period state to the client.
The <rgp:report> element contains: <rgp:preData> (pre-delete registration data), <rgp:postData> (post-restore registration data), <rgp:delTime> (delete request timestamp), <rgp:resTime> (restore command timestamp), <rgp:resReason> (reason for restore), two <rgp:statement> elements (client attestations), and an optional <rgp:other> element for supporting information.
Two IANA XML namespace/schema registrations are created: 'urn:ietf:params:xml:ns:rgp-1.0' for the registry grace period namespace, and 'urn:ietf:params:xml:schema:rgp-1.0' for the registry grace period XML schema, both conforming to RFC 3688.
Redemption of a deleted domain object MUST be restricted to the sponsoring client as authenticated using the mechanisms described in RFC 3730. 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.
The mapping extensions described in this document do not provide any security services beyond those described by EPP (RFC 3730), the EPP domain name mapping (RFC 3731), and protocol layers used by EPP. All security considerations from those specifications apply here.
The Redemption Grace Period (RGP) defines an 11-step state machine: domain starts in 'ok', receives a <delete> command, transitions to EPP 'pendingDelete' with RGP status 'redemptionPeriod', then either a <restore> request moves it to 'pendingRestore' (awaiting report), or the period elapses moving it to RGP 'pendingDelete', and finally the domain is purged and available for re-registration.
The <rgp:report> element's schema requires in order: preData (mixedType), postData (mixedType), delTime (dateTime), resTime (dateTime), resReason (reportTextType), one or two statement elements (reportTextType, maxOccurs='2'), and an optional other element (mixedType). All are required except 'other'.
The XML Schema for this extension uses namespace 'urn:ietf:params:xml:ns:rgp-1.0'. The <rgp:restore> element has a required 'op' attribute of enumerated type rgpOpType ('request' or 'report'). The <rgp:rgpStatus> element has a required 's' attribute of type statusValueType and an optional 'lang' attribute (default 'en').