Extensible Provisioning Protocol (EPP) is a new way of registering and maintaining domain names.

How EPP works

EPP is a client-server protocol, where all communications use XML as defined by a series of schemas.

The normal conversation between a client and the server will be:

• Client connects to server over SSL.
• Server identifies itself and the commands and extensions that it supports.
• Client logs in by supplying login name and password.
• Client polls the server to see if there are any notifications waiting to be collected and then collects them (or it could do this later).
• Client issues commands to server, which then replies immediately with response status.
• Client then idles until it has more commands to send, polling periodically for any notifications.
  

Benefits of using EPP

The main benefits of using EPP are:

• Responses to commands are generally instant. You can issue a command to register a domain, get a response and then confirm with your customer that this has happened all in real time.
• Your investment in EPP client programming should be transferrable when integrating with the EPP service of other registries.
• You can choose when to collect notifications that we send you and can be sure that you have received them.

What you need to use EPP

You will either need to write your own EPP client or buy one off the shelf. EPP is not intended for an individual to type out an EPP command in the same way that you can with the Automaton. Your software will then need to be able to connect directly to the EPP server using SSL.

To connect to our EPP server you need to register for this service. We also provide an EPP testbed to allow you to test your EPP implementation.

Our custom extensions of EPP

EPP is an international standard, and is specified in RFCs 4930 to 4934. However, it was developed largely by those working for gTLD registries, who have a very different data model from us.  As a result we have been unable to use the standard definitions for domains, contacts and hosts and have instead implemented our own versions.

Please be clear that all of the extensions we have made conform to the guidelines for extending EPP given in RFC 4930.

To summarise the differences:

• We have developed our own mapping for domains and contacts to reflect the data we hold.
• We have added a new object, called account, to represent our account structure.
• We have developed our own nameserver mapping to fit with our data model that is named differently from that used in other EPP variants.
• Nameservers are held as objects rather than as domain name attributes. Nameservers can be non-unique and so existing nameservers must be referred to by an identifier. Multiple registrars may hold nameservers with the same name.
• We have used the EPP transfer command to represent our release operation. This was considerably simpler to understand than using the EPP command extension mechanism.
• In our own objects, we have used local timestamps rather than UTC timestamps. The timestamp returned in the <greeting> element is UTC as specified in RFC 4930.