Hi James, Mario,
From: Gould, James <[email protected]> Date: Tuesday, July 7, 2026 at 6:48 PM To: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-13.txt On 7/7/26, 4:20 PM, "Andy Newton" <[email protected] <mailto:[email protected]>> wrote: On 7/7/26 1:44 PM, Gould, James wrote: > 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). [JS] Glad to learn that the “draft” prefix idea could work for the draft-authoring scenario. This also seems in line with insights from Mark's blogs [1] [2]: It is not considered a good idea to emulate software versioning (use of dots with numbers) for an HTTP API like RDAP. Using a versioning query parameter in a URI (e.g., "https://example.com/rdap/domain/versioning.example?versioning=point_ext1-0.1”) would make identifying the resource (e.g., “versioning.example” domain) brittle. Instead, using “draftExample0”, “draftExample1”, etc. extension id's in the “exts_list” parameter for RDAP’s media type in Accept and/or Content-Type headers would avoid this URI brittleness problem because such signaling is offloaded to normal HTTP content negotiation. Per those blogs, using opaque extension ids for major (breaking) versions of an extension should be also fine, advising not to read too much into numbers. Yes, “draftExample0” and “draftExample1” seem to use numbers but they might have instead been called “hello” and “world” (per second para of section 5.4). 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. [JS] If software-versioning-like signaling is need during draft authoring for minor revisions, this looks like a cheap way, no? 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. [JS] Beg to differ here. Being HTTP/REST/JSON-based, most, if not all, changes for an RDAP extension affect one or more resources and/or their representations. Furthermore, trying to make changes backwards-compatible for an extension is encouraged before “wiping the slate clean” for an unavoidable breaking change and creating a new extension id. 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. [JS] If “debugging” is the primary use case for numbered versioning, IMHO, it would be prudent to consider above advice from Mark’s blog. That way, it should be relatively cheap for both clients and servers: “draft” prefix for (breaking and/or non-breaking) extension id's, Accept/Content-Type headers for content negotiation, and Server/User-Agent headers for minor version signaling. That said, it'd be good to know if there are other use cases beside draft-authoring that the versioning draft is expecting to tackle. Just asking from what-not-to-do angle. Thanks, Jasdip [1] https://mnot.net/blog/2011/web_api_versioning_smackdown [2] https://mnot.net/blog/2012/api-evolution (referred from [1])
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
