[regext] Re: RDAP versioning - on client-server interactions and 2-RTT flow

[Mario Loffredo <[e-mail]>]

Hi Pawel,

Il 08/01/2025 09:57, [e-mail] ha scritto:
>
> [PK] This is all true, assuming there is always 100% match between the 
> client and the server on the version. Note that here, because we 
> version a specification not an implementation, we may face an unusual 
> situation that the client may be ahead of the server. In this case if 
> client depends on 0.8 functionality, it would not be fine with 0.4 
> response (missing fields added between 0.4 and 0.8). So, if the server 
> eventually would ramp up 0.9 (not default yet) the client would not 
> get 0.9 response which would be working for him, unless it makes 2-RTT 
> flow and discovers 0.9 version, which it does not know (yet), but 
> which may serve a compatible response for it.
>
> The bottom line is, that the clients would either need the implement 
> 2-RTT flow to get an optimum answer, or always support somehow the 
> lowest version that may come from the server missing functionality 
> that may have come from a better version.
>
> This could be solved if the client would be able to make range version 
> requests. For me it would be one of the reasons to bother with 
> semantic versioning at all if machines could figure out on their own 
> the best fit.
>
> If it is not a goal and semantics behind versioning is just for 
> humans, then I would return to my previous position that we shouldn't 
> bother defining any semantics at all and let each extension define 
> their own stuff how they like. It is a waste in my eyes to define and 
> maintain strict rules for versioning with a new IANA registry and all 
> processes around it.
>
[ML] At any time a client version of a given specification may be ahead 
of a server version and vice versa.

I wouldn't worry if the mismatch was due to a chain of backward 
compatible changes as the client can still process the response. Since 
we are talking about backward compatible versions, if the client is 
ahead of the server, all missing fields should be optional and the 
client would interpret their absence as a lack of information, vice 
versa, the client would ignore fields it doesn't recognize due to JSON 
being schemaless. Anyway, if both the client and the server supported 
the rdap-versioning spec, the client would get from the response the 
information about the version currently supported by the server. In a 
way, this is what happens when the client gets a redacted response. The 
only difference is that, if the server supports RFC 9537, the client can 
know that a missing field is not returned but supported.


If the mismatch is due to a breaking change, both clients and servers 
are expected to play their part in the transition process :

- The breaking version is supported as default by the client but not by 
the server

The client should previously check if that version is supported before 
asking the server for it or submitting a request anyway. If the new 
version is not supported, the client should be able to switch to the old 
version as long as all the servers it usually deals with are alligned to 
the new version. Please note that the client knows that it is asking for 
and expecting a version related to a breaking change with regard to the 
previous version.

-  The breaking version is supported as default by the server but not by 
the client

Similarly, the server should have previously planned a transition 
process to switch to that version to mitigate the risk of returning a 
breaking response. Such a transition should consist in first, announcing 
the sunrise of the new version, then serving the old version by default 
and the new version on request, finally returning the new version as 
default after giving appropriate time to all (or almost all of) the 
clients it deals with to switch to the new version. This is explained in 
the rdap-jscontact document.


Generally, this is expected to happen for every version upgrade but in 
case of mismatches due to non-breaking versions both clients and servers 
never risk to break interoperability.

I also think that since managing a transition process could be very 
cumbersome for both clients and servers depending on the scope of the 
breaking change, I think introducing a breaking version as the default 
should reset the sequence of non-breaking versions supported by both of 
them.

In conclusion, I do believe that the RTT-flow is needed to efficiently 
implement a possible transition process and the rdap-versioning spec is 
helpful in this respect.


Best,

Mario




-- 
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: [phone]
Web: http://www.iit.cnr.it/mario.loffredo