RFC 3733

Extensible Provisioning Protocol (EPP) Contact Mapping

📅 published March 2004, from ietf

RFC 3733: Extensible Provisioning Protocol (EPP) Contact Mapping 🦋✨

Okay bestie, this one is by S. Hollenbeck from VeriSign, Inc., dated March 2004, and it's on the Standards Track 🔥. It's a "Network Working Group" doc, and the header doesn't list any "Obsoletes" or "Updates" lines, so it isn't replacing or patching anything else 💅. It's a mapping for EPP, the Extensible Provisioning Protocol.

Status of this Memo 🌸

This document describes an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For where this protocol stands on the standardization ladder, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💖.

Copyright Notice 🎀

Abstract 🦋

So this doc describes an EPP mapping for provisioning and managing individual or organizational social information identifiers (called "contacts") that live in a shared central repository 🗂️. It's specified in Extensible Markup Language (XML), and it defines the EPP command syntax and semantics as they apply to contacts. Iconic 👑.

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
    1.1.  Conventions Used In This Document. . . . . . . . . . . .  2
2.  Object Attributes. . . . . . . . . . . . . . . . . . . . . . .  3
    2.1.  Contact and Client Identifiers . . . . . . . . . . . . .  3
    2.2.  Status Values. . . . . . . . . . . . . . . . . . . . . .  3
    2.3.  Individual and Organizational Names. . . . . . . . . . .  5
    2.4.  Address. . . . . . . . . . . . . . . . . . . . . . . . .  5
          2.4.1.  Street, City, and State or Province. . . . . . .  5
          2.4.2.  Postal Code. . . . . . . . . . . . . . . . . . .  5
          2.4.3.  Country. . . . . . . . . . . . . . . . . . . . .  5
    2.5.  Telephone Numbers. . . . . . . . . . . . . . . . . . . .  5
    2.6.  Email Addresses. . . . . . . . . . . . . . . . . . . . .  6
    2.7.  Dates and Times. . . . . . . . . . . . . . . . . . . . .  6
    2.8.  Authorization Information. . . . . . . . . . . . . . . .  6
    2.9.  Disclosure of Data Elements and Attributes . . . . . . .  6
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 . . . . . . . . . . 14
    3.2.  EPP Transform Commands . . . . . . . . . . . . . . . . . 16
          3.2.1.  EPP <create> Command . . . . . . . . . . . . . . 17
          3.2.2.  EPP <delete> Command . . . . . . . . . . . . . . 20
          3.2.3.  EPP <renew> Command  . . . . . . . . . . . . . . 21
          3.2.4.  EPP <transfer> Command.  . . . . . . . . . . . . 21
          3.2.5.  EPP <update> Command.  . . . . . . . . . . . . . 23
          3.2.6.  Offline Review of Requested Actions. . . . . . . 26
4.  Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 29
5.  Internationalization Considerations  . . . . . . . . . . . . . 37
6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 38
7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 38
8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
    9.1.  Normative References . . . . . . . . . . . . . . . . . . 39
    9.2.  Informative References . . . . . . . . . . . . . . . . . 39
10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 40
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 41

1. Introduction ✨

This doc is all about a personal and organizational identifier mapping for version 1.0 of EPP 💖. It's written in XML 1.0 (see [XML]) and uses XML Schema notation (see [XMLS-1] and [XMLS-2]).

[RFC3730] covers the complete picture of EPP command and response structures 📚. You really need a solid grip on the base protocol spec before this mapping makes sense, so go read that first, bestie 🙈.

XML is case sensitive 🔠. Unless stated otherwise, XML specs and examples in this document MUST be interpreted in the character case they're presented in, so you can build a conforming implementation 💅.

1.1. 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 whitespace in examples are only there to show how elements relate. They are NOT a REQUIRED feature of this protocol, so don't panic if your spacing looks different 🦋.

2. Object Attributes 🎀

An EPP contact 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 these attribute values is in the "Formal Syntax" section of this doc, plus the appropriate normative references 🔥.

2.1. Contact and Client Identifiers 🔑

Every EPP contact gets a server-unique identifier 💖. Contact identifiers are character strings with a specified minimum length, a specified maximum length, and a specified format 📏. They use the "clIDType" client identifier syntax from [RFC3730] ✨.

2.2. Status Values 🚦

A contact object MUST always have at least one associated status value 💅. Status values can only be set by the client that sponsors the contact object, and by the server where the object lives 🏠. A client can change the status of a contact object with the EPP <update> command 🔄. Each status value MAY come with a string of human-readable text explaining why the status was applied 📝.

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 taken by a server operator 🌸.

Status values a client can add or remove are prefixed with "client" 💜. The ones a server can add or remove are prefixed with "server" 🧚. Status values that don't start with either "client" or "server" are server-managed 👑.

Status Value Descriptions:

clientDeleteProhibited, serverDeleteProhibited

Requests to delete 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. 🚫

linked

The contact object has at least one active association with another object, like a domain object 🔗. Servers SHOULD provide services to figure out existing object associations ✨.

ok

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

pendingCreate, pendingDelete, 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 all sorts of reasons, like human review or third-party action 🕵️. A processed transform command whose requested action is pending gets response code 1001 🎫.

With one exception, transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status is set 🙅‍♀️. The only exception is that a <transfer> command to approve, reject, or cancel a transfer MAY be processed while an object is in "pendingTransfer" status 💫.

When the requested action is complete, the pendingCreate, pendingDelete, 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" 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 🙅.

"pendingTransfer" status MUST NOT be combined with either "clientTransferProhibited" or "serverTransferProhibited" 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.3. Individual and Organizational Names 🏷️

Individual and organizational names tied to a contact are represented as character strings 🎀. These strings have a specified minimum and maximum length 📏. Names MAY be provided in both UTF-8 [RFC2279] and a subset of UTF-8 that can be represented in 7-bit ASCII, depending on local needs 🌍.

2.4. Address 🏡

Every contact has associated postal address info 📮. A postal address contains OPTIONAL street info, city info, OPTIONAL state/province info, an OPTIONAL postal code, and a country identifier 🧩. Address info MAY be provided in both UTF-8 and a subset of UTF-8 representable in 7-bit ASCII, depending on local needs 🌸.

2.4.1. Street, City, and State or Province 🏙️

Contact street, city, and state or province info is represented with character strings 💅. These strings have a specified minimum length and a specified maximum length 📏.

2.4.2. Postal Code 📬

Contact postal codes are represented as character strings 💌. These strings have a specified minimum length and a specified maximum length 📏.

2.4.3. Country 🌎

Contact country identifiers use the two-character identifiers specified in [ISO3166] 🗺️.

2.5. Telephone Numbers ☎️

The contact telephone number structure comes from structures defined in [E164a] 📞. Telephone numbers in this mapping are character strings that MUST begin with a plus sign (+, ASCII value 0x002B), followed by a country code defined in [E164b], followed by a dot (., ASCII value 0x002E), followed by a sequence of digits representing the phone number 🔢. There's an optional x attribute for extension info 🧚.

2.6. Email Addresses 💌

Email address syntax is defined in [RFC2822] ✉️. This mapping doesn't prescribe minimum or maximum lengths for the character strings used to represent email addresses 🦋.

2.7. 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 uppercase "T" and "Z" characters as defined in [RFC3339], MUST be used to represent date-time values 💖. XML Schema doesn't support truncated date-time forms or lowercase "T" and "Z" characters, so that's why 🙈.

Part 1 of 8 done 🫶💫 more parts coming, stay tuned bestie 🧚🎀

2.8. Authorization Information 🔐

Okay so, authorization information is attached to contact objects to help make transfers happen smoothly 🦋. It gets assigned the moment a contact object is created, and it might get updated later (glow-ups are allowed ✨). This spec describes password-based authorization information, but other mechanisms are literally possible too, so don't lock your brain into just passwords, bestie 💜

2.9. Disclosure of Data Elements and Attributes 🙈

Okay this part is giving privacy queen energy 👑. The EPP core protocol says a server operator has to announce its data collection policies to clients (see section 2.4 of [RFC3730]). On top of that, this mapping includes data elements that let a client spot the stuff that needs special handling from the server operator, so it can either allow or restrict disclosure to third parties 🫶.

A server operator announces a default disclosure policy when it sets up a session with a client 🎀. When an object gets created or updated, the client can list the contact attributes that need exceptional disclosure handling with an OPTIONAL <contact:disclose> element 💅. Once it's set, the disclosure preferences can be checked with a contact information query 🔍. A server operator MUST reject any transaction that asks for disclosure practices that don't match the announced data collection policy, and it does that with a 2308 error response code 🙅‍♀️. Not allowed, periodt.

If it's there, the <contact:disclose> element MUST contain a "flag" attribute 🚩. The "flag" attribute holds an XML Schema boolean value. A value of "true" or "1" (decimal one) means the client wants to allow disclosure of the specified elements as an exception to the stated data collection policy 🌸. A value of "false" or "0" (decimal zero) means the client wants to NOT allow disclosure of those elements as an exception to the stated policy 🙈.

The <contact:disclose> element MUST contain at least one of the following child elements 🧚:

<contact:name type="int">
<contact:name type="loc">
<contact:org type="int">
<contact:org type="loc">
<contact:addr type="int">
<contact:addr type="loc">
<contact:voice>
<contact:fax>
<contact:email>

Example <contact:disclose> element, flag="0" 🍓:

<contact:disclose flag="0">
  <contact:email>
  <contact:voice>
</contact:disclose>

In this example, the contact email address and voice telephone number can not be disclosed 🔒. Everything else gets handled by the server's data collection policy, so it's business as usual for those.

Example <contact:disclose> element, flag="1" 🦋:

<contact:disclose flag="1">
  <contact:name type="int">
  <contact:org type="int">
  <contact:addr type="int">
</contact:disclose>

In this one, the internationalized contact name, organization, and address info CAN be disclosed 🌈. Again, everything else follows the server's data collection policy.

Client identification features from the EPP <login> command, along with contact authorization information, are what decide whether a client is allowed to run contact information query commands 🔑. Those same features also decide whether a client is allowed to receive data that's otherwise marked for non-disclosure in a query response 👀. Main character energy, but make it secure 💜.

3. EPP Command mapping 💅

A detailed rundown of the EPP syntax and semantics lives in [RFC3730] 📖. The command mappings here are specifically for provisioning and managing contact objects via EPP, so that's the lane we're staying in 🛣️.

3.1. EPP Query Commands 🔍

EPP gives us three commands to retrieve contact information 🎁. There's <check>, which figures out if a contact object can be provisioned within a repository. There's <info>, which pulls up the detailed info tied to a contact object. And there's <transfer>, which gets the transfer status info for a contact object 🦋.

3.1.1. EPP <check> Command ✅

The EPP <check> command is used to find out if an object can be provisioned within a repository 🕵️‍♀️. It's basically a hint that helps a client guess whether provisioning an object with the <create> command will work out, because provisioning requirements are ultimately up to server policy, so no guarantees, bestie 🙃.

In addition to the standard EPP command elements, the <check> command MUST contain a <contact:check> element that identifies the contact namespace and where the contact schema lives 📦. The <contact:check> element has these child elements:

One or more <contact:id> elements, each holding the server-unique identifier of a contact object 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:      <contact:check
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
C:       contact-1.0.xsd">
C:        <contact:id>sh8013</contact:id>
C:        <contact:id>sah8013</contact:id>
C:        <contact:id>8013sah</contact:id>
C:      </contact: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 <contact:chkData> element that identifies the contact namespace and where the contact schema lives 🎉. The <contact:chkData> element holds one or more <contact:cd> elements, and each of those contains these child elements:

A <contact:id> element that identifies the queried object 🎯. This element MUST contain an "avail" attribute, and its value tells you whether the object is available (can it be provisioned or not) at the moment the <check> command finished. A value of "1" or "true" means the object can be provisioned ✅. A value of "0" or "false" means it can not be provisioned ❌.
An OPTIONAL <contact:reason> element that MAY be provided when an object can not be provisioned 🤷‍♀️. If it's there, it holds server-specific text that helps explain why the object can't be provisioned. That text MUST be written in the response language that was previously negotiated with the client 🗣️. An OPTIONAL "lang" attribute MAY be present to identify the language, but only if the negotiated value is something other than the default value of "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:      <contact:chkData
S:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
S:       contact-1.0.xsd">
S:        <contact:cd>
S:          <contact:id avail="1">sh8013</contact:id>
S:        </contact:cd>
S:        <contact:cd>
S:          <contact:id avail="0">sah8013</contact:id>
S:          <contact:reason>In use</contact:reason>
S:        </contact:cd>
S:        <contact:cd>
S:          <contact:id avail="1">8013sah</contact:id>
S:        </contact:cd>
S:      </contact: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, no excuses, no "it was a vibe" 💀.

3.1.2. EPP <info> Command ✨

okay so the EPP <info> command is how you ask the server for everything it knows about a contact object 🔍 Besides the usual EPP command stuff, the <info> command MUST contain a <contact:info> element that says which contact namespace you're using and where the contact schema lives 💅 The <contact:info> element has these child elements:

A <contact:id> element that holds the server-unique identifier of the contact object you want to query 🎀
An OPTIONAL <contact:authInfo> element that holds authorization info for the contact object. If you leave this out, or if the auth info is invalid, server policy decides whether the command gets rejected or whether the server still sends back the response info to you 🤷‍♀️

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:      <contact:info
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
C:       contact-1.0.xsd">
C:        <contact:id>sh8013</contact:id>
C:        <contact:authInfo>
C:          <contact:pw>2fooBAR</contact:pw>
C:        </contact:authInfo>
C:      </contact:info>
C:    </info>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

when an <info> command gets processed successfully, the EPP <resData> element MUST contain a child <contact:infData> element that says which contact namespace and schema location it's using 🦋 The <contact:infData> element is packed with goodies:

A <contact:id> element with the server-unique identifier of the contact object 🌸
A <contact:roid> element with the Repository Object IDentifier that got assigned to the contact object when it was created 💜
One or more <contact:status> elements that describe the status of the contact object 🚦
One or two <contact:postalInfo> elements with postal address info 📮 You get two so the address can show up in both internationalized and localized forms, and a "type" attribute tells you which one is which. If you give an internationalized form (type="int"), the element content MUST be represented in a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set. If you give a localized form (type="loc"), the element content MAY be represented in unrestricted UTF-8 🌈 The <contact:postalInfo> element has these child elements:
- A <contact:name> element with the name of the individual or role the contact represents 🧚
- An OPTIONAL <contact:org> element with the name of the organization the contact is affiliated with 🏢
- A <contact:addr> element with address info for the contact. A <contact:addr> element has these child elements:
  - One, two, or three OPTIONAL <contact:street> elements with the contact's street address 🛣️
  - A <contact:city> element with the contact's city 🌆
  - An OPTIONAL <contact:sp> element with the contact's state or province 🗺️
  - An OPTIONAL <contact:pc> element with the contact's postal code 📬
  - A <contact:cc> element with the contact's country code 🌍
An OPTIONAL <contact:voice> element with the contact's voice telephone number ☎️
An OPTIONAL <contact:fax> element with the contact's facsimile telephone number 📠
A <contact:email> element with the contact's email address 💌
A <contact:clID> element with the identifier of the sponsoring client 👑
A <contact:crID> element with the identifier of the client that created the contact object 🐣
A <contact:crDate> element with the date and time the contact object was created ⏰
A <contact:upID> element with the identifier of the client that last updated the contact object. This element MUST NOT be present if the contact has never been modified 🙈
A <contact:upDate> element with the date and time of the most recent contact object modification. This element MUST NOT be present if the contact object has never been modified 🕰️
A <contact:trDate> element with the date and time of the most recent successful contact object transfer. This element MUST NOT be provided if the contact object has never been transferred 🔁
A <contact:authInfo> element with authorization info for the contact object. This element MUST NOT be provided if the querying client is not the current sponsoring client 🔒
An OPTIONAL <contact:disclose> element that marks the elements needing special handling from the server operator, to either allow or restrict disclosure to third parties 🫣 See section 2.9. for a description of the child elements inside <contact:disclose> ✨

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:      <contact:infData
S:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
S:       contact-1.0.xsd">
S:        <contact:id>sh8013</contact:id>
S:        <contact:roid>SH8013-REP</contact:roid>
S:        <contact:status s="linked"/>
S:        <contact:status s="clientDeleteProhibited"/>
S:        <contact:postalInfo type="int">
S:          <contact:name>John Doe</contact:name>
S:          <contact:org>Example Inc.</contact:org>
S:          <contact:addr>
S:            <contact:street>123 Example Dr.</contact:street>
S:            <contact:street>Suite 100</contact:street>
S:            <contact:city>Dulles</contact:city>
S:            <contact:sp>VA</contact:sp>
S:            <contact:pc>20166-6503</contact:pc>
S:            <contact:cc>US</contact:cc>
S:          </contact:addr>
S:        </contact:postalInfo>
S:        <contact:voice x="1234">+1.7035555555</contact:voice>
S:        <contact:fax>+1.7035555556</contact:fax>
S:        <contact:email>jdoe@example.com</contact:email>
S:        <contact:clID>ClientY</contact:clID>
S:        <contact:crID>ClientX</contact:crID>
S:        <contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate>
S:        <contact:upID>ClientX</contact:upID>
S:        <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
S:        <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate>
S:        <contact:authInfo>
S:          <contact:pw>2fooBAR</contact:pw>
S:        </contact:authInfo>
S:        <contact:disclose flag="0">
S:          <contact:voice/>
S:          <contact:email/>
S:        </contact:disclose>
S:      </contact:infData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

⚠️ bestie, this one's a must: an EPP error response MUST be returned if an <info> command can not be processed for any reason 😭 no exceptions, no excuses 💀

3.1.3. EPP <transfer> Query Command ✨

okay so the EPP <transfer> command is the query operation that lets a client check the real-time status of pending AND completed transfer requests 👀. besides the usual EPP command elements, the <transfer> command MUST have an "op" attribute set to "query", plus a <contact:transfer> element that names the contact namespace and where the contact schema lives 🎀. that <contact:transfer> element MUST include these children:

A <contact:id> element with the server-unique identifier of the contact object you're querying 🫶
An OPTIONAL <contact:authInfo> element with authorization info tied to the contact object. if it's left out or the auth info is invalid, server policy decides whether the command gets rejected or the response info still goes back to the client 💅

Here's an example <transfer> query 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="query">
C:      <contact:transfer
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
C:       contact-1.0.xsd">
C:        <contact:id>sh8013</contact:id>
C:        <contact:authInfo>
C:          <contact:pw>2fooBAR</contact:pw>
C:        </contact:authInfo>
C:      </contact:transfer>
C:    </transfer>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

when a <transfer> query command gets processed successfully, the EPP <resData> element MUST have a child <contact:trnData> element that names the contact namespace and the contact schema location 💖. the <contact:trnData> element holds these child elements:

A <contact:id> element with the server-unique identifier for the queried contact 🍓
A <contact:trStatus> element with the state of the most recent transfer request 🦋
A <contact:reID> element with the identifier of the client that requested the object transfer 🧚
A <contact:reDate> element with the date and time the transfer was requested 🌸
A <contact:acID> element with the identifier of the client that SHOULD act upon the transfer request 👑
A <contact:acDate> element with the date and time of a required or completed response. for a pending request, this is the date and time by which a response is required before an automated response action SHOULD be taken by the server. for every other status type, it's the date and time the request was completed 🌈

Here's an example <transfer> query 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:      <contact:trnData
S:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
S:       contact-1.0.xsd">
S:        <contact:id>sh8013</contact:id>
S:        <contact:trStatus>pending</contact:trStatus>
S:        <contact:reID>ClientX</contact:reID>
S:        <contact:reDate>2000-06-06T22:00:00.0Z</contact:reDate>
S:        <contact:acID>ClientY</contact:acID>
S:        <contact:acDate>2000-06-11T22:00:00.0Z</contact:acDate>
S:      </contact:trnData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

and the big rule: an EPP error response MUST be returned if a <transfer> query command can not be processed for any reason 🚨.

3.2. EPP Transform Commands 🔥

EPP gives you four commands to transform contact object information. <create> makes a contact object, <delete> removes one, <transfer> manages sponsorship changes for a contact object, and <update> changes the info attached to a contact object 💅. this document does not define a mapping for the EPP <renew> command, so that one's a no-show here 🙈.

transform commands are usually 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 needed before it can be finished. 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 the command is about, so it reflects when the action starts and when it finishes 🦋. 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 🫶.

3.2.1. EPP <create> Command ✨

the EPP <create> command is the transform operation that lets a client create a contact object 🎀. on top of the standard EPP command elements, the <create> command MUST contain a <contact:create> element that names the contact namespace and where the contact schema lives. the <contact:create> element holds these child elements:

A <contact:id> element with the desired server-unique identifier for the contact being created 🍓
One or two <contact:postalInfo> elements with postal address info. two are allowed so the address can be given in both internationalized and localized forms, and a "type" attribute tells them apart 🌍. if you give an internationalized form (type="int"), the element content MUST be represented in a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set. if you give a localized form (type="loc"), the element content MAY be represented in unrestricted UTF-8 💜. the <contact:postalInfo> element holds these child elements:
- A <contact:name> element with the name of the individual or role the contact represents 🧚
- An OPTIONAL <contact:org> element with the name of the organization the contact is affiliated with 🏢
- A <contact:addr> element with address info for the contact. the <contact:addr> element holds these child elements:
  - One, two, or three OPTIONAL <contact:street> elements with the contact's street address 🛣️
  - A <contact:city> element with the contact's city 🌆
  - An OPTIONAL <contact:sp> element with the contact's state or province 🗺️
  - An OPTIONAL <contact:pc> element with the contact's postal code 📮
  - A <contact:cc> element with the contact's country code 🌏
An OPTIONAL <contact:voice> element with the contact's voice telephone number 📞
An OPTIONAL <contact:fax> element with the contact's facsimile telephone number 📠
A <contact:email> element with the contact's email address 💌
A <contact:authInfo> element with authorization info to attach to the contact object. this mapping includes a password-based authentication mechanism, but the schema lets new mechanisms be defined in new schemas 🔐
An OPTIONAL <contact:disclose> element that lets a client flag elements needing exceptional server operator handling, to allow or restrict disclosure to third parties 🙈. check section 2.9 for what the child elements inside <contact:disclose> do 💅

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:      <contact:create
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
C:       contact-1.0.xsd">
C:        <contact:id>sh8013</contact:id>
C:        <contact:postalInfo type="int">
C:          <contact:name>John Doe</contact:name>
C:          <contact:org>Example Inc.</contact:org>
C:          <contact:addr>
C:            <contact:street>123 Example Dr.</contact:street>
C:            <contact:street>Suite 100</contact:street>
C:            <contact:city>Dulles</contact:city>
C:            <contact:sp>VA</contact:sp>
C:            <contact:pc>20166-6503</contact:pc>
C:            <contact:cc>US</contact:cc>
C:          </contact:addr>
C:        </contact:postalInfo>
C:        <contact:voice x="1234">+1.7035555555</contact:voice>
C:        <contact:fax>+1.7035555556</contact:fax>
C:        <contact:email>jdoe@example.com</contact:email>
C:        <contact:authInfo>
C:          <contact:pw>2fooBAR</contact:pw>
C:        </contact:authInfo>
C:        <contact:disclose flag="0">
C:          <contact:voice/>
C:          <contact:email/>
C:        </contact:disclose>
C:      </contact:create>
C:    </create>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

when a <create> command gets processed successfully, the EPP <resData> element MUST have a child <contact:creData> element that names the contact namespace and where the contact schema lives 🎉. the <contact:creData> element holds these child elements:

A <contact:id> element with the server-unique identifier for the created contact 💖
A <contact:crDate> element with the date and time the contact object was created 🕰️

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

and the rule for errors: an EPP error response MUST be returned if a <create> command can not be processed for any reason 🚫.

3.2.2. EPP `<delete>` Command 💅

okay bestie, the EPP <delete> command is a transform operation that lets a client delete a contact object 💀 besides the usual EPP command stuff, the <delete> command MUST contain a <contact:delete> element that names the contact namespace and where the contact schema lives. The <contact:delete> element MUST contain this child element:

A <contact:id> element that holds the server-unique identifier of the contact object to be deleted.

A contact object SHOULD NOT be deleted if it's associated with other known objects 🙈 and an associated contact SHOULD NOT be deleted until those associations have been broken. A server SHOULD notify clients about object relationships when a <delete> command is attempted and fails because of existing object relationships. it's all about not leaving broken relationships behind 🫶

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:      <contact:delete
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
C:       contact-1.0.xsd">
C:        <contact:id>sh8013</contact:id>
C:      </contact: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. ✨

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. no silent failures, periodt 💀

3.2.3. EPP `<renew>` Command 🌸

renewal semantics just don't apply to contact objects 🙅‍♀️ so there is no mapping defined for the EPP <renew> command. nothing to renew here, bestie 🦋

3.2.4. EPP `<transfer>` Command 🔁

the EPP <transfer> command is a transform operation that lets a client manage requests to transfer the sponsorship of a contact object 👑 besides the usual EPP command stuff, the <transfer> command MUST contain a <contact:transfer> element that names the contact namespace and where the contact schema lives. The <contact:transfer> element contains these child elements:

A <contact:id> element that holds the server-unique identifier of the contact object for which a transfer request is to be created, approved, rejected, or cancelled.
A <contact:authInfo> element that holds the authorization information associated with the contact object.

Every EPP <transfer> command MUST contain an op attribute that identifies the transfer operation to be performed, as defined in [RFC3730]. the op attribute is the whole vibe of which action you're doing ✨

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:      <contact:transfer
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
C:       contact-1.0.xsd">
C:        <contact:id>sh8013</contact:id>
C:        <contact:authInfo>
C:          <contact:pw>2fooBAR</contact:pw>
C:        </contact:authInfo>
C:      </contact: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 <contact:trnData> element that names the contact namespace and where the contact schema lives. The <contact: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="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <contact:trnData
S:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
S:       contact-1.0.xsd">
S:        <contact:id>sh8013</contact:id>
S:        <contact:trStatus>pending</contact:trStatus>
S:        <contact:reID>ClientX</contact:reID>
S:        <contact:reDate>2000-06-08T22:00:00.0Z</contact:reDate>
S:        <contact:acID>ClientY</contact:acID>
S:        <contact:acDate>2000-06-13T22:00:00.0Z</contact:acDate>
S:      </contact: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. errors always get a response, no ghosting allowed 🌈

3.2.5. EPP `<update>` Command 🦋

okay bestie, this is the <update> command, and it's a transform operation, which just means it CHANGES things 💅 It lets a client modify the attributes of a contact object. Along with the usual EPP command stuff, the <update> command MUST contain a <contact:update> element that names the contact namespace and where the contact schema lives. The <contact:update> element has these child elements:

A <contact:id> element that holds the server-unique identifier of the contact object you want to update.
An OPTIONAL <contact:add> element with attribute values to add to the object.
An OPTIONAL <contact:rem> element with attribute values to remove from the object.
An OPTIONAL <contact:chg> element with object attribute values to change.

At least one <contact:add>, <contact:rem>, or <contact:chg> element MUST be provided, no skipping all three 🙈 The <contact:add> and <contact:rem> elements have these child elements:

One or more <contact:status> elements holding status values to attach to, or remove from, the object. When you're removing a value, only the attribute value matters. The element text doesn't have to match anything for removal to work ✨

A <contact:chg> element has the following OPTIONAL child elements. At least one of them MUST be present:

One or two <contact:postalInfo> elements with postal address info. Two are allowed so the address can be given in both internationalized and localized forms, and a "type" attribute tells you which is which. If you give an internationalized form (type="int"), the element content MUST be in a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set. If you give a localized form (type="loc"), the element content MAY be in unrestricted UTF-8 🌈 The <contact:postalInfo> element has these OPTIONAL child elements:
- A <contact:name> element with the name of the individual or role the contact represents.
- A <contact:org> element with the name of the organization the contact is affiliated with.
- A <contact:addr> element with the address info for the contact. It has these child elements:
  - One, two, or three OPTIONAL <contact:street> elements with the contact's street address.
  - A <contact:city> element with the contact's city.
  - An OPTIONAL <contact:sp> element with the contact's state or province.
  - An OPTIONAL <contact:pc> element with the contact's postal code.
  - A <contact:cc> element with the contact's country code.
A <contact:voice> element with the contact's voice telephone number 📞
A <contact:fax> element with the contact's facsimile telephone number.
A <contact:email> element with the contact's email address 💌
A <contact:authInfo> element with authorization info tied to the contact object. The mapping includes a password-based authentication mechanism, but the schema lets new mechanisms be defined in new schemas. Iconic flexibility 👑
A <contact:disclose> element that lets a client flag elements that need special handling by the server operator to allow or restrict disclosure to third parties. See section 2.9. for the child elements inside <contact:disclose> 🫶

Here's an 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:      <contact:update
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
C:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
C:       contact-1.0.xsd">
C:        <contact:id>sh8013</contact:id>
C:        <contact:add>
C:          <contact:status s="clientDeleteProhibited"/>
C:        </contact:add>
C:        <contact:chg>
C:          <contact:postalInfo type="int">
C:            <contact:org/>
C:            <contact:addr>
C:              <contact:street>124 Example Dr.</contact:street>
C:              <contact:street>Suite 200</contact:street>
C:              <contact:city>Dulles</contact:city>
C:              <contact:sp>VA</contact:sp>
C:              <contact:pc>20166-6503</contact:pc>
C:              <contact:cc>US</contact:cc>
C:            </contact:addr>
C:          </contact:postalInfo>
C:          <contact:voice>+1.7034444444</contact:voice>
C:          <contact:fax/>
C:          <contact:authInfo>
C:            <contact:pw>2fooBAR</contact:pw>
C:          </contact:authInfo>
C:          <contact:disclose flag="1">
C:            <contact:voice/>
C:            <contact:email/>
C:          </contact:disclose>
C:        </contact:chg>
C:      </contact:update>
C:    </update>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

When an <update> command has been processed successfully, the server MUST reply with an EPP response that has no <resData> element. Main character energy, no extra fluff 💖

Here's an 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>

If an <update> command can't be processed for any reason, an EPP error response MUST be returned. No ghosting, the client always gets an answer 🚨

3.2.6. Offline Review of Requested Actions 🌸

Commands get processed by the server in the order the client sends them, periodt 💅 The server sends back an immediate response that confirms it got and processed the command. Still, a server operator MAY do an offline review of requested transform commands before finishing the requested action. When that happens, the response from the server MUST clearly say the transform command was received and processed, but the requested action is still pending. The status of the affected object MUST clearly reflect that the pending action is being processed. Then the server MUST notify the client once the offline processing is finished 🦋

Here are examples of a <create> command that needs offline review. Look closely at the result code and message the server sends back for 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:      <contact:creData
S:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
S:       contact-1.0.xsd">
S:        <contact:id>sh8013</contact:id>
S:        <contact:crDate>1999-04-03T22:00:00.0Z</contact:crDate>
S:      </contact:creData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54321-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

After this response goes out, the status of the contact object MUST include "pendingCreate" ⏳ The server operator reviews the request offline, then tells the client how it turned out by queuing a service message to grab 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 <contact:panData> element that names the contact namespace and where the contact schema lives. The <contact:panData> element has these child elements:

A <contact:id> element with the server-unique identifier of the contact object. The <contact:id> 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 <contact:paTRID> element with the client transaction identifier and server transaction identifier that came back with the original response to the command. The client transaction identifier is OPTIONAL and only comes back if the client gave one with the original <create> command.
A <contact:paDate> element with the date and time when the review of the requested action was finished 🗓️

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:      <contact:panData
S:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
S:       xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
S:       contact-1.0.xsd">
S:        <contact:id paResult="1">sh8013</contact:id>
S:        <contact:paTRID>
S:          <clTRID>ABC-12345</clTRID>
S:          <svTRID>54321-XYZ</svTRID>
S:        </contact:paTRID>
S:        <contact:paDate>1999-04-04T22:00:00.0Z</contact:paDate>
S:      </contact:panData>
S:    </resData>
S:    <trID>
S:      <clTRID>BCD-23456</clTRID>
S:      <svTRID>65432-WXY</svTRID>
S:    </trID>
S:  </response>
S:</epp>

4. Formal Syntax 💅

An EPP object mapping is written in XML Schema notation. The formal syntax here is a complete schema representation of the object mapping, so you can run automated validation on EPP XML instances, which is so satisfying 🤩 The BEGIN and END tags aren't part of the schema. They just 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:contact-1.0"
        xmlns:contact="urn:ietf:params:xml:ns:contact-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">

Okay bestie, the schema is here and it's giving pure XML realness 💅✨ Every element and type below is part of the contact mapping, so it's all staying exactly as written 🎀

   <!--
   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
         contact provisioning schema.
       </documentation>
     </annotation>

   <!--
   Child elements found in EPP commands.
   -->
     <element name="check" type="contact:mIDType"/>
     <element name="create" type="contact:createType"/>
     <element name="delete" type="contact:sIDType"/>
     <element name="info" type="contact:authIDType"/>
     <element name="transfer" type="contact:authIDType"/>
     <element name="update" type="contact:updateType"/>

   <!--
   Utility types.
   -->
     <simpleType name="ccType">

       <restriction base="token">
         <length value="2"/>
       </restriction>
     </simpleType>

     <complexType name="e164Type">
       <simpleContent>
         <extension base="contact:e164StringType">
           <attribute name="x" type="token"/>
         </extension>
       </simpleContent>
     </complexType>

     <simpleType name="e164StringType">
       <restriction base="token">
         <pattern value="(\+[0-9]{1,3}\.[0-9]{1,14})?"/>
         <maxLength value="17"/>
       </restriction>
     </simpleType>

     <simpleType name="pcType">
       <restriction base="token">
         <maxLength value="16"/>
       </restriction>
     </simpleType>

     <simpleType name="postalLineType">
        <restriction base="normalizedString">
          <minLength value="1"/>
          <maxLength value="255"/>
        </restriction>
     </simpleType>

     <simpleType name="optPostalLineType">
        <restriction base="normalizedString">
          <maxLength value="255"/>
        </restriction>
     </simpleType>

   <!--
   Child elements of the <create> command.
   -->
     <complexType name="createType">
       <sequence>
         <element name="id" type="eppcom:clIDType"/>
         <element name="postalInfo" type="contact:postalInfoType"
          maxOccurs="2"/>
         <element name="voice" type="contact:e164Type"

          minOccurs="0"/>
         <element name="fax" type="contact:e164Type"
          minOccurs="0"/>
         <element name="email" type="eppcom:minTokenType"/>
         <element name="authInfo" type="contact:authInfoType"/>
         <element name="disclose" type="contact:discloseType"
          minOccurs="0"/>
       </sequence>
     </complexType>

     <complexType name="postalInfoType">
       <sequence>
         <element name="name" type="contact:postalLineType"/>
         <element name="org" type="contact:optPostalLineType"
          minOccurs="0"/>
         <element name="addr" type="contact:addrType"/>
       </sequence>
       <attribute name="type" type="contact:postalInfoEnumType"
        use="required"/>
     </complexType>

     <simpleType name="postalInfoEnumType">
       <restriction base="token">
         <enumeration value="loc"/>
         <enumeration value="int"/>
       </restriction>
     </simpleType>

     <complexType name="addrType">
       <sequence>
         <element name="street" type="contact:optPostalLineType"
          minOccurs="0" maxOccurs="3"/>
         <element name="city" type="contact:postalLineType"/>
         <element name="sp" type="contact:optPostalLineType"
          minOccurs="0"/>
         <element name="pc" type="contact:pcType"
          minOccurs="0"/>
         <element name="cc" type="contact:ccType"/>
       </sequence>
     </complexType>

     <complexType name="authInfoType">
       <choice>
         <element name="pw" type="eppcom:pwAuthInfoType"/>
         <element name="ext" type="eppcom:extAuthInfoType"/>
       </choice>
     </complexType>
     <complexType name="discloseType">
       <sequence>
         <element name="name" type="contact:intLocType"
          minOccurs="0" maxOccurs="2"/>
         <element name="org" type="contact:intLocType"
          minOccurs="0" maxOccurs="2"/>
         <element name="addr" type="contact:intLocType"
          minOccurs="0" maxOccurs="2"/>
         <element name="voice" minOccurs="0"/>
         <element name="fax" minOccurs="0"/>
         <element name="email" minOccurs="0"/>
       </sequence>
       <attribute name="flag" type="boolean" use="required"/>
     </complexType>

     <complexType name="intLocType">
       <attribute name="type" type="contact:postalInfoEnumType"
        use="required"/>
     </complexType>

   <!--
   Child element of commands that require only an identifier.
   -->
     <complexType name="sIDType">
       <sequence>
         <element name="id" type="eppcom:clIDType"/>
       </sequence>
     </complexType>

   <!--
   Child element of commands that accept multiple identifiers.
   -->
     <complexType name="mIDType">
       <sequence>
         <element name="id" type="eppcom:clIDType"
          maxOccurs="unbounded"/>
       </sequence>
     </complexType>

   <!--
   Child elements of the <info> and <transfer> commands.
   -->
     <complexType name="authIDType">
       <sequence>
         <element name="id" type="eppcom:clIDType"/>
         <element name="authInfo" type="contact:authInfoType"
          minOccurs="0"/>
       </sequence>

     </complexType>

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

   <!--
   Data elements that can be added or removed.
   -->
     <complexType name="addRemType">
       <sequence>
         <element name="status" type="contact:statusType"
          maxOccurs="7"/>
       </sequence>
     </complexType>

   <!--
   Data elements that can be changed.
   -->
     <complexType name="chgType">
       <sequence>
         <element name="postalInfo" type="contact:chgPostalInfoType"
          minOccurs="0" maxOccurs="2"/>
         <element name="voice" type="contact:e164Type"
          minOccurs="0"/>
         <element name="fax" type="contact:e164Type"
          minOccurs="0"/>
         <element name="email" type="eppcom:minTokenType"
          minOccurs="0"/>
         <element name="authInfo" type="contact:authInfoType"
          minOccurs="0"/>
         <element name="disclose" type="contact:discloseType"
          minOccurs="0"/>
       </sequence>
     </complexType>

     <complexType name="chgPostalInfoType">

       <sequence>
         <element name="name" type="contact:postalLineType"
          minOccurs="0"/>
         <element name="org" type="contact:optPostalLineType"
          minOccurs="0"/>
         <element name="addr" type="contact:addrType"
          minOccurs="0"/>
       </sequence>
       <attribute name="type" type="contact:postalInfoEnumType"
        use="required"/>
     </complexType>

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

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

     <complexType name="checkType">
       <sequence>
         <element name="id" type="contact:checkIDType"/>
         <element name="reason" type="eppcom:reasonType"
          minOccurs="0"/>
       </sequence>
     </complexType>

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

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

   <!--
   <info> response elements.
   -->
     <complexType name="infDataType">
       <sequence>
         <element name="id" type="eppcom:clIDType"/>
         <element name="roid" type="eppcom:roidType"/>
         <element name="status" type="contact:statusType"
          maxOccurs="7"/>
         <element name="postalInfo" type="contact:postalInfoType"
          maxOccurs="2"/>
         <element name="voice" type="contact:e164Type"
          minOccurs="0"/>
         <element name="fax" type="contact:e164Type"
          minOccurs="0"/>
         <element name="email" type="eppcom:minTokenType"/>
         <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"/>
         <element name="authInfo" type="contact:authInfoType"
          minOccurs="0"/>
         <element name="disclose" type="contact:discloseType"
          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="contact:statusValueType"
            use="required"/>
           <attribute name="lang" type="language"
            default="en"/>
         </extension>
       </simpleContent>
     </complexType>

     <simpleType name="statusValueType">
       <restriction base="token">
         <enumeration value="clientDeleteProhibited"/>
         <enumeration value="clientTransferProhibited"/>
         <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="serverTransferProhibited"/>
         <enumeration value="serverUpdateProhibited"/>
       </restriction>
     </simpleType>

   <!--
   Pending action notification response elements.
   -->
     <complexType name="panDataType">
       <sequence>
         <element name="id" type="contact:paCLIDType"/>
         <element name="paTRID" type="epp:trIDType"/>
         <element name="paDate" type="dateTime"/>
       </sequence>
     </complexType>

     <complexType name="paCLIDType">
       <simpleContent>
         <extension base="eppcom:clIDType">
           <attribute name="paResult" type="boolean"
            use="required"/>
         </extension>
       </simpleContent>
     </complexType>

   <!--
   <transfer> response elements.

   -->
     <complexType name="trnDataType">
       <sequence>
         <element name="id" type="eppcom:clIDType"/>
         <element name="trStatus" type="eppcom:trStatusType"/>
         <element name="reID" type="eppcom:clIDType"/>
         <element name="reDate" type="dateTime"/>
         <element name="acID" type="eppcom:clIDType"/>
         <element name="acDate" type="dateTime"/>
       </sequence>
     </complexType>

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

That's the whole schema block for this part, slay 🧚🌸 The next chunk picks up right where this one leaves off 🦋

5. Internationalization Considerations ✨

okay bestie, let's talk about characters 🌸 EPP is written in XML, and XML comes with native support for the Unicode character set and its more compact forms, including UTF-8 💖 Conformant XML processors recognize both UTF-8 and UTF-16 [RFC2781]. XML also has a way to name other character encodings through an encoding attribute in an <?xml?> declaration, but use of UTF-8 is RECOMMENDED in environments where parser encoding support is incompatible 🫶 bestie, the parsers don't all speak the same encodings, so just use UTF-8 and avoid the drama 💅

Date-times are a whole vibe 🕰️ All date-time values presented via EPP MUST be expressed in Universal Coordinated Time using the Gregorian calendar. no cap, that's non-negotiable 👑 The XML Schema lets you use time zone identifiers to show offsets from the zero meridian, but this option MUST NOT be used with EPP 🙈 The extended date-time form from [RFC3339] MUST be used, with upper case "T" and "Z" characters, because the XML Schema doesn't support truncated date-time forms or lower case "T" and "Z" 😭 so it's giving capital letters or nothing 🔥

Humans, organizations, and other entities often want to show social information in a character set everybody understands AND in a locally optimized one 🌈 This specification gives you both: a subset of UTF-8 for broad readability, and unrestricted UTF-8 for local optimization. iconic 🦋

6. IANA Considerations 🎀

okay so this document uses URNs to describe XML namespaces and XML schemas that follow a registry mechanism described in [RFC3688] 🧚 Two URI assignments have been registered by the IANA, and they're literally the main character of this section 💜

Registration request for the contact namespace:

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

URI: urn:ietf:params:xml:schema:contact-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 part is SERIOUS 😭🔥 Authorization information as described in section 2.8. is REQUIRED to create a contact object 💅 This info gets 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 information release, and that is NOT it 💀 Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption mechanisms to provide privacy services. No skipping the encryption, periodt 🔒

The object mapping in this document doesn't provide any other security services or bring in any additional considerations beyond what [RFC3730] and the protocol layers EPP uses already cover 🫶

8. Acknowledgements 🌷

This document started out as an individual submission Internet-Draft 🍓 The provreg working group later adopted it as a working group document and gave lots of invaluable comments and suggested improvements, so huge thanks to them 🥰 The author also 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, Eric Brunner-Williams, Jordyn Buchanan, Robert Burbidge, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer El-Showk, Dipankar Ghosh, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, Asbjorn Steira, and Rick Wesson 💖 literally a whole squad 🫶

9. References 📚

9.1. Normative References

[ISO3166]  ISO 3166-1: "Codes for the representation of names of
           countries and their subdivisions - Part 1: Country codes",
           October 1997.

[RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2279]  Yergeau, F., "UTF-8, a transformation format of ISO
           10646", RFC 2279, January 1998.

[RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
           2001.

[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.

[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.

[E164a]    ITU-T Recommendation E.164: "The International Public
           Telecommunication Numbering Plan", May 1997.

[E164b]    Complement To ITU-T Recommendation E.164 (05/1997): "List
           of ITU-T Recommendation E.164 assigned country codes",
           June 2000.

10. Author's Address 🧚

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

EMail: shollenbeck@verisign.com 💌

11. Full Copyright Statement ⚖️

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 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. 🌈

📦 where this page comes from

ietf: rfc3733 2004-03
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms