Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Extensible Provisioning Protocol
open-in-new
<h2 id="history">History</h2> <p>The first protocol drafts were published as <a href="/facts/IETF/tIcCsFhX">IETF</a> individual submission <a href="/facts/Internet_Draft/h13QYxXa">Internet Draft</a> documents by Scott Hollenbeck of <a href="/facts/Verisign/B57fYEGl">Verisign</a> in November 2000.<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> The individual submission documents were adopted by the <a href="/facts/IETF/tIcCsFhX">IETF</a> <i>Provisioning Registry</i> (<i>provreg</i>) <a href="/facts/Working_group/dFlAPASD">working group</a>, which was created after a <a href="/facts/Birds_of_a_feather_(computing)/tIcCsFhX">BoF</a> session was held at IETF-49 in December 2000.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> Proposed Standard documents (RFCs 3730 - 3734) were published by the <a href="/facts/RFC_Editor/esftTvE7">RFC Editor</a> in March 2004.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a> Draft Standard documents (RFCs 4930 - 4934) were published in May 2007.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> </p><p>In August 2009, IETF granted EPP the status of full standard as STD 69.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> </p><p>The first EPP extension that became a proposed standard was the redemption grace period extension from RFC 3915 in September 2004.<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a> Since then, several different proposed standard extensions followed.<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a> </p> <h2 id="adoption">Adoption</h2> <p>The protocol has been adopted by a number of ccTLD domain name registries, such as: <a href="/facts/.ac/yNKRy2wj">.ac</a>, <a href="/facts/.ag/Rpt3jGpR">.ag</a>, <a href="/facts/.ai/aw4gnbq8">.ai</a>, <a href="/facts/.as/dBanWhju">.as</a>, <a href="/facts/.ar/8H4l8BvF">.ar</a>, <a href="/facts/.at/uaWu3jDP">.at</a>, <a href="/facts/.au/NSS85xac">.au</a>, <a href="/facts/.be/7uHezlyF">.be</a>, <a href="/facts/.br/RU5JM9Dd">.br</a>, <a href="/facts/.bz/CNq026l5">.bz</a>, <a href="/facts/.ca/s4RPd1rg">.ca</a>, <a href="/facts/.cat/YhWnqE4G">.cat</a>, <a href="/facts/.cc/91UB8twW">.cc</a>, <a href="/facts/.ch/NW35ur4W">.ch</a>, <a href="/facts/.cl/GjGDx0zF">.cl</a>, <a href="/facts/.cn/XVar7vVx">.cn</a>, <a href="/facts/.co/ndRh5eAJ">.co</a>, <a href="/facts/.cr/S11cWmwn">.cr</a>, <a href="/facts/.cx/hbcXNFn3">.cx</a>, <a href="/facts/.cz/R6VF9wTL">.cz</a>, <a href="/facts/.dk/gTwkE1C6">.dk</a>, <a href="/facts/.dm/a5DXN3HQ">.dm</a>, <a href="/facts/.ee/IpkK82k0">.ee</a>, <a href="/facts/.es/D8Jw0hal">.es</a> (over HTTPS), <a href="/facts/.eu/beQUzFIB">.eu</a>, <a href="/facts/.fi/hKlyK5z7">.fi</a>, <a href="/facts/.fm/YNRlHjV9">.fm</a>, <a href="/facts/.fr/IpFBQRHM">.fr</a>, <a href="/facts/.gg/28bpc4A8">.gg</a>, <a href="/facts/.gr/0etg5RBq">.gr</a> (over HTTPS), <a href="/facts/.gs/YA5bBxoV">.gs</a>, <a href="/facts/.hn/y0KGs2uj">.hn</a>, <a href="/facts/.ht/7Lyp6cdy">.ht</a>, <a href="/facts/.il/fJjfceww">.il</a>, <a href="/facts/.im/WmC9gqNp">.im</a>, <a href="/facts/.in/4tMUobrk">.in</a>, <a href="/facts/.io/PV85Ilx4">.io</a>, <a href="/facts/.it/T5AXf3Ud">.it</a> (over HTTPS), <a href="/facts/.je/t9A7oXEe">.je</a>, <a href="/facts/.ke/a4LJUzPz">.ke</a>, <a href="/facts/.ki/lRfF8IWz">.ki</a>, <a href="/facts/.ky/T2lX3oA5">.ky</a>, <a href="/facts/.kz/LTydukBM">.kz</a>, <a href="/facts/.la/yGzgFC2h">.la</a>, <a href="/facts/.lc/MErexMBE">.lc</a>, <a href="/facts/.li/Twtq3QyK">.li</a>, <a href="/facts/.lt/NRn6k7Ey">.lt</a>, <a href="/facts/.lu/7I1qJl36">.lu</a>, <a href="/facts/.lv/uXAqFtVm">.lv</a>, <a href="/facts/.md/HplsvGv5">.md</a>, <a href="/facts/.me/NXd4D4xu">.me</a>, <a href="/facts/.mk/8r1V5X7r">.mk</a>, <a href="/facts/.mn/5bmQ6HPC">.mn</a>, <a href="/facts/.ms/kbdkHRC2">.ms</a>, <a href="/facts/.mu/hgs4AEur">.mu</a>, <a href="/facts/.mx/l9I0pVcP">.mx</a>, <a href="/facts/.na/UvIo6Kf4">.na</a>, <a href="/facts/.nf/0pM94KDv">.nf</a>, <a href="/facts/.ng/UG9051Ip">.ng</a>, <a href="/facts/.nl/TY9kv3wd">.nl</a>, <a href="/facts/.no/p4gvdcT8">.no</a>, <a href="/facts/.nu/v5fg2z3M">.nu</a>, <a href="/facts/.nz/lDtelBkR">.nz</a>, <a href="/facts/.pe/4qPrdvHm">.pe</a>, <a href="/facts/.pk/8aqyKAoj">.pk</a>, <a href="/facts/.pl/xa48tDmu">.pl</a> (over HTTPS), <a href="/facts/.ps/RDvS8hnu">.ps</a>, <a href="/facts/.pt/vLVxMw6C">.pt</a>, <a href="/facts/.ru/fsMQSYQ5">.ru</a>, <a href="/facts/.ro/XggKfwPr">.ro</a>, <a href="/facts/.sc/0L6j6lcS">.sc</a>, <a href="/facts/.se/X1DczMpM">.se</a>, <a href="/facts/.sh/CvkgpkPl">.sh</a>, <a href="/facts/.si/x9LsnJW7">.si</a>, <a href="/facts/.su/oHPNNGAK">.su</a>, <a href="/facts/.tl/mGC8YVDD">.tl</a>, <a href="/facts/.tm/89hVklNy">.tm</a> <a href="/facts/.tv/11f9wvhH">.tv</a>, <a href="/facts/.tw/E2WF3G4s">.tw</a>, <a href="/facts/.ua/AeyYxb3g">.ua</a>, <a href="/facts/.uk/3wmyJIPb">.uk</a>, <a href="/facts/.us/sxNJKBJ5">.us</a>, <a href="/facts/.vc/FvMGvER2">.vc</a>, <a href="/facts/.ve/ywLh3q8u">.ve</a> and <a href="/facts/.za/WxupDMHX">.za</a> as well as <a href="/facts/ENUM/pstRkFpk">ENUM</a> registries such as those operating the +31, +41, +43, +44 and +48 country codes.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a> </p><p><a href="/facts/ICANN/2EHgcUU1">ICANN</a> has made it a condition in their base registry contract to offer an EPP service. Therefore, every <a href="/facts/Generic_top-level_domain/X0sNABPE">gTLD</a> has adopted the protocol.<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a> </p><p>There are multiple <a href="/facts/Open_source/7X9rCdz4">open source</a> implementations of EPP server software. The Council of Country Code Administrators (CoCCA) maintains an EPP server software used by around 59 ccTLDs and six gTLDs.<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a> Another open source software is FRED (maintained by <a href="/facts/CZ.NIC/GIcRtBzv">CZ.NIC</a>) which counts 11 ccTLDs as its users.<a class="footnote-ref" id="fnref:13" href="#fn:13"><sup>13</sup></a> </p> <h2 id="protocol-commands">Protocol commands</h2> <p>There are three classes of commands: Session management, query, and object transform. These commands can then be mapped onto objects, which specifies their exact functionality.<a class="footnote-ref" id="fnref:14" href="#fn:14"><sup>14</sup></a> The most common standardized objects are hosts,<a class="footnote-ref" id="fnref:15" href="#fn:15"><sup>15</sup></a> contacts<a class="footnote-ref" id="fnref:16" href="#fn:16"><sup>16</sup></a> and domains.<a class="footnote-ref" id="fnref:17" href="#fn:17"><sup>17</sup></a> There are also other standardized objects like organizations,<a class="footnote-ref" id="fnref:18" href="#fn:18"><sup>18</sup></a> however they are rarely used. </p><p>When the client connects to a server, the server immediately sends a "greeting" message to the client. This message contains information about the server that the client needs to connect to. This contains the name of the server, the server's current date and time in UTC, the supported features, and a privacy policy. The supported features include EPP versions, languages, objects, and extensions.<a class="footnote-ref" id="fnref:19" href="#fn:19"><sup>19</sup></a> </p><p>The session management commands are:<a class="footnote-ref" id="fnref:20" href="#fn:20"><sup>20</sup></a> </p> <table><tbody><tr><th>Command</th><th>Usage</th></tr><tr><td>hello</td><td>Request another "greeting" response from the server.</td></tr><tr><td>login</td><td>Start a new session that will be kept open until either logout is used or the server logs out the user. Also used to change the password. The client has to choose one EPP version and one language from the "greeting" message on login. It also has to select all objects and extensions that the server supports and wants to use in this session.</td></tr><tr><td>logout</td><td>End the current session.</td></tr></tbody></table> <p>The query commands are:<a class="footnote-ref" id="fnref:21" href="#fn:21"><sup>21</sup></a> </p> <table><tbody><tr><th>Command</th><th>Usage</th></tr><tr><td>check</td><td>Check whether an object is still available to create.</td></tr><tr><td>info</td><td>Get all the current information about an object.</td></tr><tr><td>poll</td><td>Read a message from the server for the user or acknowledge receipt, thereby deleting it to receive the next message. (<a href="/facts/Message_queue/Kq7kX86w">Message Queue</a>)</td></tr><tr><td>transfer</td><td>Get the current status of a started object transfer process.</td></tr></tbody></table> <p>The object transform commands are:<a class="footnote-ref" id="fnref:22" href="#fn:22"><sup>22</sup></a> </p> <table><tbody><tr><th>Command</th><th>Usage</th></tr><tr><td>create</td><td>Create a new object.</td></tr><tr><td>delete</td><td>Delete the object. Hosts and Contacts are deleted immediately, while domains mainly change into a <a href="/facts/Redemption_Grace_Period/21QPpT4q">redemption grace period</a>.</td></tr><tr><td>renew</td><td>Increase the amount of time the domain name is registered. Not available for objects other than domains as these don't have a lifetime.</td></tr><tr><td>transfer</td><td>Change the registrar/owner of the object. Can be used to start an incoming transfer process or cancel it as well as to approve or reject an outgoing transfer.</td></tr><tr><td>update</td><td>Update the object. This generally includes domain owner changes, although these are often implemented via EPP extensions because of a more complex workflow for these operations depending on the TLD.</td></tr></tbody></table> <h2 id="example">Example</h2><p> An example command to create a domain could look like this:</p><?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> <command> <create> <domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> <domain:name>example.com</domain:name> <domain:period unit="y">1</domain:period> <domain:ns> <domain:hostObj>ns1.example.net</domain:hostObj> <domain:hostObj>ns2.example.net</domain:hostObj> </domain:ns> <domain:registrant>REG-1738</domain:registrant> <domain:contact type="admin">ADM-9374</domain:contact> <domain:contact type="tech">OTH-2567</domain:contact> <domain:contact type="billing">OTH-2567</domain:contact> <domain:authInfo> <domain:pw>y85NS%FJ4zeKuHXo</domain:pw> </domain:authInfo> </domain:create> </create> <clTRID>uu28qbb2wo6o5bpk</clTRID> </command> </epp> <p>Note that the two host objects and three different contact objects had to be created beforehand to use them and the client had to be logged in already. The <a href="/facts/Transfer_secret/7yz0CLwY">authInfo pw</a> is a secret required in the transfer between registrars. The clTRID is a unique transaction ID for each command the client generates. A server response to the command above could look like this:</p><?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> <response> <result code="1000"> <msg>Command completed successfully</msg> </result> <resData> <domain:creData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> <domain:name>example.com</domain:name> <domain:crDate>2023-03-12T12:00:00.0Z</domain:crDate> <domain:exDate>2024-03-12T12:00:00.0Z</domain:exDate> </domain:creData> </resData> <trID> <clTRID>uu28qbb2wo6o5bpk</clTRID> <svTRID>ma3fuaeuh7bzpgv9</svTRID> </trID> </response> </epp> <p>The clTRID is the same as the client sent, while the svTRID is a unique transaction ID the server generates. The server returns a result code, message, and additional result data, such as the expiration date of the newly created domain. </p><h2 id="extensions">Extensions</h2> <p>The protocol offers the ability to send an extension object on almost every possible command to enable registries to add new functionality without changing the base commands.<a class="footnote-ref" id="fnref:23" href="#fn:23"><sup>23</sup></a> </p><p>There are a few standardized extensions that are used by a lot of registries. These include extensions for <a href="/facts/DNSSEC/cL9zwhjj">DNSSEC</a>,<a class="footnote-ref" id="fnref:24" href="#fn:24"><sup>24</sup></a> <a href="/facts/Internationalized_domain_name/nbaJweyM">IDN</a>,<a class="footnote-ref" id="fnref:25" href="#fn:25"><sup>25</sup></a> premium domain names,<a class="footnote-ref" id="fnref:26" href="#fn:26"><sup>26</sup></a> domain restoration (<a href="/facts/Redemption_Grace_Period/21QPpT4q">RGP</a>)<a class="footnote-ref" id="fnref:27" href="#fn:27"><sup>27</sup></a> and extensions to handle the launch of new TLDs<a class="footnote-ref" id="fnref:28" href="#fn:28"><sup>28</sup></a> and Registry Maintenances<a class="footnote-ref" id="fnref:29" href="#fn:29"><sup>29</sup></a> among other things.<a class="footnote-ref" id="fnref:30" href="#fn:30"><sup>30</sup></a> </p><p>Some registries also developed extensions that are specific to their TLDs. A common use case for non-standardized extensions is collecting extra data needed to create a domain, for example, a <a href="/facts/VAT_identification_number/1uWxy0gf">VAT identification number</a>.<a class="footnote-ref" id="fnref:31" href="#fn:31"><sup>31</sup></a> </p> <h2 id="result-codes">Result codes</h2> <p>All responses from the server have to follow a specified format. Each response code corresponds to a human-readable message. Codes in the format 1xxx are successful operations, while codes in the format 2xxx are errors. The errors are again divided into protocol syntax errors in the format 20xx, implementation-specific rules as 21xx, security as 22xx, data management as 23xx, server system as 24xx, and connection management as 25xx. Most results can include additional data in the resData object, for example, which required parameter is missing.<a class="footnote-ref" id="fnref:32" href="#fn:32"><sup>32</sup></a> </p><p>The response code 1001 enables offline processing, an example for this can be that a domain name registry wants to validate a registrant before the domain is registered. In this case, the domain is blocked for other clients until the process is complete, and the client will be notified via a poll message that the client can fetch via the poll command. The codes 1300 and 1301 are specifically for the poll command and signal whether there is a message.<a class="footnote-ref" id="fnref:33" href="#fn:33"><sup>33</sup></a> </p><p>The complete list of standardized result codes and result messages is:<a class="footnote-ref" id="fnref:34" href="#fn:34"><sup>34</sup></a> </p> <table><tbody><tr><th>Code</th><th>Message</th></tr><tr><td>1000</td><td>Command completed successfully</td></tr><tr><td>1001</td><td>Command completed successfully; action pending</td></tr><tr><td>1300</td><td>Command completed successfully; no messages</td></tr><tr><td>1301</td><td>Command completed successfully; ack to dequeue</td></tr><tr><td>1500</td><td>Command completed successfully; ending session</td></tr><tr><td>2000</td><td>Unknown command</td></tr><tr><td>2001</td><td>Command syntax error</td></tr><tr><td>2002</td><td>Command use error</td></tr><tr><td>2003</td><td>Required parameter missing</td></tr><tr><td>2004</td><td>Parameter value range error</td></tr><tr><td>2005</td><td>Parameter value syntax error</td></tr><tr><td>2101</td><td>Unimplemented command</td></tr><tr><td>2102</td><td>Unimplemented option</td></tr><tr><td>2103</td><td>Unimplemented extension</td></tr><tr><td>2104</td><td>Billing failure</td></tr><tr><td>2105</td><td>Object is not eligible for renewal</td></tr><tr><td>2106</td><td>Object is not eligible for transfer</td></tr><tr><td>2200</td><td>Authentication error</td></tr><tr><td>2201</td><td>Authorization error</td></tr><tr><td>2202</td><td>Invalid authorization information</td></tr><tr><td>2300</td><td>Object pending transfer</td></tr><tr><td>2301</td><td>Object not pending transfer</td></tr><tr><td>2302</td><td>Object exists</td></tr><tr><td>2303</td><td>Object does not exist</td></tr><tr><td>2304</td><td>Object status prohibits operation</td></tr><tr><td>2305</td><td>Object association prohibits operation</td></tr><tr><td>2306</td><td>Parameter value policy error</td></tr><tr><td>2307</td><td>Unimplemented object service</td></tr><tr><td>2308</td><td>Data management policy violation</td></tr><tr><td>2400</td><td>Command failed</td></tr><tr><td>2500</td><td>Command failed; server closing connection</td></tr><tr><td>2501</td><td>Authentication error; server closing connection</td></tr><tr><td>2502</td><td>Session limit exceeded; server closing connection</td></tr></tbody></table> <h2 id="epp-object-status-codes">EPP object status codes</h2> <p>There are two types of status codes: server and client. The difference is that all server status codes can only be set and removed by the registry, while the client status codes can also be set and removed by the registrar unless a server status code prohibits it.<a class="footnote-ref" id="fnref:35" href="#fn:35"><sup>35</sup></a> </p><p>The server status codes are commonly used to handle domain abuse cases, mark the domain lifecycle stage, or offer extra security against unauthorized tampering, a service often referred to as Registry-Lock. </p><p>The client status codes are commonly used also to handle abuse cases, non-payment, invalid contact data, or for a <a href="/facts/Registrar-Lock/xvgPVkWK">Registrar-Lock</a> feature. </p><p>The currently standardized server status codes are:<a class="footnote-ref" id="fnref:36" href="#fn:36"><sup>36</sup></a><a class="footnote-ref" id="fnref:37" href="#fn:37"><sup>37</sup></a> </p> <table><tbody><tr><th>Server Status</th><th>Description</th><th>User required action</th></tr><tr><td>addPeriod</td><td>This grace period is provided after the initial registration of a domain name. If the registrar deletes the domain name during this period, the registry may provide credit to the registrar for the cost of the registration.</td><td>This is an informative status set for the first several days of your domain's registration. There is no issue with your domain name.</td></tr><tr><td>autoRenewPeriod</td><td>This grace period is provided after a domain name registration period expires and is extended (renewed) automatically by the registry. If the registrar deletes the domain name during this period, the registry credits the registrar for the renewal cost.</td><td>This is an informative status set for a limited time after your domain's auto-renewal by the registry. If you do not want to keep it (i.e., pay the renewal fee) anymore, you should contact your registrar immediately to discuss options.</td></tr><tr><td>inactive</td><td>This status code indicates that delegation information (name servers) has not been associated with your domain. Your domain is not activated in the DNS and will not resolve.</td><td>If your domain has remained in this status for several days, you may want to contact your registrar to request information about the delay in processing. If the TLD requires documentation to be provided for registration, you may need to provide the required documentation.</td></tr><tr><td>ok</td><td>This is the standard status for a domain, meaning it has no pending operations or prohibitions.</td><td>Asking your registrar to enact status restrictions, like clientTransferProhibited, clientDeleteProhibited, and clientUpdateProhibited, can help to prevent unauthorized transfers, deletions, or updates to your domain.</td></tr><tr><td>pendingCreate</td><td>This status code indicates that a request to create your domain has been received and is being processed.</td><td>If the TLD is on a special registration period (e.g., sunrise), this may indicate that the domain name will be allocated at the end of such period.</td></tr><tr><td>pendingDelete</td><td>This status code may be mixed with redemptionPeriod or pendingRestore. In such a case, depending on the status (i.e., redemption period or pending restore) set in the domain name, the corresponding description presented above applies. Suppose this status is not combined with the redemptionPeriod or pendingRestore status. In that case, the pendingDelete status code indicates that your domain has been in redemptionPeriod status for 30 days, and you have not restored it within those 30 days. Your domain will remain in this status for several days, after which time your domain will be purged and dropped from the registry database. Once deletion occurs, the domain is available for re-registration following the registry's policies.</td><td>If you want to keep your domain name, you must immediately contact your registrar to discuss available options.</td></tr><tr><td>pendingRenew</td><td>This status code indicates that a request to renew your domain has been received and is being processed.</td><td>If you did not request to renew your domain and do not want to keep it (i.e., pay the renewal fee) anymore, you should contact your registrar immediately to discuss what options are available.</td></tr><tr><td>pendingRestore</td><td>This status code indicates that your registrar has asked the registry to restore your domain, which was in redemptionPeriod status. Your registry will hold the domain in this status while waiting for your registrar to provide the required restoration documentation. Suppose your registrar fails to provide documentation to the registry operator within a set period to confirm the restoration request. In that case, the domain will revert to redemptionPeriod status.</td><td>Watch your domain's status codes within this frequently defined seven-day period to ensure that your registrar has submitted the correct restoration documentation within the time window. If this period ended and your domain has reverted to a redemptionPeriod status, contact your registrar to resolve whatever issues that may have halted the delivery of your domain's required restoration documentation.</td></tr><tr><td>pendingTransfer</td><td>This status code indicates that a request to transfer your domain to a new registrar has been received and is being processed.</td><td>If you did not request to transfer your domain, you should contact your registrar immediately to request that they deny the transfer request on your behalf.</td></tr><tr><td>pendingUpdate</td><td>This status code indicates that a request to update your domain has been received and is being processed</td><td>If you did not request to update your domain, you should contact your registrar immediately to resolve the issue.</td></tr><tr><td>redemptionPeriod</td><td>This status code indicates that your registrar has asked the registry to delete your domain. Your domain will be held in this status for 30 days. After five calendar days following the end of the redemptionPeriod, your domain is purged from the registry database and becomes available for registration.</td><td>If you want to keep your domain, you must immediately contact your registrar to resolve whatever issues resulted in your registrar requesting that your domain be deleted, which resulted in the redemptionPeriod status for your domain. Once any outstanding issues are resolved and the appropriate fee has been paid, your registrar should restore the domain on your behalf.</td></tr><tr><td>renewPeriod</td><td>This grace period is provided after a domain name registration period is explicitly extended (renewed) by the registrar. If the registrar deletes the domain name during this period, the registry credits the registrar for the renewal cost.</td><td>This is an informative status set for a limited period of your domain's renewal by your registrar. If you did not request to renew your domain and do not want to keep it (i.e., pay the renewal fee) anymore, you should contact your registrar immediately to discuss what options are available.</td></tr><tr><td>serverDeleteProhibited</td><td>This status code prevents your domain from being deleted. It is an uncommon status that is usually enacted during legal disputes, at your request, or when a redemptionPeriod status is in place.</td><td>This status may indicate an issue with your domain that needs resolution. If so, you should contact your registrar to request more information and to resolve the issue. If your domain has no issues and you simply want to delete it, you must first contact your registrar and request that they work with the Registry Operator to remove this status code. Alternatively, some Registry Operators offer a Registry Lock Service that allows registrants, through their registrars, to set this status as an extra protection against unauthorized deletions. Removing this status can take longer than it does for clientDeleteProhibited because your registrar has to forward your request to your domain's registry and wait for them to lift the restriction.</td></tr><tr><td>serverHold</td><td>This status code is set by your domain's Registry Operator. Your domain is not activated in the DNS.</td><td>If you provided delegation information (name servers), this status may indicate an issue with your domain that needs resolution. If so, you should contact your registrar to request more information. Suppose your domain has no issues, but you need it to resolve in the DNS. In that case, you must contact your registrar to provide the necessary delegation information.</td></tr><tr><td>serverRenewProhibited</td><td>This status code indicates your domain's Registry Operator will not allow your registrar to renew your domain. It is an uncommon status that is usually enacted during legal disputes or when your domain is subject to deletion.</td><td>Often, this status indicates an issue with your domain that needs to be addressed promptly. You should contact your registrar to request more information and resolve the issue. If your domain does not have any issues, and you simply want to renew it, you must first contact your registrar and request that they work with the Registry Operator to remove this status code. This process can take longer than it does for clientRenewProhibited because your registrar has to forward your request to your domain's registry and wait for them to lift the restriction.</td></tr><tr><td>serverTransferProhibited</td><td>This status code prevents your domain from being transferred from your current registrar to another. It is an uncommon status that is usually enacted during legal or other disputes, at your request, or when a redemptionPeriod status is in place.</td><td>This status may indicate an issue with your domain that needs to be addressed promptly. You should contact your registrar to request more information and resolve the issue. If your domain does not have any issues, and you simply want to transfer it to another registrar, you must first contact your registrar and request that they work with the Registry Operator to remove this status code. Alternatively, some Registry Operators offer a Registry Lock Service that allows registrants, through their registrars to set this status as an extra protection against unauthorized transfers. Removing this status can take longer than it does for clientTransferProhibited because your registrar has to forward your request to your domain's registry and wait for them to lift the restriction.</td></tr><tr><td>serverUpdateProhibited</td><td>This status code locks your domain, preventing it from being updated. It is an uncommon status that is usually enacted during legal disputes, at your request, or when a redemptionPeriod status is in place.</td><td>This status may indicate an issue with your domain that needs resolution. If so, you should contact your registrar for more information or to resolve the issue. If your domain does not have any issues, and you simply want to update it, you must first contact your registrar and request that they work with the Registry Operator to remove this status code. Alternatively, some Registry Operators offer a Registry Lock Service that allows registrants, through their registrars to set this status as an extra protection against unauthorized updates. Removing this status can take longer than it does for clientUpdateProhibited because your registrar has to forward your request to your domain's registry and wait for them to lift the restriction.</td></tr><tr><td>transferPeriod</td><td>This grace period is provided after successfully transferring a domain name from one registrar to another. If the new registrar deletes the domain name during this period, the registry provides a credit to the registrar for the cost of the transfer.</td><td>This is an informative status set for a limited period of your domain's transfer to a new registrar. If you did not request to transfer your domain, you should contact your original registrar.</td></tr></tbody></table> <p>The currently standardized client status codes are:<a class="footnote-ref" id="fnref:38" href="#fn:38"><sup>38</sup></a> </p> <table><tbody><tr><th>Client Status</th><th>Description</th><th>User required action</th></tr><tr><td>clientDeleteProhibited</td><td>This status code tells your domain's registry to reject requests to delete the domain.</td><td>This status indicates that it is not possible to delete the domain name registration, which can prevent unauthorized deletions resulting from hijacking and/or fraud. If you do want to delete your domain, you must first contact your registrar and request that they remove this status code.</td></tr><tr><td>clientHold</td><td>This status code tells your domain's registry to not activate your domain in the DNS and as a consequence, it will not resolve. It is an uncommon status that is usually enacted during legal disputes, non-payment, or when your domain is subject to deletion.</td><td>Often, this status indicates an issue with your domain that needs resolution. If so, you should contact your registrar to resolve the issue. If your domain does not have any issues, but you need it to resolve, you must first contact your registrar and request that they remove this status code.</td></tr><tr><td>clientRenewProhibited</td><td>This status code tells your domain's registry to reject requests to renew your domain. It is an uncommon status that is usually enacted during legal disputes or when your domain is subject to deletion.</td><td>Often, this status indicates an issue with your domain that needs resolution. If so, you should contact your registrar to resolve the issue. If your domain does not have any issues, and you simply want to renew it, you must first contact your registrar and request that they remove this status code.</td></tr><tr><td>clientTransferProhibited</td><td>This status code tells your domain's registry to reject requests to transfer the domain from your current registrar to another.</td><td>This status indicates that it is not possible to transfer the domain name registration, which will help prevent unauthorized transfers resulting from hijacking and/or fraud. If you do want to transfer your domain, you must first contact your registrar and request that they remove this status code.</td></tr><tr><td>clientUpdateProhibited</td><td>This status code tells your domain's registry to reject requests to update the domain.</td><td>This domain name status indicates that it is not possible to update the domain, which can help prevent unauthorized updates resulting from fraud. If you do want to update your domain, you must first contact your registrar and request that they remove this status code.</td></tr></tbody></table> <h2 id="security-considerations">Security considerations</h2> <p>EPP only offers plain text passwords, additionally the EPP login password type is specified to be a string of 6-16 character length<a class="footnote-ref" id="fnref:39" href="#fn:39"><sup>39</sup></a> which might be considered very low for today's standards. Connections over TCP, therefore, must use <a href="/facts/Transport_Layer_Security/pGy16TnA">TLS</a>, and the use of <a href="/facts/Client_certificate/6w3cM2AV">client certificates</a>, as well as correct identity confirmation of the client and server, is strongly encouraged.<a class="footnote-ref" id="fnref:40" href="#fn:40"><sup>40</sup></a> </p><p>Many domain name registries also offer to set up a <a href="/facts/Whitelist/d00CnYNc">IP whitelist</a> for connecting to their EPP servers. </p><p>EPP offers some protection against replay attacks via the client generated clTRID, however this element is optional and is therefore not used by every server software. Therefore, additional anti-replay mechanisms should be implemented by the used transport mechanism.<a class="footnote-ref" id="fnref:41" href="#fn:41"><sup>41</sup></a> </p> <h2 id="related-rfcs">Related RFCs</h2> <ul><li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc3375">3375</a>, <i>Generic Registry-Registrar Protocol Requirements</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc5730">5730</a>, <i>Extensible Provisioning Protocol (EPP)</i> (obsoletes RFC <a href="https://datatracker.ietf.org/doc/html/rfc4930">4930</a>, which obsoleted RFC <a href="https://datatracker.ietf.org/doc/html/rfc3730">3730</a>)</li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc5734">5734</a>, <i>Extensible Provisioning Protocol (EPP) Transport over TCP</i> (obsoletes RFC <a href="https://datatracker.ietf.org/doc/html/rfc4934">4934</a>)</li></ul> <h3>EPP Objects RFCs</h3> <ul><li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc5731">5731</a>, <i>Extensible Provisioning Protocol (EPP) Domain Name Mapping</i> (obsoletes RFC <a href="https://datatracker.ietf.org/doc/html/rfc4931">4931</a>)</li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc5732">5732</a>, <i>Extensible Provisioning Protocol (EPP) Host Mapping</i> (obsoletes RFC <a href="https://datatracker.ietf.org/doc/html/rfc4932">4932</a>)</li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc5733">5733</a>, <i>Extensible Provisioning Protocol (EPP) Contact Mapping</i> (obsoletes RFC <a href="https://datatracker.ietf.org/doc/html/rfc4933">4933</a>)</li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc8543">8543</a>, <i>Extensible Provisioning Protocol (EPP) Organization Mapping</i></li></ul> <h3>EPP Extension RFCs</h3> <ul><li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc3735">3735</a>, <i>Guidelines for Extending EPP</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc3915">3915</a>, <i>Domain Registry Grace Period Mapping</i> (e.g. Add Grace Period, <a href="/facts/Redemption_Grace_Period/21QPpT4q">Redemption Grace Period</a>)</li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc4114">4114</a>, <i>E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc5076">5076</a>, <i><a href="/facts/ENUM/pstRkFpk">ENUM</a> Validation Information Mapping for the Extensible Provisioning Protocol</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc5910">5910</a>, <i>Domain Name System (<a href="/facts/DNS/rfxdWFsj">DNS</a>) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)</i> (obsoletes RFC <a href="https://datatracker.ietf.org/doc/html/rfc4310">4310</a>, <a href="/facts/DNSSEC/cL9zwhjj">DNSSEC</a>)</li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc8334">8334</a>, <i>Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc8495">8495</a>, <i>Allocation Token Extension for the Extensible Provisioning Protocol (EPP)</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc8544">8544</a>, <i>Organization Extension for the Extensible Provisioning Protocol (EPP)</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc8590">8590</a>, <i>Change Poll Extension for the Extensible Provisioning Protocol (EPP)</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc8748">8748</a>, <i>Registry Fee Extension for the Extensible Provisioning Protocol (EPP)</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc8807">8807</a>, <i>Login Security Extension for the Extensible Provisioning Protocol (EPP)</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc9038">9038</a>, <i>Extensible Provisioning Protocol (EPP) Unhandled Namespaces</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc9154">9154</a>, <i>Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer</i></li> <li>RFC <a href="https://datatracker.ietf.org/doc/html/rfc9167">9167</a>, <i>Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)</i></li></ul> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/WHOIS/B8wFy1BS">WHOIS</a></li> <li><a href="/facts/Registration_Data_Access_Protocol/kF4yAyr8">Registration Data Access Protocol</a></li> <li><a href="/facts/ICANN/2EHgcUU1">ICANN</a></li> <li><a href="/facts/Internationalized_domain_name/nbaJweyM">Internationalized domain name</a></li> <li><a href="/facts/Glue_record/rfxdWFsj">Glue record</a></li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>Hollenbeck, S. (2001-05-01). "Extensible Provisioning Protocol". IETF Datatracker. Retrieved 2023-03-13. <a href="https://datatracker.ietf.org/doc/html/draft-hollenbeck-epp-00" target="_blank">https://datatracker.ietf.org/doc/html/draft-hollenbeck-epp-00</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>"IETF December 2000 Proceedings". www.ietf.org. Retrieved 2023-03-13. <a href="https://www.ietf.org/proceedings/49/00dec-36.htm#P5400_260270" target="_blank">https://www.ietf.org/proceedings/49/00dec-36.htm#P5400_260270</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Hollenbeck, S. (March 2004). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC3730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC3730" target="_blank">https://doi.org/10.17487/RFC3730</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Hollenbeck, S. (May 2007). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC4930. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC4930" target="_blank">https://doi.org/10.17487/RFC4930</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". <a href="https://www.rfc-editor.org/info/std69" target="_blank">https://www.rfc-editor.org/info/std69</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>Hollenbeck, S. (September 2004). "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC3915. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC3915" target="_blank">https://doi.org/10.17487/RFC3915</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>"Extensions for the Extensible Provisioning Protocol (EPP)". www.iana.org. Retrieved 2023-03-11. <a href="https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml" target="_blank">https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>"Implementation Report for RFCs 4930-4934 - Wayback Machine". 2012-01-15. Archived from the original on 2012-01-15. Retrieved 2023-03-12.{{cite web}}: CS1 maint: bot: original URL status unknown (link) <a href="https://web.archive.org/web/20120115070825/http://www.ietf.org/iesg/implementation/report-rfc4930-4934.txt" target="_blank">https://web.archive.org/web/20120115070825/http://www.ietf.org/iesg/implementation/report-rfc4930-4934.txt</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> <li id="fn:11"><p>"ICANN base registry contract". newgtlds.icann.org. Retrieved 2023-03-12. <a href="https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification6.1" target="_blank">https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html#specification6.1</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li> <li id="fn:12"><p>"Official CoCCA website". Retrieved 2023-03-12. <a href="https://cocca.org.nz/" target="_blank">https://cocca.org.nz/</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li> <li id="fn:13"><p>"Introducing FRED - fred". fred.nic.cz. Retrieved 2023-03-12. <a href="https://fred.nic.cz/en/" target="_blank">https://fred.nic.cz/en/</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></p></li> <li id="fn:14"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:14" class="footnote-back-ref">↩</a></p></li> <li id="fn:15"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Host Mapping". doi:10.17487/RFC5732. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5732" target="_blank">https://doi.org/10.17487/RFC5732</a> <a href="#fnref:15" class="footnote-back-ref">↩</a></p></li> <li id="fn:16"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Contact Mapping". doi:10.17487/RFC5733. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5733" target="_blank">https://doi.org/10.17487/RFC5733</a> <a href="#fnref:16" class="footnote-back-ref">↩</a></p></li> <li id="fn:17"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Domain Name Mapping". doi:10.17487/RFC5731. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5731" target="_blank">https://doi.org/10.17487/RFC5731</a> <a href="#fnref:17" class="footnote-back-ref">↩</a></p></li> <li id="fn:18"><p>Zhou, L.; Kong, N.; Yao, J.; Gould, J.; Zhou, G. (March 2019). "Extensible Provisioning Protocol (EPP) Organization Mapping". doi:10.17487/RFC8543. ISSN 2070-1721. S2CID 65065583. <a href="https://doi.org/10.17487/RFC8543" target="_blank">https://doi.org/10.17487/RFC8543</a> <a href="#fnref:18" class="footnote-back-ref">↩</a></p></li> <li id="fn:19"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:19" class="footnote-back-ref">↩</a></p></li> <li id="fn:20"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:20" class="footnote-back-ref">↩</a></p></li> <li id="fn:21"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:21" class="footnote-back-ref">↩</a></p></li> <li id="fn:22"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:22" class="footnote-back-ref">↩</a></p></li> <li id="fn:23"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:23" class="footnote-back-ref">↩</a></p></li> <li id="fn:24"><p>Gould, J.; Hollenbeck, S. (May 2010). "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5910. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5910" target="_blank">https://doi.org/10.17487/RFC5910</a> <a href="#fnref:24" class="footnote-back-ref">↩</a></p></li> <li id="fn:25"><p>"Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP)". IETF Datatracker. Retrieved 2023-03-11. <a href="https://datatracker.ietf.org/doc/html/draft-obispo-epp-idn-04" target="_blank">https://datatracker.ietf.org/doc/html/draft-obispo-epp-idn-04</a> <a href="#fnref:25" class="footnote-back-ref">↩</a></p></li> <li id="fn:26"><p>Carney, R.; Brown, G.; Frakes, J. (March 2020). "Registry Fee Extension for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC8748. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC8748" target="_blank">https://doi.org/10.17487/RFC8748</a> <a href="#fnref:26" class="footnote-back-ref">↩</a></p></li> <li id="fn:27"><p>Hollenbeck, S. (September 2004). "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC3915. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC3915" target="_blank">https://doi.org/10.17487/RFC3915</a> <a href="#fnref:27" class="footnote-back-ref">↩</a></p></li> <li id="fn:28"><p>Gould, J.; Tan, W.; Brown, G. (March 2018). "Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC8334. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC8334" target="_blank">https://doi.org/10.17487/RFC8334</a> <a href="#fnref:28" class="footnote-back-ref">↩</a></p></li> <li id="fn:29"><p>Sattler, T.; Carney, R.; Kolker, J. (December 2021). "Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC9167. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC9167" target="_blank">https://doi.org/10.17487/RFC9167</a> <a href="#fnref:29" class="footnote-back-ref">↩</a></p></li> <li id="fn:30"><p>"Extensions for the Extensible Provisioning Protocol (EPP)". www.iana.org. Retrieved 2023-03-11. <a href="https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml" target="_blank">https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml</a> <a href="#fnref:30" class="footnote-back-ref">↩</a></p></li> <li id="fn:31"><p>"Extensions for the Extensible Provisioning Protocol (EPP)". www.iana.org. Retrieved 2023-03-11. <a href="https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml" target="_blank">https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml</a> <a href="#fnref:31" class="footnote-back-ref">↩</a></p></li> <li id="fn:32"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:32" class="footnote-back-ref">↩</a></p></li> <li id="fn:33"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:33" class="footnote-back-ref">↩</a></p></li> <li id="fn:34"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:34" class="footnote-back-ref">↩</a></p></li> <li id="fn:35"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Domain Name Mapping". doi:10.17487/RFC5731. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5731" target="_blank">https://doi.org/10.17487/RFC5731</a> <a href="#fnref:35" class="footnote-back-ref">↩</a></p></li> <li id="fn:36"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Domain Name Mapping". doi:10.17487/RFC5731. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5731" target="_blank">https://doi.org/10.17487/RFC5731</a> <a href="#fnref:36" class="footnote-back-ref">↩</a></p></li> <li id="fn:37"><p>Hollenbeck, S. (September 2004). "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC3915. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC3915" target="_blank">https://doi.org/10.17487/RFC3915</a> <a href="#fnref:37" class="footnote-back-ref">↩</a></p></li> <li id="fn:38"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Domain Name Mapping". doi:10.17487/RFC5731. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5731" target="_blank">https://doi.org/10.17487/RFC5731</a> <a href="#fnref:38" class="footnote-back-ref">↩</a></p></li> <li id="fn:39"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:39" class="footnote-back-ref">↩</a></p></li> <li id="fn:40"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Transport over TCP". doi:10.17487/RFC5734. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5734" target="_blank">https://doi.org/10.17487/RFC5734</a> <a href="#fnref:40" class="footnote-back-ref">↩</a></p></li> <li id="fn:41"><p>Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN 2070-1721. <a href="https://doi.org/10.17487/RFC5730" target="_blank">https://doi.org/10.17487/RFC5730</a> <a href="#fnref:41" class="footnote-back-ref">↩</a></p></li> </ol>