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

[Mario Loffredo <[e-mail]>]

Hi Andy,

most (perhaps all) of the extensions proposed so far aim to fix a flaw 
in RDAP, as defined by the STD95 standard. Therefore, I believe all 
clients and servers should implement these extensions to make RDAP more 
efficient and interoperable.

Don't you think the signaling mechanism described in rdap-x-media-type 
should be implemented by all clients and servers?

IMO the question is whether we truly believe an extension is useful or not.

Regarding versioning as defined in rdap-versioning, I believe sending a 
/help query is currently the method used by clients to discover which 
RDAP features servers implement.

Since these features might change over time, I expect clients to 
regularly (not before each request, but periodically) send a /help query 
to synchronize their implementations with those of the servers.

If a server implements the versioning specification, a client can not 
only check which extensions, but also which versions of those extensions 
are implemented by the server.


Best,

Mario


Il 09/06/2026 15:53, Andy Newton ha scritto:
> 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*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 7:58 AM
>> *To: *James Gould<[e-mail]>,"[e-mail]" <[e-mail]>
>> *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*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://secure-web.cisco.com/1-ArvJYo5ItPb617dbqm1rQRUNw3VimCCoZfdQLvuVk8hxFruFojEZlL7avAKnLmeMJ0NudIvMMqAqwcEvyB7nVlYerZ3Jd1rxh_7zVfq_P5qJlrk4geIAGfGSBmXYCo5LLHucTCACLLjimizmQ3ZqshYGnsHGJA-FDa5Kdmfw3RfCVZ5Zs7Uxt8uPHTReGdiI9Rd_K1ArdXDmEHpGnEy6GyDf8RdUrmvzO85cDKtNEzPt877oJnJOuQXxZZgrI3OAogjXrzibdrUzXGKq-nJYxZzy-VgZncGKsV-a0EEQmE/http%3A%2F%2Fverisigninc.com%2F>
>>
>>       
>>
>>      *From: *Pawel Kowalik<kowalik=[e-mail]> <mailto:kowalik=[e-mail]>
>>      *Date: *Tuesday, June 9, 2026 at 2:42 AM
>>      *To: *"[e-mail]" <mailto:[e-mail]> <[e-mail]> <mailto:[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:
>>
>>           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 [e-mail] <mailto:[e-mail]>
>>              To unsubscribe send an email [e-mail] <mailto:[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] <mailto:[e-mail]>
>>
>>          To unsubscribe send an email [e-mail] <mailto:[e-mail]>
>>
>>
>> _______________________________________________
>> regext mailing list [e-mail]
>> To unsubscribe send an email [e-mail]
> _______________________________________________
> regext mailing list [e-mail]
> To unsubscribe send an email [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