Extensible Provisioning Protocol (EPP) Host Mapping
Extracted elements (29)
A host is classified as "external" when its name does not belong to the namespace of the repository in which it is used for delegation, and as "internal" (subordinate) when it does. This distinction drives different operational rules, such as when IP addresses are required for glue records.
Host objects have no direct transfer semantics; instead they transfer implicitly when the superordinate domain object is transferred. This design preserves the subordinate relationship and is why EPP <transfer> and <renew> commands have no host mapping.
UTF-8 is RECOMMENDED for XML encoding in environments where parser encoding support incompatibility exists, though conformant XML processors must also recognize UTF-16. Time zone offset identifiers must not be used; only UTC with upper case T and Z is permitted.
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 SHOULD NOT be deleted if the host object is associated with any other object (e.g., a domain object), as deleting without breaking associations can cause DNS resolution failure.
A host object MUST always have at least one associated status value. Status values MAY be set only by the sponsoring client or the server.
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.
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.
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, using the extended date-time form with upper case "T" and "Z" characters; 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; host objects MUST be transferred implicitly when the host object's superordinate domain object is transferred.
If the host name exists in a namespace 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.
"ok" status MAY only be combined with "linked" status. "linked" status MAY be combined with any status.
"pendingDelete" status MUST NOT be combined with either "clientDeleteProhibited" or "serverDeleteProhibited" status; "pendingUpdate" MUST NOT be combined with either update-prohibited status; and the four pending status values MUST NOT be combined with each other.
The syntax for host names described in this document MUST conform to RFC 0952 as updated by RFC 1123.
The syntax for IPv4 addresses MUST conform to RFC 0791 and IPv6 addresses MUST conform to RFC 4291. When provisioned as a DNS name server, IP addresses SHOULD be required only as needed to generate DNS glue records.
When a server defers completing a transform command for offline review, the server MUST return a 1001 response code, MUST manage object status to reflect pending state, and MUST notify all involved clients via service message when the action completes.
XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation, as XML is case sensitive.
Pending action notification uses <host:panData> containing <host:name> with a required boolean "paResult" attribute, a <host:paTRID> with client and server transaction identifiers, and a <host:paDate> timestamp.
The <check> response MUST contain <host:chkData> with one or more <host:cd> elements, each holding a <host:name> with a required boolean "avail" attribute indicating provisioning availability, and an optional <host:reason> element explaining unavailability.
The EPP <check> command for host objects MUST contain a <host:check> element with one or more <host:name> child elements containing the fully qualified names of host objects to be queried.
The <info> response MUST contain <host:infData> with child elements: host:name, host:roid, one or more host:status, zero or more host:addr, host:clID, host:crID, host:crDate, and optionally host:upID, host:upDate, and host:trDate.
The <update> command uses <host:update> containing a <host:name> and optional <host:add>, <host:rem>, and <host:chg> elements to add/remove IP addresses and status values, or change the host name.
This document registers two URIs with IANA under 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 host object mapping described in this document does not provide any security services or introduce any additional security considerations beyond those described by RFC 5730 or those caused by the protocol layers used by EPP.
The <host:addr> element is defined as addrStringType: a token with minLength 3 and maxLength 45, extended with an "ip" attribute of enumerated type {"v4", "v6"} defaulting to "v4".
The <host:infData> schema enforces a fixed sequence: name, roid, status (1–7 occurrences), addr (0–unbounded), clID, crID, crDate, upID (optional), upDate (optional), trDate (optional).
The statusValueType is an enumeration of exactly ten values: clientDeleteProhibited, clientUpdateProhibited, linked, ok, pendingCreate, pendingDelete, pendingTransfer, pendingUpdate, serverDeleteProhibited, serverUpdateProhibited.