RFC 3915

Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)

📅 published October 2004, from ietf

RFC 3915: Domain Registry Grace Period Mapping for EPP 💖

okay bestie, let's get into it 🎀 This one's from September 2004 and it's a Standards Track document by S. Hollenbeck at VeriSign, Inc. It's published under the Network Working Group banner, and it's all about the Extensible Provisioning Protocol (EPP) and how domain names handle "grace periods" 🦋 The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Status of this Memo ✨

okay so this is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💅 If you want to know where it stands officially, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution is unlimited, so share it with everyone 🌈

Copyright (C) The Internet Society (2004). Mine? Nope, it's the Internet Society's 🙈

Abstract 🦋

this doc describes an EPP extension mapping for managing DNS domain names that are subject to "grace period" policies set by ICANN 🌸 Grace periods exist so a protocol action can be reversed or revoked for a short window after it happens. It's specified in XML, and it extends the EPP domain name mapping to add the features grace period processing needs 💜

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

1. Introduction 🌸

okay so this doc describes an extension mapping for version 1.0 of EPP, which is defined in RFC 3730 [1] ✨ It's an extension of the domain name mapping in RFC 3731 [2], and it's written in Extensible Markup Language (XML) 1.0 [3] with XML Schema notation ([4], [5]) 💅

The EPP core spec [1] has the full picture of EPP command and response structures. You really need to understand that base protocol before this mapping makes sense 🫶

Over several months in 2002, ICANN came up with a proposal for a "grace period" so a Domain Name System (DNS) domain can be recovered (redeemed) before it gets purged from the authoritative registry's repository 😭 This mapping extends the EPP domain <update> command so a domain in the Redemption Grace Period (RGP) can start the redemption process. It also extends the EPP domain <info> response so you can see which grace period a domain is in 👑

In March 2003, ICANN published a task force report about other registry grace periods tied to EPP operations. This mapping adds extension status values for those grace periods, including:

  • An "add grace period" after the initial registration of a domain name. If the registrar deletes the domain name during this period, the registry gives the registrar a credit for the cost of the registration. 💰
  • An "auto-renew grace period" after a domain name registration period expires and the registry automatically extends (renews) it. If the registrar deletes the domain name during this period, the registry gives a credit for the cost of the renewal. 🔁
  • A "renew grace period" after the registrar explicitly extends (renews) a domain name registration period. If the registrar deletes the domain name during this period, the registry gives a credit for the cost of the renewal. ✨
  • A "transfer grace period" after a domain name registration sponsorship moves successfully from one registrar to another. If the new sponsoring registrar deletes the domain name during this period, the registry gives a credit for the cost of the transfer. 🦋

Each grace period lasts a specific amount of time, usually measured in days 🍓 How long each one lasts is up to registry operational policy, and this document doesn't cover it ✨

1.1. Conventions Used In This Document 🎀

Here's the key-word situation, so pay attention bestie 🙈 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:" means lines sent by a protocol client, and "S:" means lines returned by a protocol server 💜 Indentation and white space in examples are only there to show how elements relate. They are not a REQUIRED feature of this specification 💅

XML is case sensitive, which is very important 😭 Unless stated otherwise, XML specifications and examples in this document MUST be interpreted in the character case shown, so you can build 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. Here's the whole journey 👑

  1. A domain starts out 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 set to "redemptionPeriod". The domain stays in this state until either a <restore> operation is requested or the redemption period runs out.
  4. A <restore> operation can be requested using the extended EPP <update> command. Go to step 8 if the redemption period runs out before a <restore> request comes in.
  5. If the <restore> succeeds, the Registry waits for a restore report from the registrar for a period of time the Registry defines. The EPP status stays "pendingDelete" and the RGP status changes to "pendingRestore". This extension defines a way to deliver a restore report over EPP, but an out-of-band mechanism (such as a web site) can also be used to deliver restore reports 🌈
  6. The domain name goes back to the redemption period state (state 3) if no restore report is received.
  7. If a restore report is received, the EPP status goes back to "ok" (or whatever it was before the <delete> command was processed), and the RGP status is removed completely ✨
  8. The redemption period runs out before a <restore> request is received.
  9. The EPP status stays "pendingDelete" and the RGP status changes to "pendingDelete". The domain name stays in this state for a period of time the Registry defines.
  10. The domain name is purged once the pending delete period runs out.
  11. The domain name is available for re-registration 🎀

Figure 1 is the RGP state diagram, and it's giving a whole map 🗺️

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

Figure 1: RGP State Diagram 📊

3. Object Attributes 💖

This extension adds more elements to the EPP domain name mapping [2]. Only the descriptions of the new elements are covered here 🧚

3.1. Status Values ✨

okay so this extension adds new status values 💅 to show every state a domain name can be in during grace period processing 🦋. here they are:

  • addPeriod: this grace period starts right after a domain name is first registered 🌸. if the registrar deletes the domain during this window, the registry gives the registrar a credit for the cost of the registration 💸.
  • autoRenewPeriod: this one kicks in after a registration period expires and the registry renews the domain automatically 🔄. if the registrar deletes it during this window, the registry credits the registrar for the cost of the renewal.
  • renewPeriod: this grace period starts after the registrar explicitly renews the domain 🎀. if the registrar deletes it during this window, the registry credits the registrar for the cost of the renewal.
  • transferPeriod: this one starts after sponsorship of a domain name moves successfully from one registrar to another 🦋. if the new sponsoring registrar deletes the domain during this window, the registry credits the registrar for the cost of the transfer.
  • redemptionPeriod: this status describes a domain that has received a <delete> command but hasn't been purged yet 🙈. there's still a chance to restore it and cancel the deletion, so it's giving second chances.
  • pendingRestore: this status describes a domain that is in the middle of being restored after being in the redemptionPeriod state 🧚.
  • pendingDelete: this status describes a domain that has moved into purge processing after finishing 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 lets a client send copies of registration data (whois [9] data, for example) and supporting info in a restore report, since the RGP process needs it 📋. there's no specific format required here, so both free text and XML markup MAY be used 🫶.

operators of servers that provide registration data might find it useful to include grace period status values in their responses to client queries 👑. this info is super helpful for people who want to know what they can do with a domain name at any given 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 that uses upper case "T" and "Z" characters, as defined in RFC 3339 [7], MUST be used to represent date-time values. the reason is that XML Schema doesn't support truncated date-time forms or lower case "T" and "Z" characters 😭.

3.4. Client Statements 📝

the RGP process requires a client to make two statements about the data in a restore report 💅. there's no specific format required, so both free text and XML markup MAY be used. English is the default language for the statements, but other languages MAY be used too 🌈.

4. EPP Command Mapping 🎀

the detailed EPP syntax and semantics live in the EPP core protocol specification [1] 📖. the command mappings here are specifically for running redemption grace period processes via EPP, so this is the part that's actually about RGP 🔥.

4.1. EPP Query Commands 🔍

EPP has three commands to retrieve object information: <check> to see if an object is known to the server, <info> to get detailed info about an object, and <transfer> to get object transfer status 🦋.

4.1.1. EPP <check> Command ✅

this extension doesn't add any elements to the <check> command or the <check> response in the EPP domain mapping [2] 💖.

4.1.2. EPP <info> Command 🧾

this extension doesn't add any elements to the <info> command in the EPP domain mapping [2] 🙌. it does define additional elements for the <info> response, and that's where the fun is ✨.

when an <info> command is processed successfully, the <resData> element MUST contain child elements as described in [2]. on top of that, the <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 holds one <rgp:rgpStatus> element, which has a single attribute "s" whose value describes the domain's current grace period status 💜. possible status values are described in section Section 3.1.

here's an example <info> response for the 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>
S:  </response>
S:</epp>

here's an example <info> response for the 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"/>
S:      </rgp:infData>
S:    </extension>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

here's an example <info> response extension for the pendingRestore status 🔄 (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>

and here's the example <info> response extension for the pendingDelete status 💀 (again, 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 doesn't add any elements to the <transfer> command or <transfer> response in the EPP domain mapping [2] 🫶.

4.2. EPP Transform Commands 🛠️

EPP has 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 the info associated with an object 🌈.

4.2.1. EPP <create> Command 🌱

this extension doesn't add any elements to the <create> command or <create> response in the EPP domain mapping [2] ✨.

4.2.2. EPP <delete> Command 🗑️

this extension doesn't add any elements to the <delete> command or <delete> response in the EPP domain mapping [2] 💖.

4.2.3. EPP <renew> Command 🔁

this extension doesn't add any elements to the <renew> command or <renew> response in the EPP domain mapping [2] 🌸.

4.2.4. EPP <transfer> Command 🔀

this extension doesn't add any elements to the <transfer> command or <transfer> response in the EPP domain mapping [2] 🧚.

4.2.5. EPP <update> Command ✨

okay so this extension is all about adding extra bits to the EPP <update> command and response from the EPP domain mapping [2] for redemption grace period processing 💖

the EPP <update> command is the transform op that lets a client change the state of a domain object 🔥. the registry grace period extension tweaks base update processing so you can redeem a domain name whose <delete> was already processed but hasn't been purged yet 🦋

Section 3.2.5 of the EPP domain mapping spells out what has to go inside an <update> command 📖. but this extension changes the "at least one" rule. if the extension is in there, at least one empty <domain:add>, <domain:rem>, or <domain:chg> element MUST be present 🫶. and no, you can't modify the domain object during redemption grace period recovery. it's a recovery-only moment, bestie 🙅‍♀️

in addition to the EPP command elements from the EPP domain mapping [2], the <update> command MUST contain an <extension> element 💅. that <extension> element MUST contain a child <rgp:update> element that names the registry grace period namespace and where its schema lives 🗂️. the <rgp:update> element holds one <rgp:restore> element, and that <rgp:restore> element can hold an OPTIONAL <rgp:report> element that MAY be used to deliver a redemption grace period restore report 📝

the <rgp:restore> element has a REQUIRED "op" attribute that says which redemption grace period operation you're asking for 🎀. there are two values. "request" means a restore request with no restore report attached, and "report" means a restore request that does include a restore report 🌸. a report MAY be submitted more than once if corrections are needed 🔁. if "op" is "request", then an <rgp:report> element MUST NOT be present 🚫. if "op" is "report", then an <rgp:report> element MUST be present ✨

the <rgp:report> element has these child elements, and honestly they're all important 🧚

  • An <rgp:preData> element holds a copy of the registration data that existed for the domain name before it was deleted 😭. This element MAY contain both text and XML markup.
  • An <rgp:postData> element holds a copy of the registration data that exists for the domain name when the restore report gets submitted 📸. This element MAY contain both text and XML markup.
  • An <rgp:delTime> element holds the date and time when the domain name delete request was sent to the server ⏰.
  • An <rgp:resTime> element holds the date and time when the original <rgp:restore> command was sent to the server 🕰️.
  • An <rgp:resReason> element holds a brief explanation of why the domain name is being restored 💬.
  • An <rgp:statement> element holds a text statement saying the client has not restored the domain name in order to assume the rights to use or sell it for itself or for any third party 🙅. Supporting information for 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 holds a text statement saying 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 🌏.
  • An OPTIONAL <rgp:other> element holds any information needed to support the statements the client provided 📎. This element MAY contain both text and XML markup.

more detailed info about what a restore report needs is available from ICANN 👑

here's an 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>

and here's one with a restore report attached 🎀

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 gets processed successfully, the response is the same as the EPP domain mapping [2] describes, with one addition 🌈. there's an extension element that shows the grace period status from processing the <update> command. that extension element has a single child, <upData>, which has a single child, <rgpStatus>. the <rgpStatus> element has a single attribute, "s", and its value MUST be "pendingRestore" if the <restore> request was accepted ⭐

here's an 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>

and when an extended <update> command with a restore report gets processed successfully, the response follows the EPP domain mapping [2] with <color>no registry grace period extension</color> 🙌. the extension isn't required here because accepting the restore report is what finishes redemption grace period processing 🏁

5. Formal Syntax 💅

okay so this section is the whole schema written in XML Schema notation, so automated tools can validate EPP XML instances against it 🤖✨ The BEGIN and END lines aren't part of the schema. They just mark where it starts and ends 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">

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

6. Internationalization Considerations 🌍

EPP is written in XML, and XML natively handles information encoded with the Unicode character set, including its more compact forms like UTF-8 [10] 🫶 Conformant XML processors recognize both UTF-8 and UTF-16 [11]. XML can also work with other encodings if you declare them with an "encoding" attribute in the <?xml?> declaration, but in environments where parsers don't fully support the encoding, UTF-8 is RECOMMENDED 💖

Since this is an extension of the EPP domain mapping [2], the elements, element content, attributes, and attribute values described here MUST inherit the internationalization conventions already used for the higher-layer domain and core protocol structures in any XML instance that includes this extension 🌸

7. IANA Considerations 📚

This document uses URNs to name XML namespaces and XML schemas, following the registry mechanism from RFC 3688 [8]. Two URI assignments were requested, and IANA has registered them ✨

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 🔐

⚠️ Please read this section carefully, bestie. It's serious.

The mapping extensions in this document don't add any security services beyond what EPP [1], the EPP domain name mapping [2], and the protocol layers EPP uses already provide. The security considerations in those other specifications apply to this one too 🫶

As with other domain object updates, redemption of a deleted domain object MUST be restricted to the sponsoring client, 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 made significant contributions to the development of this document 🌈

James Gould, Antony Perkov, and Janusz Sienkiewicz 👑

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.

Author's Address 🏠

Scott Hollenbeck
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA  20166-6503
US

EMail: shollenbeck@verisign.com

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth there, the authors keep all their rights.

This document and the information in it 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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document, or on whether any license under those rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. You can find the IETF's procedures for rights in IETF Documents in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to obtain a general license or permission for implementers or users to use these proprietary rights can be found in 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, patent applications, or other proprietary rights that may cover technology needed to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 💜

📦 where this page comes from