Hi Anthony,
I would be pleased to collaborate directly.
Looking back to my previous response, thare are many other issues coming
in my mind that I would like to discuss.
At a first sight, .it implementation seems basically the same as
described by James.
I don't want to be too verbose now but I can also explain why we decided
to use HTTP instead of TCP.
Regards,
Mario
Il 23/05/2018 13:58, Anthony Eden ha scritto:
Mario,
Thank you for your feedback. I'd love to have your direct input on the
draft if and when you have the time (and if it makes sense).
On Wed, May 23, 2018 at 4:08 AM, Mario Loffredo
<mario.loffr...@iit.cnr.it <mailto:mario.loffr...@iit.cnr.it>> wrote:
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.
The draft considers each request to be stateful in its own right. Thus
clients are effectively making each request its own session. It's a
loose interpretation of RFC5730's protocol requirements, but I still
think it fits. Supporting multipart allows for sequences of related
frames to be processed without making a new HTTP request for each.
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.
It sounds like an HTTP/2 implementation could help you significantly
given its multiplexing over a single connection.
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.
The draft indicates this as well.
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.
Totally reasonable.. Defense in depth and all that.
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.
The purpose of multipart is to allow related EPP frames to be sent in
a single HTTP request.
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
<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 <mailto:mario.loffr...@iit.cnr.it>
Phone: +39 050 3153497
Web: http://www.iit.cnr.it/mario.loffredo
<http://www.iit.cnr.it/mario.loffredo>
_______________________________________________
regext mailing list
regext@ietf.org <mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext
<https://www.ietf.org/mailman/listinfo/regext>
--
DNSimple.com
http://dnsimple.com/
Twitter: @dnsimple
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
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
