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.
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.
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)
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].
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.
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...
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.
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
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.
Best,
Mario
Il 18/06/2026 14:44, Andy Newton ha scritto:
Hi Mario and James,
Any constructive and concrete discussion of the draft text is welcome. When
doing so, please clearly quote the draft text and suggested changes. Using OLD
and NEW text blocks is a common way for doing this in the IETF. You may also
use the IDNITS tool to grab line numbers, which is very helpful. Alternatively,
you can submit a PR in GitHub.
That said, the issue you note below is NOT in the extensions draft.
Finally, it very unfair to the author team and the working group for you to
hold up this document based on your versioning draft. Since adoption, the
versioning draft has radically changed, moving from semantic versioning to
maturity versioning to point versioning and now a new theory called embedded
versioning. It is a meandering, moving target with a lot of complexity. So that
this does not spiral further, it would be best if the chairs stepped in now.
-andy
On 6/18/26 5:07 AM, Mario Loffredo wrote:
Il 17/06/2026 19:22, Gould, James ha scritto:
Andy,
I'll do a fresh review of draft-ietf-regext-rdap-extensions-13 and provide
feedback. I don't believe draft-ietf-regext-rdap-extensions is ready for WGLC
until the versioning topic is fully addressed.
Thanks,
+1
I believe complete convergence between rdap-extensions,
rdap-x-media-type, and rdap-versioning is desirable.
I'd like to point out the inconsistency that seems most glaring to me.
Section 5.4 of rdap-extensions considers the case where an extension
might use a versioning method like that described by rdap-versioning.
But section 2 of rdap-x-media-type requires that the ext_list parameter
can only include extension identifiers.
This not only seems to me a clear inconsistence between the two
documents but eliminates the possibility that the versioning parameter
could be removed in order to make clients use only exts_list to signal
the desired extensions.
Best,
Mario
_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [email protected]
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
