The EPP Message Queue
CentralNic's EPP system implements the message queuing system as described in RFC 4930. While the messaging system is generic, its most common use is to notify registrars of inbound and outbound domain transfers.
This document describes the types of messages registrars can expect to find in their message queue.
Object transfers
Our system enqueues EPP system messages for the following events:
- an inbound transfer has been initiated (by you)
- an inbound transfer has been cancelled (by you)
- an inbound transfer has been approved, rejected or cancelled (by the losing registrar)
- an outbound transfer has been initiated (by another registrar)
- an outbound transfer has been cancelled (by the gaining registrar)
- an outbound transfer has been approved or rejected (by you)
Under all of the above cases, the response from the server for a <poll op="req"> will be of the form
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully.</msg>
</result>
<msgQ count="1" id="1134055" />
<resData>
<domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
domain-1.0.xsd">
<domain:name>example.uk.com</domain:name>
<domain:trStatus>pending</domain:trStatus>
<domain:reID>H12345</domain:reID>
<domain:reDate>2008-05-21T14:39:14.0Z</domain:reDate>
<domain:acID>H12346</domain:acID>
<domain:acDate>2008-05-26T14:39:14.0Z</domain:acDate>
</domain:trnData>
</resData>
<trID>
<clTRID>07f28d0653670f43fbe8b4c4a6d0a0369454ed60</clTRID>
<svTRID>CNIC-3u2jyik180ne</svTRID>
</trID>
</response>
</epp>
When building your EPP message queue processor, the key elements to look for are the <domain:name>, <domain:trStatus>, <domain:reID> and <domain:acID> elements:
Obviously, the <domain:name> element contains the domain name that is subject to the transfer request.
The <domain:trStatus> element will contain a text string that will be one of the following:
- pending (the transfer is pending action by the losing registrar)
- clientCancelled (the transfer was cancelled by the gaining registrar)
- clientApproved (the transfer was approved by the losing registrar)
- clientRejected (the transfer was rejected by the losing registrar)
- serverRejected (the transfer was rejected by the registry, as will happen for auto-reject transfers initiated without the authInfo code)
As with object status codes, these codes are prepended with either client or server, depending on whether the event was initiated by a registrar (either gaining or losing) or the registry.
For an inbound transfer, the contents of the <domain:reID> element will correspond to your registrar ID, and the contents of the <domain:acID> element will correspond to the losing registrar's ID. For an outbound transfer, the reverse is true.
Other events
The EPP message queue can be used to send notifications of other events, such as the deletion of objects, or out-of-band changes. The EPP specification encourages server operators to provide such messages, and we plan to do so in the future (subject to feedback from our registrars).
Click here for engineering and software development jobs at CentralNic