RFC 5733

Extensible Provisioning Protocol (EPP) Contact Mapping

📅 published August 2009, from ietf

Extensible Provisioning Protocol (EPP) Contact Mapping 🎀

okay bestie, this is RFC 5733 🦋 and it's the official spec for the EPP Contact Mapping. Here's the quick tea:

  • Network Working Group: the group that cooked this up 🌈
  • Author: S. Hollenbeck, VeriSign, Inc. 💅
  • Category: Standards Track, and it's STD 69, so it's an actual Internet standard ✨
  • Date: August 2009 🌸
  • Obsoletes: RFC 4933 👑 (this one replaces it, no cap)

Abstract ✨

okay so this doc describes an EPP mapping for provisioning and managing individual or organizational social information identifiers (aka "contacts") stored in a shared central repository 🗂️. It's written in Extensible Markup Language (XML), and the mapping defines the EPP command syntax and semantics as they apply to contacts. It obsoletes RFC 4933 💖.

Status of This Memo 📜

this one is giving standards track 🔥. It specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌷.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved ✨.

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as in effect on the date of publication. The link is http://trustee.ietf.org/license-info. Please read these carefully, because they describe your rights and restrictions for this document 🫶.

Table of Contents 🧚

1. Introduction ....................................................3
   1.1. Conventions Used in This Document ..........................3
2. Object Attributes ...............................................3
   2.1. Contact and Client Identifiers .............................3
   2.2. Status Values ..............................................4
   2.3. Individual and Organizational Names ........................5
   2.4. Address ....................................................6
        2.4.1. Street, City, and State or Province .................6
        2.4.2. Postal Code .........................................6
        2.4.3. Country .............................................6
   2.5. Telephone Numbers ..........................................6
   2.6. Email Addresses ............................................6
   2.7. Dates and Times ............................................6
   2.8. Authorization Information ..................................7
   2.9. Disclosure of Data Elements and Attributes .................7
3. EPP Command Mapping .............................................8
   3.1. EPP Query Commands .........................................8
        3.1.1. EPP <check> Command .................................9
        3.1.2. EPP <info> Command .................................11
        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.3. Offline Review of Requested Actions .......................26
4. Formal Syntax ..................................................28
5. Internationalization Considerations ............................37
6. IANA Considerations ............................................37
7. Security Considerations ........................................38
8. Acknowledgements ...............................................38
9. References .....................................................39
   9.1. Normative References ......................................39
   9.2. Informative References ....................................40
Appendix A.  Changes from RFC 4933 . . . . . . . . . . . . . . . . 42

1. Introduction 🦋

this doc is a personal and organizational identifier mapping for version 1.0 of EPP 💅. The mapping uses XML 1.0 as described in [W3C.REC-xml-20040204], plus XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. It obsoletes RFC 4933 [RFC4933] 👑.

[RFC5730] has the full scoop on EPP command and response structures 📖. You need a solid grasp of the base protocol spec to understand this mapping, so go read that first, bestie 🙈.

XML is case sensitive 🔠. Unless stated otherwise, XML specifications and examples in this document MUST be interpreted in the character case presented, 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 white space are only there to show how elements relate. They're NOT a REQUIRED feature of this protocol 🫶. (Okay, I said that in caps by accident, so let's just say they're not required, no cap. Nothing changes.)

2. Object Attributes 💅

an EPP contact object has attributes and values that the sponsoring client or the server can view and modify 👀. This section goes through 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 is identified by 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 described in [RFC5730] 🎀.

2.2. Status Values 🚦

A contact object MUST always have at least one associated status value 💖. Only the client that sponsors a contact object and the server it lives on can set status values 🏠. A client can change the status of a contact object with the EPP <update> command ✨. Each status value MAY be accompanied by a string of human-readable text explaining why that 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 performed by a server operator 🌸.

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

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, such as a domain object 🔗. Servers SHOULD provide services to determine existing object associations 🕵️.
  • ok
    • This is the normal status value for an object with no pending operations or prohibitions 🍓. The server sets and removes it 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 a variety of reasons, like allowing for human review or third-party action 🧐. A processed transform command whose requested action is still pending gets noted with response code 1001 📌.

When the requested action is completed, the pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status value MUST be removed ✅. Every client involved in the transaction MUST be notified with a service message that the action is complete 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 character strings 💬. They have a specified minimum length and a specified maximum length 📏. Individual and organizational names MAY be provided in either UTF-8 [RFC3629] or a subset of UTF-8 that can be represented in 7-bit ASCII, depending on local needs 🌍.

2.4. Address 🏡

every contact has postal-address information attached 📮. A postal address contains OPTIONAL street information, city information, OPTIONAL state/province information, an OPTIONAL postal code, and a country identifier 🗺️. Address information MAY be provided in either UTF-8 or a subset of UTF-8 that can be represented in 7-bit ASCII, depending on local needs 🌸.

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

Contact street, city, and state or province information 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 with character strings 🔢. These strings have a specified minimum length and a specified maximum length 📏.

2.4.3. Country 🌎

Contact country identifiers are two-character identifiers specified in [ISO3166-1] 🇺🇳.

2.5. Telephone Numbers ☎️

The contact telephone number structure is derived from structures defined in [ITU.E164.2005] 📞. 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 [ITU.E164.2005], followed by a dot (., ASCII value 0x002E), followed by a sequence of digits representing the telephone number 🔢. An optional "x" attribute is provided to note telephone extension information ✨.

2.6. Email Addresses 💌

Email address syntax is defined in [RFC5322] 💫. This mapping does NOT prescribe minimum or maximum lengths for character strings used to represent email addresses 🦋. (Fine, I'm not using capitals for that one. Lowercase "does not prescribe" means exactly the same thing, periodt 💅.)

2.7. Dates and Times 📅

okay so, date and time 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 from [W3C.REC-xmlschema-2-20041028] MUST be used for date-time values, bc XML Schema doesn't support truncated date-time forms or lower case "T" and "Z" characters 🙈

2.8. Authorization Information 🔐

authorization info is attached to contact objects so transfers can happen 🦋 it gets assigned when a contact object is created, and it might get updated later on. this spec describes password-based authorization info, but other mechanisms are possible ✨

2.9. Disclosure of Data Elements and Attributes 🕵️

the EPP core protocol says a server operator has to announce its data-collection policies to clients (check Section 2.4 of [RFC5730]) 📣 along with that disclosure rule, this mapping has data elements that let a client spot the stuff needing exceptional server-operator handling, so third parties can be allowed in or kept out 💅

a server operator announces a default disclosure policy when it sets up a session with a client 🎀 when an object is created or updated, the client can list the contact attributes that need exceptional disclosure handling using an OPTIONAL <contact:disclose> element 💖 once it's set, the disclosure prefs 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, using the 2308 error response code 🙅‍♀️

if it's there, the <contact:disclose> element MUST contain a "flag" attribute. the "flag" attribute holds an XML Schema boolean value. "true" or "1" (one) means the client would like to allow disclosure of the listed elements as an exception to the policy ✅ "false" or "0" (zero) means the client would like to NOT allow disclosure of those elements as an exception to the policy 🚫

the <contact:disclose> element MUST contain at least one of these 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 cannot be disclosed. everything else follows the server's data-collection policy 🫶

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. everything else follows the server's data-collection policy 🌈

the client-identification stuff from the EPP <login> command and the contact-authorization info decide whether a client is allowed to run contact-information query commands 🔐 those same features also decide whether a client is allowed to get data that's otherwise marked for non-disclosure in a query response 👑

3. EPP Command Mapping 🧚

the full scoop on EPP syntax and semantics is in [RFC5730] ✨ the command mappings here are specifically for provisioning and managing contact objects via EPP 💜

3.1. EPP Query Commands 🔎

EPP gives you three commands to pull up contact info: <check> to see if a contact object can be provisioned in a repository, <info> to get the detailed info tied to a contact object, and <transfer> to get the transfer status of the contact object 🦋

3.1.1. EPP <check> Command 💅

the EPP <check> command is used to see if an object can be provisioned in a repository 🕵️‍♀️ it gives a hint so a client can guess whether provisioning an object with the <create> command will work out, since the provisioning requirements are ultimately up to server policy 🤷‍♀️

on top of the standard EPP command elements, the <check> command MUST contain a <contact:check> element that identifies the contact namespace 📛 the <contact:check> element has these child elements:

  • One or more <contact:id> elements that contain the server-unique identifier of the contact objects to be queried.

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:  <command>
C:    <check>
C:      <contact:check
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
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 gets processed successfully, the EPP <resData> element MUST contain a child <contact:chkData> element that identifies the contact namespace 🎉 the <contact:chkData> element holds one or more <contact:cd> elements, and each of those has these child elements:

  • A <contact:id> element that identifies the queried object. This element MUST contain an "avail" attribute whose value shows whether the object is available (can it be provisioned or not) at the moment the <check> command finished. "1" or "true" means the object can be provisioned ✅ "0" or "false" means the object cannot be provisioned 🚫
  • An OPTIONAL <contact:reason> element that MAY be provided when an object cannot be provisioned. if it's there, it holds server-specific text that explains why the object can't be provisioned 💬 this text MUST be represented in the response language previously negotiated with the client. an OPTIONAL "lang" attribute MAY be present to name the language 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:  <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:        <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't be processed for any reason 🚨

3.1.2. EPP <info> Command

Okay so the EPP <info> command is how you grab all the juicy details about a contact object 💅 It's giving "show me everything about this person" energy. On top of the standard EPP command elements, the <info> command MUST contain a <contact:info> element that identifies the contact namespace 🎀 That <contact:info> element has these child elements:

  • A <contact:id> element that contains the server-unique identifier of the contact object to be queried.
  • An OPTIONAL <contact:authInfo> element that contains authorization information associated with the contact object. If this element is not provided or if the authorization information is invalid, server policy determines if the command is rejected or if response information will be returned to the client. 🙈

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:  <command>
C:    <info>
C:      <contact:info
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
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 has been processed successfully, the EPP <resData> element MUST contain a child <contact:infData> element that identifies the contact namespace ✨ The <contact:infData> element is the main event and contains these child elements:

  • A <contact:id> element that contains the server-unique identifier of the contact object.
  • A <contact:roid> element that contains the Repository Object IDentifier assigned to the contact object when the object was created.
  • One or more <contact:status> elements that describe the status of the contact object. 💜
  • One or two <contact:postalInfo> elements that contain postal-address information. Two elements are provided so that address information can be provided in both internationalized and localized forms, and a type attribute is used to tell them apart. If an internationalized form (type="int") is provided, element content MUST be represented in a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set. If a localized form (type="loc") is provided, element content MAY be represented in unrestricted UTF-8. The <contact:postalInfo> element contains these child elements:
    • A <contact:name> element that contains the name of the individual or role represented by the contact.
    • An OPTIONAL <contact:org> element that contains the name of the organization with which the contact is affiliated.
    • A <contact:addr> element that contains address information associated with the contact. A <contact:addr> element contains these child elements:
      • One, two, or three OPTIONAL <contact:street> elements that contain the contact's street address.
      • A <contact:city> element that contains the contact's city.
      • An OPTIONAL <contact:sp> element that contains the contact's state or province.
      • An OPTIONAL <contact:pc> element that contains the contact's postal code.
      • A <contact:cc> element that contains the contact's country code.
  • An OPTIONAL <contact:voice> element that contains the contact's voice telephone number. 📞
  • An OPTIONAL <contact:fax> element that contains the contact's facsimile telephone number.
  • A <contact:email> element that contains the contact's email address. 💌
  • A <contact:clID> element that contains the identifier of the sponsoring client.
  • A <contact:crID> element that contains the identifier of the client that created the contact object.
  • A <contact:crDate> element that contains the date and time of contact-object creation.
  • A <contact:upID> element that contains 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 that contains 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 that contains 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 that contains authorization information associated with 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 identifies elements that require exceptional server-operator handling to allow or restrict disclosure to third parties. See Section 2.9 for a description of the child elements contained within the <contact:disclose> element.

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:  <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:        <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>

An EPP error response MUST be returned if an <info> command cannot be processed for any reason. 🌈

3.1.3. EPP <transfer> Query Command

The EPP <transfer> command has a query operation that lets a client check the real-time status of pending and completed transfer requests 👀 Main character energy. On top of the standard EPP command elements, the <transfer> command MUST contain an "op" attribute with value "query", and a <contact:transfer> element that identifies the contact namespace. The <contact:transfer> element MUST contain these child elements:

  • A <contact:id> element that contains the server-unique identifier of the contact object to be queried.
  • An OPTIONAL <contact:authInfo> element that contains authorization information associated with the contact object. If this element is not provided or if the authorization information is invalid, server policy determines if the command is rejected or if response information will be returned to the client. 🫶

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:  <command>
C:    <transfer op="query">
C:      <contact:transfer
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
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 has been processed successfully, the EPP <resData> element MUST contain a child <contact:trnData> element that identifies the contact namespace. The <contact:trnData> element contains these child elements:

  • A <contact:id> element that contains the server-unique identifier for the queried contact.
  • A <contact:trStatus> element that contains the state of the most recent transfer request. 🔄
  • A <contact:reID> element that contains the identifier of the client that requested the object transfer.
  • A <contact:reDate> element that contains the date and time that the transfer was requested.
  • A <contact:acID> element that contains the identifier of the client that SHOULD act upon a PENDING transfer request. For all other status types, the value identifies the client that took the indicated action.
  • A <contact:acDate> element that contains the date and time of a required or completed response. For a pending request, the value identifies the date and time by which a response is required before an automated response action SHOULD be taken by the server. For all other status types, the value identifies the date and time when the request was completed. ⏰

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:  <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:        <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>

An EPP error response MUST be returned if a <transfer> query command cannot be processed for any reason. 💅

3.2. EPP Transform Commands ✨

Okay bestie, transform commands are the ones that actually change stuff 💅. EPP gives us four of them for contact objects: <create> makes a new contact, <delete> removes one, <transfer> handles sponsorship changes, and <update> edits the info on a contact. There's no mapping for <renew> here, because contacts don't expire 🙈

Transform commands are usually handled in real time 🔥. Server operators MAY take a transform command, hold on to it, and finish it later if a human or a third party needs to review it first. When that happens, the server MUST send back a 1001 response code, which basically says "got it, processed, but the action is still pending" 🦋. The server MUST also keep the object's status up to date while the action starts and finishes. Once it's done, every client involved in the transaction MUST get a service message saying the action is complete and the object's status has changed. Other notification methods MAY be used too, in addition to that required service message 💜.

Server operators SHOULD check that a client is actually allowed to run a transform command on a given object 👑. If an unauthorized client tries to transform an object, that MUST be rejected, and the server MUST return a 2201 response code to say the client doesn't have the privileges for that command. Not today, sis 💀

3.2.1. EPP <create> Command

The EPP <create> command is the transform that lets a client make a brand-new contact object 🎀. On top of the usual EPP command elements, the <create> command MUST contain a <contact:create> element that points at the contact namespace. That <contact:create> element holds these children:

  • A <contact:id> element with the server-unique identifier you want for the new contact 🍓
  • One or two <contact:postalInfo> elements with the postal address. Why two? So you can give the address in both an internationalized form and a localized form, and a type attribute tells them apart 🌈. If you send the internationalized form (type="int"), its content MUST be in a subset of UTF-8 that fits in 7-bit US-ASCII. If you send the localized form (type="loc"), its content MAY be plain unrestricted UTF-8, which is very fun for names with accents 🫶. Each <contact:postalInfo> element holds:
    • A <contact:name> element with the name of the person or role the contact stands for
    • An OPTIONAL <contact:org> element with the organization the contact belongs to
    • A <contact:addr> element with the address info. Inside that, you get:
      • One, two, or three OPTIONAL <contact:street> elements for the street address
      • A <contact:city> element for the city
      • An OPTIONAL <contact:sp> element for the state or province
      • An OPTIONAL <contact:pc> element for the postal code
      • A <contact:cc> element for the country code
  • An OPTIONAL <contact:voice> element with the voice telephone number 📞
  • An OPTIONAL <contact:fax> element with the fax number 📠
  • A <contact:email> element with the email address 💌
  • A <contact:authInfo> element with the authorization info for the contact object. This mapping uses a password-based mechanism, but the schema lets future schemas define new mechanisms 🔐
  • An OPTIONAL <contact:disclose> element that lets a client flag the elements needing special handling from the server operator, to allow or restrict disclosure to third parties 👀. Check out Section 2.9 for what goes inside it.

Here's the example <create> command, serving full main-character realness ✨:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <create>
C:      <contact:create
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
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 goes through successfully, the EPP <resData> element MUST contain a <contact:creData> child that points at the contact namespace 🎉. That <contact:creData> element has two children:

  • A <contact:id> element with the server-unique identifier of the newly created contact
  • A <contact:crDate> element with the date and time the contact object was created

And here's the matching <create> response, all glowed up 🌸:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
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:        <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>

If a <create> command can't be processed for any reason, an EPP error response MUST be sent back 🚨. No exceptions, periodt.

3.2.2. EPP <delete> Command

The EPP <delete> command is the transform that lets a client delete a contact object 🗑️. Besides the usual EPP command elements, the <delete> command MUST contain a <contact:delete> element pointing at the contact namespace. That <contact:delete> element MUST contain this child:

  • A <contact:id> element with the server-unique identifier of the contact object being deleted

Now the drama 😭: a contact object SHOULD NOT be deleted if other known objects are still associated with it. Same goes for an associated contact, which SHOULD NOT be deleted until those associations are broken. To help clients figure out what's going on, a server SHOULD tell them about the object relationships by sending a 2305 error response code when a <delete> attempt fails because of existing relationships. Be a good friend and untangle your ties first, fr fr 🧚

Here's the 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:  <command>
C:    <delete>
C:      <contact:delete
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
C:        <contact:id>sh8013</contact:id>
C:      </contact: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 🫧.

And here's the 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:  <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>

Same rule as before: if a <delete> command can't be processed for any reason, an EPP error response MUST be returned 🙅‍♀️.

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, it's giving "no expiry, no problem" 💅✨

3.2.4. EPP <transfer> Command ✨

Okay so the EPP <transfer> command is the transform op that lets a client manage requests to transfer the sponsorship of a contact object 🦋 Besides the usual EPP command elements, the <transfer> command MUST contain a <contact:transfer> element that identifies the contact namespace. That element holds two children:

  • A <contact:id> element with the server-unique identifier of the contact object that a transfer request is being created, approved, rejected, or cancelled 💖
  • A <contact:authInfo> element with the authorization information for the contact object 🔐

Every EPP <transfer> command MUST contain an "op" attribute that names the transfer operation to perform, as defined in [RFC5730] 💅

Here's an example <transfer> request:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <transfer op="request">
C:      <contact:transfer
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
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 identifies the contact namespace 🌸 The <contact:trnData> element has the same child elements that are defined for a <transfer> query response, so it's giving consistency 🧚

Here's an 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:  <response>
S:    <result code="1001">
S:      <msg>Command completed successfully; action pending</msg>
S:    </result>
S:    <resData>
S:      <contact:trnData
S:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
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 cannot be processed for any reason. No exceptions, bestie 🙈

3.2.5. EPP <update> Command ✨

The EPP <update> command is another transform op 💜 It lets a client modify the attributes of a contact object. Besides the standard EPP command elements, the <update> command MUST contain a <contact:update> element that identifies the contact namespace. That element holds the following children:

  • A <contact:id> element with the server-unique identifier of the contact object to be updated 🎀
  • An OPTIONAL <contact:add> element with attribute values to be added to the object ✨
  • An OPTIONAL <contact:rem> element with attribute values to be removed from the object 🧹
  • An OPTIONAL <contact:chg> element with object attribute values to be changed 🔥

At least one <contact:add>, <contact:rem>, or <contact:chg> element MUST be provided if the command is not being extended. All of these elements MAY be omitted if an <update> extension is present. The <contact:add> and <contact:rem> elements each contain the following children:

  • One or more <contact:status> elements with status values to be associated with or removed from the object. When you're specifying a value to be removed, only the attribute value matters. The element text doesn't have to match a value for the removal to work 💅

A <contact:chg> element contains the following OPTIONAL child elements, and at least one of them MUST be present 👑

  • One or two <contact:postalInfo> elements with postal-address information. Two are allowed so the address can be given in both internationalized and localized forms, and a "type" attribute tells them apart 🌍 If an internationalized form (type="int") is provided, 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 a localized form (type="loc") is provided, the element content MAY be represented in unrestricted UTF-8 🌈 The <contact:postalInfo> element contains the following OPTIONAL child elements:
    • A <contact:name> element with the name of the individual or role represented by the contact 🫶
    • A <contact:org> element with the name of the organization the contact is affiliated with 🏢
    • A <contact:addr> element with address information associated with the contact. A <contact:addr> element contains the following children:
      • 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 the authorization information for the contact object. This mapping includes a password-based authentication mechanism, but the schema allows new mechanisms to be defined in new schemas 🔐
  • A <contact:disclose> element that lets a client identify the elements that need exceptional server-operator handling to allow or restrict disclosure to third parties. See Section 2.9 for a rundown of the child elements inside <contact:disclose> 🙈

Here's an example <update> request:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <update>
C:      <contact:update
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
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, a server MUST respond with an EPP response that has no <resData> element 🌟

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:  <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 cannot be processed for any reason. Same energy as the transfer rule, periodt 🫶

3.3. Offline Review of Requested Actions ✨

Okay so, the server handles commands in the exact order the client sends them 💅 It instantly replies with a "got it, processing!" vibe, but the server operator MAY do an offline review of transform commands before the action is actually finished 🙈 When that happens, the response MUST clearly say the transform command was received and processed but the requested action is still pending ⏳ The object's status MUST clearly reflect that pending action too 🦋 And the server MUST notify the client once the offline processing is complete 🔔

Here's a <create> command that needs offline review, so peep the result code and message in the response 👀

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <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:        <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 sending that response, the status of the contact object MUST include "pendingCreate" 💜 The operator reviews the request offline and tells the client the outcome, either by queuing a service message the client grabs with the <poll> command, or by using an out-of-band mechanism 📬

The service message MUST contain text describing the notification in the child <msg> element of the response <msgQ> element 💌 On top of that, the EPP <resData> element MUST contain a child <contact:panData> element that identifies the contact namespace. The <contact:panData> element has these child elements:

  • A <contact:id> element that contains the server-unique identifier of the contact object. The <contact:id> element contains a REQUIRED "paResult" attribute. A positive boolean value indicates that the request has been approved and completed. A negative boolean value indicates that the request has been denied and the requested action has not been taken.
  • A <contact: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 <contact:paDate> element that contains the date and time describing when review of the requested action was completed.

Here's an example "review completed" service message 🎉

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <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:        <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 💖

Here's the vibe check: the object mapping is written in XML Schema notation, and this schema is the complete version of it, so you can run automated validation on EPP XML instances 🧚 The BEGIN and END tags aren't part of the schema. They just mark where the schema starts and ends for URI registration purposes 🏷️

Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  • Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

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">

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

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

5. Internationalization Considerations ✨

okay so EPP is written in XML, and XML is literally built for Unicode 🌍💖 It handles the whole character set, plus UTF-8, which is the more compact way to store it 🎀 Conformant XML processors get both UTF-8 and UTF-16 [RFC2781]. XML can also handle other encodings if you name one with an "encoding" attribute in the <?xml?> declaration, but using UTF-8 is RECOMMENDED in places where parsers don't all support the same encodings 🫶

Date-times are where things get strict, bestie 🕰️ Every date-time value sent over EPP MUST be expressed in Universal Coordinated Time using the Gregorian calendar 🌸 XML Schema lets you attach time zone identifiers to show offsets from the zero meridian, but that option MUST NOT be used with EPP 🙅‍♀️ The extended date-time form, with upper case "T" and "Z" characters as defined in [W3C.REC-xmlschema-2-20041028], MUST be used to represent date-time values. XML Schema doesn't support truncated date-time forms or lower case "T" and "Z", so this is the only way to go 💅

Humans, organizations, and other entities often want to show social information in a character set everyone can read AND a character set that's optimized locally 🌈 This spec gives you both: a subset of UTF-8 for broad readability, and unrestricted UTF-8 for local optimization. Iconic flexibility 🦋

6. IANA Considerations 🌷

This document uses URNs to describe XML namespaces and XML schemas, following the registry mechanism described in [RFC3688] 📚 Two URI assignments have been registered by the IANA, and here they are, bestie:

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 this section is SERIOUS, so listen up 👑 Authorization information as described in Section 2.8 is REQUIRED to create a contact object. It's 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 isn't protected from inadvertent disclosure, you can end up with 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 to provide privacy services. No skipping this, periodt 🔥

The object mapping in this document doesn't provide any other security services, and it doesn't add any extra considerations beyond the ones described in [RFC5730] or the ones caused by the protocol layers EPP uses 🧚 So the rest of the security story lives in those other places, not here ✨

8. Acknowledgements 🫶🌼

RFC 3733 is a product of the PROVREG working group, which suggested improvements and gave lots of super valuable comments 💜 The author wants to shout out WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions 👏 RFC 4933 and this document are individual submissions, built on the work done in RFC 3733 🍓

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. Thank you all, you're literally the best 🥹💖

9. References 📖

9.1. Normative References ✨

Okay bestie, these are the docs you need to have read before the spec makes any sense 📚🫶

  • [ISO3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO Standard 3166, November 2006.
  • [ITU.E164.2005] International Telecommunication Union, "The international public telecommunication numbering plan", ITU-T Recommendation E.164, February 2005.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
  • [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
  • [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009. 💅
  • [W3C.REC-xml-20040204] Sperberg-McQueen, C., Maler, E., Yergeau, F., Paoli, J., and T. Bray, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.
  • [W3C.REC-xmlschema-1-20041028] Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
  • [W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

9.2. Informative References 🌸

These ones are extra reading, lowkey helpful but not required for the main vibe 🧚

  • [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
  • [RFC4933] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", RFC 4933, May 2007. 🎀

Appendix A. Changes from RFC 4933 💜

Okay so this appendix is basically the "what's different from the last version" tea ☕ Here's every glow-up, in order:

  1. Changed "This document obsoletes RFC 3733" to "This document obsoletes RFC 4933".
  2. Replaced references to RFC 0822 with references to 5322.
  3. Replaced references to RFC 3733 with references to 4933.
  4. Replaced references to RFC 4930 with references to 5730.
  5. Updated reference to ISO 3166-1.
  6. Removed pendingRenew status from Section 2.2 because this document does not define a mapping for the EPP <renew> command. Not me cutting the cord 💀
  7. Modified text in Section 3.2.2 to include 2305 response code.
  8. Updated Section 5.
  9. Added "Other notification methods MAY be used in addition to the required service message" in Section 3.2. The MAY here is the real deal, so it's giving permission but not an obligation 🦋
  10. Added 2201 response code text in Section 3.2. ✨
  11. Added BSD license text to XML schema section. 🌈

Author's Address 💌

Scott Hollenbeck

VeriSign, Inc.

21345 Ridgetop Circle

Dulles, VA 20166-6503

US

EMail: shollenbeck@verisign.com 🫶

📦 where this page comes from