It amuses me that son-of-son-of-RRP might be called RPP :-) There’s some interesting history behind EPP, which is what RPP might replace…
Back in the mists of time (the 1980s), things like domain names and IP addresses were requested and assigned by exchanging email with IANA, ie, Jon Postel, Jake Feinler, and their team. They had a collection of forms you had to fill in, and anyone could use whois to retrieve a copy of the form for a domain name or IP address block.
As part of commercializing the Internet in the early 1990s, management of the DNS was mostly outsourced to Network Solutions (apart from the ccTLDs). They kept the very manual email-based process and charged a lot of money for it. By the end of the 1990s there was a great deal of dissatisfaction, and through a lot of concerted lobbying and some direct action, the Network Solutions monopoly was broken up:
the .org TLD was taken over by the non-profit Public Interest Registry, which uses the profits to fund ISOC and the IETF
a plan was made to create new gTLDs to provide more alternatives to .com
(relevant to this article) the task of DNS registration was split in two: registries would run the registration databases and DNS servers, and would be forbidden from dealing directly with registrants; registrars would do customer service for registrants, and there would be many registrars to choose from
ICANN was established to take over IANA (after Jon Postel’s death), set up the new TLDs, and regulate the registries and registrars.
(The company currently called Network Solutions is the registrar part of the 1990s Network Solutions; the registry part is now called Verisign.)
A new automatic domain name registration API was created called RRP, the registry-registrar protocol. (Sadly they didn’t design a registrant-registrar protocol, so end-user creation and management of domain names is a mess of manual user interfaces and proprietary APIs.) RRP was a classic ARPANET-style protocol, like SMTP: four-letter commands, three digit response codes, dot-terminated messages that were basically the same format as whois records.
RRP was replaced within a few years. EPP, the extensible provisioning protocol, does the same job as RRP did, but with XML. EPP is a little like Jabber/XMPP in that it uses a long-lived stateful TCP connection, though the XML messages are framed differently.
Personally I don’t think EPP is a great improvement over RRP. XML’s extensibility doesn’t help much with this kind of thing: there’s still a lot of protocol design work required to make the application extensible, for example (like message framing) XMPP and EPP do feature negotiation differently. Also I am not a fan of using such a non-specific name for a protocol with a very specific purpose. And it’s hilarious to me that EPP uses 4 digit response codes, not 3 digit codes, and not an XML-structured code.
Stéphane lists a number of reasons that EPP is disliked. I would add that EPP makes it harder than it should be to build a registrar: you have to have some kind of back-end service that maintains your persistent stateful EPP connections, to deal with the impedance mismatch between EPP and your customer-facing web front-end and HTTP API.
The article mentions EPP-over-HTTPS in footnote 4. I think the description is not quite right (EoH does not depend on a long HTTP connection) but it’s true that EoH is a strange beast:
First make a GET request, which corresponds to an EPP connection’s initial greeting exchange. The HTTP response sets a cookie which is used to associate subsequent HTTP requests to the same EPP session.
Then POST an EPP login command, after which you can do actual useful things with your cookie. This is a freakishly non-HTTPish way to do authentication!
You aren’t allowed to make concurrent requests with the same cookie, which means EoH does not help a registrar to get rid of their stateful EPP client service.
It could be worse, though: EPP has machinery for asynchronous actions and notifications from registries to registrars, but fortunately these are implemented by the client (registrar) sending a poll command to the server to retrieve pending notifications. So apart from the login faff, the protocol is basically request/response RPC. It’s just a shame that (arguably for silly reasons) it maps poorly to HTTP.
Another thing that has been happening in recent years is the rollout of RDAP (registration data access protocol) as a JSON-over-HTTPS replacement for the venerable and unloved whois.
It makes sense to me that a successor to EPP should:
use a common and familiar style of HTTP authentication
use a common and familiar style of HTTP concurrency control and backpressure
re-use the RDAP data model and syntax
Most of this is not directly relevant to domain registrants. But in my experience the details of EPP tend to leak through to the user interfaces and APIs provided by registrars — which is why I needed to learn this stuff for practical reasons, not just general interest. So I kind of hope that an improved back-end protocol will lead to better user-facing protocols. We shall see, I guess!
It amuses me that son-of-son-of-RRP might be called RPP :-) There’s some interesting history behind EPP, which is what RPP might replace…
Back in the mists of time (the 1980s), things like domain names and IP addresses were requested and assigned by exchanging email with IANA, ie, Jon Postel, Jake Feinler, and their team. They had a collection of forms you had to fill in, and anyone could use whois to retrieve a copy of the form for a domain name or IP address block.
As part of commercializing the Internet in the early 1990s, management of the DNS was mostly outsourced to Network Solutions (apart from the ccTLDs). They kept the very manual email-based process and charged a lot of money for it. By the end of the 1990s there was a great deal of dissatisfaction, and through a lot of concerted lobbying and some direct action, the Network Solutions monopoly was broken up:
the .org TLD was taken over by the non-profit Public Interest Registry, which uses the profits to fund ISOC and the IETF
a plan was made to create new gTLDs to provide more alternatives to .com
(relevant to this article) the task of DNS registration was split in two: registries would run the registration databases and DNS servers, and would be forbidden from dealing directly with registrants; registrars would do customer service for registrants, and there would be many registrars to choose from
ICANN was established to take over IANA (after Jon Postel’s death), set up the new TLDs, and regulate the registries and registrars.
(The company currently called Network Solutions is the registrar part of the 1990s Network Solutions; the registry part is now called Verisign.)
A new automatic domain name registration API was created called RRP, the registry-registrar protocol. (Sadly they didn’t design a registrant-registrar protocol, so end-user creation and management of domain names is a mess of manual user interfaces and proprietary APIs.) RRP was a classic ARPANET-style protocol, like SMTP: four-letter commands, three digit response codes, dot-terminated messages that were basically the same format as whois records.
RRP was replaced within a few years. EPP, the extensible provisioning protocol, does the same job as RRP did, but with XML. EPP is a little like Jabber/XMPP in that it uses a long-lived stateful TCP connection, though the XML messages are framed differently.
Personally I don’t think EPP is a great improvement over RRP. XML’s extensibility doesn’t help much with this kind of thing: there’s still a lot of protocol design work required to make the application extensible, for example (like message framing) XMPP and EPP do feature negotiation differently. Also I am not a fan of using such a non-specific name for a protocol with a very specific purpose. And it’s hilarious to me that EPP uses 4 digit response codes, not 3 digit codes, and not an XML-structured code.
Stéphane lists a number of reasons that EPP is disliked. I would add that EPP makes it harder than it should be to build a registrar: you have to have some kind of back-end service that maintains your persistent stateful EPP connections, to deal with the impedance mismatch between EPP and your customer-facing web front-end and HTTP API.
The article mentions EPP-over-HTTPS in footnote 4. I think the description is not quite right (EoH does not depend on a long HTTP connection) but it’s true that EoH is a strange beast:
First make a GET request, which corresponds to an EPP connection’s initial greeting exchange. The HTTP response sets a cookie which is used to associate subsequent HTTP requests to the same EPP session.
Then POST an EPP login command, after which you can do actual useful things with your cookie. This is a freakishly non-HTTPish way to do authentication!
You aren’t allowed to make concurrent requests with the same cookie, which means EoH does not help a registrar to get rid of their stateful EPP client service.
It could be worse, though: EPP has machinery for asynchronous actions and notifications from registries to registrars, but fortunately these are implemented by the client (registrar) sending a poll command to the server to retrieve pending notifications. So apart from the login faff, the protocol is basically request/response RPC. It’s just a shame that (arguably for silly reasons) it maps poorly to HTTP.
Another thing that has been happening in recent years is the rollout of RDAP (registration data access protocol) as a JSON-over-HTTPS replacement for the venerable and unloved whois.
It makes sense to me that a successor to EPP should:
use a common and familiar style of HTTP authentication
use a common and familiar style of HTTP concurrency control and backpressure
re-use the RDAP data model and syntax
Most of this is not directly relevant to domain registrants. But in my experience the details of EPP tend to leak through to the user interfaces and APIs provided by registrars — which is why I needed to learn this stuff for practical reasons, not just general interest. So I kind of hope that an improved back-end protocol will lead to better user-facing protocols. We shall see, I guess!