Extensible Provisioning Protocol (EPP) Domain Name Mapping
Extracted elements (29)
The mapping separates discrete data elements by data type rather than aggregating them into opaque strings. This allows XML Schema processors to perform basic syntax validation, reducing ambiguity and the amount of parsing and syntax-checking work required of protocol processors.
The <renew> command requires the client to supply <domain:curExpDate> (the current expiration date) as a concurrency guard: repeated <renew> commands are idempotent-safe because the server can detect and reject attempts to renew a domain whose expiration date has already been extended by a prior renewal.
A server announcing support for host objects in its EPP greeting MUST NOT allow domain attributes to describe name server hosts; a server that does not announce host object support MUST allow domain attributes. These two forms (hostObj references vs. hostAttr inline) are mutually exclusive within a single <domain:ns> element.
Domain name internationalization is handled via ACE labels per RFC 3490 (IDNA) at the time of publication, but the document notes these conformance requirements might change as IDN standards progress. Servers MAY restrict allowable domain names to particular TLDs or domains for which they are authoritative.
A client MUST NOT alter status values set by the server. 'ok' status MUST NOT be combined with any other status. The five pending statuses MUST NOT be combined with each other. Each pending status MUST NOT be combined with its corresponding prohibit status (e.g., 'pendingDelete' MUST NOT be combined with 'clientDeleteProhibited' or 'serverDeleteProhibited').
A domain object SHOULD NOT be deleted if subordinate host objects are associated with it. A server SHOULD notify clients of existing object relationships by returning a 2305 error response code when a <delete> is attempted and fails due to these relationships.
A server operator MUST use one name server specification form consistently: a server announcing support for host objects in an EPP greeting MUST NOT allow domain attributes to describe name server hosts; a server not announcing host object support MUST allow domain attributes.
Any attempt to transform an object by an unauthorized client MUST be rejected, and the server MUST return a 2201 response code to indicate the client lacks privileges to execute the requested command.
At least one <domain:add>, <domain:rem>, or <domain:chg> element MUST be provided in an <update> command if the command is not being extended by an extension.
Date and time attribute values MUST be represented in UTC using the Gregorian calendar. The extended date-time form using upper case 'T' and 'Z' characters MUST be used; time zone offset identifiers MUST NOT be used with EPP.
Domain and host name syntax MUST conform to RFC 0952 and RFC 1123. The trailing dot required for DNS zone storage is implicit and MUST NOT be provided when exchanging host and domain names via EPP.
EPP actions (such as transfers) that do not preserve the superordinate domain / subordinate host relationship MUST be explicitly disallowed. An internal host used across domains MUST be treated under rules governing subordinate hosts within the same repository.
The <renew> command MUST include a <domain:curExpDate> element containing the current expiration date. This value ensures that repeated <renew> commands do not result in multiple unanticipated successful renewals.
Transfer of a domain object MUST implicitly transfer all host objects subordinate to the domain object. For example, transferring 'example.com' when 'ns1.example.com' exists MUST transfer the host object as part of the domain transfer.
When a pending transform action is completed, the corresponding pendingCreate/pendingDelete/pendingRenew/pendingTransfer/pendingUpdate status value MUST be removed, and all clients involved MUST be notified via a service message that the action has been completed.
When offline review of a transform command is performed, the server MUST return response code 1001, MUST manage the object status to reflect the pending action, and MUST notify the client when offline processing is complete.
When the <info> querying client is the sponsoring client or provides valid authorization information, all available information MUST be returned. The <domain:authInfo> element MUST only be returned to the current sponsoring client or a client supplying valid authorization information.
Domain object status values include client- and server-prefixed prohibition statuses (clientDeleteProhibited, clientHold, clientRenewProhibited, clientTransferProhibited, clientUpdateProhibited and server counterparts), lifecycle statuses (ok, inactive), and pending operation statuses (pendingCreate, pendingDelete, pendingRenew, pendingTransfer, pendingUpdate).
Name servers are specified within a <domain:ns> element containing either one or more <domain:hostObj> elements (referencing known host objects by fully qualified name) or one or more <domain:hostAttr> elements (containing <domain:hostName> and optional <domain:hostAddr> with ip attribute 'v4' or 'v6', defaulting to 'v4').
The <check> command accepts one or more <domain:name> elements and returns a <domain:chkData> element containing <domain:cd> entries, each with a <domain:name avail='1|0'> and an optional <domain:reason> explaining why a name cannot be provisioned.
The EPP domain object is identified by a fully qualified name and carries attributes including ROID, status values, registrant, contacts, name servers (ns), subordinate hosts, sponsoring client ID, creation/update/expiration/transfer dates, and authorization information. These are returned via the <domain:infData> element in <info> responses.
The pending action notification <domain:panData> element is returned via the poll service message mechanism and contains: <domain:name paResult='boolean'> (approved/denied indicator), <domain:paTRID> (original transaction identifiers), and <domain:paDate> (when review was completed).
The <transfer> query response and transform response both use the <domain:trnData> element containing: domain name, trStatus (transfer state), reID (requesting client), reDate (request date), acID (acting client), acDate (action date), and optional exDate (new expiration if changed by transfer).
This document registers two URIs with IANA under the IETF XML Registry (RFC 3688): the domain namespace 'urn:ietf:params:xml:ns:domain-1.0' and the domain XML schema 'urn:ietf:params:xml:schema:domain-1.0'.
Authorization information is REQUIRED to create a domain object and is used in query and transfer operations as an additional means of determining client authorization. Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption to provide privacy services; failure to protect it can result in unauthorized transfers and unauthorized information disclosure.
A domain object starts in 'inactive' status when created with no associated name server hosts. Transitions occur as operations are applied: 'ok' is set when no prohibitions or pending operations exist; 'pendingXxx' is set when a transform command is received but awaiting completion; pending statuses are removed upon completion and 'ok' is restored or other applicable statuses applied.
Contact types in the domain mapping are restricted to 'admin', 'billing', or 'tech' via the contactAttrType enumeration. The <domain:info> 'hosts' attribute accepts 'all' (default), 'del', 'sub', or 'none' to filter returned host information.
The domain mapping uses XML namespace 'urn:ietf:params:xml:ns:domain-1.0' and schema URI 'urn:ietf:params:xml:schema:domain-1.0'. All EPP domain command and response elements are qualified under this namespace.
The <domain:period> element specifies registration duration as an integer (1–99) with a required 'unit' attribute: 'y' for years or 'm' for months. Used in <create>, <renew>, and <transfer> commands.