Extensible Provisioning Protocol (EPP) Host Mapping
obsoleted by
- rfc-4932 — Extensible Provisioning Protocol (EPP) Host Mapping
Extracted elements (27)
Host objects have no direct transfer or renew semantics; transfers occur implicitly when the superordinate domain object is transferred. This preserves the subordinate relationship between host and domain objects and avoids orphaning glue records.
An internal host used as a name server for a domain in the same repository that is not its own superordinate (e.g., ns1.example1.com used for example2.com) MUST be treated as an internal host subject to rules governing operations on subordinate hosts within the same repository.
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 server policies.
A host name object MUST NOT be deleted if the host object is associated with any other object, such as a domain object; the existing association must be broken first.
A host name syntax MUST conform to RFC 952 as updated by RFC 1123. IPv4 addresses MUST conform to RFC 791 and IPv6 addresses MUST conform to RFC 3513.
Attempts to update an external host object that has associations with objects sponsored by a different client MUST fail with EPP error code 2305.
Date and time attribute values MUST be represented in UTC using the Gregorian calendar, and MUST use the extended date-time form with upper case 'T' and 'Z' characters as defined in RFC 3339. Time zone offset identifiers MUST NOT be used with EPP.
EPP actions (such as object transfers) that do not preserve the subordinate relationship between a host name object and its superordinate domain name object MUST be explicitly disallowed.
Host objects MUST NOT be transferred directly; they MUST be transferred implicitly when the host object's superordinate domain object is transferred. There is no EPP <transfer> command mapping for host objects.
If the 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.
'pendingDelete' status MUST NOT be combined with 'clientDeleteProhibited' or 'serverDeleteProhibited'; 'pendingUpdate' MUST NOT be combined with 'clientUpdateProhibited' or 'serverUpdateProhibited'; and the four pending statuses MUST NOT be combined with each other.
Transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status is set. When the requested action has been completed, the pending status value MUST be removed and all involved clients MUST be notified via a service message.
Use of UTF-8 encoding is RECOMMENDED for EPP XML in environments where parser encoding support incompatibility exists, though conformant XML processors must recognize both UTF-8 and UTF-16.
When a server performs offline review of a transform command, it MUST return response code 1001, MUST reflect the pending status on the object, and MUST notify the client when offline processing is completed.
When provisioning a host as a DNS name server, IP addresses SHOULD be required only as needed to generate DNS glue records. A server MAY reject IP addresses not allocated for public use by IANA.
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 host object MUST always have at least one associated status value. Status values are set by the sponsoring client or the server; client-settable values are prefixed with 'client', server-settable values with 'server', and server-managed values have no prefix.
The <check> response returns a <host:chkData> element containing <host:cd> elements, each with a <host:name> element bearing a required 'avail' boolean attribute, and an optional <host:reason> element when the object cannot be provisioned.
The EPP <check> command for hosts uses a <host:check> element containing one or more <host:name> elements with fully qualified host names to query for availability in the repository.
The EPP <create> command for hosts uses a <host:create> element containing a required <host:name> and zero or more <host:addr> elements. Each <host:addr> MAY carry an 'ip' attribute with value 'v4' (default) or 'v6'.
The EPP <update> command uses a <host:update> element containing the host name and optional <host:add>, <host:rem>, and <host:chg> child elements; at least one of these MUST be provided. <host:chg> carries a new <host:name> to rename the host.
The <info> response returns a <host:infData> element containing: name, roid, one or more status values, zero or more IP addresses, sponsoring client ID, creating client ID, creation date, and optionally last-update client/date and last-transfer date.
The pending action notification service message includes a <host:panData> element with: a <host:name> bearing a required boolean 'paResult' attribute, a <host:paTRID> with the original transaction identifiers, and a <host:paDate> with the review completion timestamp.
Two URN assignments registered with IANA per 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 host object mapping described in this document does not provide any security services or introduce any additional security considerations beyond those described by RFC 3730 (EPP base protocol) and the protocol layers used by EPP.
IP address strings in <host:addr> elements use addrStringType (token, minLength=3, maxLength=45) with an 'ip' attribute restricted to enumeration values 'v4' or 'v6', defaulting to 'v4'.
The statusValueType enumeration defines exactly ten valid status values: clientDeleteProhibited, clientUpdateProhibited, linked, ok, pendingCreate, pendingDelete, pendingTransfer, pendingUpdate, serverDeleteProhibited, serverUpdateProhibited.