My proposal is for the EPP Extension Registry to include specifications for all the forms of EPP extensibility by referencing both RFC 5730 and RFC 3735, since RFC 3735 only provides guidelines for the EPP XML extensions. We're in the process of working on two transports in REGEXT with EoH (draft-ietf-regext-epp-https) and EoQ (draft-ietf-regext-epp-quic), which I believe should wind up in the EPP Extension Registry. We created EPP extensions in the form of operational practices in RFC 9038 (Unhandled Namespaces) and in RFC 9154 (Secure Authorization Information for Transfer) that should continue to reside in the EPP Extension Registry. Use of a narrow view of what an EPP extension is will not enable leveraging the goal of the EPP Extension Registry of "to coordinate the development of EPP", which means that defined EPP extensions are known with an opportunity to consolidate them into a standard set of extensions. Leaving out a classification of EPP extensions based on the narrow interpretation of what an EPP extension is, will reduce the value of the EPP Extension Registry as being the possible source of truth for the EPP extensions in all forms that exist. The change is straight forward to make draft-ietf-regext-ext-registry-epp inclusive of all forms of EPP extensibility by referencing both RFC 5730 and RFC 3735 with no pre-defined expectation of the inclusion of XML namespaces and XML schemas.
-- 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, 8:53 AM, "Hollenbeck, Scott" <[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. > -----Original Message----- > From: Gould, James <[email protected] > <mailto:[email protected]>> > Sent: Thursday, March 5, 2026 8:27 AM > To: [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Subject: [EXTERNAL] [regext] Re: WG Last Call: draft-ietf-regext-ext-registry- > epp-03 (Ends 2026-03-09) > > 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. > > 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. [SAH] [snip] Something to consider: RFC 5730 and its predecessors don't describe new transport mappings as extensions. That's why they're not addressed in RFC 3735. I'm not opposed to the idea of adding text to this draft to allow registration of new transport mappings since doing so can benefit from "an IANA registry that will be used to coordinate the development of EPP extensions" as described in RFC 7451. However, it's a new feature. We need a clear sense of working group consensus to add that new feature. Scott _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
