In discussing breaking and non-breaking changes of RDAP extensions, one aspect that seems to be missed is who will being broken by the introduction of a new RDAP extension. RDAP is not a stateful protocol, where clients are switching from an old version to a new version of an RDAP extension. An RDAP extension is broad (e.g., query parameters, HTTP headers, path segments, JSON members, media type parameters) and not equivalent to a change to a REST API. A client needs to leverage the versioning information provided by the server to determine the entire RDAP interface supported, which includes the specific set of RDAP extensions, and the interfaces supported by those RDAP extensions considering the broad definition of an RDAP extension. Would it be helpful for the versioning extension to provide predecessor and successor extension information in the /help response that would apply to opaque versioning?
It would be helpful for draft-ietf-regext-rdap-extensions to cover the forms of RDAP extensibility in a similar fashion to how RFC 3735 provides guidelines to the forms of EPP extensibility. The forms of RDAP extensibility have grown over time, so I certainly wouldn't recommend providing a static enumerated list for RDAP, but at a minimum cover the known forms of RDAP extensibility would help. 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 7/2/26, 10:01 AM, "Pawel Kowalik" <[email protected] <mailto:[email protected]>> wrote: Hi, On 02.07.26 14:41, Andy Newton wrote: >>>> 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. I just wanted to point out, that fulfilment of this condition can never be stated with certainty by the server "clients have switched from the old version to the new one.". Basically client has no way to tell the server if it switched or not, because it happens only after the response has been received from the server. Also in most cases not every client is even known to the server, when out-of-band approaches would come into consideration. Only in case of restricted access RDAP with authentication of clients this may be considered at all. In terms of interoperability it is something different if the client would notice the extension it used to process is not there any longer as opposed to receiving a response with a known extension identifier but with the content which cannot be processed. Kind Regards, Pawel _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
