Hi Mario, On 6/10/26 10:14 AM, Mario Loffredo wrote: >> >> No clients do this today. But this confirms my earlier assertion that what >> is being attempted with the versioning draft is not backwards compatible >> with everything deployed today. > [ML] I'm sorry, but I don't understand why you think the versioning extension > is backwards-incompatible.
Likewise, I don't understand why you and James are not comprehending the points that I and others have made in this thread. But miscommunication happens with complex topics. That is why I asked that the version draft include some query/response examples of how a client is suppose to handle backwards incompatibility.... both for a client that supports this versioning extension and one that does not. James seems more interested in discussing the conceptual definition of a breaking change, but since you are also one of the authors would it be possible for you to provide those examples to help clarify this discussion? >>> If a server implements the versioning specification, a client can not only >>> check which extensions, but also which versions of those extensions are >>> implemented by the server. >> And what will the client do with that information? I have asked this >> question multiple times and have yet to get an answer. > > [ML] Clients may notice that a backwards-compatible change has occurred, as > explained in Section 5.4.5 of the rdap-extensions draft. > > They can also clearly determine the relationship between two versions of an > extension that differ by a backwards-incompatible change, as explained in > Section 5.4. Nothing in Section 5.4.x says a client dynamically changes behavior upon receiving versioning information. When you say "They can also clearly determine the relationship between two versions of an extension", then what? What is client software suppose to do with that information? -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
