Extensible Provisioning Protocol (EPP)
Extracted elements (30)
All EPP commands are designed to be idempotent so that executing a command more than once has the same net effect as successfully executing it once. This ensures safety when retrying after response-delivery failure, since command success or failure MUST NOT be assumed if no response is returned or if a returned response is malformed.
EPP was designed for use in a layered protocol environment because it is intended for diverse operating environments where transport and security requirements vary greatly. Bindings to specific transport and security protocols are outside the scope of the base EPP specification.
Globally unique repository object identifiers (ROIDs) are designed to facilitate object-information sharing between repositories. Disjoint copies without shared identifiers can produce inconsistencies — for example, a name server renamed in one repository but not another can cause unexpected DNS results.
The EPP extension framework pushes object-specific protocol operation definitions into per-object documents and allows adding new object mappings without modifying the base protocol. Three extension levels are defined: protocol extensions (at the <epp> element), object extensions (per object namespace), and command-response extensions (per command).
The <version> and <lang> elements in the <login> command MUST exactly match one of the values advertised in the server's <greeting>. Clients negotiate a single protocol version and response language for the duration of the session from the server's advertised set.
A client MUST acknowledge each <poll> response (op="ack" with the msgID) to dequeue the message and make subsequent messages available. The server MUST dequeue the message and decrement the queue counter after acknowledgement.
A conforming EPP implementation MUST NOT require use of any specific XML namespace prefixes. Namespace prefixes used in examples are solely illustrative.
A globally unique identifier MUST be assigned to every object when created and MUST be returned to the client on any detailed attribute retrieval. The RECOMMENDED construction concatenates a local identifier, a hyphen, and an IANA-maintained repository identifier.
A <login> command MUST be sent to a server before any other EPP command to establish an ongoing session. A <login> command MUST be rejected if received within the bounds of an existing session.
All XML instances SHOULD begin with an <?xml?> declaration. EPP clients and servers MUST accept a UTF-8 BOM if present, though emitting a UTF-8 BOM is NOT RECOMMENDED. UTF-8 is the RECOMMENDED character encoding for use with EPP per RFC 2277.
An EPP server MUST respond to client-initiated communication (connection or <hello>) by returning a <greeting>. The server MUST promptly respond to each EPP command with a coordinated response describing the results of processing.
Every EPP response MUST include a result code and a human-readable description. Response code values MUST NOT be changed when translating text to other languages. The default response language is English ("en").
Objects eligible for transfer MUST have associated authorization information that MUST be provided to complete a <transfer> command. Transfer status is sensitive; object mappings MUST provide features to restrict transfer queries to authorized clients.
The <logout> command MUST be rejected if it has not been preceded by a successful <login>. After successful logout, the server MUST end the current session. The <logout> element MUST be an empty element with no child elements.
Transport mappings for EPP MUST preserve command order, address sessions vs. connections, preserve statefulness, frame data units, ensure reliability, use congestion-avoiding transports (TCP/SCTP) or account for overload when using SMTP/BEEP, and explicitly allow or prohibit pipelining.
When offline processing is pending, the server response MUST clearly note the command has been received but the action is pending (result code 1001). The object state MUST reflect the pending action, and the server MUST notify the client when offline processing completes.
The <dcp> data collection policy in the greeting discloses the server's privacy practices for data collection, access, retention, and recipient categories. Policy implications extend beyond the client-server relationship, and the specification notes that policy information MUST be disclosed to provisioning entities, though disclosure methods outside direct protocol interaction are out of scope.
An EPP command contains a command element (login, logout, check, info, poll, create, delete, renew, transfer, or update), an optional <extension> element for server-defined extensions, and an optional <clTRID> client transaction identifier. All commands are wrapped in an outer <epp> element.
An EPP response contains one or more <result> elements (each with a 'code' attribute and <msg> child, plus optional <value> and <extValue> elements), an optional <msgQ> element for queued messages, optional <resData> with object-specific data, optional <extension>, and a <trID> element combining <clTRID> and <svTRID>.
The <dcp> (data collection policy) element within <greeting> describes the server's privacy policy via an <access> element (all/none/null/personal/personalAndOther/other), one or more <statement> elements each containing <purpose>, <recipient>, and <retention> child elements, and an optional <expiry> element.
The <greeting> element is returned by the server on successful connection or in response to <hello>. It contains <svID> (server name), <svDate> (UTC timestamp), <svcMenu> (protocol versions, languages, object URIs, optional extensions), and a <dcp> data collection policy element.
The <login> command establishes a session and contains <clID> (client identifier), <pw> (plain text password), optional <newPW> (new password), <options> with <version> and <lang> (must exactly match greeting values), and <svcs> listing <objURI> elements and optional <svcExtension>.
The <poll> command manages a server-side service message queue. With op="req" it retrieves the head message; with op="ack" and a msgID attribute it acknowledges receipt and dequeues the message. The response includes a <msgQ> element with 'count' and 'id' attributes, plus optional <qDate> and <msg> child elements.
The <transfer> command manages client sponsorship changes via an 'op' attribute with values: request, cancel, approve, reject. The <transfer> query (op="query") retrieves real-time transfer status. Transfer responses MUST include object identity, transfer status, requesting client ID/date, authorizing client ID/date, and an optional expiry date.
This document registers the MIME media type application/epp+xml for EPP XML instances. The type is defined in Appendix B and identifies all EPP protocol content.
EPP is protected using lower-layer security protocols; the specification does not define transport-level security itself. Server operators may limit failed login attempts (N >= 1) after which the connection is closed. Transaction identifiers SHOULD be logged, retained, and protected to ensure consistent temporal and state-management records.
EPP transmits client credentials (identifier and password) as plain text XML elements. The specification requires additional identification and authorization schemes at other protocol layers to provide robust security, and mandates that initial credentials be delivered to clients via out-of-band methods that protect against inadvertent disclosure.
The EPP server transitions through states: Waiting for Client → Prepare Greeting (on connection or <hello>) → Waiting for Client Authentication → Processing <login> → Waiting for Command or <hello> → Processing Command → Prepare Response. Failed authentication returns a 2501 response and closes the connection; timeout from any waiting state ends the session.
EPP result codes are four-digit decimal numbers. The first digit indicates success (1) or failure (2). The second digit categorizes: 0=Protocol Syntax, 1=Implementation Rules, 2=Security, 3=Data Management, 4=Server System, 5=Connection Management. The third and fourth digits provide detail within the category.
The transaction identifier <trID> element combines a client-supplied <clTRID> and a server-assigned <svTRID>. Both are returned in every response. The <svTRID> is unique to the server; clients use <clTRID> to correlate commands with responses.