As noted previously, I believe the versioning topic should be handled in draft-ietf-regext-rdap-versioning and not draft-ietf-regext-rdap-extensions, where the language in 5.3 is fine, but the language in 5.3.1 and 5.3.2 is out-of-scope. Please review draft-ietf-regext-rdap-versioning and comment on the versioning use cases that need to be covered.
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: Thursday, October 23, 2025 at 4:28 AM To: Jasdip Singh <[email protected]>, Andy Newton <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] [regext] Re: RDAP Extensions - opaque versions, extension identifiers and rdap conformance Hi Jasdip, On 22.10.25 17:29, Jasdip Singh wrote: Hi Pawel, From: Pawel Kowalik <[email protected]><mailto:[email protected]> Date: Wednesday, October 22, 2025 at 1:55 AM To: Jasdip Singh <[email protected]><mailto:[email protected]>, Andy Newton <[email protected]><mailto:[email protected]>, [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: Re: [regext] Re: RDAP Extensions - opaque versions, extension identifiers and rdap conformance <snip> See my other E-mail I sent yesterday. What you mention is variant 1. Data is 100% duplicated between the "versions" (even if JSON-wise the payloads under foo0_x and foo1_x are back compatible). After foo0_x is removed and only foo1_x payload remains, the clients only knowing foo0_x break - so the statement that it is safe to remove is false. [JS] It’s a trade-off. From reputational angle, no RDAP service would want to break clients inadvertently and without sufficient forewarning about sunsetting older versions of an extension. However, operationally, backwards-compatibility is generally not for perpetuity since it costs to maintain older versions. Yes, the current approach in the draft (approach 1 per your earlier note) costs in terms of larger responses because of data duplication but then there would be a way for clients to negotiate a particular version with the server through, say, the “exts_list” parameter approach, as long as that server decides to keep supporting older versions from cost perspective. IMHO, it would be prudent to consider this to help keep the RDAP extensions architecture simple. This is fine and if we are in consensus this is the way to go, then 5.3.1 shall be removed and 5.3 extended with a clear guidance that pure RDAP does not offer versioning or back compatibility because the data/parameters/paths are in distinct elements so to support older clients all versions of an extensions have to be used in the response. If one would want one draft versioning is the solution. This is also what I hear from Jim G. Most of the text if not all of 5.3.2 can be integrated into 5.3 because it actually applies all times. There is also one more alternative which comes to my mind. A variant when back-compatible version would be published without new identifier. All elements remain the same and if extension author can guarantee back compatibility then nothing brakes. Downside: without draft versioning the clients will not know which version they see. But maybe this is the trade-off we could just take. Then 5.3.1 would not be removed but only change the recommendation to not register new identifiers. Kind Regards, Pawel
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
