Andy, It's not a requirement for the client to use the /help to get additional versioning data, but a feature that a client can opt to use. The extension identifier is not a good versioning signal and leveraging the extensibility of RDAP to provide that versioning information is an option and not a mandate for interoperability. We could add additional opaque versioning information to the /help, such as opaque version relationships, to further help with those extensions that choose to use opaque versioning instead of point versioning. Do you see a benefit in working on this? This meta-data is not required but helpful to client implementations and for troubleshooting.
Thanks, -- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/9/26, 9:53 AM, "Andy Newton" <[email protected] <mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Pawel's correct. What you are advocating is that every client issue /help before issuing queries for data and that every client and server now has to support your versioning draft. That is not backwards compatible with everything deployed today, and it puts extra load on servers. -andy, no hats On 6/9/26 8:30 AM, Gould, James wrote: > Pawel, > > > > The client can easily leverage the extension of the help command to obtain > the versioning information. Again, if the client is interested in versioning > and breaking/non-breaking information then they can leverage the extension. I > don’t see how the extension identifier mitigates the breaking change impact, > since the proposal is to change the extension identifier that will certainly > break the client looking for the JSON members using the prior extension > identifier prefix. Additionally, changing the extension identifier will > impact the query elements (path segment and query parameters). As Mario > pointed out, changing the extension identifier causes maximum breakage, so > it’s a very poor versioning signal for interoperability. The > draft-ietf-regext-rdap-versioning extension supports the opaque versioning > that can only use the extension identifier as a versioning signal, but I > believe the point versioning type in draft-ietf-regext-rdap-versioning > provides for a much better > versioning signal. > > > > The extension identifier is best suited as a namespace without attempting to > embed versioning information, since it’s too coarse grained and doesn’t > provide any standard versioning information. > > > > Thanks, > > > > -- > > > > JG > > > cid87442*[email protected] > > *James Gould > *Fellow Engineer > [email protected] <mailto:[email protected]> > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected] > <mailto:[email protected]>> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > <http://secure-web.cisco.com/1Tm2Obkv0IEX7nJ37mkolY0BYBOZLiz3vyepVJAbHsIoY1W2DJLiJdOAWcRw1_R6UPgxmlNQsGFJWc9Wd6AwEpY_0ZwvLBaRXQKKHYYz4Crp_YEaZQw9WbdcoTYDOvOgU3fFQ09HozlpsVakr3D0SZWrGNl26oBnboEfytXxA7QNkqSkzIB_6_9qjNfAct3TGp4Mh-s60HsCActzkTYgUReOCSRSCZohzF5QH_mTevuZXOxIJ854rVsjzWlX60tCWJ2bsix1lIiOfLkg6NWlnKUXCY-Sb0rREgqXaF8k2JRU/http%3A%2F%2Fverisigninc.com%2F> > > <http://secure-web.cisco.com/1Tm2Obkv0IEX7nJ37mkolY0BYBOZLiz3vyepVJAbHsIoY1W2DJLiJdOAWcRw1_R6UPgxmlNQsGFJWc9Wd6AwEpY_0ZwvLBaRXQKKHYYz4Crp_YEaZQw9WbdcoTYDOvOgU3fFQ09HozlpsVakr3D0SZWrGNl26oBnboEfytXxA7QNkqSkzIB_6_9qjNfAct3TGp4Mh-s60HsCActzkTYgUReOCSRSCZohzF5QH_mTevuZXOxIJ854rVsjzWlX60tCWJ2bsix1lIiOfLkg6NWlnKUXCY-Sb0rREgqXaF8k2JRU/http%3A%2F%2Fverisigninc.com%2F>> > > > > *From: *Pawel Kowalik <[email protected] > <mailto:[email protected]>> > *Date: *Tuesday, June 9, 2026 at 7:58 AM > *To: *James Gould <[email protected] <mailto:[email protected]>>, > "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > *Subject: *[EXTERNAL] Re: [regext] Re: draft-ietf-regext-rdap-x-media-type > and draft-ietf-regext-rdap-versioning Compatibility Topic 1: Query Identifiers > > > > 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*[email protected] > > *James Gould > *Fellow Engineer > [email protected] <mailto:[email protected]> > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected] > <mailto:[email protected]>> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > <http://secure-web.cisco.com/1-ArvJYo5ItPb617dbqm1rQRUNw3VimCCoZfdQLvuVk8hxFruFojEZlL7avAKnLmeMJ0NudIvMMqAqwcEvyB7nVlYerZ3Jd1rxh_7zVfq_P5qJlrk4geIAGfGSBmXYCo5LLHucTCACLLjimizmQ3ZqshYGnsHGJA-FDa5Kdmfw3RfCVZ5Zs7Uxt8uPHTReGdiI9Rd_K1ArdXDmEHpGnEy6GyDf8RdUrmvzO85cDKtNEzPt877oJnJOuQXxZZgrI3OAogjXrzibdrUzXGKq-nJYxZzy-VgZncGKsV-a0EEQmE/http%3A%2F%2Fverisigninc.com%2F> > > <http://secure-web.cisco.com/1-ArvJYo5ItPb617dbqm1rQRUNw3VimCCoZfdQLvuVk8hxFruFojEZlL7avAKnLmeMJ0NudIvMMqAqwcEvyB7nVlYerZ3Jd1rxh_7zVfq_P5qJlrk4geIAGfGSBmXYCo5LLHucTCACLLjimizmQ3ZqshYGnsHGJA-FDa5Kdmfw3RfCVZ5Zs7Uxt8uPHTReGdiI9Rd_K1ArdXDmEHpGnEy6GyDf8RdUrmvzO85cDKtNEzPt877oJnJOuQXxZZgrI3OAogjXrzibdrUzXGKq-nJYxZzy-VgZncGKsV-a0EEQmE/http%3A%2F%2Fverisigninc.com%2F>> > > > > *From: *Pawel Kowalik <[email protected] > <mailto:[email protected]>> <mailto:[email protected] > <mailto:[email protected]>> > *Date: *Tuesday, June 9, 2026 at 2:42 AM > *To: *"[email protected] <mailto:[email protected]>" <mailto:[email protected] > <mailto:[email protected]>> <[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]>> > *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: > > 1. treat the extension identifier as the identity and namespace of the > extension, and > 2. 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] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[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://secure-web.cisco.com/1c-FnrvDRkm6dlUNcMP5El0GehtfarBALVgZLSr7r_huHqQ_sPS_5SZsDkvAdrseo6-l5N24rSC8TtdZu470Wj3d2UU8UjB4CDDhAentz51sbsdMCMje5AoYKTCztW6n4Az19CqmXRVuaSEXs_3ofjtwK6Qv-7K4z3k_DeS3F9LFSLGXLuB7zRgcbjYKj75Y1H0fRXwoW1FZRfEOPHdV0q4Hzq2e9j48M4y_y5yQRCuXwPcQ7fhUidaurHxp1EyilJvQ49bahDd63p41yHhI9Xm4--jg2G9lWmdrykA0bGGo/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo > > <http://secure-web.cisco.com/1c-FnrvDRkm6dlUNcMP5El0GehtfarBALVgZLSr7r_huHqQ_sPS_5SZsDkvAdrseo6-l5N24rSC8TtdZu470Wj3d2UU8UjB4CDDhAentz51sbsdMCMje5AoYKTCztW6n4Az19CqmXRVuaSEXs_3ofjtwK6Qv-7K4z3k_DeS3F9LFSLGXLuB7zRgcbjYKj75Y1H0fRXwoW1FZRfEOPHdV0q4Hzq2e9j48M4y_y5yQRCuXwPcQ7fhUidaurHxp1EyilJvQ49bahDd63p41yHhI9Xm4--jg2G9lWmdrykA0bGGo/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> > > <http://secure-web.cisco.com/1pGwZktmuX0P0y1JXWeDhDsipewe976AG5LgpCNxOsehafEhmHKWlHuEHwlwKpK9rwsMcqs_iQJnhmM6ymBYnRt9sjAn4SJ349ra_UqXVkZKayaaIzxKNswEpJqwnkqldSVK4HacjPNEZbeOdVDUQloYsUDFzhmUyIrsyp3cCdN5kOO6g57nAo7eLal7WGUv1jf33FU7GDUvpOcXt6MFWVpnM4kWhUMB5o5qMVFX-z5oCJy_JZbHR_AP3mfWtIm4JREQ3RciEwjSAhIwJ5F_0G1E6ghXvY-rbzau3WtO5cko/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.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 -- [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > To unsubscribe send an email to [email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > > > _______________________________________________ > regext mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
