Hi Pawel,
again comments below.
Il 21/06/2026 08:20, Pawel Kowalik ha scritto:
Hi Mario,
On 20.06.26 08:02, Mario Loffredo wrote:
Il 19/06/2026 18:54, Pawel Kowalik ha scritto:
Hi Mario,
On 19.06.26 18:47, Mario Loffredo wrote:
[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).
Deprecation of risk_ext.score without change of extension identifier
is a complex decision, as in fact it would be breaking for unaware
client so in fact would again require a change of extension identifier.
Why would it break clients ?
What would be the difference between deprecating risk_ext1 in favor
of risK_ext2 and deprecating risk_ext.score by adding
risk_ext.normalizedScore and then managing the transition from
risk_ext.score to risk_ext.normalizedScore ?
The clients seeing risk_ext1 in the RDAP conformance shall be able to
interoperate with the server announcing it, with the specification
versions the client happened to implement at a time.
So as long as risk_ext1 is there, the risk_ext.score shall be there.
If risk_ext.score is gone, also risk_ext1 shall be gone, otherwise the
clients would see risk_ext1 and either try to read an non-existing
property (if it was obligatory) or maybe misinterpret the result (if
for example missing optional risk_ext.score had a meaning).
If the client does not see risk_ext1, it would certainly have code
paths for handling no extension support reliably.
Checking the rdapConformance values does not minimize the likelihood
of causing problems for clients unless they implement a defensive
parser, which Andy considers very complex.
The rdap-extensions draft describes a transition period approach where
both the old and new version of an extension are served simultaneously.
However, after the old version is removed and only the new payload
remains, the clients only knowing the old version break — so the
statement that it is safe to remove is false.
A big limitation is that RDAP extension identifiers are opaque, and, as
also pointed out in Section 5.4 of rdap-extensions, overlapping
successors are indistinguishable from one extension referencing another
extension. This means a client cannot programmatically determine
whether risk_ext2 is a breaking successor to risk_ext1 or a completely
unrelated extension — it must consult the specification. That way,
clients relying on the previous version of the extension will continue
to function as intended, while clients wanting to make use of the newer
version of the extension can check for the new identifier in the response.
Best,
Mario
Kind Regards,
Pawel
--
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]
