Re: [regext] Interest in collaborating on an EPP over HTTP draft?

[Patrick Mevzek <[e-mail]>]

On Wed, May 23, 2018, at 13:46, Anthony Eden wrote:
> I do see mentions of SMTP and BEEP in RFC 5730 in the transport discussion,
> but none of them ever became standards, right?

You are correct, after all discussions, only EPP over TLS was defined as transport.

I was able to find the following documents describing various transports for EPP:
* EPP over BXXP: https://tools.ietf.org/html/draft-ietf-provreg-epp-beep-02
* EPP over REST: https://tools.ietf.org/html/draft-wullink-restful-epp-00
(so again over HTTP too)
* EPP over SOAP: https://tools.ietf.org/html/draft-liu-epp-soap-00
(some kind of HTTP also, even if SOAP could be layered on top of various transports)
* EPP over SMTP: https://tools.ietf.org/html/draft-brunner-epp-smtp-00

They all have sections on sessions, stateless vs stateful, etc.
 
As for discussions, this page:
http://www.cafax.se/ietf-provreg/maillist/2001-08/threads.html
as links to more than one email about messages and transports.

> I mention briefly in the introduction of the draft, however my goals with
> this draft would be to make it registry implementation easier for small
> registries who currently only provide a very small number of concurrent TCP
> connections. Stateless protocols should be easier for a small registry to
> work with as requests can be distributed across multiple servers without
> the need for session tracking.

My experience does not match this, so I may lack some examples/points,
and I would like to learn more.

I guess it all depends what you define as big or small registries.

Here are some facts I know about:

* for the one I know using EPP over HTTPS they are not exactly registries I would call small: both .IT and .PL are well over 2 millions of domain names. I am sure they would have been smaller when they started EPP over HTTPS and while I lack hard facts on this, I am sure they already had hundreds of thousands of domains then
* I know at least one ccTLD registry even bigger than .IT or .PL, where everything (all TLS connections) are handled by one server
* I think big/small is here not really related to the number of domain names but more the number of registrars, and the number of connections allowed to each of them (connections or sessions, depending how much state you have).
I believe that a small registry could be something with dozens of registrars maybe in the small hundreds number, that is all, and for the number of connections I guess there would be no need of more than 1 or 2 per registrar.
What I want to say here is that alltogether I think it makes a low number of connections to handle.
* all registries impose timeouts on their connections, typically in the 15 minutes average, and some of them apply also hard timeouts, hence releasing a connection after a given time whatever happens.

What is true however is that nowadays with many services using the "cloud",
no other port than 443 may be exposed to the outside world, or maybe no "lower" ports. In the second case, even if 700 is the standard EPP port, any other one could be used.

Also, Nomulus, the Google open source EPP based registry implementation
had the same kind of problems for a long time, quoting their documentation:
GAE Proxy: App Engine Standard only serves HTTP/S traffic. A proxy to forward traffic on EPP and WHOIS ports to App Engine via HTTPS is provided.
(first releases did not have this proxy)

So maybe the problem is more related on where/how the application servers run?

> Additionally I think HTTP would be easier for new registrars to start with
> because of existing client-side tooling and libraries.

I am not sure to understand this point. You have two parts, the transport and the protocol. The protocol is EPP, based on XML. All languages have full support of XML. You may want to have an EPP library for some abstraction over XML but in any case it would be the same library used for generating/parsing the EPP frames, whatever transport you are using, so HTTPS or TLS that does not change that point I believe.
And all languages also have full support for TLS (HTTPS needs it obviously), real problems are more around certificates management and algorithms configuration, which will be exactly the same at the TLS or HTTPS level.

> As for the drawbacks, to take advantage of HTTP 1.1's stateless nature, the
> specific requirement of EPP being stateful will need to be relaxed. Also,
> there is additional data (headers) that must be transported with HTTP
> requests vs. EPP over TCP which increases the amount of bandwidth used per
> request.

I believe anyway that even without adding anything, HTTP as a layer adds data/metadata and hence the messages are bigger.

For example, the length of the message will need as many bytes as
"Content-Length: " + size where in TCP there would be just the size.

However I would not think too much about bandwidth use, as XML is already not a very light serialization mechanism.
 
> I have nothing against an HTTP/2 implementation, I just don't see it as
> having the same benefits as HTTP/1.1 given that HTTP/2 uses a single TCP
> connection and multiplexing, effectively negating the stateless benefits of
> HTTP/1.1.

Ok, I can see that. But I think it would still be strange to define a new standard today saying that you need to use HTTP/1 with it and not the newer HTTP/2.

And at least in the gTLD world, things could probably not implemented before existing as an RFC. And some gTLDs are very small. This is not technical related but may need to be taken into account if you wish for large adoption.

-- 
  Patrick Mevzek