Pawel, We may get to agreeing to disagree on this. RDAP is extensible, since there was no way that the working group could envision everything from the start. The extension identifier alone was agreed to not carry explicit versioning information years ago, which is what drove the work to address it in draft-ietf-regext-rdap-versioning. Now you’re arguing that an extension, such as draft-ietf-regext-rdap-versioning , that provides versioning information and that supports passing the versioning information is mandatory and needs to be baked into the core RDAP RFCs. There is nothing forcing a client to implement the versioning extension other than wanting to receive real versioning information to help in interoperability. At a minimum the versioning extension will help in troubleshooting interoperability issues that may arise for clients that have a dependency to a version of an extension and choose not to implement the versioning extension.
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 10:19 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, On 09.06.26 14:30, Gould, James wrote: 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. [PK] This is exactly what the client should not be forced to do. An extension identifier shall carry enough information to tell the client if it is able to parse the response. A breaking change shall make such clients aware of incompatible response they cannot or should not try to parse and this is where extension identifier is the right tool in the core protocol. Versioning or any other extension, if not in the core protocol, is not sufficient to deal with clients who do not know them. 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. [PK] Yes, if the change is breaking than it is breaking all the way down. Otherwise the extension authors shall keep the back compatibility and keep the extension identifier intact. 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. [PK] Sure it is, but still as extension cannot solve the problem for the clients who do not support it. It is unacceptable for the client to break on a response it considers valid based on extension identifier, just because of not knowing "versioning" extension which would by chance tell that the extension is incompatible. If this is the requirement, than we need to bake in versioning into the core protocol, with all the consequences. 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. [PK] You are again right, but this is the only tool we have in the core RDAP. Kind Regards, Pawel
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
