**Session Date/Time:** 13 Jan 2026 17:00

# [REGEXT](../wg/regext.html)

## Summary

This interim meeting focused on two key issues related to the EPP extension registry (RFC 7451-bis): the allowance and conditions for registering Internet Drafts, and the proper use of IETF namespace URIs by non-IETF (proprietary) extensions. Discussion highlighted a conflict between the current practice of some deployments relying on Internet Drafts and the IETF's established policy that drafts are not stable specifications. While there was general agreement on preventing proprietary extensions from using IETF namespaces, the question of whether to permit Internet Drafts in the registry at all, and if so, under what terms, remained unresolved.

## Key Discussion Points

*   **Purpose of the Registry (RFC 7451):** The registry's primary purpose is to manage and coordinate the development of protocol extensions, providing awareness, and registering *mature* specifications, not specific implementations. RFC 7451 was an individual submission, not a working group product.
*   **Internet Drafts as Specifications:**
    *   RFC 3688 (IETF XML registry) requires RFC specifications for IETF namespace URIs, which Internet Drafts do not meet.
    *   **Problem:** Some Internet Drafts registered in the EPP registry have been abandoned but had implementations, leading to issues with unstable references and misuse of IETF namespaces.
    *   **Arguments for allowing Internet Drafts:**
        *   Antoine initially argued that Internet Drafts could serve as "stable documentation" for proprietary extensions, especially for early implementation experience.
        *   Jim Gould noted that the existing ICANN registry agreement might create a hard requirement for registries to register extensions, including those based on Internet Drafts, to gain implementation experience before RFC publication. Not allowing this could drive development towards proprietary extensions, hindering standardization.
        *   Gavin suggested that abandoned drafts being converted into proprietary extensions could signal demand for the functionality, prompting the working group to reconsider standardization.
        *   Jasdip referenced precedents like RPKI OID and Media Type registries, which allow provisional registration for drafts with an intent to become RFCs, under expert review.
    *   **Arguments against allowing Internet Drafts:**
        *   Jim Galvin strongly asserted that the registry requires "specification," and Internet Drafts are, by definition, temporary ("work in progress") and not stable. He argued that ICANN-related issues are external and not relevant to IETF technical decisions. He stressed that it is the responsibility of businesses to adapt to IETF processes or pursue proprietary solutions if they need early deployment.
        *   Scott reiterated concerns that modifying RFC 7451 to allow drafts under a "specification required" policy would likely be rejected by the IESG, as drafts do not meet the definition of a stable specification (per RFC 8126). He also raised practical questions about who registers drafts and how multiple versions would be handled.
        *   Antoine later inclined towards not allowing Internet Drafts, aligning with the view that they are not stable documentation.
*   **Non-IETF Extensions and IETF XML Namespace/Schema URIs:**
    *   Instances occurred where non-IETF extensions were registered using IETF XML namespace or schema URIs, likely due to a lack of diligence from the Designated Expert.
    *   There was general agreement that proprietary extensions should *not* squat on IETF namespaces.
    *   The IETF XML registry allows registration of non-IETF URNs without an RFC, requiring only a valid URI and Designated Expert review.
    *   Andy suggested that the new RFC 7451-bis draft should provide clear guidance to registrants on choosing a namespace URI and avoiding collisions.
    *   The sense of those present indicated that proprietary extensions should be encouraged, or required, to register their URIs using *non-IETF namespaces* to prevent collisions and confusion.

## Decisions and Action Items

*   **Decision:** The EPP extension registry will continue to allow the registration of proprietary (non-IETF) extensions.
*   **Decision:** Proprietary extensions should be encouraged to register their URIs using non-IETF namespaces. Explicit guidance to this effect will be considered for RFC 7451-bis.
*   **Action Item:** Scott to prepare and propose text on the REGEXT mailing list summarizing the discussion points and proposing specific changes for RFC 7451-bis. This text will address:
    1.  Guidance for proprietary extensions regarding URI registration and the use of non-IETF namespaces.
    2.  The fundamental question of whether Internet Drafts are considered "stable documentation" according to the "specification required" policy for the registry, and thus if their registration should be allowed at all.

## Next Steps

*   The discussion on the allowance and conditions for registering Internet Drafts will continue on the REGEXT mailing list based on Scott's proposed text.
*   Depending on the mailing list discussion and potential for consensus, further discussions will be scheduled, possibly as another interim meeting or at the upcoming IETF meeting in Shenzhen.
*   Scott will discuss with the chairs (Jorge and Jim) and Antoine the possibility of adding another editor to the RFC 7451-bis draft in light of his upcoming retirement, to ensure continuity.