On Wed, May 23, 2018 at 7:57 AM, Gould, James <jgould=40verisign.com@dmarc. ietf.org> wrote:
> Anthony, > > > > I reviewed your draft. We implemented EPP over HTTP a while back, where > HTTP was treated as transport in line with EPP over TCP (RFC 5734). It was > shut down when it became clear that EPP over TCP was the preferred option.. > The difference with your draft and our implementation is that the draft > defines a stateless transport and our implementation was a stateful > transport. We simply framed the EPP packets using HTTP, with HTTP > keep-alive, and with full support for the EPP login and logout commands. > Changing from stateful to stateless would really not allow easily replacing > the transport on the client-side or the server-side. We used the following > HTTP properties: > > > > 1. Content length is explicitly specified > 2. Chunked transfer encoding of HTTP 1.1 > 3. Content-type set to “text/xml” > > > > The 2-way HTTPS connection would be established, the client packet is > framed as an HTTP packet and sent to the server, where the server processed > the HTTP packet as it would a framed packet with EPP over TCP. All of the > EPP over HTTP commands and responses would behave consistently with EPP > over TCP. > Thanks for the details James. I agree that existing EPP clients and servers that depend on the statefulness of the transport would not be able to use stateless HTTP. I envision this as more of an alternative for smaller registries that currently limit their concurrent connections to extremely low values (as low as max 2 concurrent connections in some cases, as far as I understand it). Larger registries would probably not see an advantage in using HTTP 1.1, although might receive benefits from HTTP/2 (I have not investigated this fully). Sincerely, Anthony Eden -- DNSimple.com http://dnsimple.com/ Twitter: @dnsimple
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
