RFC 4930
Extensible Provisioning Protocol (EPP)
Extensible Provisioning Protocol (EPP) 🎀
Okay bestie, let's talk about RFC 4930! 💖 It's from the Network Working Group, written by S. Hollenbeck at VeriSign, Inc., and dated May 2007. It's a Standards Track doc, which means it's the real deal 👑 and not just someone's opinion. It also obsoletes RFC 3730, so this is the glow-up of an older spec ✨. Its title is Extensible Provisioning Protocol (EPP). Iconic 💅
Status of This Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 💬. If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🧐. Also, distribution of this memo is unlimited, so share it with your whole group chat 🦋.
Copyright Notice 🌸
The notice reads Copyright (C) The IETF Trust (2007). Nothing too dramatic, just a little legal sparkle ✨.
Abstract 🧚
So this 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 it gives you generic object management operations plus an extensible framework that maps protocol operations onto objects. Main character energy 👑. The document includes a protocol specification, an object mapping template, and an XML media type registration 🎀. It also obsoletes RFC 3730 💅.
Table of Contents 📚
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4
2.1. Transport Mapping Considerations . . . . . . . . . . . . . 7
2.2. Protocol Identification . . . . . . . . . . . . . . . . . 8
2.3. Hello Format . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Greeting Format . . . . . . . . . . . . . . . . . . . . . 8
2.5. Command Format . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Response Format . . . . . . . . . . . . . . . . . . . . . 13
2.7. Protocol Extension Framework . . . . . . . . . . . . . . . 18
2.7.1. Protocol Extension . . . . . . . . . . . . . . . . . . 18
2.7.2. Object Extension . . . . . . . . . . . . . . . . . . . 18
2.7.3. Command-Response Extension . . . . . . . . . . . . . . 19
2.8. Object Identification . . . . . . . . . . . . . . . . . . 20
2.9. Protocol Commands . . . . . . . . . . . . . . . . . . . . 21
2.9.1. Session Management Commands . . . . . . . . . . . . . 21
2.9.1.1. EPP <login> Command . . . . . . . . . . . . . . . 21
2.9.1.2. EPP <logout> Command . . . . . . . . . . . . . . . 24
2.9.2. Query Commands . . . . . . . . . . . . . . . . . . . . 25
2.9.2.1. EPP <check> Command . . . . . . . . . . . . . . . 25
2.9.2.2. EPP <info> Command . . . . . . . . . . . . . . . . 27
2.9.2.3. EPP <poll> Command . . . . . . . . . . . . . . . . 28
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 . . . . . . . . . . . . . . . 36
2.9.3.3. EPP <renew> Command . . . . . . . . . . . . . . . 37
2.9.3.4. EPP <transfer> Command . . . . . . . . . . . . . . 39
2.9.3.5. EPP <update> Command . . . . . . . . . . . . . . . 41
3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . . . 42
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1. Base Schema . . . . . . . . . . . . . . . . . . . . . . . 48
4.2. Shared Structure Schema . . . . . . . . . . . . . . . . . 58
5. Internationalization Considerations . . . . . . . . . . . . . 60
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
7. Security Considerations . . . . . . . . . . . . . . . . . . . 62
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.1. Normative References . . . . . . . . . . . . . . . . . . . 63
9.2. Informative References . . . . . . . . . . . . . . . . . . 64
Appendix A. Object Mapping Template . . . . . . . . . . . . . . . 66
Appendix B. Media Type Registration: application/epp+xml . . . . 68
Appendix C. Changes from RFC 3730 . . . . . . . . . . . . . . . . 691. Introduction ✨
Alright, so this doc describes version 1.0 of the Extensible Provisioning Protocol (EPP) 💖. It's an XML text protocol that lets multiple service providers do object provisioning operations on a shared central object repository 🫶. EPP is specified using Extensible Markup Language (XML) 1.0 as described in [W3C.REC-xml-20040204], and it uses XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. Honestly, EPP meets and exceeds the requirements for a generic registry registrar protocol as described in [RFC3375] 👑. And yes, this document obsoletes RFC 3730 [RFC3730] 🌈.
EPP content is identified by the MIME media type application/epp+xml 🎀. You'll find the registration info for this media type in an appendix 💅.
EPP is built for diverse operating environments where transport and security requirements vary a LOT 🦋. No single transport or security specification is going to fit every operator, so EPP was designed to live in a layered protocol environment 🧚. Bindings to specific transport and security protocols are outside the scope of this specification 🙈.
The original motivation 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 also expected that this protocol will have additional uses beyond domain name registration ✨.
XML is case sensitive 🙈. Unless stated otherwise, the XML specifications and examples in this document MUST be interpreted in the character case presented, so you can build a conforming implementation 💅.
1.1. Conventions Used in This Document 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🧠.
In examples, C: means lines sent by a protocol client, and S: means lines returned by a protocol server 💬. Indentation and white space in the examples are only there to show how the elements relate, and they are 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 🦋. Once it's protected by lower-layer security protocols, clients swap identification, authentication, and option info, then run a whole series of client-initiated command-response exchanges 🔁. All EPP commands are atomic (no partial success, no partial failure, no in-between vibes) 💀, and they're designed so they can be made idempotent (running a command more than once has the same net effect on system state as running it successfully just once) 🫶.
EPP gives you four basic service elements 👑: service discovery, commands, responses, and an extension framework. That framework is what lets you define managed objects and link protocol requests and responses to those objects 🌈.
An EPP server MUST respond to client-initiated communication (which can be either a lower-layer connection request or an EPP service discovery message) by returning a greeting to a client 🎀. A server MUST promptly respond to each EPP command with a coordinated response that describes the results of processing the command 💖. Here's the state machine diagram that walks through 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 +-----------------+
| | Timeout |
| +-------------------------------+ | Auth OK
| | V
| +-----------------+ <hello> +-----------------+
| | Prepare |<----------| Waiting for |
| | Greeting |---------->| Command or |
| +-----------------+ Send | <hello> |
| Send x5xx Greeting +-----------------+
| Response +-----------------+ Send ^ |
+-----------| Prepare | Response | | Command
| Response |----------+ | Received
+-----------------+ V
^ +-----------------+
Command | | Processing |
Processed +----------| Command |
+-----------------+Figure 1: EPP Server State Machine
EPP commands come in three flavours 🧚: session management commands, query commands, and object transform commands. Session management commands are used to establish and end persistent sessions with an EPP server 🌸. Query commands are for read-only object information retrieval, basically look-but-don't-touch 🙈. Transform commands are for read-write object management operations ✍️.
Commands are processed by a server in the order they arrive from a client 📬. An immediate response confirming receipt and processing of the command comes back from the server, but the protocol also has features that allow offline review of transform commands before the requested action is actually completed 🕰️. In those situations, 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 of the action has been completed 🔔. Object mappings SHOULD describe standard formats for notices that describe completion of offline processing 📝.
EPP uses XML namespaces to provide an 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 XML namespace prefixes used in examples (such as the string "foo" in "xmlns:foo") are solely for illustrative purposes 💅. A conforming implementation MUST NOT require the use of these or any other specific namespace prefixes 🚫.
All XML instances SHOULD begin with an <?xml?> declaration 💌. That declaration identifies the version of XML being used, can optionally identify the character encoding, and can optionally give an XML parser a hint that an external schema file is needed to validate the XML instance. Conformant XML parsers recognize both UTF-8 (defined in RFC 3629 [RFC3629]) 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 encoding 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. EPP clients and servers MUST accept a UTF-8 BOM if one is present, though 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 earlier, EPP can be layered over multiple transport protocols 🦋. There is, however, 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 [RFC0793] or Stream Control Transmission Protocol (SCTP) [RFC2960] that provides congestion avoidance that follows RFC 2914 [RFC2914], or if it maps onto a protocol such as SMTP [RFC2821] or Blocks Extensible Exchange Protocol (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 the commands, the client waits for the responses to arrive in the order that matches the completed commands 🏃♀️. Performance gains can sometimes be realized with pipelining, especially on high-latency transports, but defining a transport mapping that supports pipelining comes with extra considerations:
- 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 and identifies the namespace used within the protocol 🏷️. 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">
</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 between a successful <login> command and a <logout> command, by sending a <hello> to a server 👋. Using this element is essential in a connection-less environment, where a server cannot 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: <hello/>
C:</epp>2.4. Greeting Format ✨
okay bestie, so when a client connects and sends its <hello>, the EPP server replies with a <greeting> element 🎀 Here's everything that goes in it 💅
- An
<svID>element that contains the name of the server. - An
<svDate>element that contains the server's current date and time in UTC. - An
<svcMenu>element that identifies the services supported by the server, including:- One or more
<version>elements that identify the protocol versions supported by the server. - One or more
<lang>elements that contain the identifiers of the text response languages known by the server. Language identifiers MUST be structured as documented in [RFC3066]. 🌸 - One or more
<objURI>elements that contain namespace URIs representing the objects that the server is capable of managing. A server MAY limit object management privileges on a per-client basis. 👑 - An OPTIONAL
<svcExtension>element that contains one or more<extURI>elements that contain namespace URIs representing object extensions supported by the server. ✨ - A
<dcp>(data collection policy) element that contains child elements used to describe the server's privacy policy for data collection and management. Policy implications usually extend beyond the client-server relationship, bc both clients and servers can have relationships with other entities that need to know the server operator's data collection policy to make informed provisioning decisions 🧚 Policy information MUST be disclosed to provisioning entities, though the method of disclosing policy data outside of direct protocol interaction is beyond the scope of this specification. Child elements include the following:- An
<access>element that describes the access provided by the server to the client on behalf of the originating data source. The<access>element MUST contain one of the following 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 relating to individuals and organizational entities.<personalAndOther/>: Access is given to identified data relating to individuals, organizational entities, and other data of a non-personal nature.<other/>: Access is given to other identified data of a non-personal nature.
- 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 the following child elements that describe the purposes for which data is 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 contact individuals, through a communications channel other than the protocol, for the promotion of 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 other ways not captured by the above definitions.
- The
<recipient>element MUST contain one or more of the following child elements that describes the recipients of collected data:<other/>: Other entities following unknown practices.<ours>: Server operator and/or entities acting as agents or entities for whom the server operator is acting as an agent. An agent in this instance is defined as a third party that processes data only on behalf of the service provider for the completion of the stated purposes. The<ours>element contains an OPTIONAL<recDesc>element that can be used to describe the recipient.<public/>: Public forums.<same/>: Other entities following server practices.<unrelated/>: Unrelated third parties.
- The
<retention>element MUST contain one of the following child elements that describes data retention practices:<business/>: Data persists per business practices.<indefinite/>: Data persists indefinitely.<legal/>: Data persists per legal requirements.<none/>: Data is not persistent and is not retained for more than a brief period of time necessary to make use of it during the course of a single online interaction.<stated/>: Data persists to meet the stated purpose.
- An OPTIONAL
<expiry>element that describes the lifetime of the policy. The<expiry>element MUST contain one of the following child elements:<absolute/>: The policy is valid from the current date and time until it expires on the specified date and time.<relative/>: The policy is valid from the current date and time until the end of the specified duration.
- An
- One or more
Data collection policy elements are based on work described in the World Wide Web Consortium's Platform for Privacy Preferences [W3C.REC-P3P-20020416] specification. 💜
Example greeting:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
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 so an EPP client talks to an EPP server by sending a command and getting a response back 🫶 On top of the standard EPP elements, an EPP command has these extras:
- A command element whose tag corresponds to one of the valid EPP commands described 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 maintaining their own transaction identifier space to ensure uniqueness. 🍓
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: <command>
C: <info>
C: <obj:info xmlns:obj="urn:ietf:params:xml:ns:obj">
C: <obj:name>example</obj:name>
C: </obj:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>2.6. Response Format 💌
okay so the server always answers a client command with a response 📬 EPP commands are atomic, which means a command either succeeds completely or fails completely. no in-between 🫶 Success and failure results MUST NOT be mixed. on top of the usual EPP elements, a response has these extras:
- One or more <result> elements that show whether the command worked or flopped 💅 If the command was processed successfully, only one <result> element MUST be returned. If it wasn't processed successfully, multiple <result> elements MAY be returned to explain the failures. Each <result> element has the following attribute and child elements:
- A "code" attribute, which is a four-digit, decimal number that describes whether the command succeeded or failed ✨
- A <msg> element with a human-readable description of the response code 🌸 The language is set with an OPTIONAL "lang" attribute. If it isn't specified, the default value MUST be "en" (English).
- Zero or more OPTIONAL <value> elements that point to the client-provided element (XML tag and value) or other info that caused a server error 🔍
- Zero or more OPTIONAL <extValue> elements for extra error diagnostics, including:
- A <value> element that points to the client-provided element (XML tag and value) that caused the server error 🎀
- A <reason> element with a human-readable message explaining the error 🙈 The language is set with an OPTIONAL "lang" attribute. If it isn't specified, the default value MUST be "en" (English).
- An OPTIONAL <msgQ> element that tells the client about messages waiting in the queue for 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 has these attributes:
- A "count" attribute for how many messages are in the queue 🧮
- An "id" attribute that uniquely identifies the message at the head of the queue 🪪
The <msgQ> element also has these OPTIONAL child elements. They 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 with the date and time the message was enqueued 🗓️
- A <msg> element with a human-readable message 🍓 The language is set with an OPTIONAL "lang" attribute. If it isn't specified, the default value MUST be "en" (English). This element MAY contain XML content for formatting purposes, but the protocol doesn't specify that XML content, so it won't be checked for validity 🤷♀️
- An OPTIONAL <resData> (response data) element with child elements that are specific to the command and the object 🧁
- An OPTIONAL <extension> element that MAY be used for server-defined response extensions 🌈
- A <trID> (transaction identifier) element with the transaction identifier the server assigned to the command the response is for 🆔 It's formed from the <clTRID> the client attached to the command (if it sent one) plus a <svTRID> (server transaction identifier) that the server assigns and that is unique to it 🦋
Transaction identifiers give you command-response synchronization integrity, which is so important 😭 They SHOULD be logged, retained, and protected so that both the client and the server have consistent temporal and state management records. Main character energy for good record-keeping 📚
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: <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> 🫧
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <obj:creData xmlns:obj="urn:ietf:params:xml:ns:obj">
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>Now one with error value elements, which is a little drama 😤
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="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 last, one 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: <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>Command success or failure MUST NOT be assumed if no response is returned or if a returned response is malformed. 🚨 Protocol idempotency is what makes it safe to retry a command when a response fails to arrive 🔁
2.7. Protocol Extension Framework 🧩
EPP has an extension framework, so features can be added at the protocol, object, and command-response levels. It's giving customization 💖
2.7.1. Protocol Extension 🌷
The EPP extension framework lets you define new protocol elements. They're identified with XML namespace notation, plus a reference to an XML schema that defines the namespace 🪄 The <epp> element that starts a protocol instance has several child element choices, and one of them is an <extension> element whose children define the extension. A protocol extension element would look generically like this:
C:<epp>
C: <extension>
C: <!-- One or more extension elements. -->
C: <ext:foo xmlns:ext="urn:ietf:params:xml:ns:ext">
C: <!-- One or more extension child elements. -->
C: </ext:foo>
C: </extension>
C:</epp>This document doesn't define mappings for specific extensions 🙅♀️ Extension specifications MUST be described in separate documents that define the objects and operations the extension applies to 📖
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 puts 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. Iconic 🙌
Protocol elements with object-specific data are identified with XML namespace notation too, 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 🧠 The start of an object-specific command element would generically look like this:
C:<EPPCommandName>
C: <object:command xmlns:object="urn:ietf:params:xml:ns:object">
C: <!-- One or more object-specific command elements. -->
C: </object:command>
C:</EPPCommandName>An object-specific response element looks similar:
S:<resData>
S: <object:resData xmlns:object="urn:ietf:params:xml:ns:object">
S: <!-- One or more object-specific response elements. -->
S: </object:resData>
S:</resData>This document doesn't define mappings for specific objects 🫠 The mapping of EPP to an object MUST be described in separate documents that address each command and response in the context of that object 📝 There's also a suggested object mapping outline in an appendix to this document 🎀
2.7.3. Command-Response Extension 🍬
EPP has a facility for command and response extensions 🪩 Protocol commands and responses MAY be extended by an <extension> element that contains additional elements whose syntax and semantics aren't explicitly defined by EPP or an EPP object mapping. This element is OPTIONAL. Extensions are usually defined by agreement between client and server, and they MAY be used to extend EPP for unique operational needs 🤝 A server-extended command element would generically look 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: <!-- 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 looks like this:
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 address extended commands and responses in the server's operational context 🫶
2.8. Object Identification ✨
Okay bestie, so some objects, like name servers and contacts, are useful in multiple repositories 🌸. But keeping messy, disjoint copies of the same object info across repos leads to inconsistencies, and those can seriously hurt the Internet 💀. Like, change a name server name in one repo but not in a second repo that uses it for domain name delegation, and DNS queries can return totally unexpected results. Not it 🙈.
Globally unique identifiers help repos share object info way smoother 🦋. A globally unique identifier MUST be assigned to every object when the object is created, and the identifier MUST be returned to the client as part of any request to retrieve the detailed attributes of an object. The actual identifier values are a matter of repository policy, but they SHOULD be built using this 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 value 0x002D), followed by the repository identifier. ✨
2.9. Protocol Commands 💅
EPP gives you commands to manage sessions, retrieve object information, and perform transformation operations on objects. All EPP commands are atomic and designed so they can be made idempotent, meaning they either succeed completely or fail completely, with predictable results even if you run them again and again 🔁. This section walks through each EPP command, with examples and representative server responses. Iconic 👑.
2.9.1. Session Management Commands 🔐
EPP has two session management commands: <login> to establish a session with a server, and <logout> to end a session with a server. The <login> command sets up an ongoing server session that keeps the client's identity and authorization info around for the whole session 🫶.
2.9.1.1. EPP <login> Command 🎀
The EPP <login> command is used to establish a session with an EPP server after the server sends a greeting. A <login> command MUST be sent to a server before any other EPP command, so you can set up an ongoing session 🌸. A server operator MAY limit the number of failed login attempts N, where 1 <= N <= infinity. After that, a login failure results in the connection to the server being closed (if there is a connection) 🙅♀️.
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 secrets SECRET 🤫.
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 these 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. 🌍
- A
The values of the <version> and <lang> elements MUST exactly match one of the values presented in the EPP greeting. No freestyling here 💀.
- A
<svcs>element that contains one or more<objURI>elements. These contain 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 identifying object extensions to be used during the session 🧩.
The PLAIN Simple Authentication and Security Layer (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 📝. The EPP authentication mechanism is similar, though EPP does not 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 provide more robust security services. Layers of protection, bestie 🛡️✨.
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: <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 with no <resData> element 📭. If it works, the server creates and maintains a new session, which SHOULD be ended by a future <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: <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 is 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 due to client inactivity or excessive client session longevity 😴. 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 the 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: <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 with 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: <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 has not been preceded by a successful <login> command 🙅♀️. This action MUST be open to all authorized clients 💖.
2.9.2. Query Commands 🔍
2.9.2.1. EPP <check> Command ✨
okay bestie, the <check> command is how you ask the server "can I actually make this object??" 💅 It's more of a vibe check than a promise, bc whether you're allowed to provision something is ultimately up to the server's policy, not the command itself. So think of it as a hint that helps you guess if your <create> is gonna slay or flop 🔮
The stuff needed to identify an object is different for every object type, so the child elements of <check> are defined through the EPP extension framework 🧩 On top of the usual EPP command elements, the <check> command 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:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <check>
C: <obj:check xmlns:obj="urn:ietf:params:xml:ns:obj">
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 has been processed successfully, a server MUST respond with an EPP <resData> element that MUST contain a child element that identifies the object namespace 🌸 The child elements of <resData> are object-specific, but the EPP <resData> element MUST contain a child <obj:chkData> element, and that one holds one or more <obj:cd> (check data) elements. Each <obj:cd> element has these child elements:
- An object-specific element that identifies the queried object. This element MUST contain an "avail" attribute whose value tells you whether the object is available (can it be provisioned or not) at the moment the
<check>command was completed. A value of "1" or "true" means the object can be provisioned ✅ A value of "0" or "false" means it cannot be provisioned ❌ - An OPTIONAL
<obj:reason>element that MAY be provided when an object cannot be provisioned. If it shows up, it has server-specific text that helps explain why the object is a no-go 🙈 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:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <obj:chkData xmlns:obj="urn:ietf:params:xml:ns:obj">
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>So the <check> command is used to figure out 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 <info> command is for pulling up the details on an object that already exists 🦋 Same deal as before: the elements that identify the object and the kind of info you want are both object-specific, so the child elements of <info> come from 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: <command>
C: <info>
C: <obj:info xmlns:obj="urn:ietf:params:xml:ns:obj">
C: <!-- Object-specific elements. -->
C: </obj:info>
C: </info>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>When an <info> command has been processed successfully, a server MUST respond with an EPP <resData> element that MUST contain a child element that identifies the object namespace and the Repository Object IDentifier (ROID) that was assigned to the object when it was created 🆔✨ The other child elements of <resData> are object-specific, so they vary by object type 💅
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: <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: <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>Okay so the <info> command is used to retrieve information about an existing object. This action SHOULD be limited to authorized clients, and restricting it to the sponsoring client is RECOMMENDED 🔐 Privacy is giving main character energy 👑🌸
2.9.2.3. EPP <poll> Command
Okay so the EPP <poll> command is how a client finds and grabs the service messages the server has queued up just for it ✨. If the message queue isn't empty, a successful response to a <poll> command MUST return the first message from the message queue 📬. Every response from the server includes a server-unique message identifier that MUST be provided to acknowledge receipt, plus a counter for how many messages are still in the queue 🔢. Once the client has received a message, it MUST respond to that message with an explicit acknowledgement so the server knows it landed 🫶. Then the server MUST dequeue the message and decrement the queue counter after it gets that acknowledgement, which makes the next message (if there is one) available to grab 💅.
Servers can occasionally do stuff to objects that isn't a direct reply to a client request, 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 SHOULD be created for passive clients affected by an action on an object. Service messages MAY also be created for active clients that request an action on an object, though such messages MUST NOT replace the normal protocol response to the request. For example, <transfer> actions SHOULD be reported to the client that has the authority to approve or reject a transfer request. Other methods of server-client action notification, such as offline reporting, are also possible and are beyond the scope of this specification 🦋.
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 exceed server resource consumption limits. Server operators SHOULD consider time-sensitivity and resource management factors when they pick a delivery method for service information, because some message types can reasonably be delivered using non-protocol methods that require fewer server resources 🍓.
Some of the info in a <poll> response 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 value "req" is REQUIRED to retrieve the first message from the server message queue. An "op" attribute (with value "ack") and a "msgID" attribute (whose value corresponds to the value of 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: <command>
C: <poll op="req"/>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>The returned result code notes 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: <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: <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. This is the step that keeps the queue moving, so don't skip it 🙈.
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: <command>
C: <poll op="ack" msgID="12345"/>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>A <poll> acknowledgement response notes the ID of the message that has been acknowledged and the number of messages remaining in the queue 🌈.
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: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <msgQ count="4" id="12345"/>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>Service messages can also be returned without any object information 💜.
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: <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 used to note an empty server message queue 🥹.
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: <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 EPP <poll> command is used to discover and retrieve client service messages from a server. This action SHOULD be limited to authorized clients. 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 provides a query operation that lets a client check the real-time status of pending and completed transfer requests 👀. The elements needed to identify an object that is the subject of a transfer request are object-specific, so the child elements of the <transfer> query command are specified using the EPP extension framework. In addition to the standard EPP command elements, the <transfer> command contains an "op" attribute with value "query", and the following child elements:
- An object-specific
<obj:transfer>element that identifies the object whose transfer status is requested.
Transfer status is typically considered sensitive information by the clients involved in the operation. Object mappings MUST provide features to 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: <command>
C: <transfer op="query">
C: <obj:transfer xmlns:obj="urn:ietf:params:xml:ns:obj">
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 that identifies the object namespace 📦. 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 can also include 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> query response:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <obj:trnData xmlns:obj="urn:ietf:params:xml:ns:obj">
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 provides a query operation that allows a client to determine real-time status of pending and completed transfer requests. This action SHOULD be limited to authorized clients. 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
EPP provides five commands to transform objects 🦋. There's <create>, which makes a new instance of an object on a server. There's <delete>, which removes an instance of an object from a server. There's <renew>, which extends the validity period of an object. There's <transfer>, which manages changes in client sponsorship of an object. And there's <update>, which changes information associated with an object 💖.
2.9.3.1. EPP <create> Command
Okay so <create> is the command for making a brand new object 💖 An object can be made to last forever, or it can get a specific validity period 🎀 The EPP mapping for an object MUST describe the object's status over time, including what clients and servers are expected to do if a validity period is used ⏳
The bits you need to identify an object and its attributes depend on the object, so the child elements of <create> come from the EPP extension framework ✨ On top of the standard EPP command elements, <create> has this child element:
- An object-specific
<obj:create>element that identifies the object to be created and the elements required to create it.
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: <command>
C: <create>
C: <obj:create xmlns:obj="urn:ietf:params:xml:ns:obj">
C: <!-- Object-specific elements. -->
C: </obj:create>
C: </create>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>When a <create> command goes through successfully, a server MAY reply with an EPP <resData> element, and that MUST contain a child element naming the object namespace 🦋 The kids inside <resData> are object-specific, so it's a whole vibe depending on the object 🌈
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: <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: <!-- 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>Real talk: making objects is something only authorized clients should be doing 🔐 This action SHOULD be limited to authorized clients and MAY be restricted on a per-client basis 💅
2.9.3.2. EPP <delete> Command
<delete> is how you remove an object that already exists 🗑️ Again, the bits needed to identify the object are object-specific, so the child elements come from the EPP extension framework 🧚 On top of the standard EPP command elements, <delete> 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: <command>
C: <delete>
C: <obj:delete xmlns:obj="urn:ietf:params:xml:ns:obj">
C: <!-- Object-specific elements. -->
C: </obj:delete>
C: </delete>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>When a <delete> command goes through successfully, a server MAY reply with an EPP <resData> element, and that MUST contain a child element naming the object namespace. The kids inside <resData> 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: <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>This action SHOULD be limited to authorized clients, and restricting it to the sponsoring client is RECOMMENDED 🔥 Deleting someone's stuff is a big deal, so keep the gatekeeping tight 💀
2.9.3.3. EPP <renew> Command
<renew> is for stretching out the validity period of an object that already exists ⏰ The bits needed to identify the object and extend its validity are object-specific, so the child elements come from the EPP extension framework 🌸 On top of the standard EPP command elements, <renew> has this child element:
- An object-specific
<obj:renew>element that identifies the object to be renewed and the elements 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: <command>
C: <renew>
C: <obj:renew xmlns:obj="urn:ietf:params:xml:ns:obj">
C: <!-- Object-specific elements. -->
C: </obj:renew>
C: </renew>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>When a <renew> command goes through successfully, a server MAY reply with an EPP <resData> element, and that MUST contain a child element naming the object namespace. The kids inside <resData> 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: <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: <!-- 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>This action SHOULD be limited to authorized clients, and restricting it to the sponsoring client is RECOMMENDED. Also, object renewal MAY be unavailable or limited by object-specific policies 🙈
2.9.3.4. EPP <transfer> Command
<transfer> is the one for changing which client sponsors an existing object 🦋 Clients can start a transfer request, cancel one, approve one, or reject one, all by using the "op" command attribute 💜
If you want to take over sponsorship of a known object from another client, you send <transfer> with "op" set to "request" 🎀 Once you've requested it, the same client can cancel with <transfer> and "op" set to "cancel". A cancel request MUST be sent to the server before the current sponsoring client approves or rejects the transfer, and before the server automatically processes the request because the responding client has gone quiet ⏳
When the server gets a transfer request, it MUST tell the current sponsoring client about it. It can do that by queuing a service message to be retrieved with the <poll> command, or by using an out-of-band mechanism 📬 The current status of a pending <transfer> command for any object can be checked with the <transfer> query command 👀 Transfer service messages MUST include the object-specific elements specified for <transfer> command responses 🧾
The current sponsoring client MAY explicitly approve or reject the request 💅 To approve, send <transfer> with "op" set to "approve". To reject, send <transfer> with "op" set to "reject" ✨
A server MAY automatically approve or reject any transfer request that the current sponsoring client hasn't explicitly handled within a fixed amount of time 🕰️ How long to wait and what the default behavior is are local decisions that EPP doesn't specify, but they SHOULD be written up in a server-specific profile document that describes default server behavior for client information 📝
Objects that can be transferred MUST have associated authorization information, and that MUST be provided to complete a <transfer> command 🔐 The type of authorization information depends on the object. Passwords or more complex mechanisms based on public key cryptography are typical 🗝️
Like the other commands, the bits needed to identify and complete an object's transfer are object-specific, so the child elements of <transfer> come from the EPP extension framework 🌈 On top of the standard EPP command elements, <transfer> has this child element:
- An object-specific
<obj:transfer>element that identifies the object to be transferred and the elements 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: <command>
C: <transfer op="request">
C: <obj:transfer xmlns:obj="urn:ietf:params:xml:ns:obj">
C: <!-- Object-specific elements. -->
C: </obj:transfer>
C: </transfer>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>When a <transfer> command goes through successfully, a server MUST reply with an EPP <resData> element, and that MUST contain a child element naming the object namespace. The kids inside <resData> 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 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 can 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> 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: <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: <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>Okay, the big picture: this action SHOULD be limited to authorized clients. Restricting <transfer> requests to a client other than the current sponsoring client, approval requests to the current sponsoring client, and cancellation requests to the original requesting client is RECOMMENDED 🫶 Object transfer MAY be unavailable or limited by object-specific policies, so check the rules first 💖
2.9.3.5. EPP <update> Command ✨
okay so the EPP <update> command is how you change info on an object that already exists 🔧 bestie, the elements you need to find and edit an object are different for every object type, so the child elements get defined through the EPP extension framework 🧩 on top of the usual EPP command stuff, the <update> command has this one child element:
- An object-specific
<obj:update>element that names the object being updated, plus the elements needed to change it. Object-specific elements MUST identify values to be added, values to be removed, or values to be changed. 🎀
here's an example <update> command so you can see the shape of it 👀
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <update>
C: <obj:update xmlns:obj="urn:ietf:params:xml:ns:obj">
C: <!-- Object-specific elements. -->
C: </obj:update>
C: </update>
C: <clTRID>ABC-12346</clTRID>
C: </command>
C:</epp>when an <update> command gets processed successfully, a server MAY reply with an EPP <resData> element 💌 and that <resData> element MUST have a child element that identifies the object namespace 🌸 the children of <resData> are object-specific too, so they depend on the object type 🦋
and here's a successful <update> response with no <resData> in it ✨
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>ok the big picture again, because it matters 💅 the EPP <update> command changes info on an existing object, and this action SHOULD be limited to authorized clients 🔐 restricting it to the sponsoring client is RECOMMENDED 💖 main character energy for security, periodt 👑
3. Result Codes ✨
okay so result codes are giving "reply codes with main character energy" 💅 they're based on the reply code theory from section 4.2.1 of [RFC2821] 🎀 every EPP command gets back four decimal digits that say whether it worked, and each digit has its own job 🧚
1yzz Positive completion reply. The command was 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 the first digit is the verdict: 1 means it worked, 2 means it didn't 💀 The second digit sorts the response into a category, like syntax or security, and the third and fourth digits give the specific detail inside that category 🦋
x0zz Protocol Syntax
x1zz Implementation-specific Rules
x2zz Security
x3zz Data Management
x4zz Server System
x5zz Connection ManagementThe specific codes are in the tables below 🌸
Every EPP response MUST include a result code and a human-readable description of the result code. 🫶 The language of that description MAY be flagged with the "lang" attribute on the <msg> element. If you don't set it, the default is English, marked as "en". The structure of valid "lang" values is covered in [RFC3066] 📚
Translations are allowed too: response text MAY be translated into other languages, but the translation MUST keep the meaning of the code the same, and the response code values MUST NOT be changed when translating 🌈
The response text in the tables is wrapped in quotes just so you can see where each string starts and stops 👀 When the server actually sends the text over the protocol, the quotes MUST NOT be used to wrap it 🙈
Here are the successful ones ✨
Code Response text in English
____ ________________________
1000 "Command completed successfully"
This is the usual response code for a successfully completed
command that is not addressed by any other 1xxx-series
response code.
1001 "Command completed successfully; action pending"
This response code MUST be returned when responding to a
command that requires offline activity before the requested
action can be completed. See Section 2 for a description of
other processing requirements.
1300 "Command completed successfully; no messages"
This response code MUST be returned when responding to a
<poll> request command and the server message queue is empty.
1301 "Command completed successfully; ack to dequeue"
This response code MUST be returned when responding to a
<poll> request command and a message has been retrieved from
the server message queue.
1500 "Command completed successfully; ending session"
This response code MUST be returned when responding to a
successful <logout> command.And now the command error responses, which are where the drama is 😭
Code Response text in English
____ ________________________
2000 "Unknown command"
This response code MUST be returned when a server receives a
command element that is not defined by EPP.
2001 "Command syntax error"
This response code MUST be returned when a server receives an
improperly formed command element.
2002 "Command use error"
This response code MUST be returned when a server receives a
properly formed command element, but the command cannot be
executed due to a sequencing or context error. For example,
a <logout> command cannot be executed without having first
completed a <login> command.
2003 "Required parameter missing"
This response code MUST be returned when a server receives a
command for which a required parameter value has not been
provided.
2004 "Parameter value range error"
This response code MUST be returned when a server receives a
command parameter whose value is outside the range of values
specified by the protocol. The error value SHOULD be
returned via a <value> element in the EPP response.
2005 "Parameter value syntax error"
This response code MUST be returned when a server receives a
command containing a parameter whose value is improperly
formed. The error value SHOULD be returned via a <value>
element in the EPP response.
2100 "Unimplemented protocol version"
This response code MUST be returned when a server receives a
command element specifying a protocol version that is not
implemented by the server.
2101 "Unimplemented command"
This response code MUST be returned when a server receives a
valid EPP command element that is not implemented by the
server. For example, a <transfer> command can be
unimplemented for certain object types.
2102 "Unimplemented option"
This response code MUST be returned when a server receives a
valid EPP command element that contains a protocol option
that is not implemented by the server.
2103 "Unimplemented extension"
This response code MUST be returned when a server receives a
valid EPP command element that contains a protocol command
extension that is not implemented by the server.
2104 "Billing failure"
This response code MUST be returned when a server attempts to
execute a billable operation and the command cannot be
completed due to a client billing failure.
2105 "Object is not eligible for renewal"
This response code MUST be returned when a client attempts to
<renew> an object that is not eligible for renewal in
accordance with server policy.
2106 "Object is not eligible for transfer"
This response code MUST be returned when a client attempts to
<transfer> an object that is not eligible for transfer in
accordance with server policy.
2200 "Authentication error"
This response code MUST be returned when a server notes an
error when validating client credentials.
2201 "Authorization error"
This response code MUST be returned when a server notes a
client authorization error when executing a command. This
error is used to note that a client lacks privileges to
execute the requested command.
2202 "Invalid authorization information"
This response code MUST be returned when a server receives
invalid command authorization information required to confirm
authorization to execute a command. This error is used to
note that a client has the privileges required to execute the
requested command, but the authorization information provided
by the client does not match the authorization information
archived by the server.
2300 "Object pending transfer"
This response code MUST be returned when a server receives a
command to transfer of an object that is pending transfer due
to an earlier transfer request.
2301 "Object not pending transfer"
This response code MUST be returned when a server receives a
command to confirm, reject, or cancel the transfer an object
when no command has been made to transfer the object.
2302 "Object exists"
This response code MUST be returned when a server receives a
command to create an object that already exists in the
repository.
2303 "Object does not exist"
This response code MUST be returned when a server receives a
command to query or transform an object that does not exist
in the repository.
2304 "Object status prohibits operation"
This response code MUST be returned when a server receives a
command to transform an object that cannot be completed due
to server policy or business practices. For example, a
server can disallow <transfer> commands under terms and
conditions that are matters of local policy, or the server
might have received a <delete> command for an object whose
status prohibits deletion.
2305 "Object association prohibits operation"
This response code MUST be returned when a server receives a
command to transform an object that cannot be completed due
to dependencies on other objects that are associated with the
target object. For example, a server can disallow <delete>
commands while an object has active associations with other
objects.
2306 "Parameter value policy error"
This response code MUST be returned when a server receives a
command containing a parameter value that is syntactically
valid, but semantically invalid due to local policy. For
example, the server can support a subset of a range of valid
protocol parameter values. The error value SHOULD be
returned via a <value> element in the EPP response.
2307 "Unimplemented object service"
This response code MUST be returned when a server receives a
command to operate on an object service that is not supported
by the server.
2308 "Data management policy violation"
This response code MUST be returned when a server receives a
command whose execution results in a violation of server data
management policies. For example, removing all attribute
values or object associations from an object might be a
violation of a server's data management policies.
2400 "Command failed"
This response code MUST be returned when a server is unable
to execute a command due to an internal server error that is
not related to the protocol. The failure can be transient.
The server MUST keep any ongoing session active.
2500 "Command failed; server closing connection"
This response code MUST be returned when a server receives a
command that cannot be completed due to an internal server
error that is not related to the protocol. The failure is
not transient and will cause other commands to fail as well.
The server MUST end the active session and close the existing
connection.
2501 "Authentication error; server closing connection"
This response code MUST be returned when a server notes an
error when validating client credentials and a server-defined
limit on the number of allowable failures has been exceeded.
The server MUST close the existing connection.
2502 "Session limit exceeded; server closing connection"
This response code MUST be returned when a server receives a
<login> command, and the command cannot be completed because
the client has exceeded a system-defined limit on the number
of sessions that the client can establish. It might be
possible to establish a session by ending existing unused
sessions and closing inactive connections.4. Formal Syntax ✨
okay bestie, this is where EPP gets its XML Schema outfit 👗 The formal syntax here is a complete schema version of EPP, so machines can automatically validate EPP XML instances. that's the whole point 🫶
There are two schemas. The first is the base EPP schema. The second holds 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 each one starts and ends for URI registration purposes 🎀
4.1. Base Schema 💖
the base schema is giving main character energy 👑 here it is, from the top:
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"/>
<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>okay so the base schema wraps up with the message type and the result codes 💖
<!--
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>
<!--
EPP result codes.
-->
<simpleType name="resultCodeType">
<restriction base="unsignedShort">
<enumeration value="1000"/>
<enumeration value="1001"/>
<enumeration value="1300"/>
<enumeration value="1301"/>
<enumeration value="1500"/>
<enumeration value="2000"/>
<enumeration value="2001"/>
<enumeration value="2002"/>
<enumeration value="2003"/>
<enumeration value="2004"/>
<enumeration value="2005"/>
<enumeration value="2100"/>
<enumeration value="2101"/>
<enumeration value="2102"/>
<enumeration value="2103"/>
<enumeration value="2104"/>
<enumeration value="2105"/>
<enumeration value="2106"/>
<enumeration value="2200"/>
<enumeration value="2201"/>
<enumeration value="2202"/>
<enumeration value="2300"/>
<enumeration value="2301"/>
<enumeration value="2302"/>
<enumeration value="2303"/>
<enumeration value="2304"/>
<enumeration value="2305"/>
<enumeration value="2306"/>
<enumeration value="2307"/>
<enumeration value="2308"/>
<enumeration value="2400"/>
<enumeration value="2500"/>
<enumeration value="2501"/>
<enumeration value="2502"/>
</restriction>
</simpleType>
<!--
End of schema.
-->
</schema>
END4.2. Shared Structure Schema ✨
okay this one is the shared structures schema, and it's giving "everything gets reused, nothing gets wasted" 🧚
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 is literally built for Unicode 😭 it can handle the compact forms too, like UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. XML can also name other encodings through an encoding attribute in an <?xml?> declaration, but the spec says UTF-8 is RECOMMENDED wherever parser encoding support is incompatible.
EPP sends a human-readable message with every result code. This document describes the result codes in English, but the actual text returned with a result MAY be provided in a language negotiated when a session is established. Any language other than English MUST be noted with a "lang" attribute on each message. The valid values for the "lang" attribute and the "lang" negotiation elements are described in [RFC3066].
All date-time values presented via EPP MUST be expressed in Universal Coordinated Time using the Gregorian calendar. XML Schema lets you use time zone identifiers for offsets from the zero meridian, but this option MUST NOT be used with EPP. ✋ The extended date-time form using upper case "T" and "Z" characters, defined in [W3C.REC-xmlschema-2-20041028], MUST be used to represent date-time values, since XML Schema doesn't support truncated date-time forms or lower case "T" and "Z" characters. no cap, that's a lot of rules, but they're all there for a reason 🎀
6. IANA Considerations 🦋
this document uses URNs to describe XML namespaces and XML schemas, following a registry mechanism described in [RFC3688]. Four URI assignments have been registered by the IANA, and here they are, bestie:
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 section is the serious one, so read it carefully
EPP only provides simple client authentication services. A passive attack is enough to recover client identifiers and passwords, which makes command forgery trivial 😭 Protection against most common attacks, along with 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, confidentiality, and mutual strong client-server authentication.
EPP uses a variant of the PLAIN SASL mechanism described in [RFC2595] to provide a simple application-layer authentication service. It augments or supplements the authentication and identification services that might exist at other protocol layers. Where the PLAIN SASL mechanism specifies an authorization identifier, an authentication identifier, and a password as a single string separated by ASCII NUL characters, EPP instead uses a combined authorization and authentication identifier and a password, provided as distinct XML elements.
Repeated password guessing can be discouraged by limiting the number of <login> attempts allowed 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.
EPP uses authentication information associated with objects to confirm object transfer authority. Authentication information exchanged between EPP clients and third-party entities MUST be exchanged using a facility that provides privacy and integrity services, to protect against unintended disclosure and modification while in transit.
EPP instances SHOULD be protected using a transport mechanism or application protocol that provides anti-replay protection. EPP offers some protection against replay attacks through command idempotency and client-initiated transaction identification. Consecutive command replays will not change the state of an object in any way. There is, however, a chance of unintended or malicious consequences if a command is replayed after intervening commands have changed the object state and client identifiers are not used to detect replays. For example, a replayed <create> command that follows a <delete> command might succeed without additional facilities to prevent or detect the replay. 🙈
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 thank 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. thank you all, you're the real ones 👑
9. References 📚
9.1. Normative References 📚
Okay, bestie, time for the reading list that the spec is built on. These are the ones you MUST know about to get the full picture 💅
[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.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[W3C.REC-xml-20040204] Yergeau, F., Maler, E., Sperberg-McQueen, C., Bray, T., and J. Paoli, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml-20040204, February 2004, http://www.w3.org/TR/2004/REC-xml-20040204.
[W3C.REC-xmlschema-1-20041028] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028.
[W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028.
9.2. Informative References 🔍
These ones are extra background reading. Totally worth a skim if you're curious 🧚
[RFC0793] 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.
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2821] Klensin, J., "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.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, September 2002.
[RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
[W3C.REC-P3P-20020416] Marchiori, M., "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", World Wide Web Consortium Recommendation REC-P3P-20020416, April 2002, http://www.w3.org/TR/2002/REC-P3P-20020416.
Appendix A. Object Mapping Template 🧚
This appendix gives you a recommended outline for writing up the EPP mapping of an object, so it's giving organised and consistent 🎀 Documents that describe EPP object mappings SHOULD follow a format similar to this one. Additional sections are required if the object mapping is written in Internet-Draft or RFC format ✨
1. Introduction
Give a little intro that describes the object and sums up how it maps to EPP 🌸
2. Object Attributes
Describe the attributes that belong to the object, and include references to syntax specifications where they make sense. Examples of object attributes 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 required to implement the EPP <check> command. Include both sample commands and sample responses 💖
3.1.2. EPP <info> Command
Describe the object-specific mappings required to implement the EPP <info> command. Include both sample commands and sample responses 💖
3.1.3. EPP <poll> Command
Describe the object-specific mappings required to implement the EPP <poll> command. Include both sample commands and sample responses 💖
3.1.4. EPP <transfer> Command
Describe the object-specific mappings required to implement the EPP <transfer> query command. Include both sample commands and sample responses 💖
3.2. EPP Transform Commands
3.2.1. EPP <create> Command
Describe the object-specific mappings required to implement the EPP <create> command. Include both 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 required to implement the EPP <delete> command. Include both sample commands and sample responses 🫶
3.2.3. EPP <renew> Command
Describe the object-specific mappings required to implement the EPP <renew> command. Include both sample commands and sample responses 🔁
3.2.4. EPP <transfer> Command
Describe the object-specific mappings required to implement the EPP <transfer> command. Include both sample commands and sample responses 🦋
3.2.4. EPP <update> Command
Describe the object-specific mappings required to implement the EPP <update> command. Include both sample commands and sample responses ✏️
4. Formal Syntax
Provide the XML schema for the object mapping. An XML DTD MUST NOT be used, because DTDs don't give you enough support for XML namespaces and strong data typing 🙈
Appendix B. Media Type Registration: application/epp+xml 💌
MIME media type name: application
MIME subtype name: epp+xml
Required 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. Be careful with this one, it's serious 😭
Interoperability considerations: XML has proven to be interoperable across WWW Distributed Authoring and Versioning (WebDAV) clients and servers, and for import and export from multiple XML authoring tools. For maximum interoperability, validating processors are recommended. Although non-validating processors can be more efficient, they are not required to handle all features of XML. For further information, see Section 2.9, "Standalone Document Declaration", and Section 5, "Conformance", of [W3C.REC-xml-20040204] 🧠
Published specification: This document.
Applications that use this media type: EPP is device-, platform-, and vendor-neutral and is 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 & email address for further information: See the "Author's Address" section of this document.
Intended usage: COMMON
Author/Change controller: IETF
Appendix C. Changes from RFC 3730 ✨
okay bestie, this is the changelog 🧚 it's where the authors spill every tea about what changed since RFC 3730 💅 the wording is verbatim wherever it's quoted, because the exact words are the whole point 🫶
- Minor reformatting as a result of converting the I-D source format from nroff to XML. 🎀
- Updated the state diagram in Section 2 to say that a
<hello>can be received and processed at any time that a server is waiting for a command. the text already described this correctly, but the diagram didn't match it, so it got fixed 🦋 - In Section 2, the sentence about URI and namespace strings was changed. the old version said:
"The specific strings used to associate URIs and namespaces (such as the string "foo" in "xmlns:foo") in EPP are illustrative and are not needed for interoperability"
and it became:
"The XML namespace prefixes used in examples (such as the string "foo" in "xmlns:foo") are solely for illustrative purposes. A conforming implementation MUST NOT require the use of these or any other specific namespace prefixes"
the new version is a big deal 👑 an implementation MUST NOT require any specific prefix, so no more prefix drama 💖
- Removed the last paragraph from Section 2 that described an error in the W3C XML reference specification. that error got corrected in a later edition 🌸 the references now point at the most current version. the last sentence of that paragraph was saved by tacking it onto the end of the paragraph before it ✨
- Updated the description of the
<value>element in Section 2.6 so it now says "or other information" after "a client-provided element (including XML tag and value)". slay, more flexible 🌈 - Section 2.9.2.3 got a major glow-up on service messages. the old text said:
"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."
and the new text says:
"Service messages SHOULD be created for passive clients affected by an action on an object. Service messages MAY also be created for active clients that request an action on an object, though such messages MUST NOT replace the normal protocol response to the request. For example, <transfer> actions SHOULD be reported to the client that has the authority to approve or reject a transfer request. Other methods of server-client action notification, such as offline reporting, are also possible and are beyond the scope of this specification."
so the big change is that passive clients get the SHOULD treatment, active clients can optionally get one, and the normal response is still protected 🔥 the offline reporting bit is out of scope, periodt 💅
- Section 2.9.2.3 also changed the
<poll>acknowledgement description. the old version said:
"A <poll> acknowledgement response notes the number of messages remaining in the queue and the ID of the next message available for retrieval."
and the new version says:
"A <poll> acknowledgement response notes the ID of the message that has been acknowledged and the number of messages remaining in the queue."
the example got fixed to show the right message ID too 🙈 the reason is that msgID isn't needed to retrieve a message, only to ack and dequeue it, so it doesn't have to come back in the response. implementations are already doing it this way 🫶
- Section 2.9.3.4 got updated about transfer notifications. the old text said:
"Once a transfer request has been received by the server, the server MUST notify the current sponsoring client of the requested transfer by queuing a service message for retrieval via the <poll> command."
and the new text says:
"Once a transfer request has been received by the server, the server MUST notify the current sponsoring client of the requested transfer either by queuing a service message for retrieval via the <poll> command or by using an out-of-band mechanism to inform the client of the request."
so now an out-of-band mechanism is an allowed option too 🦋
- Updated Security Considerations to note implemented required practices for authentication and replay protection. security is serious business, so this one gets a 💀 moment ✨
- Updated XML references. the reference to RFC 2279 was updated to RFC 3629 🌸
- Removed the text describing use of the XML Schema
schemaLocationattribute. it's optional, and EPP doesn't need to mandate it 🧚 - Moved RFCs 2781 and 3375 (Informational RFCs) from the normative reference section to the informative reference section. 📚
- Moved RFC 3023 from the normative reference section to the informative reference section. it only shows up in an informative appendix, so it doesn't belong with the must-reads 🍓
- Removed references to RFC 3339 and replaced them with references to the W3C XML Schema specification. 💜
Author's Address
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
EMail: shollenbeck@verisign.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶✨
📦 where this page comes from
- ietf: rfc4930 2007-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms