Hi Pawel,
please find my comments embedded below prefixed with [ML].
Il 18/06/2026 19:44, Pawel Kowalik ha scritto:
Hi Mario,
Picking some of your examples with my comment:
"risk_ext": {
"score": {
"value": 0.72,
"scale": "0-1"
},
"level": "medium"
}
PK> This one, as being breaking within realm of risk_ext extension
shall require risk_ext to change to new extension identifier
(e.g. risk_ext2). This is what 5.4.1 of
draft-ietf-regext-rdap-extensions tells.
Keeping risk_ext shall be only allowed if risk_ext implements own
signalling of version changes which would make the change non-breaking
in this context. draft-ietf-regext-rdap-versioning is describing such
solution.
This is a possibility, however I don't think we should encourage such
solutions or assume them default, which would in end effect make
implementation more complex (e.g. simple curl | jq script won't work
anymore).
[ML] I agree with you that versioning shouldn't be taken for granted and
that even versioning-aware servers should implement a failsafe approach
to prevent non-versioning clients from breaking. See my comments below.
"risk_ext": {
"score": 72,
"level": "medium",
"normalizedScore": {
"value": 0.72,
"scale": "0-1"
}
}
PK> this is a non-breaking change which shall be allowed to keep
extension identifier unchanged. This is where 5.4.2. applies.
[ML] Correct. Specifically, this is an example of how, when possible, a
backwards-incompatible change can be transformed into a
backward-compatible change. Furthermore, this strategy limits the scope
of the change to the affected feature of the extension only.
The versioning extension provides clients with a mechanism for signaling
a backward-compatible change, such as those required by Section 5.4.5 of
rdap-extensions.
However, as I've already noted, rdap-x-media-type does not allow
identifiers containing the version information to be included in the
exts_list parameter.
"risk_ext": {
"score": 72,
"level": "medium"
},
"risk_ext2": {
"score": {
"value": 0.72,
"scale": "0-1"
},
"level": "medium"
}
PK> and this is a possible migration model if new extension identifier
is introduced. As per 5.4.3.
[ML] This is an example of how the given backward-incompatible change
can be handled by changing the extension identifier, thus maximizing the
scope of the change.
In both cases, a transition must be managed to deprecate an extension
feature. However, in the first example, the transition aims to deprecate
risk_ext.score; in the second example, the transition aims to deprecate
the entire risk_ext member (and any other extension features).
Best,
Mario
Kind Regards,
Pawel
On 18.06.26 10:33, Mario Loffredo wrote:
Hi Andy,
sorry for the late reply.
Please find my comments embedded below prefixed with [ML2].
Il 10/06/2026 18:34, Andy Newton ha scritto:
Hi Mario,
On 6/10/26 10:14 AM, Mario Loffredo wrote:
No clients do this today. But this confirms my earlier assertion
that what is being attempted with the versioning draft is not
backwards compatible with everything deployed today.
[ML] I'm sorry, but I don't understand why you think the versioning
extension is backwards-incompatible.
Likewise, I don't understand why you and James are not comprehending
the points that I and others have made in this thread. But
miscommunication happens with complex topics. That is why I asked
that the version draft include some query/response examples of how a
client is suppose to handle backwards incompatibility.... both for a
client that supports this versioning extension and one that does
not. James seems more interested in discussing the conceptual
definition of a breaking change, but since you are also one of the
authors would it be possible for you to provide those examples to
help clarify this discussion?
[ML2] I think we can agree that a breaking change is challenging
whatever will be the versioning scheme, opaque, point or other.
So every change should be made additive whenever possible.
Hope to make myself clear with an example.
Assume to have an extension called risk_ext like:
"risk_ext": {
"score": 72,
"level": "medium"
}
risk_ext.score is an integer from 0 to 100.
Not let's suppose to turn risk_ext.score into an object. This is
intentionally incompatible with the original version.
A first point versioning approach to risk_ext v2 implmenetation
assuming that a non-versioning client parses the response extension
defensively could be:
"risk_ext": {
"score": {
"value": 0.72,
"scale": "0-1"
},
"level": "medium"
}
but the cleanest non-breaking point versioning approach would be
mostly a server-side compatibility policy like:
"risk_ext": {
"score": 72,
"level": "medium",
"normalizedScore": {
"value": 0.72,
"scale": "0-1"
}
}
This would work regardless of whether clients supported the
versioning extension and seeems to me to be perfectly equivalent to
opaque versioning approaches such as:
"risk_ext": {
"score": 72,
"level": "medium"
},
"risk_ext2": {
"score": {
"value": 0.72,
"scale": "0-1"
},
"level": "medium"
}
or
"risk_ext_score": 72,
"risk_ext_level": "medium",
"risk_ext2_score": {
"value": 0.72,
"scale": "0-1"
},
"risk_ext2_level": "medium",
On the other hand, point versioning would work much better than
opaque versioning in handling non-breaking changes (no data
duplication, no transition to manage) which are supposed to be the
most frequent.
If a server implements the versioning specification, a client can
not only check which extensions, but also which versions of those
extensions are implemented by the server.
And what will the client do with that information? I have asked
this question multiple times and have yet to get an answer.
[ML] Clients may notice that a backwards-compatible change has
occurred, as explained in Section 5.4.5 of the rdap-extensions draft.
They can also clearly determine the relationship between two
versions of an extension that differ by a backwards-incompatible
change, as explained in Section 5.4.
Nothing in Section 5.4.x says a client dynamically changes behavior
upon receiving versioning information. When you say "They can also
clearly determine the relationship between two versions of an
extension", then what? What is client software suppose to do with
that information?
[ML2] The versioning_help member provides the full list of supported
extensions and their available versions, enabling self-configuring.
The versioning_data member tells the client exactly which version of
each extension was used to produce the response, enabling conditional
parsing and fallback handling.
During transitions between extension versions, clients can operate
with multiple versions in parallel, automatically detect when a
server has completed its migration, and plan their own upgrades
without service interruption.
Hope I answered your questions.
Best,
Mario
-andy
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
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]
