Andy, Inclusion of some query/response examples for supporting and non-supporting clients are reflected in the following draft-ietf-regext-rdap-versioning figures:
1. Non-supporting - Figure 8: RDAP Domain Lookup Response with No Client Specified Versioning 2. Supporting - Figure 9: RDAP Domain Lookup Response with "point_ext1-0.1" Extension Version 3. Supporting - Figure 10: RDAP Domain Lookup Response with "point_ext1-0.1" and "opaque_ext2" Extension Versions The only indication for the server whether the client is non-supporting or supporting is based on the inclusion of the Extension Versioning Request in Section 3.2. From an implementation perspective, a client will receive the "versioning_data" member that can be used by the supporting client to understand the extension versions included in the response and can be used for troubleshooting by a non-supporting client. The "versioning_data" member is in addition to the "rdapComformance" member and can be easily mapped based on indexing by the extension identifier. Since we have no experience with an extension transition in RDAP, we can look to the experience with an extension transition in EPP, which has been done many times. In EPP, our implementation was to return a default version based on the latest supported version of an extension. If a client does not support the latest supported version, based on the login services, the server returns the earlier supported version of the extension. For RDAP, the server can return the latest supported version of the extension and allow for the client to specify an earlier version of an extension using the Extension Versioning Request (query parameter or media type parameter) in Section 3.2 of draft-ietf-regext-rdap-versioning. The /help can also be used for automatic discovery of the extension versioning or manually for troubleshooting issues. The discovery can be done infrequently (e.g., daily), since the RDAP servers don't change their extension versions very often. I hope this helps. Thanks, -- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/10/26, 12:34 PM, "Andy Newton" <[email protected] <mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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]
