Hi Pawel,
Il 08/01/2025 09:57, kowa...@denic.de 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: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
