Hi James, Inline...
On 7/7/26 1:44 PM, Gould, James wrote: > 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? > Do you mean the gTLD RDAP profile? There are other RDAP profiles, such as the NRO profile. RDAP is used by gTLDs, ccTLDs, RIRs, NIRs, etc... For the gTLD profile, there was no hard cutover or flag day. There was a one-year transition. And there were a few servers that claimed to support both versions of the profile simultaneously. To the clients it did not really matter because this was a profile of the things already in STD95. As the predecessor did not define any new protocol elements, there was not much for the successor to break. The biggest issue to clients was the addition of RFC9537, which is not client-friendly, and to this day there are server operators who do it incorrectly. To the meta-point about policy driven cut-overs, we should probably put something in the draft about that. A policy decision does not negate the fact that a breaking change is an interoperability issue, and sometimes breaking changes are required due to policy. Life happens. > > 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. > We incorporated Scott's idea of the "draft" prefix if there is a need to designate an extension identifier in that way. See section 2.2. Also see the MNOT-VERSIONING reference: https://mnot.net/blog/2011/web_api_versioning_smackdown This suggests the use of the User-Agent and Server headers when you need software to recognize the minor revisions for the limited set of clients and servers you may be playing with in doing development. But to be honest, I've implemented many RDAP extensions in both server and client and have never run into any special need for explicit protocol support. What specific issues did you have? -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
