RFC 3731

Extensible Provisioning Protocol (EPP) Domain Name Mapping

📅 published March 2004, from ietf

RFC 3731: Extensible Provisioning Protocol (EPP) Domain Name Mapping ✨

  • Series: Network Working Group 🌸
  • Number: RFC 3731
  • Author: S. Hollenbeck, VeriSign, Inc. 💅
  • Category: Standards Track 🔥
  • Date: March 2004 🦋
  • Obsoletes / Updates: The title block doesn't list anything this RFC obsoletes or updates 🫶

Okay bestie, this one is the Extensible Provisioning Protocol (EPP) domain name mapping, and it's giving serious main character energy. It's all about how you manage Internet domain names stored in a shared central repository. 🌈

Status of this Memo 📜

This document is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 💜 Check the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited, so share the love 🫶

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

Abstract 🍓

This doc describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and managing Internet domain names that live in a shared central repository. It's specified in XML, and the mapping defines EPP command syntax and semantics as they apply to domain names. So basically, this is the rulebook for how domain names get handled ✨

Table of Contents 🗂️

1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
    1.1.  Relationship of Domain Objects and Host Objects . . . .   2
    1.2.  Conventions Used In This Document . . . . . . . . . . .   4
2.  Object Attributes . . . . . . . . . . . . . . . . . . . . . .   4
    2.1.  Domain and Host Names . . . . . . . . . . . . . . . . .   4
    2.2.  Contact and Client Identifiers. . . . . . . . . . . . .   5
    2.3.  Status Values . . . . . . . . . . . . . . . . . . . . .   5
    2.4.  Dates and Times . . . . . . . . . . . . . . . . . . . .   7
    2.5.  Validity Periods. . . . . . . . . . . . . . . . . . . .   7
    2.6.  Authorization Information . . . . . . . . . . . . . . .   7
    2.7.  Other DNS Resource Record Attributes. . . . . . . . . .   7
3.  EPP Command Mapping . . . . . . . . . . . . . . . . . . . . .   8
    3.1.  EPP Query Commands. . . . . . . . . . . . . . . . . . .   8
          3.1.1.  EPP <check> Command . . . . . . . . . . . . . .   8
          3.1.2.  EPP <info> Command. . . . . . . . . . . . . . .  10
          3.1.3.  EPP <transfer> Query Command. . . . . . . . . .  16
    3.2.  EPP Transform Commands. . . . . . . . . . . . . . . . .  18
          3.2.1.  EPP <create> Command. . . . . . . . . . . . . .  19
          3.2.2.  EPP <delete> Command. . . . . . . . . . . . . .  21
          3.2.3.  EPP <renew> Command . . . . . . . . . . . . . .  23
          3.2.4.  EPP <transfer> Command. . . . . . . . . . . . .  24
          3.2.5.  EPP <update> Command. . . . . . . . . . . . . .  27
          3.2.6.  Offline Review of Requested Actions . . . . . .  29
4.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .  32
5.  Internationalization Considerations . . . . . . . . . . . . .  41
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  42
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  42
8.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  42
9.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  43
    9.1.  Normative References. . . . . . . . . . . . . . . . . .  43
    9.2.  Informative References. . . . . . . . . . . . . . . . .  43
10. Author's Address. . . . . . . . . . . . . . . . . . . . . . .  44
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  45

1. Introduction 🌸

This doc describes an Internet domain name mapping for version 1.0 of the Extensible Provisioning Protocol (EPP). The mapping is specified using the Extensible Markup Language (XML) 1.0 as described in [XML], and XML Schema notation as described in [XMLS-1] and [XMLS-2].

[RFC3730] gives you a complete description of EPP command and response structures. You need a solid understanding of the base protocol spec to get this mapping, so go read that first 📚

XML is case sensitive 🙈 Unless stated otherwise, XML specifications and examples in this document MUST be interpreted in the character case presented if you're developing a conforming implementation. Don't mess with the capitalization!

1.1. Relationship of Domain Objects and Host Objects 🦋

The EPP mapping for host objects is described in [RFC3732]. This doc assumes that domain name objects have a superordinate relationship to subordinate host name objects. For example, the domain name example.com has a superordinate relationship to the host name ns1.example.com. EPP actions (like object transfers) that don't 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, the host name ns1.example.com can be created in the .example repository so that DNS domains in .example can be delegated to that host. These hosts are described as "external" hosts in this specification, since the name of the host doesn't belong to the namespace of the repository where the host is being used for delegation purposes.

Whether a host is external or internal depends on the repository where it's being used for delegation purposes. Whether an internal host is subordinate or not depends on a domain within the repository. For example, the host ns1.example1.com is a subordinate host of the domain example1.com, but it is not a subordinate host of the domain example2.com. The host 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 🧠

Name server hosts for domain delegation can be specified as either references to existing host objects, or as domain attributes that describe a host machine. A server operator MUST use one name server specification form consistently. A server operator that announces support for host objects in an EPP greeting MUST NOT allow domain attributes to describe a name server host machine. A server operator that does not announce support for host objects MUST allow domain attributes to describe a name server host machine. When domain attributes are used to describe a name server host machine, IP addresses SHOULD be required only as needed to generate DNS glue records 🍓

Name servers are specified within a <domain:ns> element. This element MUST contain one or more <domain:hostObj> elements or one or more <domain:hostAttr> elements. A <domain:hostObj> element contains the fully qualified name of a known name server host object. A <domain:hostAttr> element contains the following child elements:

  • A <domain:hostName> element that contains the fully qualified name of a host.
  • Zero or more OPTIONAL <domain:hostAddr> elements that contain the IP addresses to be associated with the host. Each element MAY contain an ip attribute to identify the IP address format. The attribute value v4 is used to note IPv4 address format. The attribute value v6 is used to note IPv6 address format. If the ip attribute is not specified, v4 is the default attribute value. IP address syntax requirements are described in Section 2.5 of the EPP host mapping [RFC3732] ✨

Example host object name server elements for domain example.com:

<domain:ns>
  <domain:hostObj>ns1.example.com</domain:hostObj>
  <domain:hostObj>ns1.example.net</domain:hostObj>
</domain:ns>

Example host attribute name server elements for domain example.com:

<domain:ns>
  <domain:hostAttr>
    <domain:hostName>ns1.example.com</domain:hostName>
    <domain:hostAddr
     ip="v4">192.0.2.2</domain:hostAddr>
    <domain:hostAddr
     ip="v6">1080:0:0:0:8:800:200C:417A</domain:hostAddr>
  </domain:hostAttr>
  <domain:hostAttr>
    <domain:hostName>ns1.example.net</domain:hostName>
  </domain:hostAttr>
</domain:ns>

1.2. Conventions Used In This Document 🎀

Here are the key words that get special treatment in this doc: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". They're to be interpreted as described in [RFC2119] 🫶

In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples are only there to show how elements relate, so they're not a REQUIRED feature of this protocol 💖

2. Object Attributes 💅

An EPP domain object has attributes and associated values that can be viewed and modified by the sponsoring client or the server. This section describes each attribute type in detail. The formal syntax for the attribute values described here can be found in the "Formal Syntax" section of this document and in the appropriate normative references 📖

2.1. Domain and Host Names 🌈

The syntax for domain and host names described in this document MUST conform to [RFC952] as updated by [RFC1123]. At the time of writing, RFC 3490 [RFC3490] describes a standard to use certain ASCII name labels to represent non-ASCII name labels. These conformance requirements might change as a result of progressing work in developing standards for internationalized domain names 🌍 A server MAY restrict allowable domain names to a particular top level domain, second level domain, or other domain for which the server is authoritative. The trailing dot required when these names are stored in a DNS zone is implicit, and it MUST NOT be provided when exchanging host and domain names. No trailing dots, bestie 🙅‍♀️

2.2. Contact and Client Identifiers 🧚

All EPP contacts are identified by a server-unique identifier. Contact identifiers are character strings with a specified minimum length, a specified maximum length, and a specified format. Contact identifiers use the "clIDType" client identifier syntax described in [RFC3730] 🦋

More coming in part 2 💜

2.3. Status Values ✨

Okay bestie, every domain object MUST always have at least one status value 💅 It can never be status-less, that's the rule. Only the client that sponsors the domain object and the server it lives on can set statuses 🔐 A client can change a status with the EPP <update> command 🎀 Each status value MAY be accompanied by a string of human-readable text explaining why that status got applied 📝

A client MUST NOT alter status values the server set 🚫 Rude, right? A server MAY alter or override status values a client set, subject to local server policies 👑 And the status of an object MAY change because of a client-initiated transform command or an action from a server operator 🔄

Statuses a client can add or remove start with "client" 💜 Their server twins start with "server" 🧚 Anything that doesn't start with either one is server-managed 🌸

Status Value Descriptions:

  • clientDeleteProhibited, serverDeleteProhibited
    • Requests to delete the object MUST be rejected 🙅‍♀️
  • clientHold, serverHold
    • DNS delegation information MUST NOT be published for the object 🤐
  • clientRenewProhibited, serverRenewProhibited
    • Requests to renew the object MUST be rejected 🙅‍♀️
  • clientTransferProhibited, serverTransferProhibited
    • Requests to transfer the object MUST be rejected 🙅‍♀️
  • clientUpdateProhibited, serverUpdateProhibited
    • Requests to update the object (other than to remove this status) MUST be rejected 🙅‍♀️
  • inactive
    • Delegation information has not been associated with the object 💤
  • ok
    • This is the normal status for an object with no pending operations or prohibitions ✨ The server sets and removes this value as other statuses get added or removed 🌈
  • pendingCreate, pendingDelete, pendingRenew, pendingTransfer, pendingUpdate
    • A transform command has been processed for the object, but the server hasn't finished the action yet ⏳ Server operators can delay completion for a bunch of reasons, like letting a human review it or waiting on a third party 🕵️‍♀️ A transform command that got processed but has a pending requested action gets noted with response code 1001 🎫

With one exception, transform commands MUST be rejected when any of pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate is set 🛑 The only exception is that a <transfer> command to approve, reject, or cancel a transfer MAY be processed while the object is in "pendingTransfer" status 🦋

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

ok MUST NOT be combined with any other status 🙅‍♀️

pendingDelete MUST NOT be combined with clientDeleteProhibited or serverDeleteProhibited 🙅‍♀️

pendingRenew MUST NOT be combined with clientRenewProhibited or serverRenewProhibited 🙅‍♀️

pendingTransfer MUST NOT be combined with clientTransferProhibited or serverTransferProhibited 🙅‍♀️

pendingUpdate MUST NOT be combined with clientUpdateProhibited or serverUpdateProhibited 🙅‍♀️

The pendingCreate, pendingDelete, pendingRenew, pendingTransfer, and pendingUpdate statuses 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, with upper case "T" and "Z" characters, is defined in [RFC3339] and MUST be used for date-time values 💖 The reason is that XML Schema doesn't support truncated date-time forms or lower case "T" and "Z" characters 🙈

2.5. Validity Periods ⏰

A domain name object MAY have a specified validity period 🎀 If server policy supports validity periods for domain objects, the period gets defined when the object is created, and it MAY be extended by the EPP <renew> or <transfer> commands 🔁 As a matter of server policy, this specification doesn't define what happens when a domain object's validity period expires 🤷‍♀️

Validity periods are measured in years or months, and the units get specified with the "unit" attribute 📅 Valid values for "unit" are "y" for years and "m" for months 🗓️ The minimum allowable period value is one decimal (1) and the maximum allowable value is ninety-nine decimal (99) 🔢 A server MAY support a lower maximum value 🧸

2.6. Authorization Information 🔑

Authorization information is attached to domain objects so transfers can happen 🦋 It gets assigned when the domain object is created, and it might get updated later ✨ This specification describes password-based authorization information, but other mechanisms are possible 🌈

2.7. Other DNS Resource Record Attributes 🧾

The DNS lets you associate lots of resource record types with a domain, but this mapping only explicitly spells out the elements for resource records used in domain delegation and resolution 🧠 Facilities for provisioning other domain-related resource record types can be developed by extending this mapping 🧩

The provisioning method here separates discrete data elements by data type 🗂️ This lets XML Schema processors do basic syntax validation, which cuts down on ambiguity and on the parsing and syntax-checking work protocol processors have to do 💅 Provisioning and extension methods that bundle data into opaque strings are possible, but such methods SHOULD NOT be used, because they pile on extra parsing, interpretation, and validation requirements for protocol processors 😤

3. EPP Command Mapping 📡

A detailed description of the EPP syntax and semantics can be found in [RFC3730] 📖 The command mappings here are specifically for provisioning and managing Internet domain names via EPP 🌐

3.1. EPP Query Commands 🔍

EPP gives you three commands to retrieve domain information 💜 <check> tells you whether a domain object can be provisioned within a repository, <info> retrieves detailed information about a domain object, and <transfer> retrieves domain object transfer status information 🎀

3.1.1. EPP <check> Command 💖

The EPP <check> command is used to figure out whether an object can be provisioned within a repository 🔮 It gives you a hint so you can anticipate whether a <create> will succeed, but object provisioning requirements are ultimately a matter of server policy 🤞

On top of the standard EPP command elements, the <check> command MUST contain a <domain:check> element that identifies the domain namespace and the location of the domain schema 📍 The <domain:check> element has these child elements:

  • One or more <domain:name> elements containing the fully qualified names of the domain objects you want to query 📝

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:      <domain:check
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:        <domain:name>example.net</domain:name>
C:        <domain:name>example.org</domain:name>
C:      </domain: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 <domain:chkData> element that identifies the domain namespace and the location of the domain schema 🎉 The <domain:chkData> element holds one or more <domain:cd> elements, each with these child elements:

  • A <domain:name> element containing the fully qualified name of the queried domain object 🏷️ This element MUST contain an "avail" attribute whose value shows whether the object can be provisioned at the moment the <check> command was completed ⏱️ A value of "1" or "true" means it can be provisioned ✅ A value of "0" or "false" means it can not be provisioned ❌
  • An OPTIONAL <domain:reason> element that MAY be provided when an object can not be provisioned 💬 If it's there, it holds server-specific text explaining why the object can not be provisioned 🕵️‍♀️ That text MUST be in the response language previously negotiated with the client 🌏 An OPTIONAL "lang" attribute MAY be present to identify the language when the negotiated value is something other than the default "en" (English) 🇬🇧

Example <check> 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:      <domain:chkData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:       domain-1.0.xsd">
S:        <domain:cd>
S:          <domain:name avail="1">example.com</domain:name>
S:        </domain:cd>
S:        <domain:cd>
S:          <domain:name avail="0">example.net</domain:name>
S:          <domain:reason>In use</domain:reason>
S:        </domain:cd>
S:        <domain:cd>
S:          <domain:name avail="1">example.org</domain:name>
S:        </domain:cd>
S:      </domain: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 🚨

3.1.2. EPP <info> Command ✨

okay so the EPP <info> command is how you grab all the tea on a domain object 🦋. the response MAY vary depending on who's asking, whether they bring authorization information, and what the server's policy says about unauthorized clients 👀. if the querying client is the sponsoring client, all available information MUST be returned 💅. if the querying client is not the sponsoring client but they give valid authorization information, all available information MUST be returned too 🔥. and if they're not the sponsoring client AND they don't provide valid authorization info, server policy decides which OPTIONAL elements get returned 🙈.

in addition to the standard EPP command elements, the <info> command MUST contain a <domain:info> element that identifies the domain namespace and the location of the domain schema 🎀. the <domain:info> element has these child elements:

  • A <domain:name> element that contains the fully qualified name of the domain object to be queried. An OPTIONAL "hosts" attribute lets you control whether you get host info back. A value of "all" (the default, which MAY be absent) returns info about both subordinate and delegated hosts. "del" returns info about only delegated hosts. "sub" returns info about only subordinate hosts. "none" returns no info about delegated or subordinate hosts 🍓.
  • An OPTIONAL <domain:authInfo> element that contains authorization information associated with the domain object, or authorization information associated with the domain object's registrant or associated contacts. An OPTIONAL "roid" attribute MUST be used to identify the registrant or contact object if and only if the given authInfo is associated with a registrant or contact object, and not the domain object itself. If this element isn't provided, or if the authorization information is invalid, server policy decides whether the command gets rejected or whether response info still goes back to the client 🧚.

Example <info> command without authorization information:

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:      <domain:info
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name hosts="all">example.com</domain:name>
C:      </domain:info>
C:    </info>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Example <info> command with authorization information:

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:      <domain:info
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name hosts="all">example.com</domain:name>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain: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 <domain:infData> element that identifies the domain namespace and the location of the domain schema 🌸. anything that isn't OPTIONAL MUST be returned, and OPTIONAL elements come back based on client authorization and server policy. the <domain:infData> element has these child elements:

  • A <domain:name> element that contains the fully qualified name of the domain object.
  • A <domain:roid> element that contains the Repository Object IDentifier assigned to the domain object when the object was created.
  • Zero or more OPTIONAL <domain:status> elements that contain the current status descriptors associated with the domain.
  • If supported by the server, one OPTIONAL <domain:registrant> element and one or more OPTIONAL <domain:contact> elements that contain identifiers for the human or organizational social information objects associated with the domain object.
  • An OPTIONAL <domain:ns> element that contains the fully qualified names of the delegated host objects or host attributes (name servers) associated with the domain object. See section 1.1 for a description of the elements used to specify host objects or host attributes.
  • Zero or more OPTIONAL <domain:host> elements that contain the fully qualified names of the subordinate host objects that exist under this superordinate domain object.
  • A <domain:clID> element that contains the identifier of the sponsoring client.
  • An OPTIONAL <domain:crID> element that contains the identifier of the client that created the domain object.
  • An OPTIONAL <domain:crDate> element that contains the date and time of domain object creation.
  • An OPTIONAL <domain:exDate> element that contains the date and time identifying the end of the domain object's registration period.
  • An OPTIONAL <domain:upID> element that contains the identifier of the client that last updated the domain object. This element MUST NOT be present if the domain has never been modified.
  • An OPTIONAL <domain:upDate> element that contains the date and time of the most recent domain object modification. This element MUST NOT be present if the domain object has never been modified.
  • An OPTIONAL <domain:trDate> element that contains the date and time of the most recent successful domain object transfer. This element MUST NOT be provided if the domain object has never been transferred.
  • An OPTIONAL <domain:authInfo> element that contains authorization information associated with the domain object. This element MUST only be returned if the querying client is the current sponsoring client, or if the client supplied valid authorization information with the command 🔐.

Example <info> response for an authorized client:

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:      <domain:infData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:       domain-1.0.xsd">
S:        <domain:name>example.com</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:status s="ok"/>
S:        <domain:registrant>jd1234</domain:registrant>
S:        <domain:contact type="admin">sh8013</domain:contact>
S:        <domain:contact type="tech">sh8013</domain:contact>
S:        <domain:ns>
S:          <domain:hostObj>ns1.example.com</domain:hostObj>
S:          <domain:hostObj>ns1.example.net</domain:hostObj>
S:        </domain:ns>
S:        <domain:host>ns1.example.com</domain:host>
S:        <domain:host>ns2.example.com</domain:host>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:crID>ClientY</domain:crID>
S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S:        <domain:upID>ClientX</domain:upID>
S:        <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
S:        <domain:authInfo>
S:          <domain:pw>2fooBAR</domain:pw>
S:        </domain:authInfo>
S:      </domain:infData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

a server with a different information return policy MAY provide less information in a response 🤷‍♀️.

Example <info> response for an unauthorized client:

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:      <domain:infData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:       domain-1.0.xsd">
S:        <domain:name>example.com</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:clID>ClientX</domain:clID>
S:      </domain:infData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

and if an <info> command can't be processed for any reason, an EPP error response MUST be returned 🚨. no exceptions, bestie 💀.

3.1.3. EPP <transfer> Query Command ✨

okay so the EPP <transfer> command has a query operation, and it's how a client checks the real-time status of pending AND completed transfer requests 👀🦋 no cap, it's super useful. Besides the usual EPP command elements, your <transfer> command MUST have an op attribute set to "query", plus a <domain:transfer> element that names the domain namespace and where the domain schema lives 💅 The <domain:transfer> element has these child elements:

  • A <domain:name> element that holds the fully qualified name of the domain object you're querying 🌸
  • An OPTIONAL <domain:authInfo> element that holds authorization info for the domain object, or for the domain object's registrant or associated contacts 🫶 An OPTIONAL "roid" attribute MUST be used to identify the registrant or contact object if and only if the given authInfo belongs to a registrant or contact object, and NOT to the domain object itself. If this element isn't provided, or the authorization info is invalid, server policy decides whether the command gets rejected or whether response info is still returned to the client 🙈

Here's an example <transfer> query command (it's giving very clean energy):

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:    <transfer op="query">
C:      <domain:transfer
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:        <domain:authInfo>
C:          <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:transfer>
C:    </transfer>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

When a <transfer> query command has been processed successfully, the EPP <resData> element MUST contain a child <domain:trnData> element that names the domain namespace and where the domain schema lives. The <domain:trnData> element has these child elements:

  • A <domain:name> element with the fully qualified name of the domain object 🍓
  • A <domain:trStatus> element with the state of the most recent transfer request 🔥
  • A <domain:reID> element with the identifier of the client that requested the object transfer 💜
  • A <domain:reDate> element with the date and time the transfer was requested ⭐
  • A <domain:acID> element with the identifier of the client that SHOULD act upon the transfer request 👑
  • A <domain:acDate> element with the date and time of a required or completed response. For a PENDING request, this value is the date and time by which a response is required before the server takes an automated response action. For all other status types, it's the date and time the request was completed 🌈
  • An OPTIONAL <domain:exDate> element with the end of the domain object's validity period, if the <transfer> command caused or causes a change in that validity period 🦋

Here's an example <transfer> query response, bestie:

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:      <domain:trnData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:       domain-1.0.xsd">
S:        <domain:name>example.com</domain:name>
S:        <domain:trStatus>pending</domain:trStatus>
S:        <domain:reID>ClientX</domain:reID>
S:        <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate>
S:        <domain:acID>ClientY</domain:acID>
S:        <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate>
S:        <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
S:      </domain:trnData>
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 <transfer> query command can not be processed for any reason. That's a hard no-skip rule 🚫💀

3.2. EPP Transform Commands ✨

okay this part is about the commands that actually CHANGE things 🔥 EPP gives you five transform commands for domain objects: <create> to make a domain object, <delete> to delete one, <renew> to extend its validity period, <transfer> to manage sponsorship changes, and <update> to change the info attached to a domain object 💅

Transform commands are usually processed and completed in real time 🌸 Server operators MAY receive and process transform commands, but they can hold off on completing the requested action if human or third-party review is needed first. In that situation, the server MUST return a 1001 response code to the client, which basically says "got it, processed, but the requested action is still pending" 🫶 The server MUST also manage the status of the object that's the subject of the command, so it reflects the start and finish of the requested action. Once the action is completed, 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 🎀 no one gets left on read 📬

3.2.1. EPP <create> Command

okay the EPP <create> command is a transform operation that lets a client create a domain object 🧚 Besides the standard EPP command elements, the <create> command MUST contain a <domain:create> element that names the domain namespace and where the domain schema lives. The <domain:create> element has these child elements:

  • A <domain:name> element with the fully qualified name of the domain object to be created 🍓
  • An OPTIONAL <domain:period> element with the initial registration period of the domain object. A server MAY define a default initial registration period if the client doesn't specify one 🌈
  • An OPTIONAL <domain:ns> element with the fully qualified names of the delegated host objects or host attributes (name servers) associated with the domain object, to provide resolution services for the domain. See section 1.1 for a description of the elements used to specify host objects or host attributes 💜 A host object MUST be known to the server before it can be associated with a domain object. Rule of the house!
  • An OPTIONAL <domain:registrant> element with the identifier for the human or organizational social information (contact) object to be associated with the domain object as the object registrant 👑 This object identifier MUST be known to the server before the contact object can be associated with the domain object. The EPP mapping for contact objects is described in [RFC3733] ✨
  • Zero or more OPTIONAL <domain:contact> elements with the identifiers for other contact objects to be associated with the domain object 🦋 Contact object identifiers MUST be known to the server before the contact object can be associated with the domain object.
  • A <domain:authInfo> element with the authorization information to be associated with the domain object 🔒 This mapping includes a password-based authentication mechanism, but the schema allows new mechanisms to be defined in new schemas, so it's giving future-proof 🔮

Here's an 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:      <domain:create
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:        <domain:period unit="y">2</domain:period>
C:        <domain:ns>
C:          <domain:hostObj>ns1.example.com</domain:hostObj>
C:          <domain:hostObj>ns1.example.net</domain:hostObj>
C:        </domain:ns>
C:        <domain:registrant>jd1234</domain:registrant>
C:        <domain:contact type="admin">sh8013</domain:contact>
C:        <domain:contact type="tech">sh8013</domain:contact>
C:        <domain:authInfo>
C:          <domain:pw>2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain: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 <domain:creData> element that names the domain namespace and where the domain schema lives. The <domain:creData> element has these child elements:

  • A <domain:name> element with the fully qualified name of the domain object 🌟
  • A <domain:crDate> element with the date and time the domain object was created 🎂
  • An OPTIONAL <domain:exDate> element with the date and time that marks the end of the domain object's registration period ⏳

Here's an 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:      <domain:creData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:       domain-1.0.xsd">
S:        <domain:name>example.com</domain:name>
S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S:        <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate>
S:      </domain:creData>
S:    </resData>
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 <create> command can not be processed for any reason 🚨 no exceptions, babe 💖

3.2.2. EPP <delete> Command 🗑️✨

okay so the EPP <delete> command is the transform op that lets a client delete a domain object 💅 besides the usual EPP command stuff, the <delete> command MUST contain a <domain:delete> element that names the domain namespace and where the domain schema lives 🎀 that <domain:delete> element has one child:

  • A <domain:name> element that contains the fully qualified name of the domain object to be deleted.

bestie, the big rule here is that a domain object SHOULD NOT be deleted if subordinate host objects are still attached to it 🙈 like, if domain "example.com" exists and host object "ns1.example.com" also exists, then "example.com" SHOULD NOT be deleted until "ns1.example.com" has been either deleted or renamed to exist in a different superordinate domain. it's giving tidy house rules 🧚 a server SHOULD also tell clients that these object relationships exist by sending a 2305 error response code when a <delete> command is attempted and fails because of them. and if you're curious which delegated and subordinate host objects are hanging off a domain, you can check with the <info> query command for that domain object 🔍

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:      <domain:delete
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:      </domain:delete>
C:    </delete>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

when a <delete> command goes through successfully, a server MUST respond with an EPP response that has no <resData> element 🌸

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>

and if a <delete> command can't be processed for any reason, an EPP error response MUST be returned 😭 no exceptions, periodt 💀

3.2.3. EPP <renew> Command 🔁💖

the EPP <renew> command is the transform op that lets a client extend the validity period of a domain object ✨ on top of the standard EPP command elements, the <renew> command MUST contain a <domain:renew> element that identifies the domain namespace and the location of the domain schema. the <domain:renew> element has these child elements:

  • A <domain:name> element that contains the fully qualified name of the domain object whose validity period is to be extended.
  • A <domain:curExpDate> element that contains the date on which the current validity period ends. this value is there so that repeated <renew> commands don't end up giving multiple unanticipated successful renewals 🙅‍♀️
  • An OPTIONAL <domain:period> element that contains the number of units to be added to the registration period of the domain object. the number of units available MAY be subject to limits imposed by the server 🍓

Example <renew> 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:    <renew>
C:      <domain:renew
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:        <domain:curExpDate>2000-04-03</domain:curExpDate>
C:        <domain:period unit="y">5</domain:period>
C:      </domain:renew>
C:    </renew>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

when a <renew> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:renData> element that identifies the domain namespace and the location of the domain schema 🎀 the <domain:renData> element has these child elements:

  • A <domain:name> element that contains the fully qualified name of the domain object.
  • An OPTIONAL <domain:exDate> element that contains the date and time identifying the end of the domain object's registration period 📅

Example <renew> 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:      <domain:renData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:       domain-1.0.xsd">
S:        <domain:name>example.com</domain:name>
S:        <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
S:      </domain:renData>
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 <renew> command can not be processed for any reason. no excuses, bestie 💅

3.2.4. EPP <transfer> Command 🦋🔄

the EPP <transfer> command is the transform op that lets a client manage requests to transfer the sponsorship of a domain object 🫶 besides the standard EPP command elements, the <transfer> command MUST contain a <domain:transfer> element that identifies the domain namespace and the location of the domain schema. the <domain:transfer> element has these child elements:

  • A <domain:name> element that contains the fully qualified name of the domain object for which a transfer request is to be created, approved, rejected, or cancelled.
  • An OPTIONAL <domain:period> element that contains the number of units to be added to the registration period of the domain object at completion of the transfer process. this element can only be used when a transfer is requested, and it MUST be ignored if used otherwise 🙈 the number of units available MAY be subject to limits imposed by the server.
  • A <domain:authInfo> element that contains authorization information associated with the domain object, or authorization information associated with the domain object's registrant or associated contacts. an OPTIONAL "roid" attribute MUST be used to identify the registrant or contact object if and only if the given authInfo is associated with a registrant or contact object, and not the domain object itself 🔑

every EPP <transfer> command MUST contain an "op" attribute that identifies the transfer operation to be performed. the valid values, definitions, and authorizations for all attribute values are defined in [RFC3730] 📚

the big one: transfer of a domain object MUST implicitly transfer all host objects that are subordinate to the domain object 👑 like, if domain object "example.com" is transferred and host object "ns1.example.com" exists, the host object MUST be transferred as part of the "example.com" transfer process. you can see which host objects get transferred by checking the response to an EPP <info> command on the domain object 🧚

Example <transfer> request 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:    <transfer op="request">
C:      <domain:transfer
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:        <domain:period unit="y">1</domain:period>
C:        <domain:authInfo>
C:          <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
C:        </domain:authInfo>
C:      </domain:transfer>
C:    </transfer>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

when a <transfer> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:trnData> element that identifies the domain namespace and the location of the domain schema 🎀 the <domain:trnData> element contains the same child elements defined for a transfer query response.

Example <transfer> 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:      <domain:trnData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:       domain-1.0.xsd">
S:        <domain:name>example.com</domain:name>
S:        <domain:trStatus>pending</domain:trStatus>
S:        <domain:reID>ClientX</domain:reID>
S:        <domain:reDate>2000-06-08T22:00:00.0Z</domain:reDate>
S:        <domain:acID>ClientY</domain:acID>
S:        <domain:acDate>2000-06-13T22:00:00.0Z</domain:acDate>
S:        <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>
S:      </domain:trnData>
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 <transfer> command can not be processed for any reason. ✨

3.2.5. EPP <update> Command

Okay bestie, the EPP <update> command is how a client gets a domain object its glow-up 💅✨ It's a transform operation that lets the client modify the attributes of a domain object. Besides the standard EPP command elements, the <update> command MUST contain a <domain:update> element that identifies the domain namespace and the location of the domain schema 🎀 The <domain:update> element has these child elements:

  • A <domain:name> element that contains the fully qualified name of the domain object you're updating 🌸
  • An OPTIONAL <domain:add> element that contains attribute values to be added to the object 🫶
  • An OPTIONAL <domain:rem> element that contains attribute values to be removed from the object 💀
  • An OPTIONAL <domain:chg> element that contains object attribute values to be changed 🦋

At least one <domain:add>, <domain:rem>, or <domain:chg> element MUST be provided, no cap 🙈 The <domain:add> and <domain:rem> elements have these child elements:

  • An OPTIONAL <domain:ns> element that contains the fully qualified names of the delegated host objects or host attributes (name servers) associated with the domain object, so they can provide resolution services for the domain. See section 1.1 for how to specify host objects or host attributes 👑 A host object MUST be known to the server before it can be associated with a domain object. If host attributes are used to specify name servers, IP address elements aren't needed to identify a name server that's being removed. They can safely be absent or ignored in that situation 🧚
  • Zero or more <domain:contact> elements that contain the identifiers for contact objects to be associated with or removed from the domain object. Contact object identifiers MUST be known to the server before the contact object can be associated with the domain object 🍓
  • Zero or more <domain:status> elements that contain status values to be applied to or removed from the object. When you're specifying a value to be removed, only the attribute value is significant, so the element text doesn't have to match a value for removal 🌈

A <domain:chg> element contains these child elements:

  • A <domain:registrant> element that contains the identifier for the human or organizational social information (contact) object to be associated with the domain object as the object registrant. This object identifier MUST be known to the server before the contact object can be associated with the domain object. An empty element can be used to remove registrant information 💜
  • A <domain:authInfo> element that contains authorization information associated with the domain object. This mapping includes a password-based authentication mechanism, but the schema lets new mechanisms be defined in new schemas 🔐 A <domain:null> element can be used within the <domain:authInfo> element to remove authorization information ✨

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:      <domain:update
C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:       domain-1.0.xsd">
C:        <domain:name>example.com</domain:name>
C:        <domain:add>
C:          <domain:ns>
C:            <domain:hostObj>ns2.example.com</domain:hostObj>
C:          </domain:ns>
C:          <domain:contact type="tech">mak21</domain:contact>
C:          <domain:status s="clientHold"
C:           lang="en">Payment overdue.</domain:status>
C:        </domain:add>
C:        <domain:rem>
C:          <domain:ns>
C:            <domain:hostObj>ns1.example.com</domain:hostObj>
C:          </domain:ns>
C:          <domain:contact type="tech">sh8013</domain:contact>
C:          <domain:status s="clientUpdateProhibited"/>
C:        </domain:rem>
C:        <domain:chg>
C:          <domain:registrant>sh8013</domain:registrant>
C:          <domain:authInfo>
C:            <domain:pw>2BARfoo</domain:pw>
C:          </domain:authInfo>
C:        </domain:chg>
C:      </domain: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 can not be processed for any reason 💀

3.2.6. Offline Review of Requested Actions

Okay so commands get processed by the server in the order the client sends them 📬 The server sends back an immediate response confirming it got and processed the command, but a server operator MAY perform an offline review of requested transform commands before the requested action is completed 🕵️‍♀️ In that situation, the response from the server MUST clearly note that the transform command has been received and processed, but the requested action is pending. The status of the corresponding object MUST clearly reflect processing of the pending action. And the server MUST notify the client when offline processing of the action has been completed 🔔

Examples describing a <create> command that requires offline review are included here, so look closely at the result code and message returned in response to the <create> command 👀

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:      <domain:creData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:       domain-1.0.xsd">
S:        <domain:name>example.com</domain:name>
S:        <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
S:        <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate>
S:      </domain:creData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

After returning this response, the status of the domain object MUST include "pendingCreate" 🌸 The server operator reviews the request offline and tells the client how the review turned out by queuing a service message for retrieval via 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 <domain:panData> element that identifies the domain namespace and the location of the domain schema. The <domain:panData> element has these child elements:

  • A <domain:name> element that contains the fully qualified name of the domain object. The <domain:name> element contains a REQUIRED "paResult" attribute. A positive boolean value means the request has been approved and completed, and a negative boolean value means the request has been denied and the requested action has not been taken ✅❌
  • A <domain:paTRID> element that contains the client transaction identifier and server transaction identifier returned with the original response to process the command. The client transaction identifier is OPTIONAL and will only be returned if the client provided an identifier with the original <create> command 🪪
  • A <domain:paDate> element that contains the date and time describing when review of the requested action was completed 🗓️

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:      <domain:panData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
S:       domain-1.0.xsd">
S:        <domain:name paResult="1">example.com</domain:name>
S:        <domain:paTRID>
S:          <clTRID>ABC-12345</clTRID>
S:          <svTRID>54321-XYZ</svTRID>
S:        </domain:paTRID>
S:        <domain:paDate>1999-04-04T22:00:00.0Z</domain:paDate>
S:      </domain: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, now the schema part 💖 An EPP object mapping is specified in XML Schema notation. This formal syntax is a complete schema representation of the object mapping, so it's suitable for automated validation of EPP XML instances 🤖 The BEGIN and END tags aren't part of the schema. They're just there to mark where the schema starts and ends for URI registration purposes 🎀

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

  <schema targetNamespace="urn:ietf:params:xml:ns:domain-1.0"
          xmlns:domain="urn:ietf:params:xml:ns:domain-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"/>
    <import namespace="urn:ietf:params:xml:ns:host-1.0"
            schemaLocation="host-1.0.xsd"/>

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

okay so this part is the schema doing its thing, basically a big menu of what can go inside every command, bestie 🎀✨ it's giving very organised vibes 💅

     <!--
     Child elements found in EPP commands.
     -->
       <element name="check" type="domain:mNameType"/>
       <element name="create" type="domain:createType"/>
       <element name="delete" type="domain:sNameType"/>
       <element name="info" type="domain:infoType"/>
       <element name="renew" type="domain:renewType"/>
       <element name="transfer" type="domain:transferType"/>
       <element name="update" type="domain:updateType"/>
     <!--
     Child elements of the <create> command.
     -->
       <complexType name="createType">
         <sequence>
           <element name="name" type="eppcom:labelType"/>
           <element name="period" type="domain:periodType"
            minOccurs="0"/>
           <element name="ns" type="domain:nsType"
            minOccurs="0"/>
           <element name="registrant" type="eppcom:clIDType"
            minOccurs="0"/>
           <element name="contact" type="domain:contactType"
            minOccurs="0" maxOccurs="unbounded"/>
           <element name="authInfo" type="domain:authInfoType"/>
         </sequence>
       </complexType>

       <complexType name="periodType">
         <simpleContent>
           <extension base="domain:pLimitType">
             <attribute name="unit" type="domain:pUnitType"
              use="required"/>
           </extension>
         </simpleContent>
       </complexType>

       <simpleType name="pLimitType">
         <restriction base="unsignedShort">
           <minInclusive value="1"/>
           <maxInclusive value="99"/>
         </restriction>
       </simpleType>

       <simpleType name="pUnitType">
         <restriction base="token">
           <enumeration value="y"/>
           <enumeration value="m"/>
         </restriction>
       </simpleType>

       <complexType name="nsType">
         <choice>
           <element name="hostObj" type="eppcom:labelType"
            maxOccurs="unbounded"/>
           <element name="hostAttr" type="domain:hostAttrType"

            maxOccurs="unbounded"/>
         </choice>
       </complexType>
     <!--
     Name servers are either host objects or attributes.
     -->

       <complexType name="hostAttrType">
         <sequence>
           <element name="hostName" type="eppcom:labelType"/>
           <element name="hostAddr" type="host:addrType"
            minOccurs="0" maxOccurs="unbounded"/>
         </sequence>
       </complexType>
     <!--
     If attributes, addresses are optional and follow the
     structure defined in the host mapping.
     -->

       <complexType name="contactType">
         <simpleContent>
           <extension base="eppcom:clIDType">
             <attribute name="type" type="domain:contactAttrType"/>
           </extension>
         </simpleContent>
       </complexType>

       <simpleType name="contactAttrType">
         <restriction base="token">
           <enumeration value="admin"/>
           <enumeration value="billing"/>
           <enumeration value="tech"/>
         </restriction>
       </simpleType>

       <complexType name="authInfoType">
         <choice>
           <element name="pw" type="eppcom:pwAuthInfoType"/>
           <element name="ext" type="eppcom:extAuthInfoType"/>
         </choice>
       </complexType>

     <!--
     Child element of commands that require a single name.
     -->
       <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 <info> command.
     -->
       <complexType name="infoType">
         <sequence>
           <element name="name" type="domain:infoNameType"/>
           <element name="authInfo" type="domain:authInfoType"
            minOccurs="0"/>
         </sequence>
       </complexType>

       <complexType name="infoNameType">
         <simpleContent>
           <extension base = "eppcom:labelType">
             <attribute name="hosts" type="domain:hostsType"
              default="all"/>
           </extension>
         </simpleContent>
       </complexType>

       <simpleType name="hostsType">
         <restriction base="token">
           <enumeration value="all"/>
           <enumeration value="del"/>
           <enumeration value="none"/>
           <enumeration value="sub"/>
         </restriction>
       </simpleType>

     <!--
     Child elements of the <renew> command.
     -->
       <complexType name="renewType">
         <sequence>
           <element name="name" type="eppcom:labelType"/>
           <element name="curExpDate" type="date"/>
           <element name="period" type="domain:periodType"
            minOccurs="0"/>
         </sequence>
       </complexType>

     <!--
     Child elements of the <transfer> command.
     -->
       <complexType name="transferType">
         <sequence>
           <element name="name" type="eppcom:labelType"/>
           <element name="period" type="domain:periodType"
            minOccurs="0"/>
           <element name="authInfo" type="domain:authInfoType"
            minOccurs="0"/>
         </sequence>
       </complexType>

     <!--
     Child elements of the <update> command.
     -->
       <complexType name="updateType">
         <sequence>
           <element name="name" type="eppcom:labelType"/>
           <element name="add" type="domain:addRemType"
            minOccurs="0"/>
           <element name="rem" type="domain:addRemType"
            minOccurs="0"/>
           <element name="chg" type="domain:chgType"
            minOccurs="0"/>
         </sequence>
       </complexType>

     <!--
     Data elements that can be added or removed.
     -->
       <complexType name="addRemType">
         <sequence>
           <element name="ns" type="domain:nsType"
            minOccurs="0"/>
           <element name="contact" type="domain:contactType"
            minOccurs="0" maxOccurs="unbounded"/>
           <element name="status" type="domain:statusType"
            minOccurs="0" maxOccurs="11"/>
         </sequence>
       </complexType>

     <!--
     Data elements that can be changed.
     -->
       <complexType name="chgType">
         <sequence>
           <element name="registrant" type="domain:clIDChgType"
            minOccurs="0"/>
           <element name="authInfo" type="domain:authInfoChgType"
            minOccurs="0"/>
         </sequence>
       </complexType>

     <!--
     Allow the registrant value to be nullified by changing the
     minLength restriction to "0".
     -->
       <simpleType name="clIDChgType">
         <restriction base="token">
           <minLength value="0"/>
           <maxLength value="16"/>
         </restriction>
       </simpleType>

     <!--
     Allow the authInfo value to be nullified by including an
     empty element within the choice.
     -->
       <complexType name="authInfoChgType">
         <choice>
           <element name="pw" type="eppcom:pwAuthInfoType"/>
           <element name="ext" type="eppcom:extAuthInfoType"/>
           <element name="null"/>
         </choice>
       </complexType>

     <!--
     Child response elements.
     -->
       <element name="chkData" type="domain:chkDataType"/>
       <element name="creData" type="domain:creDataType"/>
       <element name="infData" type="domain:infDataType"/>
       <element name="panData" type="domain:panDataType"/>
       <element name="renData" type="domain:renDataType"/>
       <element name="trnData" type="domain:trnDataType"/>

     <!--
     <check> response elements.
     -->
       <complexType name="chkDataType">

         <sequence>
           <element name="cd" type="domain:checkType"
            maxOccurs="unbounded"/>
         </sequence>
       </complexType>

       <complexType name="checkType">
         <sequence>
           <element name="name" type="domain: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"/>
           <element name="exDate" type="dateTime"
            minOccurs="0"/>
         </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="domain:statusType"
            minOccurs="0" maxOccurs="11"/>
           <element name="registrant" type="eppcom:clIDType"
            minOccurs="0"/>
           <element name="contact" type="domain:contactType"
            minOccurs="0" maxOccurs="unbounded"/>

           <element name="ns" type="domain:nsType"
            minOccurs="0"/>
           <element name="host" type="eppcom:labelType"
            minOccurs="0" maxOccurs="unbounded"/>
           <element name="clID" type="eppcom:clIDType"/>
           <element name="crID" type="eppcom:clIDType"
            minOccurs="0"/>
           <element name="crDate" type="dateTime"
            minOccurs="0"/>
           <element name="upID" type="eppcom:clIDType"
            minOccurs="0"/>
           <element name="upDate" type="dateTime"
            minOccurs="0"/>
           <element name="exDate" type="dateTime"
            minOccurs="0"/>
           <element name="trDate" type="dateTime"
            minOccurs="0"/>
           <element name="authInfo" type="domain:authInfoType"
            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="domain:statusValueType"
              use="required"/>
             <attribute name="lang" type="language"
              default="en"/>
           </extension>
         </simpleContent>
       </complexType>

       <simpleType name="statusValueType">
         <restriction base="token">
           <enumeration value="clientDeleteProhibited"/>
           <enumeration value="clientHold"/>
           <enumeration value="clientRenewProhibited"/>
           <enumeration value="clientTransferProhibited"/>
           <enumeration value="clientUpdateProhibited"/>
           <enumeration value="inactive"/>
           <enumeration value="ok"/>
           <enumeration value="pendingCreate"/>
           <enumeration value="pendingDelete"/>
           <enumeration value="pendingRenew"/>
           <enumeration value="pendingTransfer"/>
           <enumeration value="pendingUpdate"/>
           <enumeration value="serverDeleteProhibited"/>
           <enumeration value="serverHold"/>
           <enumeration value="serverRenewProhibited"/>
           <enumeration value="serverTransferProhibited"/>
           <enumeration value="serverUpdateProhibited"/>
         </restriction>
       </simpleType>

ngl the status list at the bottom is giving a whole roster of states 🧚💜

5. Internationalization Considerations 🌍

okay so EPP is written in XML, which means it comes with built-in support for Unicode 💅 It can use the Unicode character set and its more compact form, UTF-8, which is honestly so efficient. Conformant XML processors recognize both UTF-8 and UTF-16 [RFC2781]. XML can use other character encodings if you name them in an encoding attribute on the <?xml?> declaration, but UTF-8 is RECOMMENDED wherever parser encoding support is inconsistent. bestie, trust me on this one 🫶

All date-time values sent through EPP MUST be expressed in Universal Coordinated Time, using the Gregorian calendar. XML Schema lets you use time zone identifiers for offsets from the zero meridian, but that option MUST NOT be used with EPP. ngl this is a strict rule, so no sneaky offsets 🙈 Date-times MUST use the extended form defined in [RFC3339], with upper case "T" and "Z" characters. XML Schema doesn't support truncated date-time forms or lower case "T" and "Z" characters, so this is the only way to make it work ✨

This document needs domain and host name syntax as specified in [RFC952] as updated by [RFC1123]. At the time of writing, RFC 3490 [RFC3490] describes a way to use certain ASCII name labels to represent non-ASCII name labels. Those conformance requirements might change as the work on internationalized domain names keeps progressing 🌸

6. IANA Considerations 🦋

This document uses URNs to describe XML namespaces and XML schemas, following a registry mechanism described in [RFC3688]. The IANA has registered two URI assignments, and they're iconic 👑

Registration request for the domain namespace:

  • URI: urn:ietf:params:xml:ns:domain-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 domain XML schema:

  • URI: urn:ietf:params:xml:schema:domain-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 this section is SERIOUS, so pay attention bestie 😭

Authorization information, as described in section 2.6, is REQUIRED to create a domain object. This information is also used in some query and transfer operations as an extra way to check that a client is allowed to run the command. If authorization information gets disclosed by accident, that can lead to unauthorized transfer operations and unauthorized release of information. Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption mechanisms so it stays private 🔥

The object mapping in this document doesn't provide any other security services, and it doesn't add any other considerations beyond what's covered in [RFC3730] and the protocol layers EPP runs on. Not me having to double-check that 😤

8. Acknowledgements 🫶

This document started life as an individual submission Internet-Draft. The provreg working group later adopted it as a working group document and gave it many invaluable comments and suggested improvements. The author would like to shout out the WG chairs, Edward Lewis and Jaap Akkerhuis, for their process and editorial contributions 👏

A bunch of people gave specific suggestions that ended up in this document, and they're all iconic: Joe Abley, Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, Asbjorn Steira, Bruce Tonkin, and Rick Wesson 💖

9. References 📚

9.1. Normative References

  • [RFC952]: Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet Host Table Specification", RFC 952, October 1985.
  • [RFC1123]: Braden, R., Ed., "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.
  • [RFC3688]: Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
  • [RFC3730]: Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
  • [RFC3732]: Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", RFC 3732, March 2004.
  • [RFC3733]: Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", RFC 3733, 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

  • [RFC2781]: Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
  • [RFC3490]: Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.

10. Author's Address 🎀

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 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 on 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 on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for implementers or users to use these proprietary rights can be obtained from the IETF online 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 needed to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org 🦋

Acknowledgement

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

📦 where this page comes from