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.
[2] 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.
[3] Proposed Standard documents (RFCs 3730 - 3734) were published by the RFC Editor in March 2004.
[9] ICANN has made it a condition in their base registry contract to offer an EPP service.
The Council of Country Code Administrators (CoCCA) maintains an EPP server software used by around 59 ccTLDs and six gTLDs.
A common use case for non-standardized extensions is collecting extra data needed to create a domain, for example, a VAT identification number.
Most results can include additional data in the resData object, for example, which required parameter is missing.
[15] 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 client status codes are:[15] EPP only offers plain text passwords, additionally the EPP login password type is specified to be a string of 6-16 character length[1] which might be considered very low for today's standards.
[22] Many domain name registries also offer to set up a IP whitelist for connecting to their EPP servers.
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.