Hi Mario,the points you rise have all merits. They only do not address the issue of clients not knowing/supporting versioning extension, which must be able to tell the difference based on extension identifier itself.
What you are proposing would require versioning to be an update to the standard (rdap_level_1 or so), not an extension - only then we would be able to build the whole framework around it.
On the flip side, such coarse-grained versioning can be actually a benefit to the ecosystem as it would encourage extension developers to keep backwards compatibility, so I would be actually in favour of keeping this bar high.
Kind Regards, Pawel On 22.04.26 16:01, Mario Loffredo wrote:
Hi Andy, please find a late comment below. Il 14/04/2026 22:04, Andy Newton ha scritto:On 14-04-2026 3:19 PM, Gould, James wrote:JG-A server supporting an RDAP extension that does use Maturity Versioning in the versioning extension should add support for the versioning extension as well. Clients can then take advantage of the versioning extension to obtain the extension versioning information and request for a specific extension version. There is a bootstrapping period, but if the client cares about extension versioning it should implement the versioning extension.There is a bootstrapping process to use the versioning extension? Is this in addition to RFC 9224 or does it take the place of RFC 9224?We first looked at defining breaking changes in the versioning draft with the Semantic Versioning, but it wound up to focus on the major version being associated with stable interface change and the minor version being associated with an unstable interface change.That's not semantic versioning. I don't know what that is, but in semantic versioning major means breaking changes and minor means backwards compatible.JG-We changed the name to Maturity Versioning to be clear that it's not semantic versioning based on our meeting at IETF-124. Do you want us to go back to signaling breaking and non-breaking changes?I'd prefer to go back to the scheme proposed by Pawel, where the major means breaking change and it is in the extension identifier (e.g. "example1" ) and, consequently the minor does not need to be signaled because it always means backwards compatible. Not only is this simpler, but it potentially allows RDAP extensions that are opaquely versioned right now ("cidr0", "ttl0", "rirSearch1", etc...) to switch to major/minor versioning later on if there is need.[ML] I’m not convinced that changing the RDAP extension identifier for every backward-incompatible change is the right general approach.While using a new identifier provides a simple and unambiguous signal to clients, it effectively turns the extension identifier into a coarse-grained versioning mechanism. This has an important side effect: it couples together all protocol surfaces of the extension — request parameters, response structure, conformance signaling, and so on — even when the incompatible change affects only one of them.For example, if an extension modifies only the response format in a backward-incompatible way, requiring a new extension identifier also forces a change in the request side (e.g., query parameters or media type usage), even though no change is technically needed there. In practice, this maximizes the impact of the change rather than minimizing it.From a protocol design perspective, this seems at odds with the general goal of enabling evolution while preserving interoperability. HTTP-based designs typically favor extensibility and mechanisms that avoid unnecessary breakage or “all-or-nothing” transitions (see RFC 9205).It may be more appropriate to: * treat the extension identifier as the identity and namespace of the extension, and * use a separate, finer-grained mechanism (e.g. version signaling) to also handle backward-incompatible changes.In that model, changing the extension identifier would be reserved for cases where the conceptual identity of the extension changes, rather than being the default response to any incompatible modification.I believe this separation would better support incremental evolution and reduce unnecessary operational and implementation impact.Best, Mario-andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]-- 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 [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
