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]
