Orie, I agree with your synopsis of the situation, where registries may implement EPP extensions in the wild that don’t fit the IETF procedures strictly or even loosely. The goal of the EPP extension registry is to publicize the implemented EPP extensions to help and not hinder consolidation and standardization of EPP extensions, since registries will see like extensions that can be implemented instead of defining a new similar extension. We can see the result of the numerous similar IDN extensions and the balance extensions in the EPP Extensibility and Extension analysis and we can see that only around 60% of the known extensions have been registered in the EPP extension registry.
Your proposal looks to match the goal of enhancing the visibility by reducing the hurdles. I added comments to your proposal points below. 1. Add the EPP namespaces that the extension uses to the registry (making collisions visible via in page search). I like exposing the EPP namespaces in the EPP extension registry. I assume that we’re not attempting to register them in the XML registry, since those will get registered naturally via the RFC process of standard extensions and we don’t want the XML registry to deal with conflicting namespaces. One corner case is that there may be multiple independent implementations of an EPP extension with different namespaces while it progressed, such as what occurred with the point version of the registry fee extension: RFC 8748: urn:ietf:params:xml:ns:epp:fee-1.0 draft-ietf-regext-epp-fees-07: draft-ietf-regext-epp-fees-07 draft-brown-epp-fees-02: urn:ietf:params:xml:ns:fee-0.5 I’m unsure if we want to capture every implemented version in the wild, but should the extension registry support identifying the draft versions and draft namespaces that are actively implemented? I don’t believe the extension versions will be accurate based on the need for reference counts and a commitment of registries to keep the versions up to date in the registry. 2. Remove the "Document Status"... this column has no meaning outside of IETF, and is misleading when applied to external (outside the IETF) specifications. Agreed, the Registrant and the Reference defines whether it’s an IESG registered RFC, which is most important. 3. Use the "notes" column to highlight any cases of collision, and ideally point to helpful guidance on mitigating the impact of collisions. Who would define the impact of collisions, the Registrant or the DEs? 4. Consider an early registration procedure for EPP. One issue that I see with provisional registrations of working group drafts is the XML namespace, where the pattern is to use point version namespaces and to update to “1.0” once the draft passes WGLC. Would be put a pattern for the XML namespaces to reflect the point versioning in a provisional registration? I do like the concept of a provisional registration to make the EPP extension registry more representative of what is being worked on. -- JG [cid87442*[email protected]] 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/> From: Orie <[email protected]> Date: Friday, November 7, 2025 at 11:49 AM To: James Gould <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: The IETF XML registry and the EPP Extensions 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, Some of https://datatracker.ietf.org/doc/html/rfc7320<https://secure-web.cisco.com/1vTYWGw8JvA-V0VEsKJEdJhRFPMYBeelJ9ssXy5cUhmN6DXoVJ_Hz-8aC8ovodjV2NkVGs-KjMgNaMw8xb1aMkjpgIUZ8yzeT4MOjKaNTrObp-_wlprfbNpmUWFbtJEqUgoQXvuBg3VP3_IBlw9yDdx1YvCyMJlqcSX2rb17w8-pLDHeeE0dmlBDfa0hvph8eLyL7oDlBL2trhahE0tOnAVWkA9bL0hkib_ZxkAUESaZEU_Dhrnb1272tPk-yhGzbqnEeyhlAxtewIyo0V8ZYoVLJUHgDA0RfylwIyB27XSU/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7320> may be relevant to this discussion. Although EPP registry is specification required, if the specification is an expired internet draft that assumed publication with IETF review, and used namespace URIs like (urn:ietf:params:xml:ns:...)... We need to balance the value of "discoverability of deployed software that cannot be changed", with "adherence to IETF procedures", specifically the requirements for registration of IETF Review required URIs in XML registry vs the benefit of documenting extensions in the wild that use URIs (correctly or incorrectly). Practically, this sort of "collision" can happen even without interaction with IETF, simply by developers following string conventions without awareness of procedures, and then shipping code that requires namespace URIs (which might never make it into XML registries) to never change. Registration with IANA as early as possible reduces the chances of these collisions, but cannot prevent it. In the context of the IANA EPP registries, the best thing for the community is to make these interoperability issues clear and visible, when they cannot be avoided. I would recommend the WG consider the following changes to the EPP registry at some point: 1. Add the EPP namespaces that the extension uses to the registry (making collisions visible via in page search). 2. Remove the "Document Status"... this column has no meaning outside of IETF, and is misleading when applied to external (outside the IETF) specifications. 3. Use the "notes" column to highlight any cases of collision, and ideally point to helpful guidance on mitigating the impact of collisions. 4. Consider an early registration procedure for EPP. Regards, OS, ART AD On Fri, Nov 7, 2025 at 10:31 AM Gould, James <[email protected]<mailto:[email protected]>> wrote: Pawel, I don’t have an issue with marking the registration accordingly, but I don’t believe it should be removed from the registry. We want the EPP extension registry to include the set of implemented EPP extensions, so keeping the implemented extensions in the registry with an appropriate status is a priority. Think about our experience discovering the set of implemented EPP extensions in the wild for the EPP Extensibility and Extension Analysis, where we analyzed 67 EPP extensions and the EPP extension registry only has 39 registrations or 58% of the extensions. It would be better if we could get that percentage to 90% or above. -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://secure-web.cisco.com/1VW7BIl-0rEI3qif7m5w-nhXJdaqGVDFCW0CWf-dMUTjwOeOOntLwqR4lp41-Dg9yGYDduxjatZbTxm09RbpjJ7h7Rstxy8adro-uC00NlDhn13GLqZF8aNqE0fWHkyxzZRc8LTTxP-rLXZaYIcdN0VrNF8Bcn8Y4JzzRkkgi4Nzwf0uJUGdk3NuhzPoapcHreRwNcMPhTqhNK79M0RdIBaqAOTOrbk3XGYmZGvpYmucxuBDNK0S96H5EkaNeM5BB9DABeWJ-KkCoGFd1NekYXCEm7CJXNGYpSyxST82lgZ0/http%3A%2F%2Fverisigninc.com%2F> From: Pawel Kowalik <[email protected]<mailto:[email protected]>> Date: Friday, November 7, 2025 at 10:18 AM To: James Gould <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] Re: [regext] Re: The IETF XML registry and the EPP Extensions Jim, Andy, I would not be against removing provisional entries from the registry, in a way. I would even go further, that a provisional entry should have a deadline, which could be prolonged, but with clear indication when an entry will drop or be marked as "abandoned" / "discontinued" from the registry. Releasing a name can have imho possible interoperability consequences, so I would not do that to remove the registration entirely. Talking of external consequences, let me say: let's not make someone else's problem to our problem. As soon as the registry would tell clearly "abandoned" / "discontinued", the consumers of this registry may decide on their own policies and rules what to do about it. On our own playfield, having a clear and transparent view on what is the process behind, REGEXT may find a different motivation not to let such situation to happen. Kind Regards, Pawel On 07.11.25 09:40, Gould, James wrote: Andy, I believe the provisional registration could work as long it doesn't get removed if the draft becomes abandoned, where that would meet the goal of publicizing the existence of an EPP extension in the EPP extension registry. In the EPP Extensibility and Extension Analysis it would great when we the extensions were in the EPP extension registry. I don't like using a non-IETF namespace for the IETF drafts, where starting with the registry fee extension we started using point version IETF namespaces for the EPP extension drafts that changed to "1.0" after WGLC. That has worked very well to support development and deployment during the progression of the IETF draft with the needed level of isolation. We implemented and deployed two point versions of the registry fee extension prior to transitioning to the final "1.0" version in the RFC, which helped to improve the draft. I would stay away from attempting to register the XML namespace in the XML registry for drafts, since they aren't final. Thanks, -- JG James Gould Fellow Engineer [email protected]<mailto:[email protected]> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]><mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/><http://secure-web.cisco.com/1BxrWEEAqJouGZgxo-FbpvOHXtwZ7H3St9p4cFv5_LAdzy9wsn0hKeD25qyuR7uHAXOG72SonkCh8LJuISd6lpHoPwlnYyY1f9YakuL3SlJkTvhGdJm3Omd-hj7uVxaHPzA9TQvFPmLGrkNy967F0zmWasJ4ZOkKRuDuJhVBEsRW4DjYra0c92Mj9LAoQSRu1Z-EPpqFpDXEn_qBWc_inDWFNwQGZ2pwKBrOxhc-2GQoBarkbS1tW78r1yAzfu0ccCJcKsDQccagfibBHRhpjzFUEfP9_xv7usp439WBb1Rs/http%3A%2F%2Fverisigninc.com%2F> On 11/7/25, 9:20 AM, "Andrew Newton (andy)" <[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. On Thu, Nov 6, 2025 at 8:38 PM Gould, James <[email protected]<mailto:[email protected]> <mailto:[email protected]><mailto:[email protected]>> wrote: 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. Setting aside this incorrect assertion, if you don't like the "provisional" registrations then another solution is to use a URI like "file:///dev/null" in I-Ds and have IANA assign the URN at publication time according to the provisions of RFC 3688 via a note in the IANA considerations section to both IANA and the RFC editor (for changing examples). This means I-Ds would not be registered until publication. -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]<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]
