Hi Andy,
again my comments embedded below.
Il 29/06/2026 17:50, Andy Newton ha scritto:
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.
[ML] Can you please explain why the versioning draft is going beyond the
scope of versioning ?
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.
[ML] Good. But what would be the suggested mechanism for signaling a
non-breaking change ?
Per Section 5.4.5, the versioning extension is mentioned as an example
of a mechanism that allows clients to recognize a non-breaking change.
Correct?
Additional suggested change:
Section 5.4.1
OLD
Removing a required protocol element from a response;
NEW
Removing a required protocol element from a response that has not yet been
fully deprecated;
Best,
Mario
-andy
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [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]
