On 6/18/26 4:33 AM, Mario Loffredo wrote:
> [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",
Thanks for the examples.
>
> 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.
But how? Everything you just described above doesn't require point versioning.
It's just basic RDAP (unless I misread the examples).
>>>>> 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.
Ok. So your claim is that clients must implement dynamic behavior and must be
very sophisticated in how they parse data, and they must have a lot of
conditional logic to do the parsing. As a client implementer, I find this to be
a horrible imposition. I already have a lot of logic just to deal with
misbehaving servers, adding this type of thing makes the code extremely
complex. This also violates RFC 7480:
In designing these common usage patterns, this document introduces
considerations for a simple use of HTTP. Where complexity may
reside, it is the goal of this document to place it upon the server
and to keep the client as simple as possible. A client
implementation should be possible using common operating system
scripting tools (e.g., bash and wget).
-andy
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
