The Extensible Provisioning Protocol (EPP) is a flexible protocol designed for allocating objects within registries over the Internet. The motivation for the creation of EPP was to create a robust and flexible protocol that could provide communication between domain name registries and domain name registrars. These transactions are required whenever a domain name is registered or renewed, thereby also preventing domain hijacking. Before its introduction, registries had no uniform approach, and many different proprietary interfaces existed. While its use for domain names was the initial driver, the protocol is designed to be usable for any kind of ordering and fulfillment system.
EPP is based on XML - a structured, text-based format. The underlying network transport is not fixed, although the only currently specified method is over TCP. The protocol has been designed with the flexibility to allow it to use other transports such as BEEP, SMTP, SOAP or HTTPS. However only HTTPS has seen some usage while the vast majority uses TCP.
History The first protocol drafts were published as IETF individual submission Internet Draft documents by Scott Hollenbeck of Verisign in November 2000. The individual submission documents were adopted by the IETF Provisioning Registry (provreg) working group, which was created after a BoF session was held at IETF-49 in December 2000. Proposed Standard documents (RFCs 3730 - 3734) were published by the RFC Editor in March 2004. Draft Standard documents (RFCs 4930 - 4934) were published in May 2007.
In August 2009, IETF granted EPP the status of full standard as STD 69.
The first EPP extension that became a proposed standard was the redemption grace period extension from RFC 3915 in September 2004. Since then, several different proposed standard extensions followed.
Adoption The protocol has been adopted by a number of ccTLD domain name registries, such as: .ac, .ag, .ai, .as, .ar, .at, .au, .be, .br, .bz, .ca, .cat, .cc, .ch, .cl, .cn, .co, .cr, .cx, .cz, .dk, .dm, .ee, .es (over HTTPS), .eu, .fi, .fm, .fr, .gg, .gr (over HTTPS), .gs, .hn, .ht, .il, .im, .in, .io, .it (over HTTPS), .je, .ke, .ki, .ky, .kz, .la, .lc, .li, .lt, .lu, .lv, .md, .me, .mk, .mn, .ms, .mu, .mx, .na, .nf, .ng, .nl, .no, .nu, .nz, .pe, .pk, .pl (over HTTPS), .ps, .pt, .ru, .ro, .sc, .se, .sh, .si, .su, .tl, .tm .tv, .tw, .ua, .uk, .us, .vc, .ve and .za as well as ENUM registries such as those operating the +31, +41, +43, +44 and +48 country codes.
ICANN has made it a condition in their base registry contract to offer an EPP service. Therefore, every gTLD has adopted the protocol.
There are multiple open source 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. Another open source software is FRED (maintained by CZ.NIC) which counts 11 ccTLDs as its users.
Protocol commands 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. The most common standardized objects are hosts, contacts and domains. There are also other standardized objects like organizations, however they are rarely used.
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.
The session management commands are: CommandUsagehelloRequest another "greeting" response from the server.loginStart 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.logoutEnd the current session. The query commands are: CommandUsagecheckCheck whether an object is still available to create.infoGet all the current information about an object.pollRead a message from the server for the user or acknowledge receipt, thereby deleting it to receive the next message. (Message Queue)transferGet the current status of a started object transfer process. The object transform commands are: CommandUsagecreateCreate a new object.deleteDelete the object. Hosts and Contacts are deleted immediately, while domains mainly change into a redemption grace period.renewIncrease the amount of time the domain name is registered. Not available for objects other than domains as these don't have a lifetime.transferChange 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.updateUpdate 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.
Example An example command to create a domain could look like this:<?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>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 authInfo pw 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:<?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>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.
Extensions 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.
There are a few standardized extensions that are used by a lot of registries. These include extensions for DNSSEC, IDN, premium domain names, domain restoration (RGP) and extensions to handle the launch of new TLDs and Registry Maintenances among other things.
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 VAT identification number.
Result codes 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.
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.
The complete list of standardized result codes and result messages is: Code Message 1000 Command completed successfully 1001 Command completed successfully; action pending 1300 Command completed successfully; no messages 1301 Command completed successfully; ack to dequeue 1500 Command completed successfully; ending session 2000 Unknown command 2001 Command syntax error 2002 Command use error 2003 Required parameter missing 2004 Parameter value range error 2005 Parameter value syntax error 2101 Unimplemented command 2102 Unimplemented option 2103 Unimplemented extension 2104 Billing failure 2105 Object is not eligible for renewal 2106 Object is not eligible for transfer 2200 Authentication error 2201 Authorization error 2202 Invalid authorization information 2300 Object pending transfer 2301 Object not pending transfer 2302 Object exists 2303 Object does not exist 2304 Object status prohibits operation 2305 Object association prohibits operation 2306 Parameter value policy error 2307 Unimplemented object service 2308 Data management policy violation 2400 Command failed 2500 Command failed; server closing connection 2501 Authentication error; server closing connection 2502 Session limit exceeded; server closing connection
EPP object status codes 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.
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.
The client status codes are commonly used also to handle abuse cases, non-payment, invalid contact data, or for a Registrar-Lock feature.
The currently standardized server status codes are: