Hi Thomas,
given that I agree with James that the issue here is whether new EPP
transports should be registered as extensions, I would like to address
some of your points in this post.
So please find my comments below.
Il 05/03/2026 11:19, Thomas Corte ha scritto:
Hello Mario,
On 05.03.26 09:18, Mario Loffredo wrote:
[ML] Regarding registrar costs, I'd like to point out that, based on
the experience of .it, managing a TCP connection is much more complex
than managing an HTTP session for clients. Implementers are more
accustomed to sending requests via HTTP rather than TCP, and their
work is supported by frameworks and libraries that relieve them of
many implementation details, such as managing the HTTP session
through the exchange of session cookie. At .it we have several small
registrars and none of them have complained about the implementation
effort required to create a client capable of interacting with the
EPP server.
Just because we didn't complain (after all, what good would that have
done? ccTLDs do as they please anyway) doesn't mean we liked it.
Working for two registrars tasked with connecting to all kinds of
registries, I actually found it pretty annoying having to deal with
registries like .it or .pl using HTTP instead of TCP for their EPP
servers.
I don't think you can sell this HTTP thing as a benefit to registrars.
[ML] I never said that. I simply emphasized that the implementation
effort required by EoH itself is low because managing TCP sockets is
more complex than managing HTTP requests and sessions, especially since
several libraries in different languages support HTTP programming.
When the .it registry planned to migrate from the old asynchronous
management system to the synchronous EPP-based version, it decided that,
for the reasons outlined above, it was much more advantageous for most
Italian registrars registering .it domains to implement EPP over HTTP
rather than TCP. Implementing EPP over HTTP was also advantageous for
the registry because many of the implementation details related to
managing concurrency, receiving EPP requests and sending EPP responses,
managing EPP sessions, and even configuring an efficient load-balancing
infrastructure could be delegated to established HTTP and L7 technologies.
Additionally, there is now also demand from registries intending to
migrate their services to the cloud that could benefit from implementing
EoH instead EoT.
Once registrars have a proper EPP-over-TCP toolkit in place, the hard
part is done and they can connect to any registry using that protocol.
Any deviations will only cause more work.
The only prospect of use for registrars would be if *all* registries
switched to HTTP without exception, but that's not going to happen.
[ML] There's a middle ground between little or 0% and 100%.
Since RFC5730 allows EPP to be implemented on different transports, I
think it's natural to expect that different transport layer mappings can
be used.
Otherwise, it would be like saying that EPP is inextensible and
unchangeable from this perspective.
Therefore, RPP also has little reason to exist, because EPP and RPP
fulfill the same requirements but in different ways.
EoH aims to take advantage of HTTP as a transport, minimizing the
implementation effort required by registries planning to migrate their
services to the cloud.
Best,
Mario
Best regards,
Thomas
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
