Extensible Provisioning Protocol (EPP)

All EPP commands are designed to be atomic and idempotent (executing a command more than once has the same net effect as executing it once successfully), ensuring that retrying a command after response delivery failure is safe.

EPP uses XML namespaces for object management to push the definition of each protocol operation into the context of a specific object, enabling new object mappings to be added without modifying the base protocol. This extensible object framework enables generic operations to be applied to any managed object type.

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, and a single transport or security specification cannot meet all operators' needs. Transport and security bindings are explicitly out of scope.

Globally unique object identifiers are needed because objects such as name servers and contacts can have utility in multiple repositories; maintaining disjoint copies can cause inconsistencies with adverse Internet consequences (e.g., stale DNS delegation after renaming a name server in only one repository).

dns

A client identifier and initial password MUST be created on the server before a client can log in, and MUST be delivered to the client using an out-of-band method that protects them from inadvertent disclosure.

security

A conforming EPP implementation MUST NOT require use of specific XML namespace prefixes. The XML namespace prefixes used in examples are solely for illustrative purposes.

A globally unique identifier (ROID) MUST be assigned to every object when created and MUST be returned to the client as part of any <info> request. The RECOMMENDED construction is a local identifier concatenated with 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.

A <logout> command MUST be rejected if not preceded by a successful <login>. When processed successfully, the server MUST respond with result code 1500 and MUST end the current session.

After receiving a <poll> response, a client MUST acknowledge each response using op='ack' and the message ID to dequeue the message and make subsequent messages available. The server MUST dequeue the message and decrement the queue counter after acknowledgement.

All EPP XML instances MUST begin with an <epp> element that identifies the start of a protocol element and its namespace. The <epp> start and </epp> end elements MUST be applied to all structures sent by both clients and servers.

An EPP server MUST respond to client-initiated communication (connection request or <hello>) by returning a greeting, and MUST promptly respond to each EPP command with a coordinated response describing processing results.

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 EPP per RFC 2277.

EPP commands are atomic: success and failure results MUST NOT be mixed. Command success or failure MUST NOT be assumed if no response is returned or if a returned response is malformed; protocol idempotency ensures the safety of retrying.

Objects eligible for transfer MUST have associated authorization information that MUST be provided to complete a <transfer> command. Authorization types are object-specific; passwords or public key cryptography are typical.

security

Once a transfer has been requested, the server MUST notify the current sponsoring client by queuing a service message for <poll> retrieval or by out-of-band means. Transfer service messages MUST include object-specific elements specified for <transfer> command responses.

Transport mappings for EPP MUST: preserve command order, address session/connection relationships, preserve protocol statefulness, frame data units, use a congestion-aware transport (TCP or SCTP), ensure reliability, and explicitly allow or prohibit pipelining.

When a command requires offline activity before completion, the server MUST clearly note in the response that the command has been received and processed but the action is pending (result code 1001). The object's state MUST clearly reflect the pending action, and the server MUST notify the client when offline processing completes.

The <dcp> element in the greeting MUST disclose the server's data collection policy, including <access> (scope of data access), one or more <statement> elements with mandatory <purpose>, <recipient>, and <retention> child elements, and an optional <expiry>. Policy information MUST be disclosed to provisioning entities. This design is based on W3C P3P.

privacy

An EPP command contains a command element (one of the defined EPP commands), an optional <extension> element for server-defined extensions, and an optional <clTRID> (client transaction identifier) for client-side unique command identification.

An EPP response contains one or more <result> elements (each with a 'code' attribute, <msg> element, optional <value> and <extValue> error details), an optional <msgQ> element for queued messages, an optional <resData> element for object-specific response data, and a <trID> element containing <clTRID> and <svTRID>.

EPP result codes use four decimal digits: the first digit indicates success (1) or failure (2); the second digit categorizes the response (0=syntax, 1=implementation rules, 2=security, 3=data management, 4=server system, 5=connection management); the third and fourth provide detail. Every EPP response MUST include a result code and human-readable description.

Key EPP result codes include: 1000 (command completed successfully), 1001 (action pending), 1300 (no messages), 1301 (ack to dequeue), 1500 (ending session), 2000 (unknown command), 2002 (command use error/sequencing), 2200 (authentication error), 2201 (authorization error), 2202 (invalid authorization information), 2300 (object pending transfer), 2302 (object exists), 2303 (object does not exist).

The EPP <greeting> element contains <svID> (server name), <svDate> (current UTC date/time), and <svcMenu> (supported versions, languages, object namespace URIs, optional extensions). It also contains a <dcp> (data collection policy) element describing the server's privacy practices.

The <login> command contains <clID> (client identifier), <pw> (plain text password), optional <newPW> (new password), an <options> element with <version> and <lang> whose values MUST exactly match those in the greeting, and a <svcs> element listing object namespace URIs to manage during the session.

The <poll> command uses an 'op' attribute: value 'req' retrieves the first message from the server queue (REQUIRED), and value 'ack' with a 'msgID' attribute (copied from the returned message 'id') acknowledges receipt and dequeues the message.

Transaction identifiers provide command-response synchronization integrity. Each response includes a <trID> element containing the client-supplied <clTRID> (if provided) and a server-assigned <svTRID>. These SHOULD be logged, retained, and protected.

This document registers the MIME media type 'application/epp+xml' with IANA (Appendix B). EPP content is identified by this type; the registration includes required type, subtype, encoding, and security considerations fields.

registry

EPP relies on lower-layer security protocols to protect client-server exchanges. The PLAIN SASL-like authentication (clID and password in <login>) provides only basic security; additional identification and authorization schemes MUST be provided at other protocol layers for more robust security. A server operator MAY limit failed login attempts.

security

The EPP server state machine defines states: Waiting for Client, Prepare Greeting, Waiting for Client Authentication, Processing <login>, Waiting for Command or <hello>, Processing Command, Prepare Response, Prepare Fail Response, and End Session. Transitions are triggered by connection or <hello> receipt, <login> success/failure, command receipt, timeout, and session close.