Hi James,
For what I have understood, your implementation is based on the
assumption that once the HTTP Connection is established, it is used for
the transit of all the HTTP requests of an EPP session, starting from
the Login and ending with the Logout.
Consequently, you rely on keeping the
All,
My apologies for the lateness of this reply.
As the Document shepherd I have verified that no substantial changes were made
since version 04 of the document. I will start my writeup of the document and
plan to complete in the next several days.
Please let me know if you have any question
Thank you Dmitry.
@Jim (Gould) and Dimtry - Does this draft contain any IPR? We'll need to know
in order to complete the review for the submission.
Thanks,
Jody Kolker.
-Original Message-
From: regext On Behalf Of Dmitry Belyavsky
Sent: Friday, January 21, 2022 12:15 PM
To: regext
S
Hello Mario,
On 3/31/22 13:52, Mario Loffredo wrote:
Hi James,
For what I have understood, your implementation is based on the
assumption that once the HTTP Connection is established, it is used for
the transit of all the HTTP requests of an EPP session, starting from the
Login and ending w
Hi Thomas,
thanks a lot for your interest as well as your attempt to mediate
between James's position and mine. Very appreciated :-)
Starting an HTTP session when receiving an EPP command other than the
Login command is in .it experience (but I can speak on behalf of .pl
too) very inefficien
On Thu, Mar 31, 2022, at 10:36, Mario Loffredo wrote:
> Starting an HTTP session when receiving an EPP command other than the
> Login command is in .it experience (but I can speak on behalf of .pl
> too) very inefficient because you can't immediately lock the HTTP
> session to the Registrar.
I
Hi Patrick,
thanks for your interest.
Il 31/03/2022 17:54, Patrick Mevzek ha scritto:
On Thu, Mar 31, 2022, at 10:36, Mario Loffredo wrote:
Starting an HTTP session when receiving an EPP command other than the
Login command is in .it experience (but I can speak on behalf of .pl
too) very ineff
Hello Mario,
On 3/31/22 17:36, Mario Loffredo wrote:
Starting an HTTP session when receiving an EPP command other than the
Login command is in .it experience (but I can speak on behalf of .pl too)
very inefficient because you can't immediately lock the HTTP session to
the Registrar.
Ok, but
In a scenario where a proxy/load balancer is terminating the TLS
connection, it will most likely need to extract the certificate
information, and encode it into a HTTP header, so that the backend could
later tie the `clID` with the certificate in a way (i.e.: `cn`).
That's what I would do, to
Hi Thomas,
Il 31/03/2022 19:17, Thomas Corte (TANGO support) ha scritto:
Hello Mario,
On 3/31/22 17:36, Mario Loffredo wrote:
Starting an HTTP session when receiving an EPP command other than the
Login command is in .it experience (but I can speak on behalf of .pl
too) very inefficient becau
> -Original Message-
> From: regext On Behalf Of Thomas Corte
> (TANGO support)
> Sent: Thursday, March 31, 2022 1:17 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-
> over-http
>
> Caution: This email originated from outside the organizatio
Hi Francisco,
Maybe we are complicating a bit (just to be polite) something that
would be very easy if the server started every EPP session only after a
successful Login.
Anyway, just for curiosity, can you provide me with an example for NGINX?
It doesn't sound so simple according to this p
Something like this would work with HAproxy:
https://www.haproxy.com/blog/ssl-client-certificate-information-in-http-headers-and-logs/
Best,
On 31 Mar 2022, at 11:14, Mario Loffredo wrote:
Hi Francisco,
Maybe we are complicating a bit (just to be polite) something that
would be very easy
Hi Francisco,
appreciated but:
1) The ssl variables in NGINX are different.
2) Even supposing to extract CN or SAN, as it seems one should do in
NGINX via a regular expression, it doesn't necessarily correspond to the
registrar username to access the EPP server.
3) I repeat: why should I co
From: regext On Behalf Of Mario Loffredo
Sent: Thursday, March 31, 2022 4:03 PM
To: Francisco Obispo
Cc: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http
Caution: This email originated from outside the organization. Do not click
links or open att
Hi Mario,
Response inline.
On 31 Mar 2022, at 13:03, Mario Loffredo wrote:
Hi Francisco,
appreciated but:
1) The ssl variables in NGINX are different.
Yes, they usually are :-)
2) Even supposing to extract CN or SAN, as it seems one should do in
NGINX via a regular expression, it does
A new Request for Comments is now available in online RFC libraries.
STD 95
RFC 9224
Title: Finding the Authoritative Registration Data
Access Protocol (RDAP) Service
Author: M. Blanchet
Status: Standards Track
17 matches
Mail list logo
