The other factor for EPP extension I-Ds is the need for URIs to change during the maturity of the draft to encourage implementation. This has been the pattern for the latest set of EPP extensions. Can RFC 7120 support a wildcard namespace URI early allocation?
Consider the latest EPP extension I-D draft-ietf-regext-balance that has the XML namespace URI urn:ietf:params:xml:ns:epp:balance-0.1, which is close to the Maturity Versioning defined for RDAP, where when the XML schema is change in the I-D the namespace will be bumped and changed to finally changed to urn:ietf:params:xml:ns:epp:balance-1.0 once the I-D passes WGLC. The ABNF format for the XML namespace is "urn:ietf:params:xml:ns:epp:balance-" DIGIT "." DIGIT. There is the risk of material changes occurring after WGLC, but that's a risk an implementer would need to take in implementing ahead of the EPP extension becoming an RFC. -- 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 1/15/26, 4:37 PM, "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: Andy Newton <[email protected] <mailto:[email protected]>> > Sent: Thursday, January 15, 2026 3:26 PM > To: Hollenbeck, Scott <[email protected] > <mailto:[email protected]>>; [email protected] <mailto:[email protected]> > Subject: [EXTERNAL] Re: [regext] Re: I-D Action: > draft-ietf-regext-ext-registry- > epp-01.txt > > 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. > > > On 1/15/26 2:46 PM, Hollenbeck, Scott wrote: > > [SAH] Before I comment on anything below, we need to discuss the > applicability of RFC 7120. It's focused on "Early IANA Allocation of Standards > Track Code Points". I want to emphasize the "Code Points" part of the title. I > didn't find a concise definition in 7120 that describes what a code point is, > but > the acceptability of your replacement text hinges on whether or not an > Internet-Draft can be described as a code point. It seems like a stretch to me > since an I-D isn't a value that needs to be implemented in code where > interoperability depends on value agreement. It's not exactly a TCP port > number, for example. > > > > That's just my take. What do others think? > > Do we really want to rathole on what is and what is not a "code point"? Is it > only a value of no more than one octet? Can a 1 million bit number be a code > point? Are OIDs code points, because they too are sequences of octets, just > like a URI. And OIDs are definitely used in IETF early registrations. > > The point is that 7120 describes the process for early registrations. It is > well > used in the IETF and we would not be doing anything unusual. You stated > during the interim that it would be difficult to write the instructions for > doing > early registrations, and the text on offer shows that you do not need to do > so... it already exists in an RFC. [SAH] 7120 describes a process for early registration of _code points_, not specifications. I agree that it could be used for early registration of URIs, but I'm not convinced that it applies for registration of Internet-Draft specifications. Scott _______________________________________________ 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]
