Andy, Do you have an alternate proposal in defining the goal? I believe interoperability is improved based on having visibility of what already exists before creating a duplicate extension and to help consolidate the overlapping extensions.
-- 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, 3:13 PM, "Andy Newton" <[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. Nope. RFC 8126 says that IANA registries are for interoperability. That is the purpose of IANA registries. If you want to make others aware of what you have done, I suggest LinkedIn. -andy On 05-03-2026 2:46 PM, Gould, James wrote: > Andy, > > Should we replace those paragraphs with an agreed upon goal for the registry, > such as? > > The goal of the registry is to publish the known existing extensions for > visibility for consolidation and to reduce functional duplication. > > Thanks, > > -- > > JG > > James Gould > > Fellow Engineer > > [email protected] <mailto:[email protected]> > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected] > <mailto:[email protected]>> > > 703-948-3271 > > 12061 Bluemont Way > > Reston, VA 20190 > > Verisign.com > <http://secure-web.cisco.com/1GUbsi-PZYM9j0Qn0YPUP0SouEsWP5QZEcbhll8wSLL-VpDfI_5g_lPr7e2UYvbihHX_GMc6cL-tct3ylMMU0UZ7g2Or2YhVSCjhubfD6vt98dph5RFbKEgGCfk4p22Xm4XiPewnS-lnFTdxdU5N7sg9s6JcGcXYPrkZ4s2VMG6l07cAe75YHLwtqm--MnR5zfTagBDw4RhA4iqh_3owvXEXATJP3vF-JKw79YOieFXBnuepi2GvuOa2csuAwOx0ayLCwHVQwgxQ2WUOnVi9rUWb5uce61GNk4lHLHKH1_RAlSSKX-tmjgjEyjd_Df5Rc/http%3A%2F%2Fverisigninc.com%2F> > > <http://secure-web.cisco.com/1GUbsi-PZYM9j0Qn0YPUP0SouEsWP5QZEcbhll8wSLL-VpDfI_5g_lPr7e2UYvbihHX_GMc6cL-tct3ylMMU0UZ7g2Or2YhVSCjhubfD6vt98dph5RFbKEgGCfk4p22Xm4XiPewnS-lnFTdxdU5N7sg9s6JcGcXYPrkZ4s2VMG6l07cAe75YHLwtqm--MnR5zfTagBDw4RhA4iqh_3owvXEXATJP3vF-JKw79YOieFXBnuepi2GvuOa2csuAwOx0ayLCwHVQwgxQ2WUOnVi9rUWb5uce61GNk4lHLHKH1_RAlSSKX-tmjgjEyjd_Df5Rc/http%3A%2F%2Fverisigninc.com%2F>> > > On 3/5/26, 2:40 PM, "Andy Newton" <[email protected] <mailto:[email protected]> > <mailto:[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. > > I agree. If 50% of EPP extensions have not been registered than the goal of > this registry has not been met. > > Given that, the following paragraphs from Section 1 should be struck: > > > RFCs 3735 and 5730 do not describe how extension development can be managed > > and coordinated. This has led to a situation in which server operators can > > develop different extensions to address similar needs, such as the > > provisioning of Value Added Tax (VAT) information. Clients then need to > > support multiple extensions that serve similar purposes, and > > interoperability suffers as a result. > > > > > > An IANA registry can be used to help manage and coordinate the development > > of protocol extensions. This document describes an IANA registry that will > > be used to coordinate the development of EPP extensions. > > > > > Thanks for pointing this out. > > -andy, as an individual > > On 05-03-2026 8:26 AM, Gould, James wrote: > > > 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. > > > > > _______________________________________________ > > regext mailing list -- [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > To unsubscribe send an email to [email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
