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.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.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).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.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
