RFC 3730
Extensible Provisioning Protocol (EPP)
RFC 3730: Extensible Provisioning Protocol (EPP) ✨
Okay bestie, let's get the basics down first 🎀. This is RFC 3730, titled Extensible Provisioning Protocol (EPP). It was written by S. Hollenbeck at VeriSign, Inc. It's a Standards Track document from the Network Working Group, dated March 2004. The header doesn't list anything it obsoletes or updates 💅.
Status of This Memo
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋. If you want to know where this protocol stands in the standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. 💜
Abstract
EPP is an application layer client-server protocol for provisioning and managing objects that live in a shared central repository 🧚. It's written in XML and gives you generic object management operations plus an extensible framework that maps those operations onto objects. This document includes a protocol specification, an object mapping template, and an XML media type registration ✨.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . 3
2. Protocol Description. . . . . . . . . . . . . . . . . . . . . 3
2.1. Transport Mapping Considerations. . . . . . . . . . . . 6
2.2. Protocol Identification . . . . . . . . . . . . . . . . 7
2.3. Hello Format. . . . . . . . . . . . . . . . . . . . . . 7
2.4. Greeting Format . . . . . . . . . . . . . . . . . . . . 8
2.5. Command Format. . . . . . . . . . . . . . . . . . . . . 11
2.6. Response Format . . . . . . . . . . . . . . . . . . . . 12
2.7. Protocol Extension Framework. . . . . . . . . . . . . . 16
2.7.1. Protocol Extension. . . . . . . . . . . . . . . 16
2.7.2. Object Extension. . . . . . . . . . . . . . . . 17
2.7.3. Command-Response Extension. . . . . . . . . . . 18
2.8. Object Identification . . . . . . . . . . . . . . . . . 19
2.9. Protocol Commands . . . . . . . . . . . . . . . . . . . 19
2.9.1. Session Management Commands . . . . . . . . . . 20
2.9.1.1. EPP <login> Command . . . . . . . . . 20
2.9.1.2. EPP <logout> Command. . . . . . . . . 22
2.9.2. Query Commands. . . . . . . . . . . . . . . . . 23
2.9.2.1. EPP <check> Command . . . . . . . . . 24
2.9.2.2. EPP <info> Command. . . . . . . . . . 26
2.9.2.3. EPP <poll> Command. . . . . . . . . . 27
2.9.2.4. EPP <transfer> Query Command. . . . . 32
2.9.3. Object Transform Commands . . . . . . . . . . . 34
2.9.3.1. EPP <create> Command. . . . . . . . . 34
2.9.3.2. EPP <delete> Command. . . . . . . . . 35
2.9.3.3. EPP <renew> Command . . . . . . . . . 37
2.9.3.4. EPP <transfer> Command. . . . . . . . 38
2.9.3.5. EPP <update> Command. . . . . . . . . 41
3. Result Codes. . . . . . . . . . . . . . . . . . . . . . . . . 42
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1. Base Schema . . . . . . . . . . . . . . . . . . . . . . 49
4.2. Shared Structure Schema . . . . . . . . . . . . . . . . 58
5. Internationalization Considerations . . . . . . . . . . . . . 60
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
7. Security Considerations . . . . . . . . . . . . . . . . . . . 62
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 62
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.1. Normative References. . . . . . . . . . . . . . . . . . 63
9.2. Informative References. . . . . . . . . . . . . . . . . 64
Appendix A: Object Mapping Template . . . . . . . . . . . . . . . 65
Appendix B: Media Type Registration: application/epp+xml. . . . . 67
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 68
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 691. Introduction ✨
Okay so EPP is the Extensible Provisioning Protocol, version 1.0 💖. It's an XML text protocol that lets multiple service providers do object provisioning operations using one shared central object repository 🫶. EPP is specified with Extensible Markup Language (XML) 1.0 as described in [XML], and with XML Schema notation as described in [XMLS-1] and [XMLS-2]. Honestly, it meets and exceeds the requirements for a generic registry registrar protocol as described in [RFC3375] 👑.
EPP content is identified by the MIME media type application/epp+xml. The registration info for this media type is in an appendix to this document 🎀.
EPP is built for diverse operating environments where transport and security needs vary a lot 🌈. Realistically, one transport or security spec won't cover what every operator needs, so EPP was designed to sit in a layered protocol environment 🧚. Bindings to specific transport and security protocols are outside the scope of this specification 🙈.
The original motivation for this protocol was a standard Internet domain name registration protocol for use between domain name registrars and domain name registries 🍓. It gives registrars' applications a way to interact with registry applications 💅. It's expected that EPP will have additional uses beyond domain name registration ✨.
XML is case sensitive 🦋. Unless stated otherwise, XML specifications and examples in this document MUST be interpreted in the character case presented to develop 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:" represents lines sent by a protocol client, and "S:" represents lines returned by a protocol server 🌸. Indentation and white space in examples only exist to show how elements relate to each other. They're not a REQUIRED feature of this protocol 🔥.
2. Protocol Description ✨
okay so EPP is a stateful XML protocol 💅 and it can be layered over multiple transport protocols 🦋. Protected by lower-layer security protocols, clients swap identification, authentication, and option info, then run a series of client-initiated command-response exchanges 🎀. All EPP commands are atomic (no partial success, no partial failure, bestie 💀) and they're designed to be idempotent, which means running a command more than once has the same net effect on system state as running it once ✨ iconic.
EPP gives you four basic service elements: service discovery, commands, responses, and an extension framework that supports defining managed objects and how protocol requests and responses relate to those objects 🧚.
An EPP server MUST respond to client-initiated communication (a lower-layer connection request or an EPP service discovery message) by returning a greeting to the client 👑. A server MUST promptly respond to each EPP command with a coordinated response that describes the results of processing that command 💖. Here's the server state machine diagram so you can see the whole message exchange in detail 🌈:
|
V
+-----------------+ +-----------------+
| Waiting for | Connected | Prepare |
| Client |----------------->| Greeting |
+-----------------+ or <hello> +-----------------+
^ |
| Close Connection Send |
| or Idle Greeting |
+-----------------+ V
| End | Timeout +-----------------+
| Session |<-----------------| Waiting for |
+-----------------+ | Client |
^ ^ ^ Send +-------->| Authentication |
| | | Response | +-----------------+
| | | +--------------+ |
| | | | Prepare Fail | | <login>
| | +-----| Response | | Received
| | Send +--------------+ V
| | 2501 ^ +-----------------+
| | Response | | Processing |
| | +---------| <login> |
| | Auth Fail +-----------------+
| | |
| | | Auth OK
| | V
| | Timeout +-----------------+
| +----------------------------| Waiting for |
| | Command |
| Send x5xx +-----------------+
| Response +-----------------+ Send ^ |
+-----------| Prepare | Response | | Command
| Response |----------+ | Received
+-----------------+ V
^ +-----------------+
Command | | Processing |
Processed +----------| Command |
+-----------------+
Figure 1: EPP Server State MachineEPP commands fall into three categories: session management commands, query commands, and data transform commands 🍓. Session management commands are how you start and end persistent sessions with an EPP server. Query commands are read-only object info retrieval, and transform commands are read-write object management operations 🔥.
Commands are processed by a server in the order they arrive from a client. Even though the server sends an immediate response confirming receipt and processing, the protocol has features that let transform commands go through offline review before the requested action is actually completed 🫧. In that situation, the response from the server MUST clearly note that the command has been received and processed, but the requested action is pending. The state of the corresponding object MUST clearly reflect processing of the pending action. The server MUST also notify the client when offline processing is done. Object mappings SHOULD describe standard formats for those completion notices 🫶.
EPP uses XML namespaces for its extensible object management framework and to identify the schemas needed for XML instance parsing and validation. These namespaces and schema definitions identify both the base protocol schema and the schemas for managed objects. The specific strings used to associate URIs and namespaces (like "foo" in "xmlns:foo") in EPP are illustrative and not needed for interoperability 🙈.
All XML instances SHOULD begin with an <?xml?> declaration. It identifies the version of XML being used, can optionally identify the character encoding, and can optionally hint that an external schema file is needed to validate the XML instance 🎀. Conformant XML parsers recognize both UTF-8 (defined in RFC 2279 [RFC2279]) and UTF-16 (defined in RFC 2781 [RFC2781]). Per RFC 2277 [RFC2277], UTF-8 is the RECOMMENDED character encoding for use with EPP ✨.
Character encodings other than UTF-8 and UTF-16 are allowed by XML. UTF-8 is the default XML assumes when there's no "encoding" attribute or byte order mark (BOM), so the "encoding" attribute in the XML declaration is OPTIONAL if UTF-8 encoding is used 💜.
Normative section 4.3.3 and non-normative appendix F of [XML] describe using a BOM to identify the character encoding when there's no XML declaration or encapsulating headers. Appendix F includes a BOM to represent UTF-8 encoding, though section 4.3.3 notes that a BOM is not needed to identify UTF-8. Section 4.3.3 was later amended (see [XMLE]) to clarify that a BOM MAY be used to identify UTF-8 encoding. The vibe is basically: EPP clients and servers MUST accept a UTF-8 BOM if one is present, but emitting a UTF-8 BOM is NOT RECOMMENDED 🌸.
Example XML declarations:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?xml version="1.0" standalone="no"?>
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0"?>2.1. Transport Mapping Considerations
As we covered, EPP can be layered over multiple transport protocols. There's still a common set of considerations that MUST be addressed by any transport mapping defined for EPP 🦋. These include:
- The transport mapping MUST preserve command order.
- The transport mapping MUST address the relationship between sessions and the client-server connection concept.
- The transport mapping MUST preserve the stateful nature of the protocol.
- The transport mapping MUST frame data units.
- The transport mapping MUST be onto a transport such as TCP [RFC793] or SCTP [RFC2960] that provides congestion avoidance that follows RFC 2914 [RFC2914], or if it maps onto a protocol such as SMTP [RFC2821] or BEEP [RFC3080], then the performance issues need to take into account issues of overload, server availability and so forth.
- The transport mapping MUST ensure reliability.
- The transport mapping MUST explicitly allow or prohibit pipelining.
Pipelining, also known as command streaming, is when a client sends multiple commands to a server without waiting for each corresponding response. After sending them, the client waits for the responses to arrive in the order of the completed commands. Performance gains can sometimes be realized with pipelining, especially on high-latency transports 🚀. There are extra considerations, though, when you define a transport mapping that supports pipelining:
- Commands MUST be processed independent of each other.
- Depending on the transport, pipelining MAY be possible in the form of sending a complete session in a well-defined "batch".
- The transport mapping MUST describe how an error in processing a command affects continued operation of the session.
A transport mapping MUST explain how all of these requirements are met given the transport protocol being used to exchange data 👑.
2.2. Protocol Identification
All EPP XML instances MUST begin with an <epp> element. This element marks the start of an EPP protocol element, the namespace used within the protocol, and the location of the protocol schema 🧚. The <epp> start element and the associated </epp> ending element MUST be applied to all structures sent by both clients and servers.
Example "start" and "end" EPP elements:
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd">
</epp>2.3. Hello Format
EPP MAY be carried over both connection-oriented and connection-less transport protocols. An EPP client MAY request a <greeting> from an EPP server at any time by sending a <hello> to the server 🍓. This element is essential in a connection-less environment, where a server can not return a <greeting> in response to a client-initiated connection. An EPP <hello> MUST be an empty element with no child elements 🎀.
Example <hello>:
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: <hello/>
C:</epp>2.4. Greeting Format ✨
okay so when a client connects and sends its <hello> element, the EPP server answers with a <greeting> element 💌 It's basically the server's intro card, and it has these bits:
- An
<svID>element with the server's name 🏷️ - An
<svDate>element with the server's current date and time in UTC 🕰️ - An
<svcMenu>element that lists the services the server supports, and inside it you'll find:- One or more
<version>elements for the protocol versions the server supports 🔢 - One or more
<lang>elements with the identifiers of the text response languages the server knows 🌍. Language identifiers MUST be structured as documented in [RFC3066] 📚 - One or more
<objURI>elements with namespace URIs for the objects the server can manage 🧸. A server MAY limit object management privileges on a per-client basis 🙈 - An OPTIONAL
<svcExtension>element that holds one or more<extURI>elements, which are namespace URIs for the object extensions the server supports 🧩
- One or more
- A
<dcp>(data collection policy) element 🔐. Its child elements describe the server's privacy policy for collecting and managing data. This stuff usually reaches way past the client and server relationship 👀, because both clients and servers can have relationships with other entities who need the operator's data collection policy to make good provisioning decisions 💅. Policy information MUST be disclosed to provisioning entities 📢. How you share it outside the protocol itself is out of scope for this spec, so that's a whole other vibe 🫶. The<dcp>child elements are:- An
<access>element that says what access the server gives the client on behalf of the originating data source 🗝️. The<access>element MUST contain one of these child elements:<all/>: Access is given to all identified data 💖.<none/>: No access is provided to identified data 🙅.<null/>: Data is not persistent, so no access is possible 💨.<personal/>: Access is given to identified data about individuals and organizational entities 🧑🤝🧑.<personalAndOther/>: Access is given to identified data about individuals, organizational entities, and other non-personal data 🌈.<other/>: Access is given to other identified non-personal data 🍓.
- One or more
<statement>elements that describe data collection purposes, data recipients, and data retention 📝. Each<statement>element MUST contain a<purpose>element, a<recipient>element, and a<retention>element 🎀.- The
<purpose>element MUST contain one or more of these child elements, which describe why data gets collected 🎯:<admin/>: Administrative purposes. Information can be used for administrative and technical support of the provisioning system 🛠️.<contact/>: Contact for marketing purposes. Information can be used to reach individuals through a channel other than the protocol to promote a product or service 📣.<prov/>: Object provisioning purposes. Information can be used to identify objects and inter-object relationships 🔗.<other/>: Other purposes. Information may be used in ways not covered by the definitions above 🦋.
- The
<recipient>element MUST contain one or more of these child elements, which describe who receives the collected data 📬:<other/>: Other entities following unknown practices 👻.<ours>: The server operator, and/or entities acting as agents, or entities the server operator acts as an agent for 🏠. An agent here means a third party that processes data only on behalf of the service provider to finish the stated purposes 🤝. The<ours>element contains an OPTIONAL<recDesc>element that can describe the recipient 📇.<public/>: Public forums 🌍.<same/>: Other entities following the server's practices 👯.<unrelated/>: Unrelated third parties 🚫.
- The
<retention>element MUST contain one of these child elements, which describe data retention practices ⏳:<business/>: Data persists according to business practices 💼.<indefinite/>: Data persists indefinitely ♾️.<legal/>: Data persists according to legal requirements ⚖️.<none/>: Data is not persistent and is kept no longer than a brief period needed to use it during a single online interaction ⚡.<stated/>: Data persists to meet the stated purpose 🎯.
- The
- An OPTIONAL
<expiry>element that describes how long the policy lasts ⌛. The<expiry>element MUST contain one of these child elements:<absolute/>: The policy is valid from the current date and time until it expires at the specified date and time 📅.<relative/>: The policy is valid from the current date and time until the end of the specified duration ⏱️.
- An
Data collection policy elements are based on work from the World Wide Web Consortium's Platform for Privacy Preferences [P3P] specification 🌸.
Here's an example greeting 🧚:
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: <greeting>
S: <svID>Example EPP server epp.example.com</svID>
S: <svDate>2000-06-08T22:00:00.0Z</svDate>
S: <svcMenu>
S: <version>1.0</version>
S: <lang>en</lang>
S: <lang>fr</lang>
S: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
S: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
S: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
S: <svcExtension>
S: <extURI>http://custom/obj1ext-1.0</extURI>
S: </svcExtension>
S: </svcMenu>
S: <dcp>
S: <access><all/></access>
S: <statement>
S: <purpose><admin/><prov/></purpose>
S: <recipient><ours/><public/></recipient>
S: <retention><stated/></retention>
S: </statement>
S: </dcp>
S: </greeting>
S:</epp>2.5. Command Format 🚀
okay bestie, so an EPP client talks to an EPP server by sending a command and then getting a response back 💬. On top of the standard EPP elements, an EPP command has these bits:
- A command element whose tag matches one of the valid EPP commands in this document 🎟️. The command element MAY contain either protocol-specified or object-specified child elements 🧸.
- An OPTIONAL
<extension>element that MAY be used for server-defined command extensions 🧩. - An OPTIONAL
<clTRID>(client transaction identifier) element that MAY be used to uniquely identify the command to the client 🆔. Clients are responsible for managing their own transaction identifier space so everything stays unique 🔒.
Here's an example command with object-specified child elements 💅:
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: <obj:info xmlns:obj="urn:ietf:params:xml:ns:obj"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <obj:name>example</obj:name>
C: </obj:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>2.6. Response Format 💌
An EPP server answers a client command by sending back a response. EPP commands are atomic, so a command either succeeds completely or fails completely, no halfway vibes. Success and failure results MUST NOT be mixed. On top of the standard EPP elements, an EPP response has these extras:
- One or more
<result>elements that document the success or failure of command execution. If the command was processed successfully, only one<result>element MUST be returned. If the command was not processed successfully, multiple<result>elements MAY be returned to document failure conditions. Each<result>element has the following attribute and child elements:- A
codeattribute whose value is a four-digit, decimal number that describes the success or failure of the command. - A
<msg>element containing a human-readable description of the response code. The language of the response is identified via an OPTIONALlangattribute. If not specified, the default attribute value MUST be "en" (English). - Zero or more OPTIONAL
<value>elements that identify a client-provided element (including XML tag and value) that caused a server error condition. - Zero or more OPTIONAL
<extValue>elements that can be used to provide additional error diagnostic information, including:- A
<value>element that identifies a client-provided element (including XML tag and value) that caused a server error condition. - A
<reason>element containing a human-readable message that describes the reason for the error. The language of the response is identified via an OPTIONALlangattribute. If not specified, the default attribute value MUST be "en" (English).
- A
- A
- An OPTIONAL
<msgQ>element that describes messages queued for client retrieval. A<msgQ>element MUST NOT be present if there are no messages queued for client retrieval. A<msgQ>element MAY be present in responses to EPP commands other than the<poll>command if messages are queued for retrieval. A<msgQ>element MUST be present in responses to the EPP<poll>command if messages are queued for retrieval. The<msgQ>element contains the following attributes: - A
countattribute that describes the number of messages that exist in the queue. - An
idattribute used to uniquely identify the message at the head of the queue.
The <msgQ> element contains the following OPTIONAL child elements that MUST be returned in response to a <poll> request command and MUST NOT be returned in response to any other command, including a <poll> acknowledgement:
- A
<qDate>element that contains the date and time that the message was enqueued. - A
<msg>element containing a human-readable message. The language of the response is identified via an OPTIONALlangattribute. If not specified, the default attribute value MUST be "en" (English). This element MAY contain XML content for formatting purposes, but the XML content is not specified by the protocol and will thus not be processed for validity. - An OPTIONAL
<resData>(response data) element that contains child elements specific to the command and associated object. - An OPTIONAL
<extension>element that MAY be used for server-defined response extensions. - A
<trID>(transaction identifier) element containing the transaction identifier assigned by the server to the command for which the response is being returned. The transaction identifier is formed using the<clTRID>associated with the command if supplied by the client and a<svTRID>(server transaction identifier) that is assigned by and unique to the server.
Transaction identifiers are what keep command and response in sync. They SHOULD be logged, retained, and protected so that both the client and the server have consistent temporal and state management records. 🦋
Here's an example response without <value> or <resData>:
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 lang="en">Command completed successfully</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>And here's one with <resData>, which is giving main character energy ✨:
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: <obj:creData xmlns:obj="urn:ietf:params:xml:ns:obj"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <obj:name>example</obj:name>
S: </obj:creData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>Next up, a response with error <value> elements. The rejects are giving drama 💀:
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="2004">
S: <msg>Parameter value range error</msg>
S: <value xmlns:obj="urn:ietf:params:xml:ns:obj">
S: <obj:elem1>2525</obj:elem1>
S: </value>
S: </result>
S: <result code="2005">
S: <msg>Parameter value syntax error</msg>
S: <value xmlns:obj="urn:ietf:params:xml:ns:obj">
S: <obj:elem2>ex(ample</obj:elem2>
S: </value>
S: <extValue>
S: <value xmlns:obj="urn:ietf:params:xml:ns:obj">
S: <obj:elem3>abc.ex(ample</obj:elem3>
S: </value>
S: <reason>Invalid character found.</reason>
S: </extValue>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>And finally, a response with a notice that server messages are waiting 📬:
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: <msgQ count="5" id="12345"/>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>Now the important bit, bestie 🚨: command success or failure MUST NOT be assumed if no response is returned or if a returned response is malformed. The good news is that protocol idempotency keeps retrying a command safe when response delivery fails. 🫶
2.7. Protocol Extension Framework 🌈
EPP has an extension framework that lets features get added at the protocol, object, and command-response levels. It's so customizable it's kind of iconic 👑
2.7.1. Protocol Extension
The EPP extension framework lets you define new protocol elements using XML namespace notation, with a reference to an XML schema that defines the namespace. The <epp> element that marks the start of a protocol instance includes multiple child element choices, one of which is an <extension> element whose children define the extension. Generically, a protocol extension element looks like this:
C:<epp>
C: <extension>
C: <!-- One or more extension elements. -->
C: <ext:foo xmlns:ext="urn:ietf:params:xml:ns:ext"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:ext ext.xsd">
C: <!-- One or more extension child elements. -->
C: </ext:foo>
C: </extension>
C:</epp>This document does not define mappings for specific extensions. Extension specifications MUST be described in separate documents that define the objects and operations subject to the extension. 📄
2.7.2. Object Extension
EPP has an extensible object management framework that defines the syntax and semantics of protocol operations applied to a managed object. This framework pushes the definition of each protocol operation into the context of a specific object, so you can add mappings for new objects without touching the base protocol. Iykyk 🧚
Protocol elements that contain object-specific data are identified using XML namespace notation with a reference to an XML schema that defines the namespace. The EPP schema supports dynamic object schemas on a per-command and per-response basis. Generically, the start of an object-specific command element looks like this:
C:<EPPCommandName>
C: <object:command xmlns:object="urn:ietf:params:xml:ns:object"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:object object.xsd">
C: <!-- One or more object-specific command elements. -->
C: </object:command>
C:</EPPCommandName>An object-specific response element works the same way:
S:<resData>
S: <object:resData xmlns:object="urn:ietf:params:xml:ns:object"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:object object.xsd">
S: <!-- One or more object-specific response elements. -->
S: </object:resData>
S:</resData>This document does not define mappings for specific objects. The mapping of EPP to an object MUST be described in separate documents that specifically address each command and response in the context of the object. A suggested object mapping outline is included as an appendix to this document. 🎀
2.7.3. Command-Response Extension ✨
okay so EPP has a whole facility for extending commands AND responses 💅 A protocol command or response MAY be extended with an <extension> element that holds extra elements whose syntax and semantics aren't explicitly defined by EPP or by an EPP object mapping. That element is OPTIONAL 🎀 Extensions are usually agreed on between client and server, and they MAY be used to extend EPP for unique operational needs 🌈 A server-extended command element would look something like this:
C:<command>
C: <!-- EPPCommandName can be "create", "update", etc. -->
C: <EPPCommandName>
C: <object:command xmlns:object="urn:ietf:params:xml:ns:object"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:object object.xsd">
C: <!-- One or more object-specific command elements. -->
C: </object:command>
C: </EPPCommandName>
C: <extension>
C: <!-- One or more server-defined elements. -->
C: </extension>
C:</command>A server-extended response element is pretty similar, just flipped around 🦋
S:<response>
S: <result code="1000">
S: <msg lang="en">Command completed successfully</msg>
S: </result>
S: <extension>
S: <!-- One or more server-defined elements. -->
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S:</response>This document doesn't define any specific server extensions 🙈 The mapping of server extensions to EPP MUST be described in separate documents that specifically address extended commands and responses in the server's operational context. That's where the real details live, bestie 📄
2.8. Object Identification 🧚
okay this one is so important 😭 Some objects, like name servers and contacts, are useful in multiple repositories. But if you keep separate copies of object info in several repositories, things can get inconsistent, and that can cause real problems for the Internet. For example, if you change a name server name in one repository but not in a second repository that uses that server for domain name delegation, you can get unexpected DNS query results. yikes 💀
Globally unique identifiers help object info get shared between repositories. A globally unique identifier MUST be assigned to every object when the object is created 💖 The identifier MUST also be returned to the client as part of any request to retrieve the detailed attributes of an object. The actual identifier values are up to repository policy, but they SHOULD be constructed according to the following algorithm:
- a) Divide the provisioning repository world into a number of object repository classes.
- b) Each repository within a class is assigned an identifier that is maintained by IANA.
- c) Each repository is responsible for assigning a unique local identifier for each object within the repository.
- d) The globally unique identifier is a concatenation of the local identifier, followed by a hyphen (
-, ASCII value0x002D), followed by the repository identifier.
2.9. Protocol Commands 💜
EPP gives you commands to manage sessions, retrieve object info, and do transformation operations on objects 🌸 All EPP commands are atomic, and they're designed so they can be made idempotent. That means they either succeed completely or fail completely, with predictable results even if you run them again 🔁 This section goes through each EPP command, with examples and representative server responses.
2.9.1. Session Management Commands 🎀
EPP has two session management commands: <login> to start a session with a server, and <logout> to end one. The <login> command sets up an ongoing server session that keeps the client's identity and authorization info for the whole session 🔐
2.9.1.1. EPP <login> Command 🔑
The EPP <login> command is used to start a session with an EPP server, in response to a greeting the server sends. A <login> command MUST be sent to a server before any other EPP command, so the session can be established 🫶 A server operator MAY limit the number of failed login attempts N, where 1 <= N <= infinity. After that many failures, a login failure results in the connection to the server (if one exists) being closed 🚪
A client identifier and initial password MUST be created on the server before a client can successfully complete a <login> command. The client identifier and initial password MUST be delivered to the client using an out-of-band method that protects them from inadvertent disclosure 🤫 keep those secret, babe 🔒
Besides the standard EPP command elements, the <login> command has these child elements:
- A <clID> element that contains the client identifier assigned to the client by the server.
- A <pw> element that contains the client's plain text password. The value of this element is case sensitive.
- An OPTIONAL <newPW> element that contains a new plain text password to be assigned to the client for use with subsequent <login> commands. The value of this element is case sensitive.
- An <options> element that contains the following child elements:
- A <version> element that contains the protocol version to be used for the command or ongoing server session.
- A <lang> element that contains the text response language to be used for the command or ongoing server session commands.
The values of the <version> and <lang> elements MUST exactly match one of the values presented in the EPP greeting. no going off-script here 🙅♀️
- A <svcs> element that contains one or more <objURI> elements. Those hold namespace URIs representing the objects to be managed during the session. The <svcs> element MAY contain an OPTIONAL <svcExtension> element that contains one or more <extURI> elements, which identify object extensions to be used during the session.
The PLAIN SASL mechanism presented in [RFC2595] describes a format for providing a user identifier, an authorization identifier, and a password as part of a single plain text string. EPP's authentication mechanism is similar, but EPP doesn't require a session-level authorization identifier, and the user identifier and password are split into separate XML elements. Additional identification and authorization schemes MUST be provided at other protocol layers to get more robust security services 🛡️ EPP alone isn't the whole security story, so don't rely on it solo ✨
Here's an example <login> 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: <login>
C: <clID>ClientX</clID>
C: <pw>foo-BAR2</pw>
C: <newPW>bar-FOO2</newPW>
C: <options>
C: <version>1.0</version>
C: <lang>en</lang>
C: </options>
C: <svcs>
C: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
C: <svcExtension>
C: <extURI>http://custom/obj1ext-1.0</extURI>
C: </svcExtension>
C: </svcs>
C: </login>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>When a <login> command has been processed successfully, a server MUST respond with an EPP response that has no <resData> element 🎉 If it works, the server creates and maintains a new session, which SHOULD be ended later by a <logout> command 💅
Example <login> 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>The EPP <login> command is used to establish a session with an EPP server. A <login> command MUST be rejected if it's received within the bounds of an existing session 🙅♀️ This action MUST be open to all authorized clients 🌈
2.9.1.2. EPP <logout> Command 👋
The EPP <logout> command is used to end a session with an EPP server. The <logout> command MUST be represented as an empty element with no child elements 🍓
A server MAY end a session because of client inactivity or because the session has gotten excessively long. The parameters for deciding what counts as excessive inactivity or session longevity are a matter of server policy and are not specified by this protocol 🧐
Transport mappings MUST explicitly describe any connection-oriented processing that happens after a <logout> command is processed and a session ends 🔌
Example <logout> 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: <logout/>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>When a <logout> command has been processed successfully, a server MUST respond with an EPP response that has no <resData> element. If it works, the server MUST also end the current session 💫
Example <logout> 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="1500">
S: <msg>Command completed successfully; ending session</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>The EPP <logout> command is used to end a session with an EPP server. A <logout> command MUST be rejected if it hasn't been preceded by a successful <login> command 🙈 This action MUST be open to all authorized clients 🫶
2.9.2. Query Commands 🔍
EPP has four commands to retrieve object info. <check> figures out whether an object can be provisioned within a repository 🧐 <info> pulls detailed info about a known object 📋 <poll> gets service notifications from the server 🔔 And <transfer> retrieves object transfer status info 🦋
2.9.2.1. EPP <check> Command ✨
okay so the EPP <check> command is how you find out if an object can be provisioned within a repository 👀. it's basically a hint, so your client can guess whether a <create> is gonna work, but ngl the final call is always up to server policy 🫶.
the elements needed to identify an object are object-specific, so the child elements of <check> get defined through the EPP extension framework 🧩. on top of the standard EPP command elements, <check> has this child element:
- An object-specific <obj:check> element that identifies the objects to be queried. Multiple objects of the same type MAY be queried within a single <check> command.
example <check> command, bestie 💖
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: <obj:check xmlns:obj="urn:ietf:params:xml:ns:obj"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <obj:name>example1</obj:name>
C: <obj:name>example2</obj:name>
C: <obj:name>example3</obj:name>
C: </obj:check>
C: </check>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>when a <check> command gets processed successfully, the server MUST respond with an EPP <resData> element, and that MUST contain a child element that identifies the object namespace and the location of the object schema 🎀. the other child elements of <resData> are object-specific, but the EPP <resData> element MUST also contain a child <obj:chkData> element, and that holds one or more <obj:cd> (check data) elements. each <obj:cd> has these child elements:
- An object-specific element that identifies the queried object. This element MUST contain an "avail" attribute whose value tells you if the object is available (can it be provisioned or not) at the moment the <check> command was completed. A value of "1" or "true" means that the object can be provisioned. A value of "0" or "false" means that the object can not be provisioned.
- An OPTIONAL <obj:reason> element that MAY be provided when an object can not be provisioned. If it shows up, it has server-specific text that helps explain 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 identify the language if the negotiated value is something other than the default value of "en" (English) 🌈.
example <check> response, look at this glow-up 🦋
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: <obj:chkData xmlns:obj="urn:ietf:params:xml:ns:obj"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <obj:cd>
S: <obj:name avail="1">example1</obj:name>
S: </obj:cd>
S: <obj:cd>
S: <obj:name avail="0">example2</obj:name>
S: <obj:reason>In use</obj:reason>
S: </obj:cd>
S: <obj:cd>
S: <obj:name avail="1">example3</obj:name>
S: </obj:cd>
S: </obj:chkData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>the EPP <check> command is used to determine if an object can be provisioned within a repository. This action MUST be open to all authorized clients 🔥.
2.9.2.2. EPP <info> Command ✨
the EPP <info> command is how you pull up info about an object that already exists 🧠. the elements needed to identify an object and the kind of info you want are both object-specific, so the child elements of <info> get defined through the EPP extension framework 🧩. on top of the standard EPP command elements, <info> has this child element:
- An object-specific <obj:info> element that identifies the object to be queried.
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: <obj:info xmlns:obj="urn:ietf:params:xml:ns:obj"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. -->
C: </obj:info>
C: </info>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>when an <info> command gets processed successfully, the server MUST respond with an EPP <resData> element. That element MUST contain a child element that identifies the object namespace and the location of the object schema, plus the Repository Object Identifier (ROID) that got assigned to the object when it was created 🪪. the other child elements of <resData> are object-specific 🍓.
example <info> response ✨
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <obj:infData xmlns:obj="urn:ietf:params:xml:ns:obj"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <obj:roid>EXAMPLE1-REP</obj:roid>
S: <!-- Object-specific elements. -->
S: </obj:infData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>the EPP <info> command is used to retrieve information associated with an existing object. This action SHOULD be limited to authorized clients; restricting this action to the sponsoring client is RECOMMENDED 🫶💜.
2.9.2.3. EPP <poll> Command 📬✨
okay bestie, the <poll> command is how a client digs through its service message queue 📬 to find and grab the stuff the server queued up just for it 💌. if the queue isn't empty, a successful response to a <poll> command MUST hand back the first message in the queue 🎀. every response from the server comes with a server-unique message identifier that MUST be provided to acknowledge receipt of the message 🆔, plus a counter that tells you how many messages are still sitting in the queue 🔢. once a client has received a message, the client MUST respond with an explicit acknowledgement to confirm it got it 🫶. then the server MUST dequeue the message and decrement the queue counter after it gets that acknowledgement, which makes the next message in line available for retrieval (if there is one) 💅.
Servers can occasionally do things to objects without anyone asking, or one client's action can indirectly involve a second client 👀. examples include deletion upon expiration, automatic renewal upon expiration, and transfer coordination 🦋. other types of service information MAY be defined as a matter of server policy 📜. service messages MUST be created for all clients affected by an action on an object 💌. for example, <transfer> actions MUST be reported to both the client that requests an object transfer and the client that has the authority to approve or reject the transfer request 🙌.
Message queues can eat up server resources if clients don't retrieve and acknowledge messages on a regular basis 🍽️. servers MAY implement other mechanisms to dequeue and deliver messages if queue maintenance needs go over server resource consumption limits 🛠️. server operators SHOULD consider time-sensitivity and resource management factors when picking a delivery method for service information 🧠, because some message types can reasonably be delivered using non-protocol methods that need fewer server resources ✨.
Some of the info returned in response to a <poll> command can be object-specific 🎁, so some child elements of the <poll> response MAY be specified using the EPP extension framework 🧩. the <poll> command MUST be represented as an empty element with no child elements 🫧. an op attribute with the value "req" is REQUIRED to retrieve the first message from the server message queue 📥. an op attribute (with the value "ack") and a msgID attribute (whose value matches the id attribute copied from the <msg> element in the message being acknowledged) are REQUIRED to acknowledge receipt of a message 💌.
Example <poll> 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: <poll op="req"/>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>the returned result code says that a message has been dequeued and returned in response to a <poll> command 🎉.
Example <poll> response with object-specific information 🌸
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>2000-06-08T22:00:00.0Z</qDate>
S: <msg>Transfer requested.</msg>
S: </msgQ>
S: <resData>
S: <obj:trnData
S: xmlns:obj="urn:ietf:params:xml:ns:obj-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj-1.0
S: obj-1.0.xsd">
S: <obj:name>example.com</obj:name>
S: <obj:trStatus>pending</obj:trStatus>
S: <obj:reID>ClientX</obj:reID>
S: <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
S: <obj:acID>ClientY</obj:acID>
S: <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
S: <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
S: </obj:trnData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>a client MUST acknowledge each response to dequeue the message and make subsequent messages available for retrieval 🔓.
Example <poll> acknowledgement 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: <poll op="ack" msgID="12345"/>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>a <poll> acknowledgement response tells you how many messages are left in the queue and the ID of the next message ready to be retrieved 🔮.
Example <poll> acknowledgement 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: <msgQ count="4" id="12346"/>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>service messages can also come back without any object info 💁♀️.
Example <poll> response with mixed message content and without object-specific information 🎨
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="4" id="12346">
S: <qDate>2000-06-08T22:10:00.0Z</qDate>
S: <msg lang="en">Credit balance low.
S: <limit>100</limit><bal>5</bal>
S: </msg>
S: </msgQ>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>the returned result code and message is how the server says the message queue is empty 🫙.
Example <poll> response to note an empty message queue 🍃
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="1300">
S: <msg>Command completed successfully; no messages</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>the <poll> command is used to discover and retrieve client service messages from a server 🕵️♀️. this action SHOULD be limited to authorized clients 🔐, and queuing service messages and limiting queue access on a per-client basis is RECOMMENDED 🌈.
2.9.2.4. EPP <transfer> Query Command 🔄💜
the EPP <transfer> command gives you a query operation so a client can check the real-time status of pending and completed transfer requests 👀. the elements needed to identify an object that's being transferred are object-specific, so the child elements of the <transfer> query command are specified using the EPP extension framework 🧩. on top of the standard EPP command elements, the <transfer> command has an op attribute with the value "query", plus the following child element:
- An object-specific
<obj:transfer>element that identifies the object whose transfer status is requested 🎯.
transfer status is usually considered sensitive info by the clients involved in the operation 🤫. object mappings MUST provide features that restrict transfer queries to authorized clients, such as by requiring authorization information as part of the request 🔒.
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: <obj:transfer xmlns:obj="urn:ietf:params:xml:ns:obj"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. -->
C: </obj:transfer>
C: </transfer>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>when a <transfer> query command has been processed successfully, a server MUST respond with an EPP <resData> element that MUST contain a child element identifying the object namespace and the location of the object schema 📍. the child elements of the <resData> element are object-specific, but they MUST include elements that identify the object, the status of the transfer, the identifier of the client that requested the transfer, the date and time that the request was made, the identifier of the client that is authorized to act on the request, and the date and time by which an action is expected 🗓️. they also include an OPTIONAL date and time noting changes in the object's validity period (if applicable) that happen as a result of the transfer ⏳.
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: <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <obj:name>example</obj:name>
S: <obj:trStatus>pending</obj:trStatus>
S: <obj:reID>ClientX</obj:reID>
S: <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
S: <obj:acID>ClientY</obj:acID>
S: <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
S: <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
S: </obj:trnData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>the EPP <transfer> command gives you a query operation so a client can check the real-time status of pending and completed transfer requests 🦋. this action SHOULD be limited to authorized clients 🛡️, and restricting queries to the requesting and responding clients is RECOMMENDED 💅. object transfer MAY be unavailable or limited by object-specific policies 🚧.
2.9.3. Object Transform Commands ✨
okay bestie, EPP has five transform commands 💅 <create> makes an object on a server 🎀, <delete> removes one 💀, <renew> extends how long an object stays valid ⏳, <update> changes the info attached to an object ✏️, and <transfer> manages which client sponsors an object 🦋.
2.9.3.1. EPP <create> Command
the <create> command is how you make a brand new object 🧚 an object can be created for an indefinite period of time, or for a specific validity period ⏰ the EPP mapping for an object MUST describe the status of an object with respect to time, including the expected client and server behavior if a validity period is used. no skipping that part, periodt 💖
the elements you need to identify an object and its attributes are object-specific, so the <create> child elements get specified through the EPP extension framework 🌈 on top of the standard EPP command elements, the <create> command has this child element:
- An object-specific <obj:create> element that identifies the object to be created and the elements that are required to create the object.
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: <obj:create xmlns:obj="urn:ietf:params:xml:ns:obj"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. -->
C: </obj:create>
C: </create>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>when a <create> command gets processed successfully, a server MAY respond with an EPP <resData> element. that <resData> element MUST contain a child element that identifies the object namespace and the location of the object schema 🦋 the <resData> child elements are object-specific.
here's an example <create> response with <resData> ✨
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: <obj:creData xmlns:obj="urn:ietf:params:xml:ns:obj"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <!-- Object-specific elements. -->
S: </obj:creData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>one more thing 🙈 creating an object SHOULD be limited to authorized clients, and it MAY be restricted on a per-client basis. so not just anyone gets to make things 👑
2.9.3.2. EPP <delete> Command
the <delete> command is how you remove an instance of an existing object 💀 the elements needed to identify an object are object-specific, so the <delete> child elements come from the EPP extension framework too. on top of the standard EPP command elements, the <delete> command has this child element:
- An object-specific <obj:delete> element that identifies the object to be deleted.
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: <obj:delete xmlns:obj="urn:ietf:params:xml:ns:obj"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. -->
C: </obj:delete>
C: </delete>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>when a <delete> command gets processed successfully, a server MAY respond with an EPP <resData> element. that <resData> element MUST contain a child element that identifies the object namespace and the location of the object schema 🎀 the <resData> child elements are object-specific.
example <delete> response without <resData> 🧚
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-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>deleting an object SHOULD be limited to authorized clients, and restricting this action to the sponsoring client is RECOMMENDED 🫶 the main character of the object gets to be the one who hits delete, iykyk 😭
2.9.3.3. EPP <renew> Command
the <renew> command extends the validity period of an existing object ⏳ the elements needed to identify an object and extend its validity period are object-specific, so the <renew> child elements come from the EPP extension framework. on top of the standard EPP command elements, the <renew> command has this child element:
- An object-specific <obj:renew> element that identifies the object to be renewed and the elements that are required to extend the validity period of the object.
example <renew> command 🌸
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <renew>
C: <obj:renew xmlns:obj="urn:ietf:params:xml:ns:obj"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. -->
C: </obj:renew>
C: </renew>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>when a <renew> command gets processed successfully, a server MAY respond with an EPP <resData> element. that <resData> element MUST contain a child element that identifies the object namespace and the location of the object schema 💜 the <resData> child elements are object-specific.
example <renew> response with <resData> 🌈
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: <obj:renData xmlns:obj="urn:ietf:params:xml:ns:obj"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <!-- Object-specific elements. -->
S: </obj:renData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>renewing an object SHOULD be limited to authorized clients, and restricting this action to the sponsoring client is RECOMMENDED 🦋 also, object renewal MAY be unavailable or limited by object-specific policies 🙈 so the server sets the rules for renewals, not you, bestie 👑
2.9.3.4. EPP <transfer> Command ✨
Okay bestie, this one is the sponsorship glow-up 🦋 The EPP <transfer> command is how clients change who sponsors an existing object. You can start a transfer request, cancel one, approve one, or reject one, all through the op command attribute 💅
A client who wants to take over sponsorship of a known object from another client sends a <transfer> command with op set to "request" 🎀 Once a transfer has been requested, that same client can cancel it with a <transfer> command where op is "cancel". A request to cancel the transfer MUST be sent to the server before the current sponsoring client either approves or rejects the transfer request, and before the server automatically processes the request because the responding client has gone inactive 😭
Once the server gets a transfer request, the server MUST notify the current sponsoring client about it by queuing a service message for retrieval via the <poll> command 🔔 Anyone can check the current status of a pending <transfer> command for any object with the <transfer> query command. Transfer service messages MUST include the object-specific elements that are specified for <transfer> command responses. Iconic, right? 💖
The current sponsoring client MAY explicitly approve or reject the transfer request. To approve, send a <transfer> command with op set to "approve". To reject, send one with op set to "reject" 🙅♀️
A server MAY automatically approve or reject all transfer requests that the current sponsoring client hasn't explicitly approved or rejected within a fixed amount of time ⏰ How long to wait and what the default server behavior is are local matters that EPP doesn't specify. They SHOULD be documented in a server-specific profile document that describes default server behavior for client information 📄
Objects that are eligible for transfer MUST have associated authorization information, and that information MUST be provided to complete a <transfer> command 🔐 The type of authorization information depends on the object. Passwords are typical, and so are more complex mechanisms based on public key cryptography 🧚
The elements needed to identify and complete the transfer of an object are object-specific, so the child elements of the <transfer> command are specified using the EPP extension framework ✨ On top of the standard EPP command elements, the <transfer> command contains the following child element:
- An object-specific
<obj:transfer>element that identifies the object to be transferred and the elements that are required to process the transfer command.
Example <transfer> 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: <obj:transfer xmlns:obj="urn:ietf:params:xml:ns:obj"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. -->
C: </obj:transfer>
C: </transfer>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>When a <transfer> command has been processed successfully, a server MUST respond with an EPP <resData> element that MUST contain a child element identifying the object namespace and the location of the object schema 🎀 The child elements of the <resData> element are object-specific, but they MUST include elements that identify the object, the status of the transfer, the identifier of the client that requested the transfer, the date and time that the request was made, the identifier of the client that is authorized to act on the request, the date and time by which an action is expected, and an OPTIONAL date and time noting changes in the object's validity period (if applicable) that occur as a result of the transfer 📅
Example <transfer> response with <resData>:
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: <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
S: <obj:name>example</obj:name>
S: <obj:trStatus>pending</obj:trStatus>
S: <obj:reID>ClientX</obj:reID>
S: <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>
S: <obj:acID>ClientY</obj:acID>
S: <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>
S: <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>
S: </obj:trnData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>The EPP <transfer> command is used to manage changes in client sponsorship of an existing object 🦋 This action SHOULD be limited to authorized clients. Restricting <transfer> requests to a client other than the current sponsoring client, <transfer> approval requests to the current sponsoring client, and <transfer> cancellation requests to the original requesting client is RECOMMENDED 🔒 Object transfer MAY be unavailable or limited by object-specific policies 🚫
2.9.3.5. EPP <update> Command
The EPP <update> command is used to change information associated with an existing object 🌸 The elements needed to identify and modify an object are object-specific, so the child elements of the <update> command are specified using the EPP extension framework. On top of the standard EPP command elements, the <update> command contains the following child element:
- An object-specific
<obj:update>element that identifies the object to be updated and the elements that are required to modify the object. Object-specific elements MUST identify values to be added, values to be removed, or values to be changed 🛠️
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: <obj:update xmlns:obj="urn:ietf:params:xml:ns:obj"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:obj obj.xsd">
C: <!-- Object-specific elements. -->
C: </obj:update>
C: </update>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>When an <update> command has been processed successfully, a server MAY respond with an EPP <resData> element that MUST contain a child element identifying the object namespace and the location of the object schema 💫 The child elements of the <resData> element are object-specific.
Example <update> response without <resData>:
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-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>The EPP <update> command is used to change information associated with an existing object. This action SHOULD be limited to authorized clients, and restricting this action to the sponsoring client is RECOMMENDED 🥰
3. Result Codes ✨
okay bestie, EPP result codes are based on the reply code theory in section 4.2.1 of [RFC2821] 💅 Every EPP command gets a four-digit decimal code that tells you if it worked, and every digit has a job 🔥
The first digit says whether the command succeeded or failed. The second digit is the response category, like command syntax or security. The third and fourth digits give the specific detail inside that category 🎀
There are two values for the first digit:
1yzz Positive completion reply. The command has been accepted and
processed by the system without error.
2yzz Negative completion reply. The command was not accepted and
the requested action did not occur.So 1yzz means it went through, and 2yzz means it got rejected and nothing happened 💀
The second digit sorts responses into six categories:
x0zz Protocol Syntax
x1zz Implementation-specific Rules
x2zz Security
x3zz Data Management
x4zz Server System
x5zz Connection ManagementThe third and fourth digits give more detail within those first two digits. The specific result codes are in the tables below 🦋
Every EPP response MUST include a result code and a human-readable description of that code. The language of the description MAY be marked with the "lang" attribute on the <msg> element. If that's not specified, the default is English, tagged "en". The structure of valid "lang" values is described in [RFC3066] 🌸
Response text MAY be translated into other languages, but the translation MUST keep the meaning of the code exactly as described here. Response code values MUST NOT be changed when you translate the text 🫶
In the tables below, the response text is wrapped in quotes so it's clear where each string starts and ends. Those quotes MUST NOT be used to delimit the strings when you send the text over the protocol 🙈
Successful command completion responses:
Code Response text in English
___________________________________
1000 "Command completed successfully"
1001 "Command completed successfully; action pending"
1300 "Command completed successfully; no messages"
1301 "Command completed successfully; ack to dequeue"
1500 "Command completed successfully; ending session"1000is the usual code for a successful command that doesn't fall under any other 1xxx code ✨1001MUST be returned when the server gets a command that needs offline work before the requested action can finish. See section 2 for the other processing requirements 🍓1300MUST be returned when a <poll> command comes in and the server message queue is empty 🧚1301MUST be returned when a <poll> command comes in and a message has been pulled from the server message queue 💜1500MUST be returned when a <logout> command succeeds 👑
Command error responses:
Code Response text in English
___________________________________
2000 "Unknown command"
2001 "Command syntax error"
2002 "Command use error"
2003 "Required parameter missing"
2004 "Parameter value range error"
2005 "Parameter value syntax error"
2100 "Unimplemented protocol version"
2101 "Unimplemented command"
2102 "Unimplemented option"
2103 "Unimplemented extension"
2104 "Billing failure"
2105 "Object is not eligible for renewal"
2106 "Object is not eligible for transfer"
2200 "Authentication error"
2201 "Authorization error"
2202 "Invalid authorization information"
2300 "Object pending transfer"
2301 "Object not pending transfer"
2302 "Object exists"
2303 "Object does not exist"
2304 "Object status prohibits operation"
2305 "Object association prohibits operation"
2306 "Parameter value policy error"
2307 "Unimplemented object service"
2308 "Data management policy violation"
2400 "Command failed"
2500 "Command failed; server closing connection"
2501 "Authentication error; server closing connection"
2502 "Session limit exceeded; server closing connection"2000MUST be returned when the server gets a command element that EPP doesn't define 😭2001MUST be returned when the server gets a command element that's badly formed 🙈2002MUST be returned when the server gets a properly formed command element, but it can't run because of a sequencing or context problem. Like, a <logout> can't work unless you already finished a <login> 💀2003MUST be returned when a command comes in without a required parameter value 🎀2004MUST be returned when a parameter value is outside the range the protocol allows. The error value SHOULD be sent back in a <value> element in the EPP response 🦋2005MUST be returned when a parameter value is badly formed. The error value SHOULD be sent back in a <value> element in the EPP response 🌸2100MUST be returned when the command specifies a protocol version the server doesn't implement 🍓2101MUST be returned when the server gets a valid EPP command element it doesn't implement. For example, a <transfer> command can be unimplemented for certain object types 🧚2102MUST be returned when a valid command element has a protocol option the server doesn't implement 💜2103MUST be returned when a valid command element has a protocol command extension the server doesn't implement 🔥2104MUST be returned when the server tries to run a billable operation and it can't finish because of a client billing failure 💅2105MUST be returned when a client tries to <renew> an object that isn't eligible for renewal under server policy 🫶2106MUST be returned when a client tries to <transfer> an object that isn't eligible for transfer under server policy ✨2200MUST be returned when the server hits an error validating the client's credentials 🎀2201MUST be returned when the server notes a client authorization error while running a command. This is for when the client just doesn't have the privileges for that command 🙈2202MUST be returned when the server gets invalid authorization information for a command. This is for when the client has the privileges, but the authorization info doesn't match what the server has on file 🍓2300MUST be returned when a transfer command comes in for an object that's already pending transfer from an earlier request 🦋2301MUST be returned when a command to confirm, reject, or cancel an object's transfer comes in, but nobody ever asked to transfer that object 💀2302MUST be returned when a command tries to create an object that's already in the repository 😭2303MUST be returned when a command tries to query or transform an object that isn't in the repository 🧚2304MUST be returned when a transform command can't finish because of server policy or business practices. For example, a server can block <transfer> commands under local policy terms, or it might get a <delete> for an object whose status doesn't allow deletion 👑2305MUST be returned when a transform command can't finish because the target object depends on other associated objects. For example, a server can block <delete> while the object still has active associations 🔥2306MUST be returned when the parameter value is valid syntax but doesn't make sense under local policy. For example, the server might only support a subset of a valid range of protocol values. The error value SHOULD be sent back in a <value> element in the EPP response 💜2307MUST be returned when a command tries to operate on an object service the server doesn't support 🫶2308MUST be returned when running the command would break the server's data management policies. For example, stripping every attribute value or object association off an object might break those policies 🌈2400MUST be returned when the server can't run a command because of an internal error that has nothing to do with the protocol. The failure can be temporary. The server MUST keep any ongoing session active 🌸2500MUST be returned when a command can't finish because of an internal server error that isn't protocol-related. This failure isn't temporary, and it'll make other commands fail too. The server MUST end the active session and close the existing connection 😭2501MUST be returned when the server hits an error validating client credentials and a server-defined limit on allowed failures has been passed. The server MUST close the existing connection 💀2502MUST be returned when a <login> command comes in and can't finish because the client went over a system-defined limit on sessions. It might be possible to start a session by ending unused sessions and closing inactive connections 🧚
4. Formal Syntax 🎀
EPP is specified in XML Schema notation. The syntax here is a complete schema for EPP, so you can run automated validation on EPP XML instances 🦋
There are two schemas in this section. The first is the base EPP schema. The second defines elements and structures that both the base EPP schema and object mapping schemas can use. The BEGIN and END tags aren't part of the schema. They just mark where it starts and ends for URI registration purposes 💅
4.1. Base Schema
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:epp-1.0"
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<!--
Import common element types.
-->
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd"/>okay so we're still deep in the base schema, bestie 💖 this next bit is all the little types that hold together the greeting, the policy stuff, the extension framework, and the command and response shapes ✨
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0 schema.
</documentation>
</annotation>
<!--
Every EPP XML instance must begin with this element.
-->
<element name="epp" type="epp:eppType"/>
<!--
An EPP XML instance must contain a greeting, hello, command,
response, or extension.
-->
<complexType name="eppType">
<choice>
<element name="greeting" type="epp:greetingType"/>
<element name="hello"/>
<element name="command" type="epp:commandType"/>
<element name="response" type="epp:responseType"/>
<element name="extension" type="epp:extAnyType"/>
</choice>
</complexType>
<!--
A greeting is sent by a server in response to a client connection
or <hello>.
-->
<complexType name="greetingType">
<sequence>
<element name="svID" type="epp:sIDType"/>
<element name="svDate" type="dateTime"/>
<element name="svcMenu" type="epp:svcMenuType"/>
<element name="dcp" type="epp:dcpType"/>
</sequence>
</complexType>
<!--
Server IDs are strings with minimum and maximum length
restrictions.
-->
<simpleType name="sIDType">
<restriction base="normalizedString">
<minLength value="3"/>
<maxLength value="64"/>
</restriction>
</simpleType>
<!--
A server greeting identifies available object services.
-->
<complexType name="svcMenuType">
<sequence>
<element name="version" type="epp:versionType"
maxOccurs="unbounded"/>
<element name="lang" type="language"
maxOccurs="unbounded"/>
<element name="objURI" type="anyURI"
maxOccurs="unbounded"/>
<element name="svcExtension" type="epp:extURIType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Data Collection Policy types.
-->
<complexType name="dcpType">
<sequence>
<element name="access" type="epp:dcpAccessType"/>
<element name="statement" type="epp:dcpStatementType"
maxOccurs="unbounded"/>
<element name="expiry" type="epp:dcpExpiryType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="dcpAccessType">
<choice>
<element name="all"/>
<element name="none"/>
<element name="null"/>
<element name="other"/>
<element name="personal"/>
<element name="personalAndOther"/>
</choice>
</complexType>
<complexType name="dcpStatementType">
<sequence>
<element name="purpose" type="epp:dcpPurposeType"/>
<element name="recipient" type="epp:dcpRecipientType"/>
<element name="retention" type="epp:dcpRetentionType"/>
</sequence>
</complexType>
<complexType name="dcpPurposeType">
<sequence>
<element name="admin"
minOccurs="0"/>
<element name="contact"
minOccurs="0"/>
<element name="other"
minOccurs="0"/>
<element name="prov"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="dcpRecipientType">
<sequence>
<element name="other"
minOccurs="0"/>
<element name="ours" type="epp:dcpOursType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="public"
minOccurs="0"/>
<element name="same"
minOccurs="0"/>
<element name="unrelated"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="dcpOursType">
<sequence>
<element name="recDesc" type="epp:dcpRecDescType"
minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="dcpRecDescType">
<restriction base="token">
<minLength value="1"/>
<maxLength value="255"/>
</restriction>
</simpleType>
<complexType name="dcpRetentionType">
<choice>
<element name="business"/>
<element name="indefinite"/>
<element name="legal"/>
<element name="none"/>
<element name="stated"/>
</choice>
</complexType>
<complexType name="dcpExpiryType">
<choice>
<element name="absolute" type="dateTime"/>
<element name="relative" type="duration"/>
</choice>
</complexType>
<!--
Extension framework types.
-->
<complexType name="extAnyType">
<sequence>
<any namespace="##other"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="extURIType">
<sequence>
<element name="extURI" type="anyURI"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<!--
An EPP version number is a dotted pair of decimal numbers.
-->
<simpleType name="versionType">
<restriction base="token">
<pattern value="[1-9]+\.[0-9]+"/>
<enumeration value="1.0"/>
</restriction>
</simpleType>
<!--
Command types.
-->
<complexType name="commandType">
<sequence>
<choice>
<element name="check" type="epp:readWriteType"/>
<element name="create" type="epp:readWriteType"/>
<element name="delete" type="epp:readWriteType"/>
<element name="info" type="epp:readWriteType"/>
<element name="login" type="epp:loginType"/>
<element name="logout"/>
<element name="poll" type="epp:pollType"/>
<element name="renew" type="epp:readWriteType"/>
<element name="transfer" type="epp:transferType"/>
<element name="update" type="epp:readWriteType"/>
</choice>
<element name="extension" type="epp:extAnyType"
minOccurs="0"/>
<element name="clTRID" type="epp:trIDStringType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
The <login> command.
-->
<complexType name="loginType">
<sequence>
<element name="clID" type="eppcom:clIDType"/>
<element name="pw" type="epp:pwType"/>
<element name="newPW" type="epp:pwType"
minOccurs="0"/>
<element name="options" type="epp:credsOptionsType"/>
<element name="svcs" type="epp:loginSvcType"/>
</sequence>
</complexType>
<complexType name="credsOptionsType">
<sequence>
<element name="version" type="epp:versionType"/>
<element name="lang" type="language"/>
</sequence>
</complexType>
<simpleType name="pwType">
<restriction base="token">
<minLength value="6"/>
<maxLength value="16"/>
</restriction>
</simpleType>
<complexType name="loginSvcType">
<sequence>
<element name="objURI" type="anyURI"
maxOccurs="unbounded"/>
<element name="svcExtension" type="epp:extURIType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
The <poll> command.
-->
<complexType name="pollType">
<attribute name="op" type="epp:pollOpType"
use="required"/>
<attribute name="msgID" type="token"/>
</complexType>
<simpleType name="pollOpType">
<restriction base="token">
<enumeration value="ack"/>
<enumeration value="req"/>
</restriction>
</simpleType>
<!--
The <transfer> command. This is object-specific, and uses attributes
to identify the requested operation.
-->
<complexType name="transferType">
<sequence>
<any namespace="##other"/>
</sequence>
<attribute name="op" type="epp:transferOpType"
use="required"/>
</complexType>
<simpleType name="transferOpType">
<restriction base="token">
<enumeration value="approve"/>
<enumeration value="cancel"/>
<enumeration value="query"/>
<enumeration value="reject"/>
<enumeration value="request"/>
</restriction>
</simpleType>
<!--
All other object-centric commands. EPP doesn't specify the syntax or
semantics of object-centric command elements. The elements MUST be
described in detail in another schema specific to the object.
-->
<complexType name="readWriteType">
<sequence>
<any namespace="##other"/>
</sequence>
</complexType>
<complexType name="trIDType">
<sequence>
<element name="clTRID" type="epp:trIDStringType"
minOccurs="0"/>
<element name="svTRID" type="epp:trIDStringType"/>
</sequence>
</complexType>
<simpleType name="trIDStringType">
<restriction base="token">
<minLength value="3"/>
<maxLength value="64"/>
</restriction>
</simpleType>
<!--
Response types.
-->
<complexType name="responseType">
<sequence>
<element name="result" type="epp:resultType"
maxOccurs="unbounded"/>
<element name="msgQ" type="epp:msgQType"
minOccurs="0"/>
<element name="resData" type="epp:extAnyType"
minOccurs="0"/>
<element name="extension" type="epp:extAnyType"
minOccurs="0"/>
<element name="trID" type="epp:trIDType"/>
</sequence>
</complexType>
<complexType name="resultType">
<sequence>
<element name="msg" type="epp:msgType"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="value" type="epp:errValueType"/>
<element name="extValue" type="epp:extErrValueType"/>
</choice>
</sequence>
<attribute name="code" type="epp:resultCodeType"
use="required"/>
</complexType>
<complexType name="errValueType" mixed="true">
<sequence>
<any namespace="##any" processContents="skip"/>
</sequence>
<anyAttribute namespace="##any" processContents="skip"/>
</complexType>
<complexType name="extErrValueType">
<sequence>
<element name="value" type="epp:errValueType"/>
<element name="reason" type="epp:msgType"/>
</sequence>
</complexType>
<complexType name="msgQType">
<sequence>
<element name="qDate" type="dateTime"
minOccurs="0"/>
<element name="msg" type="epp:mixedMsgType"
minOccurs="0"/>
</sequence>
<attribute name="count" type="unsignedLong"
use="required"/>
<attribute name="id" type="eppcom:minTokenType"
use="required"/>
</complexType>
<complexType name="mixedMsgType" mixed="true">
<sequence>
<any processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="lang" type="language"
default="en"/>
</complexType>
<!--
Human-readable text may be expressed in languages other than English.
-->
<complexType name="msgType">
<simpleContent>
<extension base="normalizedString">
<attribute name="lang" type="language"
default="en"/>
</extension>
</simpleContent>
</complexType>that's the whole schema chunk for this part 🧚 the message types are about to get even more fun, so stay right here 🦋
4.2. Shared Structure Schema 🎀
okay so this is the shared structures schema, the bits that both EPP and the other schemas borrow from. here's the whole thing, bestie 🫶
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
shared structures schema.
</documentation>
</annotation>
<!--
Object authorization information types.
-->
<complexType name="pwAuthInfoType">
<simpleContent>
<extension base="normalizedString">
<attribute name="roid" type="eppcom:roidType"/>
</extension>
</simpleContent>
</complexType>
<complexType name="extAuthInfoType">
<sequence>
<any namespace="##other"/>
</sequence>
</complexType>
<!--
<check> response types.
-->
<complexType name="reasonType">
<simpleContent>
<extension base="eppcom:reasonBaseType">
<attribute name="lang" type="language"/>
</extension>
</simpleContent>
</complexType>
<simpleType name="reasonBaseType">
<restriction base="token">
<minLength value="1"/>
<maxLength value="32"/>
</restriction>
</simpleType>
<!--
Abstract client and object identifier type.
-->
<simpleType name="clIDType">
<restriction base="token">
<minLength value="3"/>
<maxLength value="16"/>
</restriction>
</simpleType>
<!--
DNS label type.
-->
<simpleType name="labelType">
<restriction base="token">
<minLength value="1"/>
<maxLength value="255"/>
</restriction>
</simpleType>
<!--
Non-empty token type.
-->
<simpleType name="minTokenType">
<restriction base="token">
<minLength value="1"/>
</restriction>
</simpleType>
<!--
Repository Object IDentifier type.
-->
<simpleType name="roidType">
<restriction base="token">
<pattern value="(\w|_){1,80}-\w{1,8}"/>
</restriction>
</simpleType>
<!--
Transfer status identifiers.
-->
<simpleType name="trStatusType">
<restriction base="token">
<enumeration value="clientApproved"/>
<enumeration value="clientCancelled"/>
<enumeration value="clientRejected"/>
<enumeration value="pending"/>
<enumeration value="serverApproved"/>
<enumeration value="serverCancelled"/>
</restriction>
</simpleType>
<!--
End of schema.
-->
</schema>
END5. Internationalization Considerations 🌸
okay, so EPP is written in XML, and XML comes with built-in support for Unicode, plus the more compact forms like UTF-8 💖 Conformant XML processors recognize both UTF-8 and UTF-16. XML also has a way to pick other encodings, using an encoding attribute in the <?xml?> declaration, but UTF-8 is RECOMMENDED wherever parsers don't all support the same encodings. the vibe is: keep it simple, babe 💅
EPP has a spot for a human-readable message with every result code 🦋 This document describes the result codes in English, but the actual text sent back with a result MAY be in a language that gets negotiated when the session is set up. Any language that isn't English MUST be marked with a lang attribute on each message. The valid values for lang, and for the lang negotiation elements, are described in [RFC3066] ✨
all date-time values sent over EPP MUST be in Universal Coordinated Time, using the Gregorian calendar 🌈 XML Schema lets you use time zone identifiers for offsets from the zero meridian, but that option MUST NOT be used with EPP, no exceptions 🙈 The extended date-time form with upper case "T" and "Z", as defined in [RFC3339], MUST be used, because XML Schema doesn't support truncated date-time forms or lower case "T" and "Z" characters 🫶
6. IANA Considerations 🧚
this part is about the XML namespaces and schemas, which are described with URNs and follow the registry mechanism in [RFC3688] ✨ Four URI assignments have been registered with IANA, and here they are 👑
Registration request for the EPP namespace:
URI: urn:ietf:params:xml:ns:epp-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 EPP XML schema:
URI: urn:ietf:params:xml:schema:epp-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: See the "Base Schema" section of this document.Registration request for the EPP shared structure namespace:
URI: urn:ietf:params:xml:ns:eppcom-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 EPP shared structure XML schema:
URI: urn:ietf:params:xml:schema:eppcom-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: See the "Shared Structure Schema" section of this document.7. Security Considerations 💀
okay bestie, this is the serious part, so read it carefully 🙈 EPP only gives you simple client authentication. A passive attack is enough to recover client identifiers and passwords, which makes command forgery trivial. Protection against most common attacks, and more robust security services, MUST be provided by other protocol layers. Specifically, EPP instances MUST be protected using a transport mechanism or application protocol that provides integrity and confidentiality. no shortcuts, periodt 😭
EPP uses a variant of the PLAIN SASL mechanism described in [RFC2595] to provide a simple application-layer authentication service ✨ It's meant to augment or supplement the authentication and identification services that might exist at other protocol layers. Where PLAIN SASL specifies an authorization identifier, an authentication identifier, and a password as one string separated by ASCII NUL characters, EPP instead uses a combined authorization and authentication identifier and a password, each in their own separate XML elements 🎀
Repeated password guessing can be discouraged by limiting how many <login> attempts can be made on an open connection 🔥 A server MAY close an open connection if multiple <login> attempts are made with an invalid client identifier, an invalid password, or both an invalid client identifier and an invalid password. protect your account, main character energy 👑
EPP uses the authentication information associated with objects to confirm transfer authority 🦋 Authentication information exchanged between EPP clients and third-party entities MUST be exchanged using a facility that provides privacy and integrity services, so nothing gets disclosed or modified by accident while it's in transit 🔒
8. Acknowledgements 💜
this document started life as an individual submission Internet-Draft 🌷 The provreg working group later adopted it as a working group document and gave it lots of invaluable comments and suggested improvements. the author wants to shout out WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions 🫶
specific suggestions that made it into this document came from Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, Roger Castillo Cortazar, Dave Crocker, Ayesha Damaraju, Sheer El-Showk, Patrik Faltstrom, James Gould, John Immordino, Dan Kohn, Hong Liu, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, Andrew Newton, Budi Rahardjo, Asbjorn Steira, Rick Wesson, and Jay Westerdal. iconic cast, honestly 🌟
9. References 📚
9.1. Normative References
- [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
- [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
- [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
- [RFC3023] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
- [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
- [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
- [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, September 2002.
- [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
- [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation 6 October 2000.
- [XMLE] "XML 1.0 Second Edition Specification Errata", E22, 25 July 2001,
http://www.w3.org/XML/xml-V10-2e-errata#E22. - [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
Okay bestie, these are the extra-credit reads 📚✨ Not required to build the thing, but they're the background stuff the spec leans on:
- [P3P] Editor M. Marchiori: "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", W3C Recommendation 16 April 2002.
- [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
- [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
- [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
- [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
- [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
Appendix A: Object Mapping Template
Okay so this appendix is basically a fill-in-the-blanks outline 🌸 for writing up how an object gets mapped to EPP. Documents describing EPP object mappings SHOULD follow a format similar to this one. And if your object mapping is written up as an Internet-Draft or an RFC, you'll need extra sections on top of these, no skipping 🫶
1. Introduction
Give a little intro that describes the object and a quick overview of how it maps onto EPP ✨
2. Object Attributes
List the attributes the object has, and link out to syntax specs where they apply 🎀 Examples are a name or identifier, plus dates tied to modification events.
3. EPP Command Mapping
3.1. EPP Query Commands
3.1.1. EPP <check> Command
Describe the object-specific mappings you need to implement the EPP <check> command. Include sample commands and sample responses too 💅
3.1.2. EPP <info> Command
Describe the object-specific mappings you need to implement the EPP <info> command. Include sample commands and sample responses too 💅
3.1.3. EPP <poll> Command
Describe the object-specific mappings you need to implement the EPP <poll> command. Include sample commands and sample responses too 💅
3.1.4. EPP <transfer> Command
Describe the object-specific mappings you need to implement the EPP <transfer> query command. Include sample commands and sample responses too 🦋
3.2. EPP Transform Commands
3.2.1. EPP <create> Command
Describe the object-specific mappings you need to implement the EPP <create> command. Include sample commands and sample responses. Also describe the status of the object with respect to time, including expected client and server behavior if a validity period is used ⏳
3.2.2. EPP <delete> Command
Describe the object-specific mappings you need to implement the EPP <delete> command. Include sample commands and sample responses too 💅
3.2.3. EPP <renew> Command
Describe the object-specific mappings you need to implement the EPP <renew> command. Include sample commands and sample responses too 💅
3.2.4. EPP <transfer> Command
Describe the object-specific mappings you need to implement the EPP <transfer> command. Include sample commands and sample responses too 🦋
3.2.5. EPP <update> Command
Describe the object-specific mappings you need to implement the EPP <update> command. Include sample commands and sample responses too 💅
4. Formal Syntax
Provide the XML schema for the object mapping. An XML DTD MUST NOT be used 🚫 DTDs just don't give you enough support for XML namespaces and strong data typing, so don't even go there 💀
Appendix B: Media Type Registration: application/epp+xml
Here's the registration info for the application/epp+xml media type 🧚 Let's go through it:
MIME media type name: application
MIME subtype name: epp+xml
Mandatory parameters: none
Optional parameters: Same as the charset parameter of application/xml as specified in [RFC3023].
Encoding considerations: Same as the encoding considerations of application/xml as specified in [RFC3023].
Security considerations: This type has all of the security considerations described in [RFC3023], plus the considerations specified in the Security Considerations section of this document 🔐
Interoperability considerations: XML has proven itself to be interoperable across WebDAV clients and servers, and for import and export from multiple XML authoring tools, which is iconic 👑 For maximum interoperability, validating processors are recommended. Non-validating processors can be more efficient, but they are not required to handle all features of XML. For more info, check sub-section 2.9 "Standalone Document Declaration" and section 5 "Conformance" of [XML].
Published specification: This document.
Applications which use this media type: EPP is device-, platform-, and vendor-neutral, and it's supported by multiple service providers 🌈
Additional information: If used, magic numbers, fragment identifiers, base URIs, and use of the BOM should be as specified in [RFC3023].
Magic number(s): None. File extension(s): .xml Macintosh File Type Code(s): "TEXT"
Person and email address for further information: See the "Author's Address" section of this document.
Intended usage: COMMON
Author/Change controller: IETF
Author's Address
Scott Hollenbeck
VeriSign Global Registry Services
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: shollenbeck@verisign.comFull 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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't claim it has made any independent effort to identify any such rights 🕵️ Info on how rights work for RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use these proprietary rights can all be obtained from the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info 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: rfc3730 2004-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms