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 <[email protected]> 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). 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: [email protected] > Phone: +39 050 3153497 > Web: http://www.iit.cnr.it/mario.loffredo > > > _______________________________________________ > regext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/regext > -- DNSimple.com http://dnsimple.com/ Twitter: @dnsimple
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
