Extensible Provisioning Protocol

Last updated
Extensible Provisioning Protocol
Communication protocol
AbbreviationEPP
PurposeAutomated domain name transactions like registrations and renewals
Developer(s)Scott Hollenbeck, Internet Engineering Task Force (IETF)
Introduction2009;15 years ago (2009)
OSI layer Application layer
Port(s) 700
RFC(s) RFC   5730, 5731, 5732, 5733, 5734

The Extensible Provisioning Protocol (EPP) is a flexible protocol designed for allocating objects within registries over the Internet. The motivation for the creation of EPP was to create a robust and flexible protocol that could provide communication between domain name registries and domain name registrars. These transactions are required whenever a domain name is registered or renewed, thereby also preventing domain hijacking. Prior to its introduction, registries had no uniform approach, and many different proprietary interfaces existed. While its use for domain names was the initial driver, the protocol is designed to be usable for any kind of ordering and fulfilment system. [1]

Contents

EPP is based on XML - a structured, text-based format. The underlying network transport is not fixed, although the only currently specified method is over TCP. The protocol has been designed with the flexibility to allow it to use other transports such as BEEP, SMTP, SOAP or HTTPS. [1] However only HTTPS has seen some usage while the vast majority uses TCP.

History

The first protocol drafts were published as IETF individual submission Internet Draft documents by Scott Hollenbeck of Verisign in November 2000. [2] The individual submission documents were adopted by the IETF Provisioning Registry (provreg) working group, which was created after a BoF session was held at IETF-49 in December 2000. [3] Proposed Standard documents (RFCs 3730 - 3734) were published by the RFC Editor in March 2004. [4] Draft Standard documents (RFCs 4930 - 4934) were published in May 2007. [5]

In August 2009 IETF granted EPP the status of full standard as STD 69. [6]

The first EPP extension that became a proposed standard was the redemption grace period extension from RFC 3915 in September 2004. [7] Since then a number of different proposed standard extensions followed. [8]

Adoption

The protocol has been adopted by a number of ccTLD domain name registries, such as: .ac, .ag, .ai, .as, .ar, .at, .au, .be, .br, .bz, .ca, .cat, .cc, .ch, .cl, .cn, .co, .cr, .cx, .cz, .dk, .dm, .ee, .es (over HTTPS), .eu, .fi, .fm, .fr, .gg, .gr (over HTTPS), .gs, .hn, .ht, .il, .im, .in, .io, .it (over HTTPS), .je, .ke, .ki, .ky, .kz, .la, .lc, .li, .lt, .lu, .lv, .md, .me, .mk, .mn, .ms, .mu, .mx, .na, .nf, .ng, .nl, .no, .nu, .nz, .pe, .pk, .pl (over HTTPS), .ps, .pt, .ru, .ro, .sc, .se, .sh, .si, .su, .tl, .tm .tv, .tw, .ua, .uk, .us, .vc, .ve and .za as well as ENUM registries such as those operating the +31, +41, +43, +44 and +48 country codes. [9]

ICANN has made it a condition in their base registry contract to offer an EPP service, therefore every gTLD has adopted the protocol. [10]

There are multiple open source implementations of EPP server software. The Council of Country Code Administrators (CoCCA) maintain an EPP server software that is used by around 59 ccTLDs and 6 gTLDs. [11] Another open source software is FRED (maintained by CZ.NIC) which counts 11 ccTLDs as its users. [12]

Protocol commands

There are 3 classes of commands: Session management, query and object transform. These commands can then be mapped onto objects which specifies their exact functionality more. [1] The most common standardized objects are hosts, [13] contacts [14] and domains. [15] There are also other standardized objects like organizations, [16] however they are rarely used.

When the client connects to a server, the server immediately sends a "greeting" message to the client. This message contains information about the server that the client needs to connect. This contains the name of the server, the servers current date and time in UTC, the supported features and a privacy policy. The supported features include EPP versions, languages, objects and extensions. [1]

The session management commands are: [1]

CommandUsage
helloRequest another "greeting" response from the server.
loginStart a new session that will be kept open until either logout is used or the server logs out the user. Also used to change the password. The client has to choose one EPP version and one language from the "greeting" message on login. It also has to select all objects and extensions that are supported by the server and that it wants to use in this session.
logoutEnd the current session.

The query commands are: [1]

CommandUsage
checkCheck whether an object is still available to create.
infoGet all the current information about an object.
pollRead a message from the server for the user or acknowledge the receipt of a message and thereby deleting it to receive the next message. (Message Queue)
transferGet the current status of a started object transfer process.

The object transform commands are: [1]

CommandUsage
createCreate a new object.
deleteDelete the object. Hosts and Contacts are deleted immediately, while domains mostly change into a redemption grace period.
renewIncrease the amount of time the domain name is registered. Not available for objects other than domains as these don't have a lifetime.
transferChange the registrar / owner of the object. Can be used to start an incoming transfer process or cancel it as well as to approve or reject an outgoing transfer.
updateUpdate the object. This generally includes domain owner changes, although these are also often instead implemented via EPP extensions because of a more complex workflow for these operations depending on the TLD.

Example

An example command to create a domain could look like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?><eppxmlns="urn:ietf:params:xml:ns:epp-1.0"><command><create><domain:createxmlns:domain="urn:ietf:params:xml:ns:domain-1.0"><domain:name>example.com</domain:name><domain:periodunit="y">1</domain:period><domain:ns><domain:hostObj>ns1.example.net</domain:hostObj><domain:hostObj>ns2.example.net</domain:hostObj></domain:ns><domain:registrant>REG-1738</domain:registrant><domain:contacttype="admin">ADM-9374</domain:contact><domain:contacttype="tech">OTH-2567</domain:contact><domain:contacttype="billing">OTH-2567</domain:contact><domain:authInfo><domain:pw>y85NS%FJ4zeKuHXo</domain:pw></domain:authInfo></domain:create></create><clTRID>uu28qbb2wo6o5bpk</clTRID></command></epp>

Note that the two host objects and 3 different contact objects had to be created beforehand to use them and the client had to be logged in already. The authInfo pw is a secret that is required in the transfer between registrars. The clTRID is a unique transaction id for each command that is generated by the client. A server response to the command above could look like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?><eppxmlns="urn:ietf:params:xml:ns:epp-1.0"><response><resultcode="1000"><msg>Commandcompletedsuccessfully</msg></result><resData><domain:creDataxmlns:domain="urn:ietf:params:xml:ns:domain-1.0"><domain:name>example.com</domain:name><domain:crDate>2023-03-12T12:00:00.0Z</domain:crDate><domain:exDate>2024-03-12T12:00:00.0Z</domain:exDate></domain:creData></resData><trID><clTRID>uu28qbb2wo6o5bpk</clTRID><svTRID>ma3fuaeuh7bzpgv9</svTRID></trID></response></epp>

The clTRID is the same as the client sent, while the svTRID is a unique transaction id generated by the server. The server returns a result code, message and additional result data like the expiration date of the newly created domain.

Extensions

The protocol offers the ability to send an extension object on almost every possible command to enable registries to add new functionality without changing the base commands. [1]

There are a few standardized extensions that are used by a lot of registries. These include extensions for DNSSEC, [17] IDN, [18] premium domain names, [19] domain restoration (RGP) [7] and extensions to handle the launch of new TLDs [20] among other things. [8]

Some registries also developed extensions that are specific for their TLDs. A common use case for non-standardized extensions is the collection of extra data that is needed to create a domain, for example a VAT identification number. [8]

Result Codes

All responses from the server have to follow a specified format. Each response code is corresponding to a human readable message. Codes in the format 1xxx are successful operations, while codes in the format 2xxx are errors. The errors are again divided into protocol syntax errors in the format 20xx, implementation specific rules as 21xx, security as 22xx, data management as 23xx, server system as 24xx and connection management as 25xx. Most results can include additional data in the resData object, for example which required parameter is specifically missing. [1]

The response code 1001 enables offline processing, an example for this can be that a domain name registry wants to validate a registrant before the domain is registered. In this case the domain is blocked for other clients until the process is complete and the client will be notified via a poll message that can be fetched by the client via the poll command. The codes 1300 and 1301 are for the poll command specifically and signal whether there is a message or not. [1]

The complete list of standardized result codes and result messages is: [1]

CodeMessage
1000Command completed successfully
1001Command completed successfully; action pending
1300Command completed successfully; no messages
1301Command completed successfully; ack to dequeue
1500Command completed successfully; ending session
2000Unknown command
2001Command syntax error
2002Command use error
2003Required parameter missing
2004Parameter value range error
2005Parameter value syntax error
2101Unimplemented command
2102Unimplemented option
2103Unimplemented extension
2104Billing failure
2105Object is not eligible for renewal
2106Object is not eligible for transfer
2200Authentication error
2201Authorization error
2202Invalid authorization information
2300Object pending transfer
2301Object not pending transfer
2302Object exists
2303Object does not exist
2304Object status prohibits operation
2305Object association prohibits operation
2306Parameter value policy error
2307Unimplemented object service
2308Data management policy violation
2400Command failed
2500Command failed; server closing connection
2501Authentication error; server closing connection
2502Session limit exceeded; server closing connection

EPP object status codes

There are 2 types of status codes: server and client. The difference is that all server status codes can only be set and removed by the registry, while the client status codes can also be set and removed by the registrar, unless a server status code prohibits it. [15]

The server status codes are commonly used to handle domain abuse cases, mark the domain lifecycle stage or offer extra security against unauthorized tampering, a service often referred to as Registry-Lock.

The client status codes are commonly used to also handle abuse cases, non-payment, invalid contact data or for a Registrar-Lock feature.

The currently standardized server status codes are: [15] [7]

Server StatusDescriptionUser required action
addPeriodThis grace period is provided after the initial registration of a domain name. If the registrar deletes the domain name during this period, the registry may provide credit to the registrar for the cost of the registration.This is an informative status set for the first several days of your domain's registration. There is no issue with your domain name.
autoRenewPeriodThis grace period is provided after a domain name registration period expires and is extended (renewed) automatically by the registry. If the registrar deletes the domain name during this period, the registry provides a credit to the registrar for the cost of the renewal.This is an informative status set for a limited time after your domain's auto- renewal by the registry. If you do not want to keep it (i.e., pay the renewal fee) anymore, you should contact your registrar immediately to discuss what options are available.
inactiveThis status code indicates that delegation information (name servers) has not been associated with your domain. Your domain is not activated in the DNS and will not resolve.If your domain has remained in this status for several days, you may want to contact your registrar to request information about the delay in processing. If the TLD requires documentation to be provided for registration, you may need to provide the required documentation.
okThis is the standard status for a domain, meaning it has no pending operations or prohibitions.Asking your registrar to enact status restrictions, like clientTransferProhibited, clientDeleteProhibited, and clientUpdateProhibited, can help to prevent unauthorized transfers, deletions, or updates to your domain.
pendingCreateThis status code indicates that a request to create your domain has been received and is being processed.If the TLD is on a special registration period (e.g. sunrise), this may indicate that the domain name will be allocated at the end of such period.
pendingDeleteThis status code may be mixed with redemptionPeriod or pendingRestore. In such case, depending on the status (i.e. redemptionPeriod or pendingRestore) set in the domain name, the corresponding description presented above applies. If this status is not combined with the redemptionPeriod or pendingRestore status, the pendingDelete status code indicates that your domain has been in redemptionPeriod status for 30 days and you have not restored it within that 30-day period. Your domain will remain in this status for several days, after which time your domain will be purged and dropped from the registry database. Once deletion occurs, the domain is available for re-registration in accordance with the registry's policies.If you want to keep your domain name, you must immediately contact your registrar to discuss what options are available.
pendingRenewThis status code indicates that a request to renew your domain has been received and is being processed.If you did not request to renew your domain and do not want to keep it (i.e., pay the renewal fee) anymore, you should contact your registrar immediately to discuss what options are available.
pendingRestoreThis status code indicates that your registrar has asked the registry to restore your domain that was in redemptionPeriod status. Your registry will hold the domain in this status while waiting for your registrar to provide required restoration documentation. If your registrar fails to provide documentation to the registry operator within a set time period to confirm the restoration request, the domain will revert to redemptionPeriod status.Watch your domain's status codes within this frequently defined seven day period to ensure that your registrar has submitted the correct restoration documentation within the time window. If this period ended and your domain has reverted to a redemptionPeriod status, contact your registrar to resolve whatever issues that may have halted the delivery of your domain's required restoration documentation.
pendingTransferThis status code indicates that a request to transfer your domain to a new registrar has been received and is being processed.If you did not request to transfer your domain, you should contact your registrar immediately to request that they deny the transfer request on your behalf.
pendingUpdateThis status code indicates that a request to update your domain has been received and is being processedIf you did not request to update your domain, you should contact your registrar immediately to resolve the issue.
redemptionPeriodThis status code indicates that your registrar has asked the registry to delete your domain. Your domain will be held in this status for 30 days. After five calendar days following the end of the redemptionPeriod, your domain is purged from the registry database and becomes available for registration.If you want to keep your domain, you must immediately contact your registrar to resolve whatever issues resulted in your registrar requesting that your domain be deleted, which resulted in the redemptionPeriod status for your domain. Once any outstanding issues are resolved and the appropriate fee has been paid, your registrar should restore the domain on your behalf.
renewPeriodThis grace period is provided after a domain name registration period is explicitly extended (renewed) by the registrar. If the registrar deletes the domain name during this period, the registry provides a credit to the registrar for the cost of the renewal.This is an informative status set for a limited period or your domain's renewal by your registrar. If you did not request to renew your domain and do not want to keep it (i.e., pay the renewal fee) anymore, you should contact your registrar immediately to discuss what options are available.
serverDeleteProhibitedThis status code prevents your domain from being deleted. It is an uncommon status that is usually enacted during legal disputes, at your request, or when a redemptionPeriod status is in place.This status may indicate an issue with your domain that needs resolution. If so, you should contact your registrar to request more information and to resolve the issue. If your domain does not have any issues, and you simply want to delete it, you must first contact your registrar and request that they work with the Registry Operator to remove this status code. Alternatively, some Registry Operators offer a Registry Lock Service that allows registrants, through their registrars to set this status as an extra protection against unauthorized deletions. Removing this status can take longer than it does for clientDeleteProhibited because your registrar has to forward your request to your domain's registry and wait for them to lift the restriction.
serverHoldThis status code is set by your domain's Registry Operator. Your domain is not activated in the DNS.If you provided delegation information (name servers), this status may indicate an issue with your domain that needs resolution. If so, you should contact your registrar to request more information. If your domain does not have any issues, but you need it to resolve in the DNS, you must first contact your registrar in order to provide the necessary delegation information.
serverRenewProhibitedThis status code indicates your domain's Registry Operator will not allow your registrar to renew your domain. It is an uncommon status that is usually enacted during legal disputes or when your domain is subject to deletion.Often, this status indicates an issue with your domain that needs to be addressed promptly. You should contact your registrar to request more information and resolve the issue. If your domain does not have any issues, and you simply want to renew it, you must first contact your registrar and request that they work with the Registry Operator to remove this status code. This process can take longer than it does for clientRenewProhibited because your registrar has to forward your request to your domain's registry and wait for them to lift the restriction.
serverTransferProhibitedThis status code prevents your domain from being transferred from your current registrar to another. It is an uncommon status that is usually enacted during legal or other disputes, at your request, or when a redemptionPeriod status is in place.This status may indicate an issue with your domain that needs to be addressed promptly. You should contact your registrar to request more information and resolve the issue. If your domain does not have any issues, and you simply want to transfer it to another registrar, you must first contact your registrar and request that they work with the Registry Operator to remove this status code. Alternatively, some Registry Operators offer a Registry Lock Service that allows registrants, through their registrars to set this status as an extra protection against unauthorized transfers. Removing this status can take longer than it does for clientTransferProhibited because your registrar has to forward your request to your domain's registry and wait for them to lift the restriction.
serverUpdateProhibitedThis status code locks your domain preventing it from being updated. It is an uncommon status that is usually enacted during legal disputes, at your request, or when a redemptionPeriod status is in place.This status may indicate an issue with your domain that needs resolution. If so, you should contact your registrar for more information or to resolve the issue. If your domain does not have any issues, and you simply want to update it, you must first contact your registrar and request that they work with the Registry Operator to remove this status code. Alternatively, some Registry Operators offer a Registry Lock Service that allows registrants, through their registrars to set this status as an extra protection against unauthorized updates. Removing this status can take longer than it does for clientUpdateProhibited because your registrar has to forward your request to your domain's registry and wait for them to lift the restriction.
transferPeriodThis grace period is provided after the successful transfer of a domain name from one registrar to another. If the new registrar deletes the domain name during this period, the registry provides a credit to the registrar for the cost of the transfer.This is an informative status set for a limited period or your domain's transfer to a new registrar. If you did not request to transfer your domain, you should contact your original registrar.

The currently standardized client status codes are: [15]

Client StatusDescriptionUser required action
clientDeleteProhibitedThis status code tells your domain's registry to reject requests to delete the domain.This status indicates that it is not possible to delete the domain name registration, which can prevent unauthorized deletions resulting from hijacking and/or fraud. If you do want to delete your domain, you must first contact your registrar and request that they remove this status code.
clientHoldThis status code tells your domain's registry to not activate your domain in the DNS and as a consequence, it will not resolve. It is an uncommon status that is usually enacted during legal disputes, non-payment, or when your domain is subject to deletion.Often, this status indicates an issue with your domain that needs resolution. If so, you should contact your registrar to resolve the issue. If your domain does not have any issues, but you need it to resolve, you must first contact your registrar and request that they remove this status code.
clientRenewProhibitedThis status code tells your domain's registry to reject requests to renew your domain. It is an uncommon status that is usually enacted during legal disputes or when your domain is subject to deletion.Often, this status indicates an issue with your domain that needs resolution. If so, you should contact your registrar to resolve the issue. If your domain does not have any issues, and you simply want to renew it, you must first contact your registrar and request that they remove this status code.
clientTransferProhibitedThis status code tells your domain's registry to reject requests to transfer the domain from your current registrar to another.This status indicates that it is not possible to transfer the domain name registration, which will help prevent unauthorized transfers resulting from hijacking and/or fraud. If you do want to transfer your domain, you must first contact your registrar and request that they remove this status code.
clientUpdateProhibitedThis status code tells your domain's registry to reject requests to update the domain.This domain name status indicates that it is not possible to update the domain, which can help prevent unauthorized updates resulting from fraud. If you do want to update your domain, you must first contact your registrar and request that they remove this status code.

Security considerations

EPP only offers plain text passwords, additionally the EPP login password type is specified to be a string of 6-16 character length [1] which might be considered very low for today's standards. Connections over TCP therefore must use TLS and use of client certificates as well as correct identity confirmation of the client and server is strongly encouraged. [21]

Additionally a lot of domain name registries offer to set up a IP whitelist for connecting to their EPP servers.

EPP offers some protection against replay attacks via the client generated clTRID, however this element is optional and is therefore not used by every server software. Therefore additional anti-replay mechanisms should be implemented by the used transport mechanism. [1]

EPP Objects RFCs

EPP Extension RFCs

See also

Related Research Articles

The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.

<span class="mw-page-title-main">Network Time Protocol</span> Standard protocol for synchronizing time across devices

The Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. In operation since before 1985, NTP is one of the oldest Internet protocols in current use. NTP was designed by David L. Mills of the University of Delaware.

<span class="mw-page-title-main">XMPP</span> Communications protocol for message-oriented middleware

Extensible Messaging and Presence Protocol is an open communication protocol designed for instant messaging (IM), presence information, and contact list maintenance. Based on XML, it enables the near-real-time exchange of structured data between two or more network entities. Designed to be extensible, the protocol offers a multitude of applications beyond traditional IM in the broader realm of message-oriented middleware, including signalling for VoIP, video, file transfer, gaming and other uses.

A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that uses the urn scheme. URNs are globally unique persistent identifiers assigned within defined namespaces so they will be available for a long period of time, even after the resource which they identify ceases to exist or becomes unavailable. URNs cannot be used to directly locate an item and need not be resolvable, as they are simply templates that another parser may use to find an item.

Domain hijacking or domain theft is the act of changing the registration of a domain name without the permission of its original registrant, or by abuse of privileges on domain hosting and registrar software systems.

<span class="mw-page-title-main">Preboot Execution Environment</span> Standard for booting from a server

In computing, the Preboot eXecution Environment, PXE specification describes a standardized client–server environment that boots a software assembly, retrieved from a network, on PXE-enabled clients. On the client side it requires only a PXE-capable network interface controller (NIC), and uses a small set of industry-standard network protocols such as DHCP and TFTP.

Diameter is an authentication, authorization, and accounting protocol for computer networks. It evolved from the earlier RADIUS protocol. It belongs to the application layer protocols in the Internet protocol suite.

example.com Domain name reserved for documentation purposes and as an example of the use of domain names

The domain names example.com, example.net, example.org, and example.edu are second-level domain names in the Domain Name System of the Internet. They are reserved by the Internet Assigned Numbers Authority (IANA) at the direction of the Internet Engineering Task Force (IETF) as special-use domain names for documentation purposes. The domain names are used widely in books, tutorials, sample network configurations, and generally as examples for the use of domain names. The Internet Corporation for Assigned Names and Numbers (ICANN) operates web sites for these domains with content that reflects their purpose.

<span class="mw-page-title-main">NETCONF</span> Network management protocol

The Network Configuration Protocol (NETCONF) is a network management protocol developed and standardized by the IETF. It was developed in the NETCONF working group and published in December 2006 as RFC 4741 and later revised in June 2011 and published as RFC 6241. The NETCONF protocol specification is an Internet Standards Track document.

In the Internet addressing architecture, the Internet Engineering Task Force (IETF) and the Internet Assigned Numbers Authority (IANA) have reserved various Internet Protocol (IP) addresses for special purposes.

WHOIS is a query and response protocol that is used for querying databases that store an Internet resource's registered users or assignees. These resources include domain names, IP address blocks and autonomous systems, but it is also used for a wider range of other information. The protocol stores and delivers database content in a human-readable format. The current iteration of the WHOIS protocol was drafted by the Internet Society, and is documented in RFC 3912.

An IPv6 transition mechanism is a technology that facilitates the transitioning of the Internet from the Internet Protocol version 4 (IPv4) infrastructure in use since 1983 to the successor addressing and routing system of Internet Protocol Version 6 (IPv6). As IPv4 and IPv6 networks are not directly interoperable, transition technologies are designed to permit hosts on either network type to communicate with any other host.

A Request for Comments (RFC), in the context of Internet governance, is a type of publication from the Internet Engineering Task Force (IETF) and the Internet Society (ISOC), usually describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.

NAT64 is an IPv6 transition mechanism that facilitates communication between IPv6 and IPv4 hosts by using a form of network address translation (NAT). The NAT64 gateway is a translator between IPv4 and IPv6 protocols, for which function it needs at least one IPv4 address and an IPv6 network segment comprising a 32-bit address space. The "well-known prefix" reserved for this service is 64:ff9b::/96.

Port Control Protocol (PCP) is a computer networking protocol that allows hosts on IPv4 or IPv6 networks to control how the incoming IPv4 or IPv6 packets are translated and forwarded by an upstream router that performs network address translation (NAT) or packet filtering. By allowing hosts to create explicit port forwarding rules, handling of the network traffic can be easily configured to make hosts placed behind NATs or firewalls reachable from the rest of the Internet, which is a requirement for many applications.

The Registration Data Access Protocol (RDAP) is a computer network communications protocol standardized by a working group at the Internet Engineering Task Force in 2015, after experimental developments and thorough discussions. It is a successor to the WHOIS protocol, used to look up relevant registration data from such Internet resources as domain names, IP addresses, and autonomous system numbers.

References

  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC5730. ISSN   2070-1721.{{cite journal}}: Cite journal requires |journal= (help)
  2. "Extensible Provisioning Protocol". IETF Datatracker. Retrieved 2023-03-13.
  3. "IETF December 2000 Proceedings". www.ietf.org. Retrieved 2023-03-13.
  4. Hollenbeck, S. (March 2004). "Extensible Provisioning Protocol (EPP)". doi: 10.17487/RFC3730 . ISSN   2070-1721.{{cite journal}}: Cite journal requires |journal= (help)
  5. Hollenbeck, S. (May 2007). "Extensible Provisioning Protocol (EPP)". doi: 10.17487/RFC4930 . ISSN   2070-1721.{{cite journal}}: Cite journal requires |journal= (help)
  6. Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP)".{{cite journal}}: Cite journal requires |journal= (help)
  7. 1 2 3 Hollenbeck, S. (September 2004). "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC3915. ISSN   2070-1721.{{cite journal}}: Cite journal requires |journal= (help)
  8. 1 2 3 "Extensions for the Extensible Provisioning Protocol (EPP)". www.iana.org. Retrieved 2023-03-11.
  9. "Implementation Report for RFCs 4930-4934 - Wayback Machine". 2012-01-15. Archived from the original on 2012-01-15. Retrieved 2023-03-12.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  10. "ICANN base registry contract". newgtlds.icann.org. Retrieved 2023-03-12.
  11. "Official CoCCA website" . Retrieved 2023-03-12.
  12. "Introducing FRED - fred". fred.nic.cz. Retrieved 2023-03-12.
  13. Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Host Mapping". doi: 10.17487/RFC5732 . ISSN   2070-1721.{{cite journal}}: Cite journal requires |journal= (help)
  14. Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Contact Mapping". doi: 10.17487/RFC5733 . ISSN   2070-1721.{{cite journal}}: Cite journal requires |journal= (help)
  15. 1 2 3 4 Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Domain Name Mapping". doi:10.17487/RFC5731. ISSN   2070-1721.{{cite journal}}: Cite journal requires |journal= (help)
  16. Zhou, L.; Kong, N.; Yao, J.; Gould, J.; Zhou, G. (March 2019). "Extensible Provisioning Protocol (EPP) Organization Mapping". doi:10.17487/RFC8543. ISSN   2070-1721. S2CID   65065583.{{cite journal}}: Cite journal requires |journal= (help)
  17. Gould, J.; Hollenbeck, S. (May 2010). "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)". doi: 10.17487/RFC5910 . ISSN   2070-1721.{{cite journal}}: Cite journal requires |journal= (help)
  18. "Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP)". IETF Datatracker. Retrieved 2023-03-11.
  19. Carney, Roger (March 2020). "RFC 8748: Registry Fee Extension for the Extensible Provisioning Protocol (EPP)". www.rfc-editor.org. Retrieved 2023-03-11.
  20. Gould, J.; Tan, W.; Brown, G. (March 2018). "Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)". doi:10.17487/RFC8334. ISSN   2070-1721.{{cite journal}}: Cite journal requires |journal= (help)
  21. Hollenbeck, S. (August 2009). "Extensible Provisioning Protocol (EPP) Transport over TCP". doi:10.17487/RFC5734. ISSN   2070-1721.{{cite journal}}: Cite journal requires |journal= (help)