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]
--
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]
