Andy, I provide feedback below.
-- 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 11/6/25, 6:21 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. Hi all, I thought I would start a new thread because the other one is quite long and the conversation is all over the place. There are two IANA registries at play here, the one governed by RFC 3688 (XML Registry) and the one governed by RFC 7451 (EPP Extensions). The XML Registry is for XML namespace, schema, and publicId registrations. Any XML namespace identifier that is a URI can be registered in it, however only the IETF via an RFC can register urn:ietf... namespace identifiers. JG - There has never been the requirement to register XML namespaces for proprietary extensions. I don't believe we need to add a requirement to register the XML namespaces as a dependency to register an EPP extension in the EPP extension registry. The EPP extensions registry is a place where URLs to EPP extension specifications can be registered, and anybody can register an EPP extension. Unfortunately, many EPP extensions do not have their namespace identifiers and schemas registered in the XML registry. This is bad for interoperability, which is the entire point of an IANA registry. Even worse, six of the EPP extensions in this registry use urn:ietf namespace identifiers, and in at least one case claiming IPR over it. They should not be doing that. JG - There is no interoperability issue that I'm aware of for EPP with the existing set of XML namespaces. I don't believe the working group should make any calls with the EPP extension registry until the RST 2.0 and the Next Round Base Registry Agreement issue is addressed. The registration of the urn:ietf namespace identifier that includes IPR was due to implementation of an abandoned working group document and meeting the RST 2.0 requirement. I believe the mistake was the need to register it in the first place. While mistakes were made, we should not allow this to continue by requiring registrations into the EPP extensions registry to first require registrations in the XML registry. This will prevent the IETF namespace squatting, collisions, and it is good for interoperability. JG - There is no concept of "IETF namespace squatting" with the implementation of a working group extension that is either an active draft or an abandoned draft. Only proprietary extensions and RFC extensions should be registered in the EPP extension registry. We need to encourage the implementation of draft extensions and not penalize registries that do by requiring them to register an IETF draft in the EPP extension registry. To allow I-Ds, the EPP extensions registry could be modified to allow "provisional" or "early" registrations that sidestep the XML namespace registration requirements. This is done in many IANA protocol registries setup by the IETF, and IANA knows how to periodically check on provisional and early registrations. JG - This is an unnecessary step to fulfil the undefined goal in RST 2.0 and the Next Round Registry Agreement. Finally, the question was asked about I-Ds that are abandoned or rejected by the IETF. Those can be registered as proprietary extensions by their respective authors simply by changing the namespace URIs to something the authors control. From a running code perspective, this is no different than having had the namespace id revised during the working group deliberations because though some EPP namespace ids appear to have semantic meaning, to XML they are all opaque. JG - The changing of the namespace is a highly impactful change for the registries and registrars and will result in the fragmentation of the EPP industry. The registries would need to transition the registrars to the new proprietary extension with a range of techniques and notification periods. How many proprietary versions of the IDN map extension draft does the industry need registered in the EPP extension registry? This causes an issue and doesn't solve an issue. We want to encourage the consolidation and the standardization of EPP extensions and not creating a set of duplicate proprietary extensions that can be registered in the EPP extension registry. The easy button for the process hurdles being added and the risk of implementing IETF drafts will be creating proprietary extensions from the start, which would be an unfortunate side effect for the industry and REGEXT. -andy _______________________________________________ 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]
