Session Date/Time: 08 May 2025 17:00

REGEXT

Summary

This interim meeting of the REGEXT Working Group focused on a detailed discussion of draft-ietf-regext-ardap-extensions-06. The primary goal was to clarify how ARDAP extensions are specified, addressing underspecified areas in RFC 7480 and strengthening IANA, privacy, and security considerations. Key discussions revolved around the use of normative language (must vs. should), the handling of HTTP/HTTPS requirements, the role of Designated Experts (DEs), and the concept of extension deprecation and bare extension identifiers. The meeting included several polls to gauge the sense of those present on contentious topics.

Key Discussion Points

Note Well: The meeting began with the standard IETF Note Well reminder, covering IETF best current practices and the IETF Code of Conduct.
Introduction to draft-ietf-regext-ardap-extensions:
- The draft aims to clarify extension specification, address underspecified areas in RFC 7480 (STD 95), and strengthen IANA, privacy, and security considerations for ARDAP extensions.
- It does not intend to change anything in core ARDAP, its data models, ARDAP queries, or existing extensions. Its "updates" tag is due to IANA registry specifications and extension guidance being in core RFCs.
Changes from Draft 05 to 06:
- should changed to must: A significant number of "should" statements were changed to "must" to simplify the draft and provide clearer guidance, especially regarding interoperability, in line with recent IESG guidance on RFC 2119 language.
- Bare Extension Identifiers: The draft no longer allows bare extension identifiers (where the identifier itself is used as the JSON element name without a prefix or suffix). This was previously a "should" in RFC 7480, and the change to "must not" aims to prevent potential interoperability and error-prone situations.
- Deprecation Field: A deprecation field was added to the ARDAP extension registry in IANA considerations, an idea previously floated on the mailing list.
- IANA Mailing List Forwarding: IANA is requested to forward ARDAP extension and JSON values registry requests to the REGEXT mailing list to encourage informal feedback and notify implementers.
Remaining shoulds and their context:
- Redirects (Sections 3.1, 4.1): Some shoulds exist for redirects that may need re-evaluation, especially concerning security considerations (e.g., OAuth).
- Case-insensitive matching of values: Clients should be liberal in what they receive to be resilient to non-compliant servers, maintaining compatibility with RFC 7480.
- JSON Values Registry Strings: Allows flexibility for values taken from other documents (e.g., policy documents) even if they don't strictly adhere to ASCII lowercase recommendations.
Usage of HTTP/HTTPS and IPv6 (Section 4.4):
- The draft currently contains language indicating extensions "must not" define requests/responses over unencrypted channels and "must" mandate HTTPS.
- Concern (Pavle): Mandating HTTPS for all extensions might be a backdoor update to RFC 7480, which requires HTTPS support but not mandated use. This could impact existing implementations.
- Clarification (Andy): The intent is to prevent an extension from requiring HTTP for its implementation, but also allow profile-like extensions to state that service is only provided over HTTPS (e.g., GTLD profile).
- Historical Context (Andy): In 2015, IESG pressed for HTTPS-only, but operational experience with load balancers led to the current RFC 7480 allowing HTTP support. This situation may have changed.
- Poll: A poll was taken on whether to ban HTTP from ARDAP generally. The sense of those present indicated strong support for banning HTTP.
- IPv6: Similar discussion arose regarding IPv6, acknowledged as a broader question.
Role of Designated Experts (DEs):
- Question (Pavle): Do DEs fully review compliance of extensions with all base ARDAP RFCs or only IANA registry rules?
- Response (Andy): DEs do look at compliance with guidelines. Current RFC 7480/908x DE instructions are minimal and spread out. This draft aims to consolidate guidance, making it easier for DEs to check alignment with "must" and "should" statements. The draft also proposes increasing the number of DEs (to 3-5) and formalizing mutual verification. IANA forwarding registrations to the mailing list also provides informal feedback to DEs.
Deprecation of Extensions:
- The addition of a deprecation field in the IANA registry was discussed.
- Concern (Pavle): This could lead to "scope creep," as deprecation is a complex topic with issues like dependencies and obsoletion, potentially making the draft an "endless story." A separate draft might be more appropriate.
- Suggestion (Antoine, Scott): Emulate the EPP registry's active/inactive status.
- Opinion (Jezdeep): Keep deprecation in this draft; it's a sign of ARDAP's maturation and not large enough to warrant a separate document.
- Poll: A poll was taken on whether to keep deprecation of extensions in this draft. The sense of those present was to keep it in.
Bare Extension Identifiers (Detailed Discussion):
- Concern (Pavle): The decision to remove bare identifiers from the draft was made without sufficient prior working group consensus, making it harder to revert. He argued that IANA registration already prevents conflicts, and forcing prefixes for simple objects makes the protocol less readable (referencing JWT, JS Contact which don't use prefixes). He believes it blocks future evolution of the core protocol, as adding non-prefixed top-level objects would then require updating the core RFC.
- Response (Andy): Simpler rules are easier to follow. The "should" in RFC 7480 was weak (related to JSON naming compatibility). If bare identifiers are allowed as a "should," clear qualifications are needed for when it's permissible to violate that "should." Without such qualifications, DEs face subjective judgment, and IETF consensus would be difficult.
- Support for Simpler Rules (Jezdeep): Complexity of qualifying "shoulds" was an issue in 05. Prefixing simplifies implementations and provides clearer specifications, akin to XML namespaces for JSON.
- Poll 1: Should any extensions be banned from using bare identifiers? (Split opinion, slightly more "yes").
- Poll 2: Should future independent (non-IETF) extensions be banned from using bare identifiers? (Split opinion, slightly more "yes").
- Discussion on "Independent" vs. "Standard Track": Concerns were raised about creating a "double standard" where IETF-sanctioned extensions might have different rules than independent ones. Andy reiterated the need for clear qualifications for any "should" that allows bare identifiers.

Decisions and Action Items

DECISION: The working group intends to keep the concept and text regarding the deprecation of ARDAP extensions within the draft-ietf-regext-ardap-extensions document. (Sense of the room from poll: 7 Yes, 1 No, 0 No Opinion).
DECISION: The working group's sense of those present indicates strong support for banning the use of HTTP for ARDAP generally. (Sense of the room from poll: 8 Yes, 1 No, 0 No Opinion).
ACTION ITEM: Andy to revise the language in section 4.4 of the draft concerning HTTP/HTTPS usage to reflect the discussions, aiming for a "must not use HTTP" for extensions and clarifying how profile-specific "only HTTPS" statements are handled, potentially moving some security aspects to the security considerations section.
ACTION ITEM: The discussion on whether to forbid bare extension identifiers, and under what conditions (if any), will continue on the REGEXT mailing list. Participants, especially Pavle, are encouraged to propose specific language for qualifications if allowing bare identifiers as a "should" is desired.
ACTION ITEM: Chairs to distribute the meeting minutes and action items to the REGEXT mailing list for review and further discussion.

Next Steps

Further discussion on the specifics of HTTP/HTTPS requirements and bare extension identifiers will occur on the REGEXT mailing list.
The draft editor will incorporate feedback and decisions into future revisions of draft-ietf-regext-ardap-extensions.
The chairs remain open to organizing additional interim meetings if specific topics require interactive discussion, provided a discussion leader and topic are proposed.