RFC 3732

Extensible Provisioning Protocol (EPP) Host Mapping

📅 published March 2004, from ietf

Extensible Provisioning Protocol (EPP) Host Mapping 🎀

okay so this is RFC 3732 💅, written by S. Hollenbeck from VeriSign, Inc. and published as part of the Network Working Group in March 2004 🌸. It's on the Standards Track, and the title block doesn't list anything it obsoletes or updates ✨.

Status of this Memo

This doc is an Internet standards track protocol for the whole Internet community 🌐, and it's literally asking for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🦋.

Copyright (C) The Internet Society (2004). All Rights Reserved. 💖

Abstract

This doc describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and managing Internet host names stored in a shared central repository 🗂️. It's specified in XML, and the mapping defines EPP command syntax and semantics as applied to host names ✨.

Table of Contents

1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
    1.1.  Relationship of Host Objects and Domain Objects . . . .   2
    1.2.  Conventions Used In This Document . . . . . . . . . . .   3
2.  Object Attributes . . . . . . . . . . . . . . . . . . . . . .   3
    2.1.  Host Names. . . . . . . . . . . . . . . . . . . . . . .   3
    2.2.  Client Identifiers. . . . . . . . . . . . . . . . . . .   3
    2.3.  Status Values . . . . . . . . . . . . . . . . . . . . .   3
    2.4.  Dates and Times . . . . . . . . . . . . . . . . . . . .   5
    2.5.  IP Addresses. . . . . . . . . . . . . . . . . . . . . .   5
3. EPP Command Mapping. . . . . . . . . . . . . . . . . . . . . .   6
    3.1.  EPP Query Commands. . . . . . . . . . . . . . . . . . .   6
          3.1.1.  EPP <check> Command . . . . . . . . . . . . . .   6
          3.1.2.  EPP <info> Command. . . . . . . . . . . . . . .   8
          3.1.3.  EPP <transfer> Query Command. . . . . . . . . .  10
    3.2.  EPP Transform Commands. . . . . . . . . . . . . . . . .  11
          3.2.1.  EPP <create> Command. . . . . . . . . . . . . .  11
          3.2.2.  EPP <delete> Command. . . . . . . . . . . . . .  13
          3.2.3.  EPP <renew> Command . . . . . . . . . . . . . .  14
          3.2.4.  EPP <transfer> Command. . . . . . . . . . . . .  14
          3.2.5.  EPP <update> Command. . . . . . . . . . . . . .  15
          3.2.6.  Offline Review of Requested Actions . . . . . .  17
4.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .  19
5.  Internationalization Considerations . . . . . . . . . . . . .  24
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
8.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  25
9.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  26
    9.1.  Normative References. . . . . . . . . . . . . . . . . .  26
    9.2.  Informative References. . . . . . . . . . . . . . . . .  27
10. Author's Address. . . . . . . . . . . . . . . . . . . . . . .  27
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  28

1. Introduction ✨

This doc describes an Internet host name mapping for version 1.0 of EPP 💅. It's specified using XML 1.0 (the Extensible Markup Language) as described in [XML], plus XML Schema notation as described in [XMLS-1] and [XMLS-2].

[RFC3730] gives the full rundown on EPP command and response structures 📖. You really need a solid grip on the base protocol spec to get this mapping, so read that one first 🫶.

XML is case sensitive, bestie 🙈. Unless stated otherwise, XML specifications and examples in this doc MUST be interpreted in the character case presented to develop a conforming implementation 🔥.

1.1. Relationship of Host Objects and Domain Objects

The doc assumes host name objects have a subordinate relationship to a superordinate domain name object 👑. Like, host name "ns1.example.com" is subordinate to domain name "example.com" 🧚. EPP actions (such as object transfers) that do not preserve this relationship MUST be explicitly disallowed 💀.

A host name object can be created in a repository where no superordinate domain name object exists 🍓. For example, host name "ns1.example.com" can be created in the ".example" repository so that DNS domains in ".example" can be delegated to the host. These hosts are described as "external" hosts in this specification, since the name of the host doesn't belong to the name space of the repository where the host is being used for delegation purposes.

Whether a host is external or internal depends on the repository where the host is used for delegation purposes 🌈. Whether an internal host is subordinate or not depends on a domain within the repository. For example, host ns1.example1.com is a subordinate host of domain example1.com, but it is a not a subordinate host of domain example2.com. ns1.example1.com can be used as a name server for example2.com. In this case, ns1.example1.com MUST be treated as an internal host, subject to the rules governing operations on subordinate hosts within the same repository 💜.

1.2. Conventions Used In This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📚.

In examples, "C:" means lines sent by a protocol client, and "S:" means lines returned by a protocol server 🎀. Indentation and white space in examples only helps show how elements relate, and it is not a REQUIRED feature of this protocol 🙌.

2. Object Attributes 🦋

An EPP host object has attributes and associated values that the sponsoring client or the server can view and modify 👀. This section breaks down each attribute type in detail. The formal syntax for the attribute values covered here is in the "Formal Syntax" section of this doc and in the appropriate normative references 🧾.

2.1. Host Names

The syntax for host names in this document MUST conform to [RFC952] as updated by [RFC1123] 🔤. At the time of writing, RFC 3490 [RFC3490] describes a standard for using certain ASCII name labels to represent non-ASCII name labels 🌏. These conformance requirements might change later as standards for internationalized host names keep progressing 🔮.

2.2. Client Identifiers

Every EPP client is identified by a server-unique identifier 🪪. Client identifiers conform to the "clIDType" syntax described in [RFC3730] 💅.

2.3. Status Values

A host object MUST always have at least one associated status value ✨. Status values MAY be set only by the client that sponsors a host object and by the server where the object lives. A client can change the status of a host object using the EPP <update> command 🛠️. Each status value MAY come with a string of human-readable text explaining the reason for the status applied to the object 📝.

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 👑. The status of an object MAY change because of either a client-initiated transform command or an action performed by a server operator 🔄.

Status values a client can add or remove are prefixed with "client" 🙋‍♀️. The matching status values a server can add or remove are prefixed with "server" 🖥️. Status values that don't begin with either "client" or "server" are server-managed 🔒.

Here's the rundown on each status value 👇:

  • clientDeleteProhibited, serverDeleteProhibited

Requests to delete the object MUST be rejected 🙅‍♀️.

  • clientUpdateProhibited, serverUpdateProhibited

Requests to update the object (other than to remove this status) MUST be rejected 🙅‍♀️.

  • linked

The host object has at least one active association with another object, such as a domain object 🔗. Servers SHOULD provide services to determine existing object associations 🔍.

  • ok

This is the normal status value for an object with no pending operations or prohibitions 🍀. The server sets and removes this value as other status values are added or removed 🔁.

  • pendingCreate, pendingDelete, pendingTransfer, pendingUpdate

A transform command has been processed for the object (or, for a <transfer> command, for the host object's superordinate domain object), but the server hasn't finished the action yet ⏳. Server operators can delay completion for all sorts of reasons, like letting a human review it or waiting on a third party 🕵️. A transform command that gets processed but has a pending requested action is noted with response code 1001 🏷️.

Transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status is set 🚧.

Once the requested action is completed, the pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status value MUST be removed 🧹. All clients involved in the transaction MUST be notified with a service message saying the action is done and the object's status has changed 📣.

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 status MUST NOT be combined with either clientUpdateProhibited or serverUpdateProhibited status 🙅‍♀️.

The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate status values MUST NOT be combined with each other 💀.

Other status combinations that aren't expressly prohibited MAY be used 💜.

2.4. Dates and Times

Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar 🗓️. The extended date-time form, using upper case "T" and "Z" characters as defined in [RFC3339], MUST be used to represent date-time values, because XML Schema doesn't support truncated date-time forms or lower case "T" and "Z" characters 🕰️.

2.5. IP Addresses

The syntax for IPv4 addresses in this document MUST conform to [RFC791] 🌐. The syntax for IPv6 addresses in this document MUST conform to [RFC3513] 🛰️. Practical considerations for publishing IPv6 address information in zone files are documented in [RFC1886], [RFC2874], and [RFC3152] 📄. A server MAY reject IP addresses that IANA hasn't allocated for public use 🙈. When a host object is provisioned for use as a DNS name server, IP addresses SHOULD only be required as needed to generate DNS glue records 🧃.

3. EPP Command Mapping 🧚

The full EPP syntax and semantics are described in [RFC3730] 📖. The command mappings here are specifically for provisioning and managing Internet host names via EPP 💖.

3.1. EPP Query Commands

EPP has two commands for retrieving host information 🔍. <check> tells you whether a host object can be provisioned within a repository, and <info> retrieves the detailed information associated with a host object 🫧.

3.1.1. EPP <check> Command 🔍

Okay so the EPP <check> command is how a client asks "hey, can I make this object?" 💅 It's basically a sneak peek, because whether provisioning actually works is ultimately up to server policy. So the answer is a hint, not a promise 🙈

Besides the standard EPP command elements, a <check> command MUST contain a <host:check> element that identifies the host namespace and where to find the host schema. The <host:check> element has these child elements:

  • One or more <host:name> elements that contain the fully qualified names of the host objects you want to query.

Here's an example <check> command 🎀

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <check>
C:      <host:check
C:       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
C:       host-1.0.xsd">
C:        <host:name>ns1.example.com</host:name>
C:        <host:name>ns2.example.com</host:name>
C:        <host:name>ns3.example.com</host:name>
C:      </host:check>
C:    </check>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

When a <check> command has been processed successfully, the EPP <resData> element MUST contain a child <host:chkData> element that identifies the host namespace and where to find the host schema. The <host:chkData> element contains one or more <host:cd> elements, and each of those has these child elements:

  • A <host:name> element that contains the fully qualified name of the queried host object. This element MUST contain an "avail" attribute. Its value tells you whether the object is available (can it be provisioned or not) at the moment the <check> command was completed. A value of "1" or "true" means the object can be provisioned. A value of "0" or "false" means the object can not be provisioned.
  • An OPTIONAL <host:reason> element that MAY be provided when an object can not be provisioned. If it shows up, it contains server-specific text that helps explain why. This text MUST be represented in the response language previously negotiated with the client. An OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en" (English). 🌸

Here's what an example <check> response looks like ✨

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S:     epp-1.0.xsd">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <host:chkData
S:       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
S:       host-1.0.xsd">
S:        <host:cd>
S:          <host:name avail="1">ns1.example.com</host:name>
S:        </host:cd>
S:        <host:cd>
S:          <host:name avail="0">ns2.example2.com</host:name>
S:          <host:reason>In use</host:reason>
S:        </host:cd>
S:        <host:cd>
S:          <host:name avail="1">ns3.example3.com</host:name>
S:        </host:cd>
S:      </host:chkData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

An EPP error response MUST be returned if a <check> command can not be processed for any reason. No exceptions, bestie 🚨

3.1.2. EPP <info> Command 📋

The EPP <info> command is used to pull up information about a host object. Besides the standard EPP command elements, an <info> command MUST contain a <host:info> element that identifies the host namespace and where to find the host schema. The <host:info> element has this child element:

  • A <host:name> element that contains the fully qualified name of the host object you want info on.

Example <info> command:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <info>
C:      <host:info
C:       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
C:       host-1.0.xsd">
C:        <host:name>ns1.example.com</host:name>
C:      </host:info>
C:    </info>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

When an <info> command has been processed successfully, the EPP <resData> element MUST contain a child <host:infData> element that identifies the host namespace and where to find the host schema. The <host:infData> element contains these child elements:

  • A <host:name> element that contains the fully qualified name of the host object.
  • A <host:roid> element that contains the Repository Object IDentifier assigned to the host object when the object was created.
  • One or more <host:status> elements that describe the status of the host object.
  • Zero or more <host:addr> elements that contain the IP addresses associated with the host object.
  • A <host:clID> element that contains the identifier of the sponsoring client.
  • A <host:crID> element that contains the identifier of the client that created the host object.
  • A <host:crDate> element that contains the date and time of host object creation.
  • A <host:upID> element that contains the identifier of the client that last updated the host object. This element MUST NOT be present if the host object has never been modified.
  • A <host:upDate> element that contains the date and time of the most recent host object modification. This element MUST NOT be present if the host object has never been modified.
  • A <host:trDate> element that contains the date and time of the most recent successful host object transfer. This element MUST NOT be provided if the host object has never been transferred. Note that host objects MUST NOT be transferred directly. Host objects MUST be transferred implicitly when the host object's superordinate domain object is transferred. Host objects that are subject to transfer when transferring a domain object are listed in the response to an EPP <info> command performed on the domain object. 🦋

Example <info> response:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S:     epp-1.0.xsd">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <host:infData
S:       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
S:       host-1.0.xsd">
S:        <host:name>ns1.example.com</host:name>
S:        <host:roid>NS1_EXAMPLE1-REP</host:roid>
S:        <host:status s="linked"/>
S:        <host:status s="clientUpdateProhibited"/>
S:        <host:addr ip="v4">192.0.2.2</host:addr>
S:        <host:addr ip="v4">192.0.2.29</host:addr>
S:        <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
S:        <host:clID>ClientY</host:clID>
S:        <host:crID>ClientX</host:crID>
S:        <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
S:        <host:upID>ClientX</host:upID>
S:        <host:upDate>1999-12-03T09:00:00.0Z</host:upDate>
S:        <host:trDate>2000-04-08T09:00:00.0Z</host:trDate>
S:      </host:infData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

An EPP error response MUST be returned if an <info> command can not be processed for any reason. 💀

3.1.3. EPP <transfer> Query Command 🙅‍♀️

Transfer semantics don't directly apply to host objects, so there's no mapping defined for the EPP <transfer> query command. Not me saying "transfer" for hosts 😭

3.2. EPP Transform Commands 🛠️

EPP gives you three commands to transform host objects: <create> to create an instance of a host object, <delete> to delete an instance of a host object, and <update> to change information associated with a host object. This document does not define host object mappings for the EPP <renew> and <transfer> commands.

Transform commands are typically processed and completed in real time. Server operators MAY receive and process transform commands, but they can defer completing the requested action if human or third-party review is required before it can be finished. In those situations the server MUST return a 1001 response code to the client, to note that the command has been received and processed, but the requested action is pending. The server MUST also manage the status of the object that is the subject of the command, so it reflects the start and finish of the requested action. Once the action has been completed, all clients involved in the transaction MUST be notified, using a service message, that the action is done and the object's status has changed. Iconic behaviour, honestly 👑

3.2.1. EPP <create> Command ✨

okay so the EPP <create> command is the transform op that lets a client make a brand new host object 🧚 on top of the usual EPP command bits, the <create> command MUST contain a <host:create> element that says which host namespace it's using and where the host schema lives. the <host:create> element has these kids:

  • A <host:name> element that holds the fully qualified name of the host object you're making 💅
  • Zero or more <host:addr> elements that hold the IP addresses you want tied to the host. Each one MAY have an "ip" attribute to say what format the address is in. The value "v4" means IPv4 and "v6" means IPv6. If you skip the "ip" attribute, "v4" is the default 🌸

Hosts can be name servers in the Domain Name System (DNS), which is described in [RFC1034] and [RFC1035]. Hosts set up as name servers might be subject to server operator policies that ask for or ban IP addresses, depending on the host's name and the namespace where the server gets used as a name server 👀 When a host is set up as a name server, IP addresses are REQUIRED only as needed to produce DNS glue records. For example, if the server is authoritative for the "com" name space and it's called "ns1.example.net", it doesn't have to produce DNS glue records for the name server, and the DNS doesn't need IP addresses for it either. no pressure, no glue 🫶

If the host name exists in a name space where the server is authoritative, then the superordinate domain of the host MUST be known to the server before the host object can be created. this part is so important 😭

Example <create> command:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <create>
C:      <host:create
C:       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
C:       host-1.0.xsd">
C:        <host:name>ns1.example.com</host:name>
C:        <host:addr ip="v4">192.0.2.2</host:addr>
C:        <host:addr ip="v4">192.0.2.29</host:addr>
C:        <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
C:      </host:create>
C:    </create>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

When a <create> command has been processed successfully, the EPP <resData> element MUST contain a child <host:creData> element that identifies the host namespace and the location of the host schema. the <host:creData> element has these kids:

  • A <host:name> element that holds the fully qualified name of the host object 🌷
  • A <host:crDate> element that holds the date and time the host object got created ⏰

Example <create> response:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S:     epp-1.0.xsd">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <host:creData
S:       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
S:       host-1.0.xsd">
S:        <host:name>ns1.example.com</host:name>
S:        <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
S:      </host:creData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

An EPP error response MUST be returned if a <create> command can not be processed for any reason. no exceptions, bestie 🙅‍♀️

3.2.2. EPP <delete> Command 🗑️

The EPP <delete> command is a transform op that lets a client delete a host object. On top of the standard EPP command elements, the <delete> command MUST contain a <host:delete> element that identifies the host namespace and the location of the host schema. The <host:delete> element has this kid:

  • A <host:name> element that holds the fully qualified name of the host object you wanna delete

A host name object MUST NOT be deleted while the host object is associated with any other object. For example, if the host object is tied to a domain object, the host object MUST NOT be deleted until that association has been broken. not me deleting a host that's still attached to stuff 💀

Example <delete> command:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <delete>
C:      <host:delete
C:       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
C:       host-1.0.xsd">
C:        <host:name>ns1.example.com</host:name>
C:      </host:delete>
C:    </delete>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

When a <delete> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element. clean and simple 🧹

Example <delete> response:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S:     epp-1.0.xsd">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

An EPP error response MUST be returned if a <delete> command can not be processed for any reason.

3.2.3. EPP <renew> Command 🙅‍♀️

Renewal semantics don't apply to host objects, so there's no mapping defined for the EPP <renew> command. it's giving "not applicable" energy 💅

3.2.4. EPP <transfer> Command 🦋

Transfer semantics don't directly apply to host objects, so there's no mapping defined for the EPP <transfer> command. the vibe here is that hosts are subordinate to an existing superordinate domain object, so they get transferred along with a domain object when that domain gets transferred. main character domain, sidekick host 👑

3.2.5. EPP <update> Command 🌈

The EPP <update> command is a transform op that lets a client change the attributes of a host object. On top of the standard EPP command elements, the <update> command MUST contain a <host:update> element that identifies the host namespace and the location of the host schema. The <host:update> element has these kids:

  • A <host:name> element that holds the fully qualified name of the host object you're updating
  • An OPTIONAL <host:add> element that holds attribute values to be added to the object ➕
  • An OPTIONAL <host:rem> element that holds attribute values to be removed from the object ➖
  • An OPTIONAL <host:chg> element that holds object attribute values to be changed ✏️

At least one <host:add>, <host:rem>, or <host:chg> element MUST be provided. The <host:add> and <host:rem> elements have these kids:

  • One or more <host:addr> elements that hold IP addresses to be tied to, or removed from, the host object. The IP address restrictions from the <create> command mapping apply here too 🫶
  • One or more <host:status> elements that hold status values to be tied to, or removed from, the object. When you're removing a value, only the attribute value matters. The element text doesn't have to match a value for removal, so you can relax about that part 💜

A <host:chg> element has this kid:

  • A <host:name> element that holds a new fully qualified host name the host object will go by from now on 🎀

Host name changes MAY require adding or removing IP addresses so the server will accept them. IP address association MAY be subject to server policies for provisioning hosts as name servers. server policies are a whole mood 🙈

Host name changes can have an impact on associated objects that refer to the host object. A host name change SHOULD NOT require extra updates to associated objects just to keep the existing associations alive, with one exception: changing an external host object that has associations with objects sponsored by a different client. Attempts to update such hosts directly MUST fail with EPP error code 2305. The workaround is to create a new external host with a new name and whatever new attributes it needs, and then update the other objects your client sponsors to point at it. this exception is the drama of the whole section, no cap 😭

Example <update> command:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C:     epp-1.0.xsd">
C:  <command>
C:    <update>
C:      <host:update
C:       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
C:       host-1.0.xsd">
C:        <host:name>ns1.example.com</host:name>
C:        <host:add>
C:          <host:addr ip="v4">192.0.2.22</host:addr>
C:          <host:status s="clientUpdateProhibited"/>
C:        </host:add>
C:        <host:rem>
C:          <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
C:        </host:rem>
C:        <host:chg>
C:          <host:name>ns2.example.com</host:name>
C:        </host:chg>
C:      </host:update>
C:    </update>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

When an <update> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.

Example <update> response:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S:     epp-1.0.xsd">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

An EPP error response MUST be returned if an <update> command could not be processed for any reason. 🫶

3.2.6. Offline Review of Requested Actions ✨

Okay so, the server handles commands in the exact order the client sends them 🎀. Even though the server instantly replies to say "got it, processed!", the server operator MAY do an offline review of transform commands before actually finishing the requested action 🕵️‍♀️. When that happens, the response MUST clearly say the transform command was received and processed, but the action is still pending ⏳. The object's status MUST clearly show that the pending action is being processed. And the server MUST notify the client once the offline processing is done 💌.

Let's look at a <create> command that needs offline review. Peep the result code and message in the response 👀.

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S:     epp-1.0.xsd">
S:  <response>
S:    <result code="1001">
S:      <msg>Command completed successfully; action pending</msg>
S:    </result>
S:    <resData>
S:      <host:creData
S:       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
S:       host-1.0.xsd">
S:        <host:name>ns1.example.com</host:name>
S:        <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
S:      </host:creData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

After sending this response, the status of the host object MUST include "pendingCreate" 🌸. The server operator reviews the request offline, then lets the client know how it went by queuing a service message that the client grabs with the <poll> command 📬.

The service message MUST contain text in the <response>, <msgQ>, <msg> element that describes the notification 💬. On top of that, the EPP <resData> element MUST contain a child <host:panData> element that identifies the host namespace and the location of the host schema 🧚. The <host:panData> element has these child elements:

  • A <host:name> element with the fully qualified name of the host object. This element has a REQUIRED paResult attribute 🔑. A positive boolean value means the request was approved and completed ✅. A negative boolean value means the request was denied and the requested action was not taken ❌.
  • A <host:paTRID> element with the client transaction identifier and server transaction identifier that came back with the original response to process the command. The client transaction identifier is OPTIONAL, and it only shows up if the client gave one with the original <create> command 🫶.
  • A <host:paDate> element with the date and time when the review of the requested action was completed 🗓️.

Here's an example "review completed" service message 💖:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S:     epp-1.0.xsd">
S:  <response>
S:    <result code="1301">
S:      <msg>Command completed successfully; ack to dequeue</msg>
S:    </result>
S:    <msgQ count="5" id="12345">
S:      <qDate>1999-04-04T22:01:00.0Z</qDate>
S:      <msg>Pending action completed successfully.</msg>
S:    </msgQ>
S:    <resData>
S:      <host:panData
S:       xmlns:host="urn:ietf:params:xml:ns:host-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:host-1.0
S:       host-1.0.xsd">
S:        <host:name paResult="1">ns1.example.com</host:name>
S:        <host:paTRID>
S:          <clTRID>ABC-12345</clTRID>
S:          <svTRID>54322-XYZ</svTRID>
S:        </host:paTRID>
S:        <host:paDate>1999-04-04T22:00:00.0Z</host:paDate>
S:      </host:panData>
S:    </resData>
S:    <trID>
S:      <clTRID>BCD-23456</clTRID>
S:      <svTRID>65432-WXY</svTRID>
S:    </trID>
S:  </response>
S:</epp>

4. Formal Syntax ✨

okay so the whole object mapping is written in XML Schema notation 🎀 and this is the complete schema, so a machine can check EPP XML instances automatically 🤖💖 the BEGIN and END lines aren't part of the schema itself, they just mark where it starts and ends for URI registration purposes 🦋

BEGIN
<?xml version="1.0" encoding="UTF-8"?>

<schema targetNamespace="urn:ietf:params:xml:ns:host-1.0"
        xmlns:host="urn:ietf:params:xml:ns:host-1.0"
        xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
        xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
        xmlns="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">

<!--
Import common element types.
-->
  <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
          schemaLocation="eppcom-1.0.xsd"/>
  <import namespace="urn:ietf:params:xml:ns:epp-1.0"
          schemaLocation="epp-1.0.xsd"/>

  <annotation>

    <documentation>
      Extensible Provisioning Protocol v1.0
      host provisioning schema.
    </documentation>
  </annotation>

<!--
Child elements found in EPP commands.
-->
  <element name="check" type="host:mNameType"/>
  <element name="create" type="host:createType"/>
  <element name="delete" type="host:sNameType"/>
  <element name="info" type="host:sNameType"/>
  <element name="update" type="host:updateType"/>

<!--
Child elements of the <create> command.
-->
  <complexType name="createType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
      <element name="addr" type="host:addrType"
       minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="addrType">
    <simpleContent>
      <extension base="host:addrStringType">
        <attribute name="ip" type="host:ipType"
         default="v4"/>
      </extension>
    </simpleContent>
  </complexType>

  <simpleType name="addrStringType">
    <restriction base="token">
      <minLength value="3"/>
      <maxLength value="45"/>
    </restriction>
  </simpleType>

  <simpleType name="ipType">
    <restriction base="token">
      <enumeration value="v4"/>
      <enumeration value="v6"/>
    </restriction>
  </simpleType>

<!--
Child elements of the <delete> and <info> commands.
-->
  <complexType name="sNameType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
    </sequence>
  </complexType>

<!--
Child element of commands that accept multiple names.
-->
  <complexType name="mNameType">
    <sequence>
      <element name="name" type="eppcom:labelType"
       maxOccurs="unbounded"/>
    </sequence>
  </complexType>
<!--
Child elements of the <update> command.
-->
  <complexType name="updateType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
      <element name="add" type="host:addRemType"
       minOccurs="0"/>
      <element name="rem" type="host:addRemType"
       minOccurs="0"/>
      <element name="chg" type="host:chgType"
       minOccurs="0"/>
    </sequence>
  </complexType>

<!--
Data elements that can be added or removed.
-->
  <complexType name="addRemType">
    <sequence>
      <element name="addr" type="host:addrType"
       minOccurs="0" maxOccurs="unbounded"/>
      <element name="status" type="host:statusType"
       minOccurs="0" maxOccurs="7"/>
    </sequence>
  </complexType>

<!--
Data elements that can be changed.
-->

  <complexType name="chgType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
    </sequence>
  </complexType>

<!--
Child response elements.
-->
  <element name="chkData" type="host:chkDataType"/>
  <element name="creData" type="host:creDataType"/>
  <element name="infData" type="host:infDataType"/>
  <element name="panData" type="host:panDataType"/>

<!--
<check> response elements.
-->
  <complexType name="chkDataType">
    <sequence>
      <element name="cd" type="host:checkType"
       maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="checkType">
    <sequence>
      <element name="name" type="host:checkNameType"/>
      <element name="reason" type="eppcom:reasonType"
       minOccurs="0"/>
    </sequence>
  </complexType>

  <complexType name="checkNameType">
    <simpleContent>
      <extension base="eppcom:labelType">
        <attribute name="avail" type="boolean"
         use="required"/>
      </extension>
    </simpleContent>
  </complexType>

<!--
<create> response elements.
-->
  <complexType name="creDataType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
      <element name="crDate" type="dateTime"/>

    </sequence>
  </complexType>

<!--
<info> response elements.
-->
  <complexType name="infDataType">
    <sequence>
      <element name="name" type="eppcom:labelType"/>
      <element name="roid" type="eppcom:roidType"/>
      <element name="status" type="host:statusType"
       maxOccurs="7"/>
      <element name="addr" type="host:addrType"
       minOccurs="0" maxOccurs="unbounded"/>
      <element name="clID" type="eppcom:clIDType"/>
      <element name="crID" type="eppcom:clIDType"/>
      <element name="crDate" type="dateTime"/>
      <element name="upID" type="eppcom:clIDType"
       minOccurs="0"/>
      <element name="upDate" type="dateTime"
       minOccurs="0"/>
      <element name="trDate" type="dateTime"
       minOccurs="0"/>
    </sequence>
  </complexType>

<!--
Status is a combination of attributes and an optional human-readable
message that may be expressed in languages other than English.
-->
  <complexType name="statusType">
    <simpleContent>
      <extension base="normalizedString">
        <attribute name="s" type="host:statusValueType"
         use="required"/>
        <attribute name="lang" type="language"
         default="en"/>
      </extension>
    </simpleContent>
  </complexType>

  <simpleType name="statusValueType">
    <restriction base="token">
      <enumeration value="clientDeleteProhibited"/>
      <enumeration value="clientUpdateProhibited"/>
      <enumeration value="linked"/>
      <enumeration value="ok"/>
      <enumeration value="pendingCreate"/>
      <enumeration value="pendingDelete"/>
      <enumeration value="pendingTransfer"/>
      <enumeration value="pendingUpdate"/>
      <enumeration value="serverDeleteProhibited"/>
      <enumeration value="serverUpdateProhibited"/>
    </restriction>
  </simpleType>

<!--
Pending action notification response elements.
-->
  <complexType name="panDataType">
    <sequence>
      <element name="name" type="host:paNameType"/>
      <element name="paTRID" type="epp:trIDType"/>
      <element name="paDate" type="dateTime"/>
    </sequence>
  </complexType>
  <complexType name="paNameType">
    <simpleContent>
      <extension base="eppcom:labelType">
        <attribute name="paResult" type="boolean"
         use="required"/>
      </extension>
    </simpleContent>
  </complexType>

<!--
End of schema.
-->
</schema>
END

5. Internationalization Considerations 🌍

okay so EPP is XML, and XML comes with built-in support for Unicode 💅 you can encode stuff with UTF-8 too, which is the more compact way to do it 🫶 conformant XML processors recognize both UTF-8 and UTF-16 [RFC2781] ✨ XML can also use other encodings if you name them in the "encoding" attribute of the <?xml?> declaration, but use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists 🧚

all date-time values sent over EPP MUST be in Universal Coordinated Time using the Gregorian calendar 🕰️ XML Schema lets you use time zone identifiers for offsets from the zero meridian, but this option MUST NOT be used with EPP 🙈 the extended date-time form with upper case "T" and "Z" from [RFC3339] MUST be used to represent date-time values, because XML Schema doesn't support truncated date-time forms or lower case "T" and "Z" characters 😭 not it being picky, it's just how it works 💀

this document needs host name syntax from [RFC952] as updated by [RFC1123] 🌸 as of writing, RFC 3490 [RFC3490] describes a way to use certain ASCII name labels to stand in for non-ASCII name labels 🦋 these conformance requirements might change as the work on internationalized host names moves forward 👑

6. IANA Considerations 🎀

okay so this document uses URNs to describe XML namespaces and XML schemas, following a registry mechanism from [RFC3688] 💖 IANA has registered two URI assignments, and here they are 🍓

Registration request for the host namespace:

URI: urn:ietf:params:xml:ns:host-1.0

Registrant Contact: See the "Author's Address" section of this
document.

XML: None.  Namespace URIs do not represent an XML specification.

Registration request for the host XML schema:

URI: urn:ietf:params:xml:schema:host-1.0

Registrant Contact: See the "Author's Address" section of this
document.

XML: See the "Formal Syntax" section of this document.

7. Security Considerations 🔒

okay bestie, this one's short but it's serious 😭 the object mapping in this document doesn't provide any security services 💀 and it doesn't add any extra considerations beyond what [RFC3730] and the protocol layers EPP uses already cover 🔥 so go check those too, periodt 🫶

8. Acknowledgements 🫶

this document started out as an individual submission Internet-Draft 🌈 then the provreg working group adopted it as a working group document and gave tons of invaluable comments and suggested improvements 💜 the author wants to shout out WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions 👑

specific suggestions that made it into this document came from Chris Bason, Jordyn Buchanan, Dave Crocker, Anthony Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, and Rick Wesson ✨ main character energy for all of them 🧚

9. References 📚

9.1. Normative References 💖

okay so these are the docs you need to read before any of this makes sense, bestie 📚

  • [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 🌐
  • [RFC952] Harrenstien, K, Stahl, M. and E. Feinler, "DOD Internet Host Table Specification", RFC 952, October 1985. 🗂️
  • [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. 🧚
  • [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. 🎀
  • [RFC1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989. 🌸
  • [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💅
  • [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. ⏰
  • [RFC3513] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 3513, April 2003. 🦋
  • [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. 🗃️
  • [RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004. 🫶
  • [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation 6 October 2000. 🌈
  • [XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures", W3C Recommendation 2 May 2001. 🍓
  • [XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: Datatypes", W3C Recommendation 2 May 2001. 👑

9.2. Informative References ✨

these ones are extra reading, lowkey helpful but not required to get the core spec 🤓

  • [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995. 🌙
  • [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. 💜
  • [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000. 🌷
  • [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001. 🦄
  • [RFC3490] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. 🌍

10. Author's Address 🖊️

the person behind it all, the one and only Scott Hollenbeck 👑

Scott Hollenbeck
VeriSign Global Registry Services
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA

EMail: shollenbeck@verisign.com

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. 🔒

this next bit is the legal "no promises" part, and it's in all caps on purpose, so read it carefully 🙈

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 📜

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🗄️

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💌

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

And that's a wrap, bestie! 🎉✨

📦 where this page comes from