[regext] Re: draft-ietf-regext-rdap-x-media-type and draft-ietf-regext-rdap-versioning Compatibility Topic 1: Query Identifiers

[Pawel Kowalik <[e-mail]>]

Hi Jim,

this is not my point.

If versioning draft remains an extension, than the breaking/non-breaking 
change problem has to be solved without taking this extension into 
account. This has a consequence of extension identifier as the only 
capability to signal breaking changes.

Kind regards,
Pawel

On 09.06.26 13:42, Gould, James wrote:
>
> Pawel,
>
> The versioning extension came out of the lack of explicit versioning 
> being defined in the base RFCs. There have been many debates about 
> what kind of versioning information to embed in the extension 
> identifier, which has resulted in large inconsistency in the RDAP 
> extension registry.  The result was adopting 
> draft-ietf-regext-rdap-versioning to provide the versioning signaling 
> and capability needed in the protocol.  Adding a basic capability to 
> RDAP, like versioning, doesn’t require updating the standards, since 
> RDAP is extensible and draft-ietf-regext-rdap-versioning already 
> provides a proposal of how to do it.  Clients can support 
> draft-ietf-regext-rdap-versioning if versioning is important to them, 
> where there is no bootstrapping issue.  The compatibility issues 
> between draft-ietf-regext-rdap-versioning and 
> draft-ietf-regext-rdap-x-media-type can be easily addressed if there 
> is a desire to do so.  How to fix the incompatibilities have been 
> communicated on the mailing list (e.g., support the Extension Version 
> Identifier in the “exts_lists” parameter and remove Appendix B.2), so 
> the question is whether draft-ietf-regext-rdap-x-media-type will 
> address the incompatibilities.  I propose that 
> draft-ietf-regext-rdap-versioning and 
> draft-ietf-regext-rdap-x-media-type be merged, since 
> draft-ietf-regext-rdap-versioning is a superset of 
> draft-ietf-regext-rdap-x-media-type and merging them will ensure 
> compatibility.
>
> Thanks,
>
>  --
>
> JG
>
>
> cid87442*image001.png@01D960C5.C631DA40
>
> *James Gould
> *Fellow Engineer
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *Pawel Kowalik <kowalik=[e-mail]>
> *Date: *Tuesday, June 9, 2026 at 2:42 AM
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *[EXTERNAL] [regext] Re: draft-ietf-regext-rdap-x-media-type 
> and draft-ietf-regext-rdap-versioning Compatibility Topic 1: Query 
> Identifiers
>
> 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 -- [e-mail]
>         To unsubscribe send an email to [e-mail]
>
>     -- 
>
>     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: [phone]
>
>     Web:http://www.iit.cnr.it/mario.loffredo <http://secure-web.cisco.com/1pGwZktmuX0P0y1JXWeDhDsipewe976AG5LgpCNxOsehafEhmHKWlHuEHwlwKpK9rwsMcqs_iQJnhmM6ymBYnRt9sjAn4SJ349ra_UqXVkZKayaaIzxKNswEpJqwnkqldSVK4HacjPNEZbeOdVDUQloYsUDFzhmUyIrsyp3cCdN5kOO6g57nAo7eLal7WGUv1jf33FU7GDUvpOcXt6MFWVpnM4kWhUMB5o5qMVFX-z5oCJy_JZbHR_AP3mfWtIm4JREQ3RciEwjSAhIwJ5F_0G1E6ghXvY-rbzau3WtO5cko/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
>
>
>
>     _______________________________________________
>
>     regext mailing list [e-mail]
>
>     To unsubscribe send an email [e-mail]
>