Jasdip, You are now proposing another competing approach to versioning with the use of opaque versioning and server/user-agent headers for point versioning. We adopted the versioning draft in the working group, since it was known that the use of the extension identifier alone did not support a versioning mechanism. Opaque versioning is not versioning but namespace management, so let’s not inflate it beyond what it really is. If there was true versioning of an extension interface, the opaque versioning would work for draft versions. I don’t believe you’re proposing changing the extension identifier for every draft change, so I’m not exactly sure what the value of adding the reserved “draft” prefix is.
We’ll add the extension relationship support to the versioning draft for review at IETF-126, since that will enable the inconsistent naming schemes used by the registered RDAP extensions to be presented in a predecessor and successor chain. Clients don’t need to use the meta-data, but if you’re looking for true interoperability of extension versioning, the meta-data is essential to make sense of the inconsistency that exists and will likely exist in the future. We have been dealing with extension versioning of EPP extensions for 20+ years, so there is a wealth of experience in this working group to leverage. The approach should support versioning and transition information inline and not be reliant on out-of-band notification, considering that the RDAP servers don’t know the clients ahead of time. Thanks, -- JG [cid87442*[email protected]] 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/> From: Jasdip Singh <[email protected]> Date: Monday, July 13, 2026 at 12:21 PM To: James Gould <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-13.txt 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, Some more comments inline, marked [JS3]. (Given this long thread, emboldening my comments.) Hopefully, our discussion can help inform the WG on the next steps. Cheers, Jasdip From: Gould, James <[email protected]> Date: Monday, July 13, 2026 at 8:40 AM To: Jasdip Singh <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-13.txt You provide many references to STD 95, which there has been agreement that STD 95 doesn’t provide any formal versioning mechanism, and there is unclear and conflicting language in STD 95 that led to the creation of the 3 RDAP extensions being worked on. [JS3] If by “formal versioning”, you mean any structure and “inner meaning" for an extension id, then yes, STD 95 does not. The key question is if we really need anything beyond opaque extension ids. If the draft-authoring use case can be solved using opaque extension ids (with reserved “draft” prefix) and server/user-agent headers, it begs the question if we really need to complicate versioning beyond the revision/superseder way from the extensions draft. IMHO, when evolving a protocol, it is equally important to focus on what not to do, lest it unnecessarily ends up taxing server and client implementors. I believe your reference to STD 95 means that extension versioning can only be done via the extension identifier, which if true doesn’t consider the extensibility of STD 95. [JS3] I think it would be fair to observe that the extensions draft simply works within the Extensibility section of RFC 7480 [3] with the intent to clarify for extension authors and implementors. [3] https://datatracker.ietf.org/doc/html/rfc7480#autoid-15<https://secure-web.cisco.com/1cbvtXA1Tn0ioZXA0m-jMDzRQSoVvXI3nyy1QIwr2l9XiQppnaga-IkyfW4wBYP3arAZni3f0yml1h_dITkavtIi3y30AYuT7KYTByKKnxVeopE5a1rS91pyDajnyxhEddu0nEa2btWHmFs-eEVj7KXt9rJbr0Dk1-DO1aQIfNvtLrz8qNP8TAohpA0Owad7alxy_YS7dtTpZUvkOSjPGNhIUqD9v-huI_Djqndwux7SeEohXLH-tLxtw8v3inza2cni_X-mju2W_QZDVKDWZl5OTjTE9Aje_hI8aauW9oWg/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7480%23autoid-15> Extensions like draft-ietf-regext-rdap-versioning and hopefully draft-ietf-regext-rdap-x-media-type if it can broaden the values passed with the “exts_lists” parameter to support the extension version identifier, can certainly define additional versioning information that extends the extension identifier in STD 95. As discussed on the mailing list, if an extension supports a versioning type (e.g., Point Versioning in draft-ietf-regext-rdap-versioning) that uses the full extension version identifier there will be a normative reference to draft-ietf-regext-rdap-versioning to ensure that the supporting server and supporting client of the extension also support draft-ietf-regext-rdap-versioning. I clarify the context of the problem below: * STD 95 includes unclear and conflicting language for RDAP extensions [JS3] Clarified in the extensions draft. * STD 95 doesn’t include a formal versioning mechanism that enables discovery and negotiation of extension version interfaces. [JS3] Please see my "If by “formal versioning”, you mean …” comment above. * STD 95 doesn’t provide a versioning mechanisms, such as grouping the extension versions, extension relationships, and disclosure of extension transitions (e.g., default, start, and end). [JS3] We need to ask ourselves if doing all this is too much processing for clients and servers. Typically, sunsetting a predecessor is announced and clients prepare to use the superseder before the sunset. * STD 95 doesn’t formally define the forms of RDAP extensibility [JS3] Hopefully, the extensions draft helps clarify the STD 95 extensibility, starting with section 1.1 [4]. [4] https://www.ietf.org/archive/id/draft-ietf-regext-rdap-extensions-14.html#name-summary-of-updates<https://secure-web.cisco.com/1yzorxG9YPuLkbLGyH4siKeOYR6pn5UKCmZ2iYaS_F9Uaod_hzvKete0JTx0ELReEh8dRr-mBGcG54wWTa5cJqbySYFRZFS0bYsHlCcxx-ahz3jB_f8uVquTlOYO7FZWDHeLYPJBvpUIJoSEmsQ5IyPOAP07NE71wn_Vu-oPN4EypX_kvmo9hPrY5WhW045-NxqO2vbnWhu40ZKDhN1TemnDPk1Xyvpo1duKaRwezLipsc8DPzE2xats8wBGnmdeejuM-cGtJrzNfZi5IOmcwDGcxkYPckV9qcCN_uYd04W8/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-extensions-14.html%23name-summary-of-updates> From: Jasdip Singh <[email protected]> Date: Saturday, July 11, 2026 at 2:02 PM To: James Gould <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-13.txt Hi, To help break this logjam, it would be good for us, the WG, to first agree on the overall context of what problems we are trying to solve here. I submit they are: * Provide guidance on how to evolve an extension that’s defined per STD 95. * Provide a way for clients and servers to negotiate extensions that are defined per STD 95. * Provide a way to debug client/server implementations during draft-authoring of an extension that’s defined per STD 95. Please note how these problems are qualified with “STD 95” and no more. IMHO, that’s also important for us to agree upon. If we can at least agree on this, whether we end up with 2, 3 or more drafts is not that relevant. At least that’s my impression. :) If the WG thinks there are other problems we are solving here, please suggest. James, please find below my further feedback, marked [JS2]. Thanks, Jasdip — > 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]: JG2-Do you want us to add a matching versioning type to the versioning draft with something like “Embedded Versioning”? Adding the “draft” prefix was somewhat of a surprise since we really didn’t get anywhere close to an agreement on the mailing list for adding it. Are you supportive of embedding the versioning information in the extension identifier and changing the identifier with any change to the extension? [JS2] Allow me to hone in on your this question. For the former ("embedding the versioning information in the extension identifier”), as long as it sticks to the STD 95 grammar for extensions. Otherwise, as Pawel earlier pointed out, we would need to evolve from “rdap_level_0”. JG3-I assume you mean by STD 95 grammar that Embedded Versioning uses the extension identifier, which it would. The Embedded Versioning will formally define the versioning scheme inside of the extension identifier. The versioning draft can certain define this new versioning type as an extension without having to update STD 95 and evolve “rdap_level_0”. [JS3] As long as any new extension mechanism can be conveyed through the allowed character set for an extension [3], “rdap_level_0” would not need to be updated. For the latter ("changing the identifier with any change to the extension”), per MNOT blogs, try making changes backwards-compatible first before minting a new extension id. So, no. 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<https://secure-web.cisco.com/150GtrsSkTj2Wj8Zd2wwZbsbvV9zqlBbdEmeXn1orrfqIBPEbdIoGDQBEGXVAYvyWbabR9LJMLXjSA-4WccpUn3VPMML5_RFtwd3dq-XorLYHOTIUw40x8WUeLThv9vJe_ToflL5blubS6NURf3DTJHqAPnTZN4tng5rn5yYGFLGfNrnwf3QoExINlo3r_zZ29RBwliSRsZnnCVeKeShBMY5ylPCI_cq5fykjdpSS5SRLEE6sy5uaxm88Nc3fqXnOKdk4fefUsMJDKQowjuTJcok2ztrAEJL0i85v47ETkwQ/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%2Fversioning.example%3Fversioning%3Dpoint_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). JG3-It’s interesting that you’re treating the MNOT blog from 15 years ago as normative here. I don’t view the MNOT blog as relevant to the RDAP versioning discussion. What you’re saying is that draft-ietf-regext-rdap-extensions was updated to support what Scott proposed but the implementation of what Scott proposed is not supported. [JS3] A good advice is a good advice, however old. :) IMHO, MNOT blogs inform well and are relevant to this discussion. They in fact help corroborate that the WG is on the right track with the clarifications in the extensions draft. JG2-The point versioning is not emulating software versioning but defining the version of the extension interface. In reviewing the blog, we came to the same conclusion in the versioning draft, where we started by wanting to model the versioning based on an industry known practice of semantic versioning, but that wasn’t a good match and caused confusion. The point versioning is not associated with software versioning but interface versioning. A client should be capable of understanding the full interface of all the RDAP extensions supported by the server. I don’t believe we should be mixing extension namespace management with versioning, where you don’t want a change to a version to become a breaking change as reflected in the blog with “sticking software versions into Web URL removes a lot of the value we get from using HTTP, and if you do this, you might as well be using a ‘dumb’ RPC protocol”. In RDAP the extension prefix of an extension corresponds to the Web URL in the blog. [JS2] Let me try parsing above para a bit. "The point versioning is not emulating software versioning but defining the version of the extension interface.” … IMHO, this sentence is confusing. Is it not reasonable to comprehend the phrase "extension interface” plainly as HTTP API? As for the phrase “point versioning”, the word “point” in it seems to connote some use of dots with labels when versioning, no? "I don’t believe we should be mixing extension namespace management with versioning, where you don’t want a change to a version to become a breaking change as reflected in the blog with “sticking software versions into Web URL removes a lot of the value we get from using HTTP, and if you do this, you might as well be using a ‘dumb’ RPC protocol”.” … But, that’s exactly what "https://example.com/rdap/domain/versioning.example?versioning=point_ext1-0.1<https://secure-web.cisco.com/150GtrsSkTj2Wj8Zd2wwZbsbvV9zqlBbdEmeXn1orrfqIBPEbdIoGDQBEGXVAYvyWbabR9LJMLXjSA-4WccpUn3VPMML5_RFtwd3dq-XorLYHOTIUw40x8WUeLThv9vJe_ToflL5blubS6NURf3DTJHqAPnTZN4tng5rn5yYGFLGfNrnwf3QoExINlo3r_zZ29RBwliSRsZnnCVeKeShBMY5ylPCI_cq5fykjdpSS5SRLEE6sy5uaxm88Nc3fqXnOKdk4fefUsMJDKQowjuTJcok2ztrAEJL0i85v47ETkwQ/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%2Fversioning.example%3Fversioning%3Dpoint_ext1-0.1>” is not heeding, no? :) [JS3] It would be good to get your opinion here. I could be missing something. "In RDAP the extension prefix of an extension corresponds to the Web URL in the blog.” … That’s incorrect. Extension prefix is prepended to a path segment or a query parameter in a URI, after carefully determining if it were a breaking versus a non-breaking change for a revision, or if it was time to mint a superseder. That’s what section 5.4 provides guidance on. Also see the MNOT-VERSIONING reference: https://mnot.net/blog/2011/web_api_versioning_smackdown<https://secure-web.cisco.com/1mLCKmt3PGy4mggKFlES2qYaniu9e3bxjtlo_oZH3bo5jxCOeXNpl-lNfi65V9aNileEnrPC1Qrq1UyNh-ZOpdC2dyYum7OUuFhnypzTc72Jq3FOTnTB-d5UoZTwEYsNoaVMYINPE_6cHUoTeph7zMO-1F0v6TJBAr4vvx-QYShamBVA-nSGHQACN8sBxUN0CkoVjSk-_EiBDEJea8KB2Y5GsxYlik3HqbHIFSZPQm0mZaTXf-N3wW5oBT-ulqQngrIe8-UXT6PlZOOVICuSFM2HeBDcwOGIXNB7GvxvYpzo/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. JG3-I believe you’re putting too much weight on a blog from 15 years ago. There are many options for recognizing interface versioning with minor revisions, which is currently supported n the versioning draft with Point Versioning. [JS3] As Scott advised when inputting his “draft” prefix idea, it is prudent to keep things simple if possible. Let’s please not dismiss advice from MNOT blogs just because they are not recent. [JS] If software-versioning-like signaling is need during draft authoring for minor revisions, this looks like a cheap way, no? JG2-We can already support signaling of minor revisions in the versioning draft via a query parameter and the RDAP media type “exts_list” parameter in draft-ietf-regext-rdap-x-media-type if the compatibility issue is fixed in draft-ietf-regext-rdap-x-media-type by allowing for the passing of the extension version identifiers. [JS2] "support signaling of minor revisions in the versioning draft via a query parameter” … If "https://example.com/rdap/domain/versioning.example?versioning=point_ext1-0.1<https://secure-web.cisco.com/150GtrsSkTj2Wj8Zd2wwZbsbvV9zqlBbdEmeXn1orrfqIBPEbdIoGDQBEGXVAYvyWbabR9LJMLXjSA-4WccpUn3VPMML5_RFtwd3dq-XorLYHOTIUw40x8WUeLThv9vJe_ToflL5blubS6NURf3DTJHqAPnTZN4tng5rn5yYGFLGfNrnwf3QoExINlo3r_zZ29RBwliSRsZnnCVeKeShBMY5ylPCI_cq5fykjdpSS5SRLEE6sy5uaxm88Nc3fqXnOKdk4fefUsMJDKQowjuTJcok2ztrAEJL0i85v47ETkwQ/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%2Fversioning.example%3Fversioning%3Dpoint_ext1-0.1>” exemplifies so, is that not akin to the "‘dumb' RPC protocol"? AFAICT, that seems like a big no-no per MNOT advice. JG3-My comment was related to the use of the media type parameter in draft-ietf-regext-rdap-x-media-type as well. [JS3] But, what about above use of minor version in query parameter? JG3-Will draft-ietf-regext-rdap-x-media-type be updated to support passing the minor revisions as well by adding support for the extension version identifier? [JS3] Seems like it wouldn’t need to if we leave content negotiation at major version level (through “exts_list”) and exchange implementation details for minor versions (backwards-compatible) through server/user-agent headers, 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. JG3-I believe making extensions backwards-compatible is a good goal to have but based on my experience with EPP extensions the backward compatibility goal is rarely met. I learned that the hard way with my first RFC (DNSSEC EPP Extension in RFC 5910), where my goal was to maintain backward compatibility, but it broke quickly when addressing community feedback. It’s best to have a versioning scheme supported in the protocol to enable extensions to mature with or without backward compatibility. [JS3] But we can do both backwards-compatible (revision) and backwards-incompatible (superseder) changes for an extension the current way, including the draft-authoring use case, as shown in the extensions draft. It would be prudent for the WG to consider if anything further is indeed needed. JG2-I actually found the “wiping the slate clean” in the blog as not fully addressing the issue. From my read, it sounded like when the server removes support for an old version that the URL would then change (e.g., move from “/v1” to “/v2”). I don’t believe anyone is proposing the RDAP servers change the bootstrap URL when removing support for an old extension version. We have experience with transitioning extension versions in EPP that can be leveraged in RDAP, where both EPP and RDAP are extensible. The OpenStack proposal in the blog in interesting, but I don’t believe relates to RDAP extensions. [JS2] Sorry, I need to parse this para as well. "From my read, it sounded like when the server removes support for an old version that the URL would then change (e.g., move from “/v1” to “/v2”).” … Not at all. “v1” and “v2” path segments exemplify how 2 major versions could co-exist. In RDAP's case, “exampleExt1” and “exampleExt2” would signal major version change, and each of them would subsume any non-breaking changes (read: minor versions). IIRC, it was raised earlier: But, how would such minor changes be signaled? (paraphrasing). That’s where the earlier suggestion to use Server/User-Agent headers should come handy. Please note that all this is leveraging standard HTTP concepts and not re-inventing. JG-Use of Server/User-Agent headers is another HTTP option to the use of the media type parameter in rdap-x-media-type and the query parameter in draft-ietf-regext-rdap-versioning. There is no right or wrong here. [JS3] AFAIK, good architectures don’t offer too many approaches to implementors, unless really needed [4]. IMHO, it’d be prudent to limit to clarifying the STD 95 extensibility (section 6 of RFC 7480) if possible. Also, using version in a query parameter is not right, for reasons explained earlier. [4] 3.2 from https://datatracker.ietf.org/doc/html/rfc1958#autoid-3<https://secure-web.cisco.com/11-cgFEm3vmTVTqgikVGG6UmNYL6iMpnD1wdzgeE1nFygA7DF8T-E1q4HNJN5UYekq6-xxel3oV5KjN-6UGHOxkyh0djIzaW7fmpGnsWkYJbmTkVmjavkcR9muD9aYK9f1x2wsgyWGnV7sn7c0q_SUmxkKQhcWuNA2RFHRqT1pt5zXpK2RL_gH57Ge2-w8uroi5406WrJX3ATtvga7Fn4MuAJsScyhI9cH-4ghbo6_3TynwDbSCvItleZPcKofD-IsiAZuzupUeSaJB9447-2bCMJCbzj6xlwrGmqjyItAeI/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc1958%23autoid-3> 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. JG2-I didn’t say that “debugging” is the primary use case, but at a minimum providing the meta-data for clients is help in debugging. We can look to add support for the Embedding Versioning type in the versioning draft if desired and inclusion of opaque versioning relationships in the versioning draft would help to formally define the ordering of the opaque extensions. Can draft-ietf-regext-rdap-x-media-type be updated to support the passing of the Extension Version Identifier, defined in section 3.1 of draft-ietf-regext-rdap-versioning, to enable the passing of versioning information using the “exts”list” RDAP Media Type parameter? [JS2] "I didn’t say that “debugging” is the primary use case, but at a minimum providing the meta-data for clients is help in debugging.” … But please, could you share any other practical problem the versioning draft intends solving? I ask that to get to the heart of the matter: why would clients and servers find it useful to go down the path of implementing the versioning draft if there is no other use case beyond draft-authoring and if the draft-authoring use case could be solved leveraging the standard HTTP concepts and not needing any further invention. JG3-RDAP doesn’t have any practical experience with transitioning of extensions, so what you’re referencing in draft-ietf-regext-rdap-extensions is theoretical in nature. What is supported in the versioning draft is based on the experience of versioning and transitioning of extensions in EPP. Having a clear definition of the extension interface supported by the server that can be negotiated with the client seems basic to me that can be applied during the development of any kind of RDAP extension and not only the ones that have made it to RFC. The only transition that I’m aware of in RDAP is the gTLD profile policy, which for all the servers I’m aware of was done via a default version and a hard cutover. The versioning extension could provide the transition information for clients even in the case of a profile transition. [JS3] While empathizing with the EPP extensibility, I’d submit that the current extensibility model for RDAP suffices, even for the draft-authoring use case. The latter’s extensibility benefits from what HTTP offers. 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. JG2-The versioning draft is tackling extension versioning in RDAP, with support for extension versioning meta-data in the /help response, extension versioning information in the RDAP query response, the ability for the client to provide a hint of the desired extension versions using either the query parameter in draft-ietf-regext-rdap-versioning or the “exts_list” parameter in draft-ietf-regext-rdap-x-media-type, and finally the ability to extend the versioning types to cover future forms of versioning. As an example, we can formally define the Embedded Versioning type in draft-ietf-regext-rdap-versioning if desired or the Embedded Versioning type could be defined in a separate I-D following the template used in the versioning draft for Opaque Versioning and Point Versioning. One option for the versioning draft is to add a Transition Considerations section to the template for a versioning type, which could embed some of what is defined in the extensions draft for Opaque Versioning. Thanks, Jasdip [1] https://mnot.net/blog/2011/web_api_versioning_smackdown<https://secure-web.cisco.com/1mLCKmt3PGy4mggKFlES2qYaniu9e3bxjtlo_oZH3bo5jxCOeXNpl-lNfi65V9aNileEnrPC1Qrq1UyNh-ZOpdC2dyYum7OUuFhnypzTc72Jq3FOTnTB-d5UoZTwEYsNoaVMYINPE_6cHUoTeph7zMO-1F0v6TJBAr4vvx-QYShamBVA-nSGHQACN8sBxUN0CkoVjSk-_EiBDEJea8KB2Y5GsxYlik3HqbHIFSZPQm0mZaTXf-N3wW5oBT-ulqQngrIe8-UXT6PlZOOVICuSFM2HeBDcwOGIXNB7GvxvYpzo/https%3A%2F%2Fmnot.net%2Fblog%2F2011%2Fweb_api_versioning_smackdown> [2] https://mnot.net/blog/2012/api-evolution<https://secure-web.cisco.com/1C28L71CsBv3mIxbUWVjKD0wWgYhuc_QuewOK8oy7oUAbSDp4FpZlOfw2BPROe01Ug12MoPN8_6zW60lOxJX0FG55ZkB94TSRefKhhm7fRtWsCrxHxeQaNiu20hpW4eWqRTICQ0EXtnB32kdTlM7vgHoNTAUVgE3kSwE_NQzRRKBACLSWqxSCxkn7EoFc_bmskXadSf0MbU7l0uXXjBLLyvvCH_4Oh-wWoRpxEpMMLJ_y5iXFWtBlszA0gMh-mqVGQN1AxaLqIMXMNUyoI03MWLQro27_5rVA0Ui2_JndnVQ/https%3A%2F%2Fmnot.net%2Fblog%2F2012%2Fapi-evolution> (referred from [1])
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
