Extensible Provisioning Protocol (EPP) Domain Name Mapping
obsoleted by
- rfc-4931 — Extensible Provisioning Protocol (EPP) Domain Name Mapping
Extracted elements (29)
Name servers can be specified as references to existing host objects or as inline domain attributes describing a host machine. This dual approach exists to support registries that do and do not implement the EPP host object mapping, but a server MUST choose one form and use it consistently.
The mapping separates discrete data elements by data type to allow XML Schema processors to perform basic syntax validation, reducing ambiguity and parsing work. Provisioning methods that aggregate data into opaque strings are explicitly discouraged because they re-impose that burden on protocol processors.
The <renew> command requires the current expiration date (curExpDate) as an idempotency guard: if a client accidentally sends the same <renew> twice, the second command will fail because the expiry date no longer matches, preventing unintended double renewals.
Whether a host is 'external' or 'internal' depends on the repository in which it is used for delegation. A host such as ns1.example1.com used as a name server for example2.com in the same repository MUST be treated as an internal (non-subordinate) host, subject to subordinate-host operation rules within that repository.
A domain object MUST always have at least one associated status value. A client MUST NOT alter status values set by the server; a server MAY alter or override client-set status values subject to local policy.
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 sending a 2305 error response when a <delete> fails due to such relationships.
A server operator MUST use one name server specification form (either host objects or host attributes) consistently. A server that announces support for host objects in an EPP greeting MUST NOT allow domain attributes to describe a name server host machine.
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 defined in RFC3339 MUST be used; time zone offset identifiers MUST NOT be used with EPP.
Domain and host name syntax MUST conform to RFC952 as updated by RFC1123. 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.
EPP actions such as object transfers that do not preserve the superordinate relationship between domain objects and subordinate host objects MUST be explicitly disallowed. When ns1.example1.com is used as a name server for example2.com, it MUST be treated as an internal host subject to the rules governing subordinate hosts.
Provisioning methods that aggregate data into opaque strings SHOULD NOT be used because they impose additional parsing, interpretation, and validation requirements on protocol processors; discrete data elements by type are preferred.
The <info> command MUST return all available information if the querying client is the sponsoring client or provides valid authorization information. The <domain:authInfo> element MUST only be returned to the sponsoring client or a client that supplied valid authorization.
The <renew> command requires a <domain:curExpDate> element containing the current validity period 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 that are subordinate to the domain object. For example, transferring 'example.com' must also transfer host object 'ns1.example.com'.
Transform commands (other than a transfer approve/reject/cancel) MUST be rejected when a pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status is set. When the action completes, the pending status MUST be removed and all involved clients MUST be notified via a service message.
When an offline-reviewed transform command is pending, the server MUST return response code 1001. The server MUST manage object status to reflect the pending action and MUST notify all involved clients via a service message when the action completes.
The <domain:check> command accepts one or more <domain:name> elements and returns a <domain:chkData> element with <domain:cd> children, each containing a <domain:name> with required boolean 'avail' attribute and an optional <domain:reason> element explaining unavailability.
The <domain:create> command requires <domain:name> and <domain:authInfo>; optional elements include <domain:period> (1–99 years or months), <domain:ns> (name servers), <domain:registrant>, and <domain:contact> (admin/billing/tech types). The <domain:creData> response returns name, creation date, and optional expiry date.
The <domain:infData> response element returns the domain name, ROID, status, registrant, contacts, name servers, subordinate hosts, sponsoring client ID, creation/update/expiration/transfer dates, and (conditionally) authorization information.
The <domain:info> command's <domain:name> element carries an optional 'hosts' attribute controlling host information returned: 'all' (default, both subordinate and delegated), 'del' (delegated only), 'sub' (subordinate only), or 'none'.
The <domain:ns> element MUST contain either one or more <domain:hostObj> elements (fully qualified names of known host objects) or one or more <domain:hostAttr> elements (each with <domain:hostName> and optional <domain:hostAddr> children with optional 'ip' attribute defaulting to 'v4').
The <domain:panData> element, returned via the <poll> service message after offline review, contains the domain name with a required boolean 'paResult' attribute, the original transaction IDs (<domain:paTRID>), and the review completion date (<domain:paDate>).
The <domain:trnData> element (returned for transfer query and transfer command responses) 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 <domain:update> command accepts <domain:add>, <domain:rem>, and <domain:chg> child elements; at least one MUST be present. <domain:add>/<domain:rem> modify name servers, contacts, and status values; <domain:chg> modifies registrant and authInfo (a <domain:null> element removes authInfo).
Two IANA URN registrations are made under the IETF XML Registry (RFC3688): the domain namespace URI 'urn:ietf:params:xml:ns:domain-1.0' and the domain XML schema URI 'urn:ietf:params:xml:schema:domain-1.0'.
Authorization information (required to create a domain object and used in query and transfer operations) MUST be stored and exchanged using high-grade encryption. Failure to protect authorization information can result in unauthorized transfer operations and unauthorized information release.
Domain status values include client/server prohibition pairs (Delete, Hold, Renew, Transfer, Update Prohibited), server-managed values (inactive, ok), and pending operation values (pendingCreate, pendingDelete, pendingRenew, pendingTransfer, pendingUpdate). 'ok' MUST NOT be combined with any other status; pending values MUST NOT be combined with each other or with the corresponding prohibition status.
Contact type is encoded as a 'type' attribute on <domain:contact> with enumerated values: 'admin', 'billing', or 'tech'. Status values are encoded on <domain:status> as required 's' attribute (enumerated) with optional 'lang' attribute (default 'en') and optional human-readable text content.
The domain validity period is encoded as a <domain:period> element with required 'unit' attribute ('y' for years, 'm' for months) and an unsigned short value between 1 and 99 inclusive. Servers MAY support a lower maximum.