> -----Original Message----- > From: Andy Newton <[email protected]> > Sent: Wednesday, October 22, 2025 11:41 AM > To: Hollenbeck, Scott <[email protected]>; > [email protected]; draft-ietf-regext-ext-registry- > [email protected]; [email protected] > Subject: [EXTERNAL] Re: [regext] Re: WG Last Call: > draft-ietf-regext-ext-registry- > epp-00 (Ends 2025-10-27) > > 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 22-10-2025 10:59 AM, Hollenbeck, Scott wrote: > >> -----Original Message----- > >> From: Andy Newton <[email protected]> > >> Sent: Tuesday, October 21, 2025 2:57 PM > >> To: Hollenbeck, Scott <[email protected]>; > >> [email protected]; draft-ietf-regext-ext-registry- > >> [email protected]; [email protected] > >> Subject: [EXTERNAL] Re: [regext] Re: WG Last Call: > >> draft-ietf-regext-ext-registry- > >> epp-00 (Ends 2025-10-27) > >> > >> 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 10/21/25 14:23, Hollenbeck, Scott wrote: > >>>> Once there is an implementation of a particular version of an I-D, > >>>> does that mean a WG or the IETF are no longer free to change the > >> specification? > >>> > >>> [SAH] Of course not, but you dodged *my* question. What are we > >>> trying to > >> accomplish? If our goal is transparency, I see more benefit in > >> allowing the EPP registration, not registering the squatted-on > >> namespace URNs, and adding a note to the EPP registry entry that the > >> registered extension references unregistered URNs than in rejecting the EPP > registration. > >> > >> So the IETF should sanction a process whereby the IETF's own BCP is > >> being violated? Then what is the point of having namespaces in EPP if > >> they can be violated? (which also brings up the issue that the DEs > >> should be checking to make sure new registrations aren't re-using > >> URIs that are already registered) Also, what happens if the IETF > >> un-abandons > the work? > >> > >> The point I was attempting to make above is that if an implementation > >> can change within the WG process, it can change outside of it as > >> well. That is, the registration of the "abandoned" extension should > >> have changed to use a non- conflicted URI. > >> > >> Also, the point of the IANA registry is interoperability. To that > >> end, mistakes made in the past should not continued to be made in the > future. > > > > [SAH] When dealing with a non-RFC specification, registration of both the > > EPP > extension and any XML schemas and/or namespaces is voluntary. There's no > BCP (are you referring to BCP 81?) violation if no one requests registration > of > the values. So let's imagine that some submits a request to register an EPP > extension, and an expert notices that an XML namespace hasn't been > registered. If this draft says that the namespace MUST be registered in order > to > register the EPP extension, and the requestor refuses to do so for some > reason, > the extension registration request must be rejected and we lose information > describing the extension. If the draft says SHOULD be registered, we can still > register the EPP extension if the namespace isn't registered. I agree that it > isn't > optimal, but I'd prefer to have the extension registered without the namespace > being registered as opposed to not registering the extension at all. As I > wrote > above, we can always add a note in the EPP extension registry that the > namespace hasn't been registered for some reason. > > > > We're talking about adding a normative requirement that will have an impact > on the DE review process. I'll repeat what I wrote yesterday about wanting > more > input to better measure consensus. > > If neither XML schemas or namespaces are required to be produced when > submitting a registration, then how does this work? (from 7451). > > Extensions should be evaluated for architectural soundness using the > guidelines described in RFC 3735 [RFC3735], including the Security > Considerations section of that document. Expert evaluation should > explicitly include consideration of the privacy consequences of > proposed extensions, and, at a minimum, ensure that any privacy > considerations are fully documented in the relevant specification(s). > > BTW, the BCP I was referencing was RFC 3688 / BCP 81.
[SAH] Note that there's nothing explicitly mentioned there about registering XML namespace or schema URIs. The syntax of the values used is addressed in Section 2.2 of RFC 3735. When IANA asks me to review a registration request, my review includes looking at the namespace and schema URIs in the spirit of "architectural soundness" and the requirements from 3735. If they're not registered, I ask IANA to ask the requestor to register them. IANA does that, and sometimes they get registered. Sometimes they don't. If the rest of the specification is OK, and the registration template is OK, I approve the request. Scott _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
