I agree with "most servers will serve what they have and most clients will just get what they get. There is no relationship between the user and the service provider, and there is no incentive for a service provider to serve anything other than what is required by policy.".
RDAP doesn't have a known set of clients that the servers coordinate with and monitor during a transition like what occurs in EPP. Consider the upgrade of the RDAP Profile by the servers, the server simply cutover from the old RDAP profile to the new RDAP Profile without any coordination. The RDAP profile extension identifier was used as the signal of the RDAP policy supported by the servers. Did any server out there do something more elaborate in the transition? Were there any reported issues in implementing the hard cutover? It's much less of an issue for RDAP extension updates at the level of an RFC than at the level of an extension drafts if servers and clients desire to implement I-Ds ahead of becoming RFCs. I see the need for this to get implementation experience for making better extension RFCs. I don't see a server supporting two versions of an extension at the same time, but it is good that the protocol supports it if needed. One option is to support a default version with allowing for the client to override the default. Server policy will drive if there is a transition period or a hard cutover, like what I believe occurred with the RDAP policy update. -- 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 7/2/26, 8:43 AM, "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. inline... On 7/2/26 4:37 AM, Mario Loffredo wrote: > [ML2] Good. Another aspect I'm not clear on is when the transition > period from the old to the new version should end. > > I mean, what criteria would a server use to permanently remove the old > version, being relatively confident that this switch won't break clients? > > I imagine it could be done based on the contents of the `exts_list` > parameter. > > As soon as all clients that previously referenced the old version in the > `exts_list` parameter start referencing the new one, servers could stop > (or plan to stop ) supporting the old version. > > Do you agree? That would be ideal, though I think in reality it is just one of many factors that would inform a policy decision. If we look at something like the WHOIS Sunset, that was a date picked several years in the future, and when it arrived there were still billions of WHOIS queries every month when many of the gTLD services were shut off. In general, I think most spec authors are far more concerned about adoption than deprecation. Additionally, most servers will serve what they have and most clients will just get what they get. There is no relationship between the user and the service provider, and there is no incentive for a service provider to serve anything other than what is required by policy. > >>> >>> >>> Additional suggested change: >>> >>> Section 5.4.1 >>> >>> OLD >>> >>> Removing a required protocol element from a response; >>> >>> NEW >>> >>> Removing a required protocol element from a response that has not yet >>> been fully deprecated; >> Is this really necessary? Why would a protocol element be in an >> extension if it was fully deprecated? > > [ML2] This is inherent in managing the transition period from the old to > the new one. > > At some point, the old version will be removed from the response. > > Therefore, stating that removing a required protocol element from a > response is a breaking change seems to me equivalent to stating that > required protocol elements can never be removed, even if they have been > completely deprecated and all clients have switched from the old version > to the new one. I see your point. I'll add this. > >> >> >> Given your feedback, I have attempted to make 5.4 clearer. Here is the PR >> https://github.com/anewton1998/draft-regext-rdap-extensions/pull/85 >> <https://github.com/anewton1998/draft-regext-rdap-extensions/pull/85> >> >> Keep in mind that the I-D deadline is Monday, and I'd like to rev this >> before then. > > [ML2] Can I add comments on that branch ? You can pull down the branch, but it is probably easier just to comment on the files in the PR. -andy _______________________________________________ regext mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
