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]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
*From: *Pawel Kowalik<[email protected]>
*Date: *Tuesday, June 9, 2026 at 7:58 AM
*To: *James Gould<[email protected]>,"[email protected]" <[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]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[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>
*From: *Pawel Kowalik<[email protected]>
<mailto:[email protected]>
*Date: *Tuesday, June 9, 2026 at 2:42 AM
*To: *"[email protected]" <mailto:[email protected]> <[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]>
To unsubscribe send an email [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://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 [email protected] <mailto:[email protected]>
To unsubscribe send an email [email protected]
<mailto:[email protected]>
_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [email protected]
