Il 18/06/2026 14:12, Andy Newton ha scritto:
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).
[ML3] The example aimed to demonstrate that, in case of breaking
changes, the approach that could be adopted by servers dealing with
clients that don't support the versioning extension is similar to that
adopted with opaque versioning.
However, rather than duplicating all the extension features, only the
feature affected by the change is duplicated. Therefore, even in
non-breaking changes, point versioning can limit the scope of change
more than opaque versioning. Transition between the old and new version
must be managed in both cases.
In case of non-breaking changes, which are expected to be the most,
point versioning doesn't require features duplication and transition,
unlike opaque versioning.
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:
[ML3] I'm not claiming anything. Difensive parsing is an option that
clients can adopt regardless of the versioning scheme used but it's not
mandatory. As I wrote, "the cleanest non-breaking point versioning
approach would be mostly a server-side compatibility policy" which
works for both versioning and non-versioning clients and doesn't require
specific parsing capabilities.
Furthermore, I remind everyone that some form of difensive parsing is
already required by jCard handling since some values can appear
sometimes as strings while some other as arrays of strings; see section
3.3.1.3 of RFC7095
Therefore, parsers of jCard data SHOULD check
even known property values for structured information by considering
the JSON data type of the value, which can be an array or a primitive
value.
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
--
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]
