Hi Andy,
I was referring to this post when I wrote on the session chat that the
effort required for registrars to implement EoH is minimal.
I'd also like to point out that since 2009, approximately 2,000
registrars have implemented EoH. 90% of them are small registrars that
managed or manage just a few domains and are staffed by just a few people.
Best,
Mario
-------- Messaggio Inoltrato --------
Oggetto: Re: [regext] Re: WG Last Call:
draft-ietf-regext-ext-registry-epp-03 (Ends 2026-03-09)
Data: Thu, 5 Mar 2026 09:18:02 +0100
Mittente: Mario Loffredo <[email protected]>
A: Gould, James <[email protected]>, [email protected] <[email protected]>,
[email protected]
<[email protected]>, [email protected] <[email protected]>
Hi Andy,
please find my additional comment below.
Il 04/03/2026 22:43, Gould, James ha scritto:
Andy,
We need to consider the purpose of the EPP Extension Registry for any form of
EPP extension. I believe the purpose of the EPP Extension Registry is to
provide visibility for EPP extension specifications to help encourage
consolidation, which is the case of EoH. I don't see EPP transports any
differently from EPP XML extensions, since both can include security and
private issues, which are not factors for consideration of the DE in
draft-ietf-regext-ext-registry-epp.
Please clarify your statement "security and transaction semantics wrong" with
EoH since I haven't seen any supporting feedback on the mailing list.
Please clarify your statement " EPP-over-HTTP discussion has focused a lot on the costs to the
registries but nobody has mentioned the costs to the registrars" since I haven't seen any
discussion on the mailing list associated with this. Your statement " New EPP transports
should only be encouraged when the costs to all parties are weighed" doesn't align with the
language in RFC 5730, where the intend was to support the extensibility of EPP transports. We
presented multiple times to the REGEXT WG of the perceived value in adding the two new EPP
transports for HTTPS and QUIC with draft-ietf-regext-epp-https and draft-ietf-regext-epp-quic.
[ML] Regarding registrar costs, I'd like to point out that, based on the
experience of .it, managing a TCP connection is much more complex than
managing an HTTP session for clients. Implementers are more accustomed
to sending requests via HTTP rather than TCP, and their work is
supported by frameworks and libraries that relieve them of many
implementation details, such as managing the HTTP session through the
exchange of session cookie. At .it we have several small registrars and
none of them have complained about the implementation effort required to
create a client capable of interacting with the EPP server.
Below is a simple Java example that uses the Apache HttpClient library
to create a client that handles cookies:
CookieStorecookieStore=newBasicCookieStore();
CloseableHttpClientclient=
HttpClients.custom().setDefaultCookieStore(cookieStore).build();
We should allow for the registration of all forms of EPP extensions in the EPP
Extension Registry, where there are no additional hurdles defined in RFC 5730
for EPP transports other than meeting the recommendations in Section 2.1 of RFC
5730.
Thanks,
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
