inline... On 1/16/26 9:58 AM, Gould, James wrote: > 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.
James, The text I offered applies 7120 process to the EPP Extension registry, not the XML namespace registry. To avoid the problem you outline, the text I offered exempts Internet Drafts from the requirement to register XML namespace IDs and schemas. >> 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, If you want to take this line of reason to its hair-splitting end, the EPP extension registry is a registry of URI references to EPP extension specifications. The specifications themselves are not in the EPP extensions registry. And URIs are a sequence of octets, just like OIDs and other "code points". What I have put forward is a compromise between "NO I-Ds AT ALL" and "I-Ds ALWAYS AND FOREVER". And, IMHO, without this compromise I believe the default is what you have in the current text. I am not gonna die on a hill over this. If the working group wants "NO I-Ds AT ALL" then so be it. -andy, as an individual _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
