Even though sections 5.3.1 and 5.3.2 have been in draft-ietf-regext-rdap-extensions since the -00 draft, they don’t belong in draft-ietf-regext-rdap-extensions. The RDAP extension identifier doesn’t have any embedded version information, which is why it is referred to as opaque. Can the working group move it’s versioning focus on draft-ietf-regext-rdap-versioning and remove the versioning detail of backwards-compatibility and backwards-incompatibility from draft-ietf-regext-rdap-extensions (section 5.3.1 and 5.3.2)?
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: Mario Loffredo <[email protected]> Date: Friday, October 24, 2025 at 9:51 AM To: Pawel Kowalik <[email protected]>, Andy Newton <[email protected]>, Jasdip Singh <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] [regext] Re: RDAP Extensions - opaque versions, extension identifiers and rdap conformance Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Andy and Pawel, I see the following possible examples for scenario 1: A) Response extension A.1) Extending an existing extension with an optional member: "fooV0_xx": { ...., "fooV1_yy": ..... } A.2) Providing additional information of an extension through a separate member "fooV0_xx": ...., "fooV1_yy": ..... This case is similar to the one corresponding to scenario 2 but here "fooV1_yy" is not going to replace "fooV1_xx". A.3) Defining an extension that includes an existing extension: "fooV1_yy": { ....., "fooV0_xx": ..... } In this case, both fooV0 and fooV1 extensions would continue to be used anyway regardless of whether "fooV0_xx" is also returned along with "fooV1_yy" (case A.2) or "fooV1_yy" is going to replace "fooV0_xx" (scenario 2 - transition between two extension versions). IMO, at least in the case of replacement, the rdap-versioning document should require renaming "fooV0_xx" to "xx" "fooV1_yy": { ....., "xx": ..... } A.4) Any combination of A.1, A.2 and A.3. B) Request extension B.1) Introducing an optional query parameter (similar to A.2) B.2) Extending an existing path with an optional sub-path (similar to A.1) B.3) Both B.1 and B.2 C) Extending both request and response as indicated by A and B Finally, I would like to point out that all the above-mentioned cases can be handled via the rdap-versioning specification in a more elegant and efficient way, as it allows any type of change to be handled in the same manner, i.e., switching between supported versions of the same extension on demand. Best, Mario Il 24/10/2025 09:13, Pawel Kowalik ha scritto: 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: 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. 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 _______________________________________________ regext mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [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/1grkJyc81cXbqn8Dwy6K_fE-4BwurDpmXcMGTDiNbtXqzt24lOYBRHo4PgRmBbIpndP2vfMIEuChhwMcKqkmV9NUfyNyqRZ5cF7Ts7zH3_CfKuczMpGC2skHk4uuPn5i1yb_ATJRFtSu4hXv7mrCd4rxRWege8dBQKIxDtdLrOlWqqs6Hbv3fThh0uJnn8LQI62vimfDVKNVe58hYy6gURQ5vWsbM9FIGYqX-SKpf2psYL4SZMW5mEi0nNq2iUA475cEIkDR-fxDwJH3hBj_ys5Y0gwBThmgnFZHMijIIh0s/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
