Hi Anthony and Patrick,
I'm interested in collaborating.
I speak on behalf of .it but I'm pretty sure that .pl implements EPP
over HTTP in the same way we do.
At .it, we have not implemented the EPP Login based on HTTP basic
authentication, we have left it as is to keep EPP as much as possible
independent from the trasport layer.
In my opinion, storing the Login information in the request header is
wrong, because you mix EPP with HTTP information. Defintively, you
cannot parse the Login request in the same way of the other requests.
It seems to me that your draft does not consider how to map an EPP
session over HTTP.
Session tracking over HTTP basically requires that a session ID is
maintained across multiple requests to the server.
A successfully Login returns a session ID in the response cookies that
the client is requested to use in the subsequent requests belonging to
the same EPP session until the session is closed
by Logout or by server timeout. In our implementation, sessions are
maintained outside the application server so we can easily add new
machines in a load-balanced architecture.
The Hello request can be used inside a session or outside. Therefore,
Hello and Login are the only requests not containing a session ID (the
Hello may not, the Login must not). Any other request which does not
contain a session ID as well as any other request containing an invalid
or unknown session ID is rejected with an error.
EPP errors are returned as part of the response body.
We use HTTPS but security is enforced by allowing the access to our live
servers only to some IP addresses each registrar has previously defined
in an appropriate portal.
With regards to multipart messages support, honestly, I must say that we
have never dealt with this case. The length of EPP requests is limited
and also the responses, even if they are generally longer than the
requests, don't need a multipart message.
Regards,
Mario
Il 23/05/2018 03:29, Patrick Mevzek ha scritto:
Hi Anthony,
On Tue, May 22, 2018, at 18:09, Anthony Eden wrote:
I've thrown together a repo over at GitHub to work on an EPP over HTTP
draft (https://github.com/aeden/epp-over-http). I'd love to know if there
are others from the community who are interested on collaborating.
As I am sure you are aware, some registries currently uses HTTPS, like .IT
and .PL at least.
It may be a good idea, if not already, to try sharing discussions with them and
see if you can converge on something, if you are planning to do a standard.
You may also be aware that when EPP itself was drafted they were then multiple
other proposals for transport, besides TLS. There was at least SMTP if I recall
correctly and BXXP (BEEP) which I think does not really exist anymore but it
looks like to me that many of its features are also present nowadays in HTTP/2.
Maybe there are some ideas to grab from these past attempts, the documents
themselves or the discussions.
As a
registrar, we'd love to be able to work with registries using HTTP as the
transport protocol in the future.
I am curious, why particularly prefering HTTP over TCP (or more precisely HTTPS
over TLS)?
Did you tak time already to document the differences with TCP, in the realm of
EPP, what are the benefits and the drawbacks?
Note that the current version of this draft deals solely with EPP over HTTP
1.1, it does not consider HTTP 2 at this time.
(I did not look at your code/document yet).
Why is it so?
Just a lack of time or some specific reason against HTTP/2?
If there anything that works with HTTP/1.1 but not /2 it should be documented.
As nowadays, for new works, I think it is best to concentrate on the newer
versions of other standards when you do a layering (hence HTTP/2) instead
of forcing retro-compatibilies, except if good reasons for that of course, this
is what I am curious about.
--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: mario.loffr...@iit.cnr.it
Phone: +39 050 3153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
