I believe that we're getting off topic of the WGLC for draft-ietf-regext-ext-registry-epp. The question is not whether creating EPP transports is a good idea, but whether if they are created can they be registered in the EPP Extension Registry. The EPP Extension Registry should not be used as a blocker for the creation of EPP extensions, but simply as a registry to publish the existence of the EPP extensions. In the case of the EPP Extensibility and Extensions analysis, we only found 60% of the EPP extensions analyzed registered in the EPP Extension Registry. I don't believe we identified all the EPP extensions in the wild, so that % is probably around 40% - 50% that are registered. I don't view that % in meeting the goal of the EPP Extension Registry, which is meant to provide visibility for consolidation of EPP extensions. What is the % that defines success for the EPP Extension Registry? I would put that % around 90% and not 40% - 50% since that would make future assessments like the EPP Extensibility and Extensions analysis much simpler and complete.
In the case of EoH, there have been multiple independent specifications and implementations in the wild that were never registered in the EPP Extension Registry. If the community wants to consolidate on EPP extensions that should include the EPP transports, independent of the anticipated number of EPP transports and whether having additional EPP transports is a good thing or a bad thing. Consider that the EPP transports will be defined independent of the registration in the EPP Extension Registry, which leads to the creation of similar incompatible extensions in the wild. -- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 3/5/26, 5:19 AM, "Thomas Corte" <[email protected] <mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello Mario, On 05.03.26 09:18, Mario Loffredo wrote: > [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. Just because we didn't complain (after all, what good would that have done? ccTLDs do as they please anyway) doesn't mean we liked it. Working for two registrars tasked with connecting to all kinds of registries, I actually found it pretty annoying having to deal with registries like .it or .pl using HTTP instead of TCP for their EPP servers. I don't think you can sell this HTTP thing as a benefit to registrars. Once registrars have a proper EPP-over-TCP toolkit in place, the hard part is done and they can connect to any registry using that protocol. Any deviations will only cause more work. The only prospect of use for registrars would be if *all* registries switched to HTTP without exception, but that's not going to happen. Best regards, Thomas -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Diplom-Informatiker Tel: +49 231 9703-0 Thomas Corte Fax: +49 231 9703-200 Stellvertretender Leiter SIP: [email protected] <mailto:[email protected]> Software-Entwicklung E-Mail: [email protected] <mailto:[email protected]> Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp Zertifiziert nach DIN ISO/IEC 27001:2024 _______________________________________________ regext mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
