Extensible Provisioning Protocol (EPP) Host Mapping
obsoleted by
- rfc-5732 — Extensible Provisioning Protocol (EPP) Host Mapping
obsoletes
- rfc-3732 — Extensible Provisioning Protocol (EPP) Host Mapping
Extracted elements (28)
A host name object has a subordinate relationship to a superordinate domain name object (e.g., 'ns1.example.com' is subordinate to 'example.com'). A host used as a name server for a domain in the same repository must be treated as an internal host, even if it is not subordinate to that specific domain.
Transfer semantics do not directly apply to host objects, and no EPP <transfer> command mapping is defined for hosts. Instead, internal host objects transfer implicitly alongside their superordinate domain object, preserving the DNS namespace hierarchy.
Host name conformance requirements reference RFC 0952 and RFC 1123, but may change as standards for internationalized host names (IDNA, RFC 3490) evolve. Implementers should monitor this area for future updates.
RFC 4932 changes the deletion prohibition from RFC 3732's 'MUST NOT be deleted' to 'SHOULD NOT be deleted' when a host object has associations with other objects, providing implementers flexibility while noting the DNS resolution failure risk.
RFC 4932 relaxes the RFC 3732 requirement that at least one <host:add>, <host:rem>, or <host:chg> element be present in an <update> command, allowing all such elements to be omitted when an <update> extension is present.
A host name object SHOULD NOT be deleted if it is associated with any other object (e.g., a domain object). Deleting a host with existing associations can cause DNS resolution failure for domain objects referencing the deleted host.
A host 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 status values set by a client subject to local policies.
At least one <host:add>, <host:rem>, or <host:chg> element MUST be provided in an <update> command if the command is not being extended. All of these elements MAY be omitted if an <update> extension is present.
Attempts to update an external host object that has associations with objects sponsored by a different client MUST fail with EPP error code 2305. The workaround is to create a new external host with the new name and update the other objects.
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; XML Schema time zone offsets MUST NOT be used with EPP.
EPP actions such as object transfers that do not preserve the subordinate relationship between a host object and its superordinate domain name object MUST be explicitly disallowed.
Host name syntax MUST conform to RFC 0952 as updated by RFC 1123. These conformance requirements might change as internationalized host name standards progress.
Host objects MUST NOT be transferred directly; they MUST be transferred implicitly when the host object's superordinate domain object is transferred. <host:upID> and <host:upDate> MUST NOT be present if the host has never been modified; <host:trDate> MUST NOT be provided if the host has never been transferred.
If a host name exists in a name space for which the server is authoritative, the superordinate domain of the host MUST be known to the server before the host object can be created.
IPv4 address syntax MUST conform to RFC 0791 and IPv6 address syntax MUST conform to RFC 4291. A server MAY reject IP addresses not allocated for public use by IANA. IP addresses SHOULD be required only as needed to generate DNS glue records.
'pendingDelete' status MUST NOT be combined with 'clientDeleteProhibited' or 'serverDeleteProhibited'. 'pendingUpdate' MUST NOT be combined with 'clientUpdateProhibited' or 'serverUpdateProhibited'. The four pending status values MUST NOT be combined with each other.
Use of UTF-8 encoding is RECOMMENDED in environments where parser encoding support incompatibility exists. EPP XML instances may use UTF-8 or UTF-16 as recognized by conformant XML processors.
When a pending action completes, the pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status value MUST be removed, and all clients involved MUST be notified via a service message.
When a server defers completing a transform command for offline review, it MUST return response code 1001, MUST manage the object status to reflect the pending action, and MUST notify all involved clients via a service message when the action is completed.
Host object status values are: clientDeleteProhibited, clientUpdateProhibited, linked, ok, pendingCreate, pendingDelete, pendingTransfer, pendingUpdate, serverDeleteProhibited, serverUpdateProhibited. Values prefixed 'client' are set by clients; values prefixed 'server' are set by servers; 'linked' and 'ok' are server-managed.
The <create> command uses a <host:create> element containing a <host:name> and zero or more <host:addr> elements. A successful response returns a <host:creData> element with the host name and creation date-time.
The EPP <check> command uses a <host:check> element containing one or more <host:name> elements. The response returns a <host:chkData> element with one or more <host:cd> elements, each containing a <host:name> with a boolean 'avail' attribute and an optional <host:reason> element.
The EPP <info> command returns a <host:infData> element containing: host name, ROID, one or more status values, zero or more IP addresses, sponsoring client ID, creating client ID and date, last update client ID and date (if modified), and last transfer date (if transferred).
The <host:panData> pending action notification element contains: a <host:name> element with a boolean 'paResult' attribute (approval/denial), a <host:paTRID> with the original transaction identifiers, and a <host:paDate> with the review completion date-time.
This document registers two URIs in the IETF XML Registry (RFC 3688): the host namespace URI 'urn:ietf:params:xml:ns:host-1.0' and the host XML schema URI 'urn:ietf:params:xml:schema:host-1.0'.
The EPP host object mapping described in this document does not provide any security services or introduce any additional security considerations beyond those described by RFC 4930 (base EPP) and the protocol layers used by EPP.
The <host:addr> element encodes an IP address as a string (3–45 characters) with an 'ip' attribute whose value is 'v4' (default) or 'v6'. The <host:status> element has a required 's' attribute for the status value and an optional 'lang' attribute defaulting to 'en'.
The <host:infData> XML Schema type defines the <info> response structure with sequenced elements: name (labelType), roid (roidType), status (1–7 occurrences), addr (0–unbounded), clID, crID, crDate, optional upID, optional upDate, optional trDate.