Extensible Provisioning Protocol (EPP)
obsoleted by
- rfc-4930 — Extensible Provisioning Protocol (EPP)
Extracted elements (32)
All EPP commands are designed to be idempotent so that executing a command more than once has the same net effect as executing it once successfully. This property ensures safety of retrying commands in cases of response delivery failure without causing unintended side effects.
EPP uses XML namespaces to push each protocol operation's definition into the context of a specific managed object, allowing new object mappings to be added without modifying the base protocol. Specific namespace prefix strings (e.g., 'foo' in 'xmlns:foo') are illustrative and not required for interoperability.
EPP was designed for use in a layered protocol environment because diverse operating environments have widely varying transport and security requirements; a single transport or security specification is unlikely to meet all anticipated operators' needs. Transport and security bindings are explicitly out of scope.
Globally unique ROIDs are constructed by concatenating a local identifier with an IANA-maintained repository class identifier to facilitate object information sharing between repositories and avoid inconsistencies (e.g., stale DNS delegations) when objects such as name servers and contacts have utility across multiple repositories.
The <dcp> data collection policy elements in the <greeting> are based on the W3C Platform for Privacy Preferences (P3P) specification, enabling machine-readable disclosure of server data collection practices to provisioning entities as part of the initial connection handshake.
The specific namespace prefix strings used in EPP (e.g., 'xmlns:foo') are illustrative and not required for interoperability; only the URI values matter. Object mapping documents MUST define specific object schemas and are explicitly outside the scope of the base EPP specification.
A globally unique identifier (ROID) MUST be assigned to every object upon creation and MUST be returned in any <info> response. The ROID is formed by concatenating the local identifier, a hyphen (ASCII 0x002D), and the IANA-assigned repository identifier.
A <login> command MUST be sent before any other EPP command. A <login> MUST be rejected if received within an existing session, and a <logout> MUST be rejected if not preceded by a successful <login>.
After retrieving a <poll> message, the client MUST acknowledge it with op='ack'; the server MUST dequeue the message and decrement the counter after receiving acknowledgement. Service messages MUST be created for all clients affected by an action, including both parties in a transfer.
An EPP server MUST respond to any client-initiated communication (lower-layer connection request or EPP <hello>) by returning a <greeting>, and MUST promptly respond to each EPP command with a coordinated response describing the results of processing.
Data collection policy information MUST be disclosed to provisioning entities via the <dcp> element in the greeting, though the method of disclosing policy data outside of direct protocol interaction is beyond the scope of EPP.
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 safe retries.
Objects eligible for transfer MUST have associated authorization information that MUST be provided to complete the <transfer> command. Object mappings MUST provide features to restrict transfer queries to authorized clients.
Once a transfer request is received, the server MUST notify the current sponsoring client by queuing a service message for retrieval via <poll>. Transfer service messages MUST include the object-specific elements specified for <transfer> command responses.
The <msgQ> element MUST NOT be present in responses when no messages are queued. It MUST be present in responses to the <poll> command when messages are queued. The <qDate> and <msg> children of <msgQ> MUST be returned only in response to a <poll> request, not in any other response including a <poll> acknowledgement.
The <version> and <lang> values in a <login> command MUST exactly match values advertised in the server's greeting. The server MUST respond to a successful <login> with no <resData> element.
Transport mappings for EPP MUST preserve command order, address session/connection relationships, preserve statefulness, frame data units, ensure reliability, use congestion-avoiding transports (TCP or SCTP, or SMTP/BEEP with overload considerations), and explicitly allow or prohibit pipelining.
UTF-8 is the RECOMMENDED character encoding for EPP. EPP clients and servers MUST accept a UTF-8 BOM if present, though emitting a UTF-8 BOM is NOT RECOMMENDED. Conformant XML parsers must recognize both UTF-8 and UTF-16.
When an offline-pending transform command is issued, the server response MUST clearly note that the action is pending; the object state MUST reflect the pending action; and the server MUST notify the client when offline processing completes. Object mappings SHOULD describe standard formats for completion notices.
The <dcp> element mandates server disclosure of data collection policies covering access scope, collection purposes (admin/contact/prov/other), recipients (ours/public/same/unrelated/other), and retention periods (business/indefinite/legal/none/stated). Policy implications extend beyond the client-server relationship to the originating data sources.
The <dcp> (data collection policy) element in the greeting discloses the server's privacy practices. It contains an <access> element (one of: all/none/null/personal/personalAndOther/other), one or more <statement> elements each with required <purpose>, <recipient>, and <retention> children, and an optional <expiry> element (absolute or relative).
The EPP extension framework supports three levels: protocol extensions (new top-level <extension> child of <epp>), object extensions (new managed object types via XML namespace, referenced in <objURI>/<extURI>), and command-response extensions (per-command <extension> element agreed between client and server).
The EPP <login> command establishes a session. It carries <clID> (client identifier), <pw> (plain text password), an optional <newPW>, <options> with <version> and <lang>, and <svcs> listing the object namespace URIs (and optional extension URIs) to be managed during the session.
The EPP <response> element contains one or more <result> elements (each with 'code' attribute and <msg> child), an optional <msgQ> for queued message notification (with 'count' and 'id' attributes), optional <resData> for command-specific data, optional <extension>, and a required <trID> containing <clTRID> and <svTRID>.
The <epp> root element identifies every EPP protocol instance, declares namespace 'urn:ietf:params:xml:ns:epp-1.0', and references the schema location. All structures sent by both clients and servers MUST be wrapped in <epp>...</epp>.
The <greeting> element is returned by the server on connection or in response to <hello>. It contains <svID> (server name), <svDate> (UTC timestamp), <svcMenu> (protocol versions, languages, object namespace URIs, optional extension URIs), and a required <dcp> data collection policy element.
The <poll> command retrieves service messages queued by the server for individual clients. op='req' retrieves the first message; op='ack' with a 'msgID' attribute acknowledges and dequeues a message. The response includes a <msgQ> element with 'count' and 'id' attributes, and optional <qDate> and <msg> children.
The <transfer> command manages object sponsorship changes using an 'op' attribute: 'request' initiates, 'cancel' withdraws, 'approve' accepts, 'reject' declines, and 'query' checks status. Transfer responses MUST include object identity, transfer status, requesting/authorized client identifiers, request/action timestamps, and optionally a validity-period change timestamp.
RFC 3730 registers the MIME media type 'application/epp+xml' (Appendix B) for EPP XML content. It also establishes that IANA assigns repository class identifiers used as the suffix component of globally unique ROIDs for each provisioning repository class.
EPP transmits client passwords as plain text in the <pw> element of <login>. The specification requires that additional identification and authorization schemes MUST be provided at other protocol layers (e.g., TLS) to provide more robust security; plain-text transmission is modeled on the PLAIN SASL mechanism but EPP omits the session-level authorization identifier.
The EPP server state machine defines states: Waiting for Client, Prepare Greeting, Waiting for Client Authentication, Processing <login>, Waiting for Command, Processing Command, Prepare Response, Prepare Fail Response, and End Session. Transitions are triggered by connection/hello receipt, <login> success or failure, command receipt and completion, timeouts, and idle conditions. Authentication failure produces a 2501 response; timeout or idle at the Waiting for Command state ends the session.
EPP result codes are four-digit decimal numbers: digit 1 indicates success (1xxx) or failure (2xxx); digit 2 indicates category (x0zz=syntax, x1zz=implementation, x2zz=security, x3zz=data management, x4zz=server system, x5zz=connection management); digits 3-4 provide detail. Every response MUST include a result code and human-readable <msg>.