Hi Mario, Thanks for this feedback. It is very helpful.
On 24-06-2026 9:00 AM, Mario Loffredo wrote:
Hi Andy, below is some feedback on version -13 of the rdap-extensions draft: 1) The definition of "breaking changes in successors" in Section 5.4.1 uses ambiguous wording: it refers to successor/predecessor extensions "identified by the same extension identifier", but then says that a breaking successor is indistinguishable from a new unrelated extension.
I agree the usage of successor/predecessor language is not ideal. We used it in an attempt to avoid confusion with the terminology in the versioning draft. Maybe we should revisit this and differentiate between a new version of an extension using the same extension identifier and a new version using a different extension identifier.
Suggested change: OLD A breaking change (also known as a backwards-incompatible change) occurs when a modification in a successor extension with respect to the predecessor extension, where each is identified by the same extension identifier (see Section 2.2), causes clients conforming to the predecessor extension to malfunction, experience degradation of functionality, or fail to interoperate in some other manner. NEW A breaking change (also known as a backwards-incompatible change) may occur either: 1. by changing the contract associated with an existing extension identifier; or 2. by defining a successor extension with a different extension identifier. In the latter case, the successor relationship is not machine-readable unless specified by the extension documentation or by a versioning mechanism. A breaking change causes clients conforming to the predecessor extension to malfunction, experience degradation of functionality, or fail to interoperate in some other manner.
Item 2 is about Section 5.4.3, not 5.4.1. But I can see the confusion given the terminology overlaps... that is we use "successor" both when discussing new versions of an extension using the same ID and successors that use a new extension ID. We need to differentiate between a successor that uses the same ID as the predecessor vs a successor that uses a different ID as the predecessor. Maybe "revision" vs. "replacement".
2) In Section 5.4.1, rdap-x-media-type is cited as an example of signaling for choosing an "old or new version", but the exts_list parameter signals extension identifiers, not versions. Suggested change: OLD Whether some sort of client signaling should be supported, so that clients can opt for the old or new version of the extension in responses that they receive (see [I-D.ietf-regext-rdap-x-media-type] for an example of how this might work) NEW Whether some sort of client signaling should be supported, so that clients can opt for the old or new version of the extension in responses that they receive (see [I-D.ietf-regext-rdap-x-media-type] for signaling support for distinct extension identifiers, and [I-D.ietf-regext-rdap-versioning] for signaling specific versions of an extension)
This highlights the issue that the versioning draft is going beyond the scope of versioning and doing client signaling.
In parallel, Section 2 of the rdap-x-media-type should be updated as follows: OLD The RDAP media type, "application/rdap+json", may have an optional parameter named "exts_list". This parameter is a whitespace-separated list of RDAP extension identifiers (as would be found in the "rdapConformance" array). NEW The RDAP media type, "application/rdap+json", may have an optional parameter named "exts_list". The "exts_list" parameter is a whitespace-separated list of RDAP conformance identifiers and/or RDAP extension version identifiers. An RDAP conformance identifier is a value that can appear in the "rdapConformance" array, including base RDAP conformance identifiers such as "rdap_level_0" and RDAP extension identifiers. An RDAP extension version identifier is an identifier that adds the version information to an RDAP extension identifier, such as the one defined by [I-D.ietf-regext-rdap-versioning].
Using the proposal put forward by Pawel, there is no need to express a version identifier: https://mailarchive.ietf.org/arch/msg/regext/sN-ar484f9n5YgXkTauq7CE6xMk/
This update would also fix the inconsistency where rdap-x-media-type claims that exts_list is a list of "RDAP extension identifiers", but its examples and text include rdap_level_0, which is not an extension identifier.
Thanks. The presence of the rdap_level_0 identifier needs to be stated.
3) In Section 5.4.5, the draft says that clients ignore "JSON names and query parameters"; however, query parameters are request-side elements, and it is normally the server that ignores unknown query parameters. Suggested change: OLD Because RDAP clients ignore unrecognized JSON names and query parameters... NEW Because RDAP clients ignore unrecognized JSON names, and RDAP servers ignore unrecognized query parameters...
Agreed.
4) Section 5.4.2 lists the following as non-breaking: - new referrals; - new JSON members; - new URL paths; - new query parameters. This is generally correct, but for query parameters it would be useful to specify that they are non-breaking only if they are optional and if servers continue to operate correctly when those parameters are absent. Suggested clarification: New optional query parameters are non-breaking. Requiring clients to send a new query parameter for behavior previously available without it is a breaking change.
Agreed, though I think it is safe to say "new optional query parameters".
5) In section 7.1.1, the draft says that the new "Deprecation Date" field should use the format specified by RFC 3339, but then asks for the deprecation date of both icann_rdap_response_profile_0 and icann_rdap_technical_implementation_guide_0 to be registered as: 20250821 20250821 doesn't seem to be canonical RFC 3339 format (see the ABNF rule: full-date = date-fullyear "-" date-month "-" date-mday) An RFC 3339 date should be: 2025-08-21 or, if a date-time is needed: 2025-08-21T00:00:00Z Suggested change: Replace 20250821 with 2025-08-21, if the field is intended to be a full-date
Good catch.
6) This is a general consideration. The draft treats the breaking changes as if they always require extension-wide management, whereas in REST/API practice many breaking changes can be reframed as additive, localized changes, according to the "Expand and Contract" pattern. Many changes listed as breaking in Section 5.4.1 can often be recast as non-breaking additive changes of the kind listed in Section 5.4.2. For example, instead of changing the type or semantics of an existing JSON member, an extension can keep the existing member unchanged and add a new member in the same namespace. Old clients continue to use the old member and ignore the new one; new clients can migrate to the new member; the old member can later be deprecated and eventually removed. This pattern limits the scope of the migration to the affected feature or protocol element, rather than requiring a successor extension for the entire extension. It is also consistent with common REST API evolution practice. In other words, breaking changes should first be "reduced" to non-breaking changes whenever possible; only non-reducible breaking changes should require a successor extension.
We can certainly give the advice explicitly to attempt non-breaking changes before resorting to breaking changes. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
