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]>
*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 [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
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
