Hi Pawel, From: Pawel Kowalik <[email protected]> Date: Wednesday, October 22, 2025 at 1:55 AM To: Jasdip Singh <[email protected]>, Andy Newton <[email protected]>, [email protected] <[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. On 21.10.25 21:49, Jasdip Singh wrote: AFAIU, "foo0" should be used to prefix whatever it needs to -- JSON names, query parameters, object class names, etc. (say, "foo0_x"). When "foo1" (or "foo99" for that matter) comes along, it holistically prefixes all it needs to, including what "foo0" prefixed (say, "foo1_x") and any additional ones (say, "foo1_y"). That way both these opaque extension ids can be used by clients based on the "exts_list" negotiation, and when "foo0" is retired, it should be safe from backwards-compatibility angle. <snip> Thanks, Jasdip
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
