RPP, a future protocol for creating and managing domain names?

The limitations of EPP

The EPP (Extensible Provisioning Protocol) works well and is currently widely used by a large number of domain name registries¹. Those under contract with ICANN are actually obliged to provide an EPP interface. EPP was standardised by the IETF (Internet Engineering Task Force) in 2004 and the current standard comprises several documents, the main one being RFC 5730. More than twenty years have passed since it was standardised. Do we want to continue using EPP?

A word in passing. In the world of online access to services, there is often talk of APIs (Application Programming Interfaces). In the context of this article, there is not really any difference between a protocol and an API, although in a broader context, API is normally used only for certain types of protocol². Note that the registrars have access to an API for their operations with Afnic.

Some people have pointed to limitations of EPP, but not everyone necessarily agrees with this perception. The criticism centres on the fact that EPP uses XML (Extensible Markup Language), a W3C (World-Wide Web Consortium) standard that some people find complex. Other criticisms concern the fact that EPP relies directly on a TCP (Transmission Control Protocol) connection, making it difficult to deploy in environments in which everything is supposed to run on HTTP (Hypertext Transfer Protocol)³. Among other things, this use of TCP connections for extended periods (days, or even weeks) may interfere with certain services such as load balancing. Lastly, there’s the human factor: many junior developers only know HTTP and the JSON format (JavaScript Object Notation). The JSON format is used for example in the RDAP protocol, (Registration Data Access Protocol), which provides access to “social” information on domain names.

The principles of RPP

These are the observations on the basis of which the idea of replacing EPP with another protocol has gradually taken shape. This protocol is the RPP. At present (December 2024), RPP exists only in name – there is as yet no protocol, just a number of basic principles waiting to be embodied in an actual protocol. So you won’t be seeing RPP any time soon. What are these principles?

• REST architecture (REpresentational State Transfer). This architecture, currently widely deployed for web APIs, is based on the notion of naming the resources handled in the URL (Uniform Resource Locator, the Internet address) and differentiating the actions by using different HTTP methods. So, for example, it would be possible to obtain information on the domain name toto.example by sending an HTTP GET request on the URL https://rpp.nic.example/domains/toto.example and to delete an unused name by sending an HTTP DELETE request on the same URL. By the way, when you use REST, each request is self-sufficient, so the notion of a session, as with EPP, no longer exists. Another consequence of using REST is that some operations can be carried out from an ordinary browser.
• Exclusive use of HTTPS (Hypertext Transfer Protocol Secure) as the transport protocol⁴. as for RDAP.
• Reuse, as far as possible, of the existing services for HTTP such as authentication⁵ (as opposed to the specific authentication used by EPP), limitation of traffic or load balancing⁶,
• Use of the JSON format, IETF standard (RFC 8259) to represent the data sent to or received from the registry.

The work of the IETF

As already said, RPP does not yet exist except as an idea. The proponents of this idea had envisaged the new protocol’s being developed by the IETF’s Regext working group which standardises EPP and RDAP. However, this group’s charter does not provide for work on other protocols, so the current thinking is to create a new working group specifically for RPP. As at 3 December 2024, the group still had not been created but it probably will be soon: the meeting of 6 November in Dublin gave a clear indication of intentions in this respect.

The future of this idea is uncertain. The Regext group already has a lot on its plate, and in many cases, it will be the same people working on RPP. What’s more, it’s one thing to issue a standard, quite another to deploy it, and for the moment it’s hard to say whether RPP will attract the necessary following. For example, ICANN (Internet Corporation for Assigned Names and Numbers), has yet to take a position, which is sensible given that RPP is still embryonic.

And it should be noted in passing that, as regards RPP, many technical points remain to be defined. For example, it remains to be seen how the information will be divided between the HTTP header field and the body of the text (in JSON format). Will the command identifier (the equivalent of the clTRID in EPP) be the RPP-clTRID field, or the clTRID component of a JSON object? There’s an advantage to this: since the protocol has not been completed, you can get involved in the project and make your opinion known.

Implementation

Once the protocol is defined, it shouldn’t be too difficult to program an RPP client. All programming languages have software libraries allowing REST requests to be made easily (HTTP and JSON libraries, etc.). In some cases, you can even use a common browser. And then there are some ready-made programs, such as the curl tool on the command line.

To program the server (although only the registry should have to do this), there are also innumerable software frameworks for building a REST server, and the RPP programmer will have many tools available. One of the aims of the RPP project was precisely to allow the numerous software applications already written to be used to facilitate the creation of REST clients and servers. This also includes testing and documentation tools such as those existing around OpenAPI and TypeSpec.

Once the server has been programmed, it has to be hosted. RPP is designed to be hostable in serverless⁷ environments, whether on the registry’s infrastructure using software applications such as OpenFAAS, Fission or Knative, or with specialist hosters such as Heroku, Vercel or Clever Cloud, which provide everything, exempting developers from system administration tasks.

An example

The service in question is a simple demonstrator; it doesn’t claim to be a true registry management system and it isn’t a real implementation of RPP, if only because the protocol is yet to be defined. In the following examples we create, obtain information on and delete a name using curl :

% curl --request PUT --data '{"holder": “Jean Durand”}8' \

        https://registry.courbu.re/domains/foobar.example

{"result": "foobar.example created", "status_code": 201,9 "status_message": "Created"}

% curl https://registry.courbu.re/domains/foobar.example10

{"result": "Domain foobar.example exists", "holder": "Jean Durand", "created": "2024-12-02T18:56:48.042794", "status_code": 200, "status_message": "OK"}

% curl --request DELETE https://registry.courbu.re/domains/foobar.example

{"result": "foobar.example deleted", "status_code": 202, "status_message": "Accepted"}

% curl https://registry.courbu.re/domains/foobar.example                

{"result": "Domain foobar.example NOT found", "status_code": 404, "status_message": "Not found"}

The service is hosted at Clever Cloud and consists of a 140-line program in Python and a PostgreSQL database. A real RPP server would of course be much more complex, with more interesting functionalities.

Conclusion

Work on RPP has barely started, so don’t hesitate to let your voice be heard, especially if you work for a registry or registrar. The API that Afnic has put in place for its registrars is often referred to during discussions, so it’s possible that the future RPP might resemble it.

1 – Other registries, including those of IP addresses such as RIPE-NCC in Europe, do not use EPP.

2 – Traditionally, the term API refers to the interface of a local software library, which programmers use to enrich the software application they’re developing. Nowadays it also often refers to a set of functions that can be called over the Internet. Among other consequences of the transition from one meaning to the other are those relating to software application licences. Some licences, such as that of Affero, have been specifically designed for programs accessed via the Internet.

3 – For example because a firewall allows only this protocol through, or because the holder wishes to use serverless hosting, which is generally HTTP-based.

4 – Work is also in progress on an EoH (EPP over HTTPS) protocol, which is very different from RPP. It does not follow the REST principles and requests are not self-sufficient. As far as EoH is concerned, HTTP is merely a transport protocol.

5 – An area for which HTTP has numerous mechanisms; see for example the HTTP message signatures described in RFC 9421.

6 – RFC 9205 lists the precautionary measures to be taken to build a protocol with HTTP, which will be the case of RPP.

7 – Needless to say, a marketing term, like “cloud”, “intuitive” or “artificial intelligence”. There is a server, but the developer isn’t aware of it and doesn’t know the people who run it. By the way, I’m not getting into the argument as to what serverless really means, since there are several possible definitions.

8 – The holder’s data, encoded in JSON format, are sent to the server. The other requests don’t require data.

9 – If we wish to see the HTTP response code, we can launch curl with the option ---write-out "\n%{http_code}\n" or simply launch it in verbose mode.

10 – We could also have made this command with a common browser, since we’re using GET, the standard browser method.