Andy, My replies are inline below.
-- 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/7/26, 4:20 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 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... JG - Yes, I meant the gTLD RDAP profile using the extension identifiers icann_rdap_technical_implementation_guide_0/ icann_rdap_response_profile_0 that was upgraded to icann_rdap_technical_implementation_guide_1 / icann_rdap_response_profile_1. 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. JG-Correct there was no gTLD-level hard cutover or flag day, but it was up to each of the registry service providers to cutover within the one-year transition period. This means that clients need to deal with servers that either supported icann_rdap_technical_implementation_guide_0/ icann_rdap_response_profile_0 or icann_rdap_technical_implementation_guide_1 / icann_rdap_response_profile_1. How did the servers support them in parallel since I viewed them as mutually exclusive? The successor defined a different set of policies that impacted what was returned and didn't change the interface, which could have impacted clients. RFC9537 is an interface change that is associated with the transition from supported icann_rdap_technical_implementation_guide_0/ icann_rdap_response_profile_0 to icann_rdap_technical_implementation_guide_1 / icann_rdap_response_profile_1. 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. JG-We could add support for predecessor and successor extensions in the versioning draft for opaque versioning that would include the "start" and "end" members currently supported for point versioning. This way it would be clear to clients what the transition period is for any opaque versioning extension. > > 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. JG-Ok that sounds good. I'm working on a detailed review of draft-ietf-regext-rdap-extensions and from a high-level it would be helpful to formally define the format using ABNF for the extension identifier and for the extension elements.(e.g., query parameters, path segments, JSON members, HTTP headers, media type parameters). Also see the MNOT-VERSIONING reference: https://secure-web.cisco.com/13dW7icXTSQ2UMAzB4bnbqQ_JnrUZ7BRjYH63GCWMrtKVmOBDhETi2oipmL0HnxkmpuJliXcbzKI6qModk1C2eWjHq5c35YYEwJj4JBzeGBFnSRN-3pHERAO8-cOUJsLHiKm7SnVChP6e4QU0sI6kdZTQIneCgXtYvTXb1895Zx17_3jRxmMODuYEXNYNXIRGbEbJaX56rLEye1rAGxRrGyyz4m0wKpe1MxpdYv6EZNhUX0PxqqeT-oDKvSEHXwkh2lfn1JupJMxcBYZlsCLD14Q8NVUsDIY-8eDNIzjLJ8s/https%3A%2F%2Fmnot.net%2Fblog%2F2011%2Fweb_api_versioning_smackdown <https://secure-web.cisco.com/13dW7icXTSQ2UMAzB4bnbqQ_JnrUZ7BRjYH63GCWMrtKVmOBDhETi2oipmL0HnxkmpuJliXcbzKI6qModk1C2eWjHq5c35YYEwJj4JBzeGBFnSRN-3pHERAO8-cOUJsLHiKm7SnVChP6e4QU0sI6kdZTQIneCgXtYvTXb1895Zx17_3jRxmMODuYEXNYNXIRGbEbJaX56rLEye1rAGxRrGyyz4m0wKpe1MxpdYv6EZNhUX0PxqqeT-oDKvSEHXwkh2lfn1JupJMxcBYZlsCLD14Q8NVUsDIY-8eDNIzjLJ8s/https%3A%2F%2Fmnot.net%2Fblog%2F2011%2Fweb_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? JG-I'm not sure how the Web API Versioning Smackdown blog matches the use case of versioning RDAP extensions, where an RDAP extension is very broad and doesn't typically impact the REST resource. When using the point versioning in the versioning draft, the server will support a default version of the extension as represented by the "default" member, which can be overridden by the client using the query parameter or the x-media exts_list parameter. This assumes that the server supports more than one version of an extension in parallel. We could add similar support for the opaque versioning based on adding relationships with the data members like "predecessor" and "successor". This way the server can provide the versioning information for the clients to understand what is supported by default and what overrides can be provided. In the end, I view the definition of the interface of the extensions as important for interoperability and defining the "predecessor" and "successor" would help in a transition and help in debugging any issues that come up at a minimum. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
