Hi Pawel,
Thanks for you patience.
I put some examples and explanatory text in a candidate PR:
https://github.com/anewton1998/draft-regext-rdap-extensions/pull/76
Let me know what you think.
-andy
On 10/24/25 03:13, Pawel Kowalik wrote:
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]>
*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.
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]
To unsubscribe send an email to [email protected]
