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).
"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.
"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.
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: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?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.[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.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?[ML] Clients may notice that a backwards-compatible change has occurred, as explained in Section 5.4.5 of the rdap-extensions draft.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.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.[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]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
