Extensible Provisioning Protocol (EPP) Domain Name Mapping
obsoleted by
- rfc-5731 — Extensible Provisioning Protocol (EPP) Domain Name Mapping
obsoletes
- rfc-3731 — Extensible Provisioning Protocol (EPP) Domain Name Mapping
Extracted elements (30)
Provisioning methods that aggregate data into opaque strings SHOULD NOT be used because they impose additional parsing, interpretation, and validation requirements on protocol processors. Separating discrete data elements by type allows XML Schema processors to perform basic syntax validation, reducing ambiguity.
The <renew> command requires a <domain:curExpDate> element containing the current expiry date. This ensures that repeated <renew> commands do not result in multiple unanticipated successful renewals, protecting against accidental double-renewal.
Domain and host name conformance requirements reference RFC 952 and RFC 1123. At the time of writing, RFC 3490 (IDNA) describes a mechanism for representing non-ASCII labels as ASCII; these requirements may change as internationalized domain name standards evolve.
UTF-8 encoding is RECOMMENDED for EPP XML in environments where parser encoding compatibility is a concern, although conformant XML processors recognize both UTF-8 and UTF-16.
A domain object MUST always have at least one status value. A client MUST NOT alter status values set by the server. When a pending action completes, the corresponding pending* status MUST be removed and all involved clients MUST be notified via a service message.
A domain object SHOULD NOT be deleted if subordinate host objects are associated with it. A server SHOULD notify clients of this dependency by returning a 2305 error response code when a <delete> command fails due to existing object relationships.
A server operator MUST use one name server specification form consistently: either host objects (<domain:hostObj>) or host attributes (<domain:hostAttr>). A server announcing support for host objects in its EPP greeting MUST NOT allow domain attributes to describe name server hosts.
All date-time attribute values MUST be represented in UTC using the Gregorian calendar. The extended date-time form using uppercase 'T' and 'Z' characters MUST be used; time zone offset identifiers and lowercase 'T' or 'Z' characters MUST NOT be used.
Domain name syntax MUST conform to RFC 952 as updated by RFC 1123. The trailing dot required when names are stored in a DNS zone is implicit and MUST NOT be provided when exchanging host and domain names via EPP.
EPP actions that do not preserve the superordinate relationship between domain name objects and subordinate host objects MUST be explicitly disallowed. For example, a domain transfer that would orphan subordinate host objects must be prevented.
The <create> command MUST include a <domain:authInfo> element. Referenced host objects MUST be known to the server before association with the domain; referenced contact object identifiers MUST likewise be pre-existing in the repository.
The EPP <info> command MUST return all available information when the querying client is the sponsoring client or provides valid authorization information. For non-sponsoring clients without valid authInfo, server policy determines which optional elements are returned.
The 'ok' status MUST NOT be combined with any other status. The five pending* status values MUST NOT be combined with each other. Each pending* status MUST NOT be combined with its corresponding *Prohibited status (e.g., pendingDelete MUST NOT combine with clientDeleteProhibited or serverDeleteProhibited).
The <update> command requires at least one of <domain:add>, <domain:rem>, or <domain:chg> to be present if the command is not being extended. All three elements MAY be omitted if an <update> extension is present.
Transfer of a domain object MUST implicitly transfer all subordinate host objects. For example, if 'example.com' is transferred and 'ns1.example.com' exists as a host object, 'ns1.example.com' MUST be transferred as part of the 'example.com' transfer process.
XML specifications and examples in this document MUST be interpreted in the character case presented to develop a conforming implementation, since XML is case sensitive.
A domain object has 17 defined status values: five client-settable values prefixed with 'client' (clientDeleteProhibited, clientHold, clientRenewProhibited, clientTransferProhibited, clientUpdateProhibited), corresponding server-prefixed values, plus 'inactive', 'ok', and five pending* values.
The <domain:infData> response contains domain name, ROID, status values, registrant and contact identifiers, name servers, subordinate host names, sponsoring client ID, creation/update/expiry/transfer dates, and optionally the authInfo—but authInfo MUST only be returned to the sponsoring client or a client supplying valid authorization information.
The <domain:ns> element specifies name servers and MUST contain either one or more <domain:hostObj> elements (referencing existing host objects by FQDN) or one or more <domain:hostAttr> elements (inline host name plus optional IP addresses). The two forms are mutually exclusive within a single <domain:ns> element.
The <domain:panData> element is used in service messages to notify clients of pending action completion. It contains the domain name with a boolean 'paResult' attribute (approved or denied), original transaction IDs in <domain:paTRID>, and the review completion date in <domain:paDate>.
The <domain:trnData> response element contains domain name, transfer status (trStatus), requesting client ID (reID), request date (reDate), acting client ID (acID), action deadline/completion date (acDate), and optional new expiry date (exDate).
The EPP <check> command for domains takes one or more <domain:name> elements and returns a <domain:chkData> element containing an 'avail' boolean attribute for each queried name, with an optional <domain:reason> element (in the negotiated response language) when unavailable.
When a server performs offline review of a transform command, it MUST return response code 1001 and set the appropriate pending* status on the object. Upon completion the server MUST notify all involved clients via a service message (or out-of-band mechanism) and remove the pending* status.
This document registers two URIs with IANA via the IETF XML Registry (RFC 3688): the namespace URI 'urn:ietf:params:xml:ns:domain-1.0' and the XML schema URI 'urn:ietf:params:xml:schema:domain-1.0' for the EPP domain name mapping.
Authorization information is REQUIRED to create a domain object and is used as an additional authorization factor in query and transfer operations. Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption to prevent unauthorized transfers and inadvertent disclosure.
Domain status transitions: 'ok' is the normal resting state; pending* states (pendingCreate, pendingDelete, pendingRenew, pendingTransfer, pendingUpdate) are entered when a transform command is processed but not yet completed; prohibited states prevent specific operations; 'inactive' indicates no delegation information is present.
The <domain:authInfoType> uses a choice between <domain:pw> (password-based, pwAuthInfoType from eppcom) and <domain:ext> (extension mechanism). In update context, an additional <domain:null> element is allowed within <domain:authInfoChgType> to remove authorization information.
The <domain:hostAttr> element encodes an inline name server with a required <domain:hostName> (FQDN) and zero or more <domain:hostAddr> elements, each optionally carrying an 'ip' attribute with value 'v4' (default) or 'v6'.
The <domain:period> element encodes a registration period as an unsigned integer in [1, 99] with a required 'unit' attribute ('y' for years, 'm' for months). It is used in <create>, <renew>, and <transfer> commands.
The <domain:statusType> XML complex type encodes a domain status as a required 's' attribute (one of 17 enumerated token values) plus an optional 'lang' attribute (default 'en') and optional human-readable normalizedString text content.