Hi Andy,I think 1) is impossible under current rules what was brought up by few folks already but it may be me interpreting the things wrongly.
If you may lay down an example it would be helpful to avoid misunderstanding.
Kind Regards, Pawel On 23.10.25 21:38, Andy Newton wrote:
On 23-10-2025 4:27 AM, Pawel Kowalik wrote:Hi Jasdip, On 22.10.25 17:29, Jasdip Singh wrote: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.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.I think there are two different things being discussed:1. One in which a "successor" extension re-uses parts of the previous extension by just including that extension. 2. And one in which a "successor" extension duplicates all parts of the previous extension but publishes both during a transition time.Anything fancier must use the versioning scheme in the versioning draft.While scenario 2 is simpler, scenario 1 is indistinguishable from one extension referencing another. And both are currently possible in STD 95. Section 5.3.1 and 5.3.2 just lays out the issues with scenario 1. However, there are issues with scenario 2 (see Tom's email), which we might need to discuss in the document.As I see it, there are a couple of things we may need to add or better describe in the document:a. referencing of one extension by another (an example would be good).b. describe scenario 2 and the compatibility issues that may arise with it.c. better describe scenario 1 (again, examples). -andy
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
