Andy, Thanks, I don't remember inclusion of a '__' in draft-ietf-regext-rdap-extensions and the discussion around its use. Were you planning on enabling embedded versioning information from the versioning extension? I believe at that time we didn't want to mess around with the extension identifier value with embedded versioning, but that's just a guess. Do you have a reference to this in GitHub since the draft doesn't include a Change History section?
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/13/26, 3:03 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. James, Up until -04, we had "__" reserved for embedding additional information in the extension identifier, including any versioning information you were to define in your draft (I don't remember which versioning scheme you were doing at the time). https://secure-web.cisco.com/1yjmzDOVlV82tRnmcnXlncT46dDZAMoFX0f902w1vPcWUNtbRWylSsblj4jt8pPiMw_KpOr_xcs6rTskdiyBVjt6MAhQyJG3xkHlvGp7ZM2Y5Epxu1DIOh9sav9Ku2RNjxXXSAvx_CYLb6HIsZYo4UinZqLa78QwcuzCAdYBtgI91apSkj3_KdJT4pGHumz5DvTA8Dvowd_cUSXhCqUF-Io-tQ_y_SNXhEbHlZFHFhmiYSgmJ7XXHpBP4JRgL9c2FL-QLqtTH8k8IOUpq5JU3p--KncJNGLNpQoMpErHxfWQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-extensions%2F03%2F <https://secure-web.cisco.com/1yjmzDOVlV82tRnmcnXlncT46dDZAMoFX0f902w1vPcWUNtbRWylSsblj4jt8pPiMw_KpOr_xcs6rTskdiyBVjt6MAhQyJG3xkHlvGp7ZM2Y5Epxu1DIOh9sav9Ku2RNjxXXSAvx_CYLb6HIsZYo4UinZqLa78QwcuzCAdYBtgI91apSkj3_KdJT4pGHumz5DvTA8Dvowd_cUSXhCqUF-Io-tQ_y_SNXhEbHlZFHFhmiYSgmJ7XXHpBP4JRgL9c2FL-QLqtTH8k8IOUpq5JU3p--KncJNGLNpQoMpErHxfWQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-extensions%2F03%2F> But we took it out after you said you would not use it. -andy On 7/13/26 2:38 PM, Gould, James wrote: > Scott, > > > > I’m not proposing changing the extension identifier with every draft change > (e.g., interface impacting and text updates), but I wanted to understand why > draft-ietf-regext-rdap-extensions added support for the “draft” prefix > without fully understanding how it would be used. I believe that the > extension identifier should only be updated when there is an interface > impacting change, where the draft version wouldn’t match the extension > identifier directly, but I’m not exactly sure how others feel. It gets more > complex when drafts go from proprietary extensions to individual drafts, to > working group drafts, and finally to RFC, since the specification version may > go back to 0 or 00 multiple times. If there is some form of versioning scheme > embedded in the extension identifier, then I was asking whether the > versioning draft should formally support it with a versioning type like > “Embedded Versioning”, which I haven’t seen support for yet. The “Embedded > Versioning” would be like > the “Point Versioning” but instead of mapping the point version included in > the draft (e.g., Extension Version Identifier) it would be mapped by > convention in the Extension Identifier. If there was not a 1-to-1 > relationship between the draft version and the extension identifier by > convention, then the mapping would need to be included in a section of the > draft. > > > > I attempted to get the preferences from the working group on the location of > the version identifier and what changes the version in the mail message > https://secure-web.cisco.com/1xeRksKnnBHZ8oGRy_NVimXV6iCXAbLCOU8jZfPz8ETY4aA_y78lVTt5m72JSKcbgixqfuJ4pqU97BTwzv_6RW3GoSOrty-wUebpITN4dKIgAkDyscW5sRxVfamwZ6_wuXCDL82SqPtXnBzBaUgvz5Uv8u24hZZu9J9FXO7XHc7wmx2qk3NrJuQq5B5srBBLYAXGH192nY5Rk5c1V1vGuN50lu1ovVuoRRBqkBVijxWsYhqOrk3LyKFFp8qE802WsmDfo_P_wCFcYrnzXpaNV-MDYnvi7Edsg2CXeWOsGsro/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FXHyPXtm0fCFlnHeHEU_kr63cg7s%2F > > <https://secure-web.cisco.com/1xeRksKnnBHZ8oGRy_NVimXV6iCXAbLCOU8jZfPz8ETY4aA_y78lVTt5m72JSKcbgixqfuJ4pqU97BTwzv_6RW3GoSOrty-wUebpITN4dKIgAkDyscW5sRxVfamwZ6_wuXCDL82SqPtXnBzBaUgvz5Uv8u24hZZu9J9FXO7XHc7wmx2qk3NrJuQq5B5srBBLYAXGH192nY5Rk5c1V1vGuN50lu1ovVuoRRBqkBVijxWsYhqOrk3LyKFFp8qE802WsmDfo_P_wCFcYrnzXpaNV-MDYnvi7Edsg2CXeWOsGsro/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FXHyPXtm0fCFlnHeHEU_kr63cg7s%2F> > > <https://secure-web.cisco.com/1xeRksKnnBHZ8oGRy_NVimXV6iCXAbLCOU8jZfPz8ETY4aA_y78lVTt5m72JSKcbgixqfuJ4pqU97BTwzv_6RW3GoSOrty-wUebpITN4dKIgAkDyscW5sRxVfamwZ6_wuXCDL82SqPtXnBzBaUgvz5Uv8u24hZZu9J9FXO7XHc7wmx2qk3NrJuQq5B5srBBLYAXGH192nY5Rk5c1V1vGuN50lu1ovVuoRRBqkBVijxWsYhqOrk3LyKFFp8qE802WsmDfo_P_wCFcYrnzXpaNV-MDYnvi7Edsg2CXeWOsGsro/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FXHyPXtm0fCFlnHeHEU_kr63cg7s%2F> > > <https://secure-web.cisco.com/1xeRksKnnBHZ8oGRy_NVimXV6iCXAbLCOU8jZfPz8ETY4aA_y78lVTt5m72JSKcbgixqfuJ4pqU97BTwzv_6RW3GoSOrty-wUebpITN4dKIgAkDyscW5sRxVfamwZ6_wuXCDL82SqPtXnBzBaUgvz5Uv8u24hZZu9J9FXO7XHc7wmx2qk3NrJuQq5B5srBBLYAXGH192nY5Rk5c1V1vGuN50lu1ovVuoRRBqkBVijxWsYhqOrk3LyKFFp8qE802WsmDfo_P_wCFcYrnzXpaNV-MDYnvi7Edsg2CXeWOsGsro/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FXHyPXtm0fCFlnHeHEU_kr63cg7s%2F>>. > Only Pawel replied to the mail message. It would be great if we can better > understand the additional options and the preferences of those options in the > working group. > > > > Thanks, > > > > -- > > > > JG > > > cid87442*[email protected] > > *James Gould > *Fellow Engineer > [email protected] <mailto:[email protected]> > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected] > <mailto:[email protected]>> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > <http://secure-web.cisco.com/1WKx35zzdLRojJL8XPjvclJuCsLyi1Mmw8UUenGHBDPdLjPtmApaQ29Fk65_Yx08oJ4-iiL3QN7d0welkeurH2fhIc--iWAQmkpUGWjwSAd2mqWydRCtVxE9I0La3IqQJqYpNTh_77btRa9IUEN5aiDzC5wr9KIgnEWqJJoAYTtQi8y5viomNQ7stwT-hUH0h3h_OCOOYrg4kiaYLJq8lpp8MixN79zO1Sb-ZEGpvReARCMZI6FuKPU8HFx4_656C2lQqijY2Zso8YTK3lhcfXD3mNp2QmqWAsCmJBcPMaBg/http%3A%2F%2Fverisigninc.com%2F> > > <http://secure-web.cisco.com/1WKx35zzdLRojJL8XPjvclJuCsLyi1Mmw8UUenGHBDPdLjPtmApaQ29Fk65_Yx08oJ4-iiL3QN7d0welkeurH2fhIc--iWAQmkpUGWjwSAd2mqWydRCtVxE9I0La3IqQJqYpNTh_77btRa9IUEN5aiDzC5wr9KIgnEWqJJoAYTtQi8y5viomNQ7stwT-hUH0h3h_OCOOYrg4kiaYLJq8lpp8MixN79zO1Sb-ZEGpvReARCMZI6FuKPU8HFx4_656C2lQqijY2Zso8YTK3lhcfXD3mNp2QmqWAsCmJBcPMaBg/http%3A%2F%2Fverisigninc.com%2F>> > > > > *From: *Scott Hollenbeck <[email protected] > <mailto:[email protected]>> > *Organization: *SAHollenbeck LLC > *Date: *Monday, July 13, 2026 at 2:00 PM > *To: *James Gould <[email protected] <mailto:[email protected]>>, > "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, "[email protected] > <mailto:[email protected]>" <[email protected] <mailto:[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. > > Jim, > > > > “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.” > > > > I **did** make just that proposal. It’s important to remember that what > ultimately gets registered with IANA is a text identifier that is **directly > associated with a single specification**. Use of the “draft” prefix, coupled > with incremental changes in the extension identifier that correspond to > changes in the draft it’s associated with (draftFoo0, draftFoo1, etc.), can > serve the same purpose while drafts are evolving. I remain convinced that it > doesn’t need to be more complicated than this. > > > > Scott > > > > *From:*Gould, James <[email protected] > <mailto:[email protected]>> > *Sent:* Monday, July 13, 2026 1:08 PM > *To:* [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]> > *Subject:* [regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-13.txt > > > > 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] <mailto:[email protected]> > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected] > <mailto:[email protected]>> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > <http://secure-web.cisco.com/1NO763Vshs5LBdEYyq1IgfY-cIQB3524Et5dwmrQ9bEp-nHEEnuVWV565k9jxiq3nmuQdgxqcU77kKQjliS4dAP1XoKSQHhwOOp4wtZUkZqZHyeZ1Vdan0NX8QMMiWgGLB_JqBW46oJcIUL5s7LuGwyppUKmKT3wv0jxb0GeAQYvP1FdcCZRtcaRRTLKSdRO6i7qbocujq5pOP24ZXsCxBrBWwm3EuN7ruo1ZteTSB7yl4iSw7uCfPOLhNEF284GAqYCmFyfMCZA00B4ef8-67URfiKEhhAW0IhGz5gurRzo/http%3A%2F%2Fverisigninc.com%2F> > > <http://secure-web.cisco.com/1NO763Vshs5LBdEYyq1IgfY-cIQB3524Et5dwmrQ9bEp-nHEEnuVWV565k9jxiq3nmuQdgxqcU77kKQjliS4dAP1XoKSQHhwOOp4wtZUkZqZHyeZ1Vdan0NX8QMMiWgGLB_JqBW46oJcIUL5s7LuGwyppUKmKT3wv0jxb0GeAQYvP1FdcCZRtcaRRTLKSdRO6i7qbocujq5pOP24ZXsCxBrBWwm3EuN7ruo1ZteTSB7yl4iSw7uCfPOLhNEF284GAqYCmFyfMCZA00B4ef8-67URfiKEhhAW0IhGz5gurRzo/http%3A%2F%2Fverisigninc.com%2F>> > > > > *From: *Jasdip Singh <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > *Date: *Monday, July 13, 2026 at 12:21 PM > *To: *James Gould <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>, "[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>" <[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>, > "[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>" > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>, > "[email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>" <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[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] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > *Date: *Monday, July 13, 2026 at 8:40 AM > *To: *Jasdip Singh <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>; [email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>; > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>; > [email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[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://secure-web.cisco.com/1KQFirzvrqw1WgHyfOFUONZSKgCNpWmy2qS-6WKKAybvbLqTHL4mTruuB4Fv2-ilvZhxkyb6vUFjxjvtE2QOC31w4Cvz51xXzFgXRVcdcPOe4OfU-E6Y2OX0oTAScMAVR1tRvd9h1yyIu93ZhbWTU1V2WZMcbvQ1Ea0ob5wh5M14frboUbyjPyZDMzuIk0QRFHHvWGWoYdRyQB3HSwbhHCkXnStV7B_UaKwbc_P0V8NVIJJNvtYHm-sQuO4EwL75MXtPQxGhOYC6kWuFIhpE5tnhjSlxbXO9R0JPOLIhch9w/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7480%23autoid-15 > > <https://secure-web.cisco.com/1KQFirzvrqw1WgHyfOFUONZSKgCNpWmy2qS-6WKKAybvbLqTHL4mTruuB4Fv2-ilvZhxkyb6vUFjxjvtE2QOC31w4Cvz51xXzFgXRVcdcPOe4OfU-E6Y2OX0oTAScMAVR1tRvd9h1yyIu93ZhbWTU1V2WZMcbvQ1Ea0ob5wh5M14frboUbyjPyZDMzuIk0QRFHHvWGWoYdRyQB3HSwbhHCkXnStV7B_UaKwbc_P0V8NVIJJNvtYHm-sQuO4EwL75MXtPQxGhOYC6kWuFIhpE5tnhjSlxbXO9R0JPOLIhch9w/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7480%23autoid-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> > > <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://secure-web.cisco.com/1UsFXBp-FsS1U0RWJxXd__xXCO0p_Ag4rZWsfO-jQ0tJifzUfPo2frK18p1_YTbiMGA6X7sN8fd7sG7pm4ZEd_oEbG2xc_IFF2PYXEpPP5nu-RpObrr5BfRPsVZi_ryhxrrhyqQGFJt_puBbD6ZnRlAM3keeQxUmfsOF2PDd8hHdZnyweKqqoRMD8RdAEQKe1hMpfLsMFmW1kv1hUSfUPHQfUYeqnhGq8dy488tRXE7GYjI8obgxg3kYwFgxvYSRApOK-hydz093DG1ubVjrciTaGHkUI0iz4x-RufYEn3q8/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-extensions-14.html%23name-summary-of-updates > > <https://secure-web.cisco.com/1UsFXBp-FsS1U0RWJxXd__xXCO0p_Ag4rZWsfO-jQ0tJifzUfPo2frK18p1_YTbiMGA6X7sN8fd7sG7pm4ZEd_oEbG2xc_IFF2PYXEpPP5nu-RpObrr5BfRPsVZi_ryhxrrhyqQGFJt_puBbD6ZnRlAM3keeQxUmfsOF2PDd8hHdZnyweKqqoRMD8RdAEQKe1hMpfLsMFmW1kv1hUSfUPHQfUYeqnhGq8dy488tRXE7GYjI8obgxg3kYwFgxvYSRApOK-hydz093DG1ubVjrciTaGHkUI0iz4x-RufYEn3q8/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-extensions-14.html%23name-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> > > <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] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > *Date: *Saturday, July 11, 2026 at 2:02 PM > *To: *James Gould <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>, "[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>" <[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>, > "[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>" > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>, > "[email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>" <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[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://secure-web.cisco.com/10gyNT87ZPY6-l8U62OdeEPzfbiqbe_L0PY9QchZCp5MRzwfF4WQpFZPTgp4RbdMzsPrjaBIqbIYIOSAxi1zx7xxofcoYEpMMRB3gaV-sTjBwOZM1FJ540UkJvLeoS5nzbxoGyy6EMe2dNiu2PfhrUE2FFHNqd2Hy6JajMvnY2mXRS1kNEu5CWWqUSfEpj6MkUpNqi_398cLwk-zqAXuYqWBUOY6AY6BbmYgTEzH4-bsvE_aoWjnA3aiJ-nWK0kge0okxgebmpu2uG4W12OBWuzv7cXa78DoVEA7gep-hUzc/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%2Fversioning.example%3Fversioning%3Dpoint_ext1-0.1 > > <https://secure-web.cisco.com/10gyNT87ZPY6-l8U62OdeEPzfbiqbe_L0PY9QchZCp5MRzwfF4WQpFZPTgp4RbdMzsPrjaBIqbIYIOSAxi1zx7xxofcoYEpMMRB3gaV-sTjBwOZM1FJ540UkJvLeoS5nzbxoGyy6EMe2dNiu2PfhrUE2FFHNqd2Hy6JajMvnY2mXRS1kNEu5CWWqUSfEpj6MkUpNqi_398cLwk-zqAXuYqWBUOY6AY6BbmYgTEzH4-bsvE_aoWjnA3aiJ-nWK0kge0okxgebmpu2uG4W12OBWuzv7cXa78DoVEA7gep-hUzc/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%2Fversioning.example%3Fversioning%3Dpoint_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> > > <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://secure-web.cisco.com/10gyNT87ZPY6-l8U62OdeEPzfbiqbe_L0PY9QchZCp5MRzwfF4WQpFZPTgp4RbdMzsPrjaBIqbIYIOSAxi1zx7xxofcoYEpMMRB3gaV-sTjBwOZM1FJ540UkJvLeoS5nzbxoGyy6EMe2dNiu2PfhrUE2FFHNqd2Hy6JajMvnY2mXRS1kNEu5CWWqUSfEpj6MkUpNqi_398cLwk-zqAXuYqWBUOY6AY6BbmYgTEzH4-bsvE_aoWjnA3aiJ-nWK0kge0okxgebmpu2uG4W12OBWuzv7cXa78DoVEA7gep-hUzc/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%2Fversioning.example%3Fversioning%3Dpoint_ext1-0.1 > > <https://secure-web.cisco.com/10gyNT87ZPY6-l8U62OdeEPzfbiqbe_L0PY9QchZCp5MRzwfF4WQpFZPTgp4RbdMzsPrjaBIqbIYIOSAxi1zx7xxofcoYEpMMRB3gaV-sTjBwOZM1FJ540UkJvLeoS5nzbxoGyy6EMe2dNiu2PfhrUE2FFHNqd2Hy6JajMvnY2mXRS1kNEu5CWWqUSfEpj6MkUpNqi_398cLwk-zqAXuYqWBUOY6AY6BbmYgTEzH4-bsvE_aoWjnA3aiJ-nWK0kge0okxgebmpu2uG4W12OBWuzv7cXa78DoVEA7gep-hUzc/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%2Fversioning.example%3Fversioning%3Dpoint_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> > > <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://secure-web.cisco.com/1DwV2bECptAxZu61msNyTBlkltN6KGC9byCgWDG3tbOhjgpuv7Et7HS_2f85K8tSYqznNzLrsGEw_OXGb2ix5Vnm7b7wP274kNH4nWYVTyy28OlrXiEnjakW-ce-s0nLMGYApA95BmD1CGLgDh6IkEtTbB7Ja_ALNmrCOy3RVCPnw62nqJbJsTzflDvV4FUxhOViqYrwlupEHhQ2l6PAE6g2y3zXRX-S5rzLSp9-lESgztrj6i3z7kGyWT2B33zSQsy0j07NgugdQglUvxawbsNME1kRKxZen4Rtq0fgR9hY/https%3A%2F%2Fmnot.net%2Fblog%2F2011%2Fweb_api_versioning_smackdown > > <https://secure-web.cisco.com/1DwV2bECptAxZu61msNyTBlkltN6KGC9byCgWDG3tbOhjgpuv7Et7HS_2f85K8tSYqznNzLrsGEw_OXGb2ix5Vnm7b7wP274kNH4nWYVTyy28OlrXiEnjakW-ce-s0nLMGYApA95BmD1CGLgDh6IkEtTbB7Ja_ALNmrCOy3RVCPnw62nqJbJsTzflDvV4FUxhOViqYrwlupEHhQ2l6PAE6g2y3zXRX-S5rzLSp9-lESgztrj6i3z7kGyWT2B33zSQsy0j07NgugdQglUvxawbsNME1kRKxZen4Rtq0fgR9hY/https%3A%2F%2Fmnot.net%2Fblog%2F2011%2Fweb_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> > > <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://secure-web.cisco.com/10gyNT87ZPY6-l8U62OdeEPzfbiqbe_L0PY9QchZCp5MRzwfF4WQpFZPTgp4RbdMzsPrjaBIqbIYIOSAxi1zx7xxofcoYEpMMRB3gaV-sTjBwOZM1FJ540UkJvLeoS5nzbxoGyy6EMe2dNiu2PfhrUE2FFHNqd2Hy6JajMvnY2mXRS1kNEu5CWWqUSfEpj6MkUpNqi_398cLwk-zqAXuYqWBUOY6AY6BbmYgTEzH4-bsvE_aoWjnA3aiJ-nWK0kge0okxgebmpu2uG4W12OBWuzv7cXa78DoVEA7gep-hUzc/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%2Fversioning.example%3Fversioning%3Dpoint_ext1-0.1 > > <https://secure-web.cisco.com/10gyNT87ZPY6-l8U62OdeEPzfbiqbe_L0PY9QchZCp5MRzwfF4WQpFZPTgp4RbdMzsPrjaBIqbIYIOSAxi1zx7xxofcoYEpMMRB3gaV-sTjBwOZM1FJ540UkJvLeoS5nzbxoGyy6EMe2dNiu2PfhrUE2FFHNqd2Hy6JajMvnY2mXRS1kNEu5CWWqUSfEpj6MkUpNqi_398cLwk-zqAXuYqWBUOY6AY6BbmYgTEzH4-bsvE_aoWjnA3aiJ-nWK0kge0okxgebmpu2uG4W12OBWuzv7cXa78DoVEA7gep-hUzc/https%3A%2F%2Fexample.com%2Frdap%2Fdomain%2Fversioning.example%3Fversioning%3Dpoint_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> > > <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://secure-web.cisco.com/1T734krLzCBLcUoMOnfir4Qvp4ARl_Sn2cuRrtbQgQW0UnjOjmvf7UDBJPYm7fdcnbXRQJ0nYufKoe3cM5TRv9Zm-NoyCbZMi-4iX5VWH43_sFN_geDbfaR2Kmak3LbB1Oy14FI6AxVOP645-CAfHm-_wH0O4z-9XQB0_9OOODlXf7CxSVvfVlvLl8LvI76QGuuxHGVirsMJCi6hyVb_Ay8K4A8GLuByBr03fKbvPiT5ULNCS4QM9SfoghrXHHKByRcG5WbvQdFNIamHM_jP5GEpYuIWsdoQvaRtU7DYOWe4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc1958%23autoid-3 > > <https://secure-web.cisco.com/1T734krLzCBLcUoMOnfir4Qvp4ARl_Sn2cuRrtbQgQW0UnjOjmvf7UDBJPYm7fdcnbXRQJ0nYufKoe3cM5TRv9Zm-NoyCbZMi-4iX5VWH43_sFN_geDbfaR2Kmak3LbB1Oy14FI6AxVOP645-CAfHm-_wH0O4z-9XQB0_9OOODlXf7CxSVvfVlvLl8LvI76QGuuxHGVirsMJCi6hyVb_Ay8K4A8GLuByBr03fKbvPiT5ULNCS4QM9SfoghrXHHKByRcG5WbvQdFNIamHM_jP5GEpYuIWsdoQvaRtU7DYOWe4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc1958%23autoid-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> > > <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://secure-web.cisco.com/1DwV2bECptAxZu61msNyTBlkltN6KGC9byCgWDG3tbOhjgpuv7Et7HS_2f85K8tSYqznNzLrsGEw_OXGb2ix5Vnm7b7wP274kNH4nWYVTyy28OlrXiEnjakW-ce-s0nLMGYApA95BmD1CGLgDh6IkEtTbB7Ja_ALNmrCOy3RVCPnw62nqJbJsTzflDvV4FUxhOViqYrwlupEHhQ2l6PAE6g2y3zXRX-S5rzLSp9-lESgztrj6i3z7kGyWT2B33zSQsy0j07NgugdQglUvxawbsNME1kRKxZen4Rtq0fgR9hY/https%3A%2F%2Fmnot.net%2Fblog%2F2011%2Fweb_api_versioning_smackdown > > <https://secure-web.cisco.com/1DwV2bECptAxZu61msNyTBlkltN6KGC9byCgWDG3tbOhjgpuv7Et7HS_2f85K8tSYqznNzLrsGEw_OXGb2ix5Vnm7b7wP274kNH4nWYVTyy28OlrXiEnjakW-ce-s0nLMGYApA95BmD1CGLgDh6IkEtTbB7Ja_ALNmrCOy3RVCPnw62nqJbJsTzflDvV4FUxhOViqYrwlupEHhQ2l6PAE6g2y3zXRX-S5rzLSp9-lESgztrj6i3z7kGyWT2B33zSQsy0j07NgugdQglUvxawbsNME1kRKxZen4Rtq0fgR9hY/https%3A%2F%2Fmnot.net%2Fblog%2F2011%2Fweb_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> > > <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://secure-web.cisco.com/1hG-_U5Kcktq8KHg7xlT5hRXfv9ATQ1C9GhXUI-5m6roQfVgvzzftVLQR5tnG6Z034KONjf5MVHZ96VtG0ldySE7kxSFtqhtsX3ngPiCR7MOr4rb5zx2c1hwapdKSZjWQQEAv_5BCwYAiJGZEsMBQ2-S42ZuK_PsJDGyF0WRVGMW7fkElK4xejJ5H-21qBBQ9HBWzqqvXyJ_g8EupCAE9gABGXCMs3sAFWXrnuN7bpamkxFCRX4DYpbzSPi6xJAHao6IOX0Gi8Gu6xdAEWQr6hC2ZiuD1OGqIxb8owpvFd00/https%3A%2F%2Fmnot.net%2Fblog%2F2012%2Fapi-evolution > > <https://secure-web.cisco.com/1hG-_U5Kcktq8KHg7xlT5hRXfv9ATQ1C9GhXUI-5m6roQfVgvzzftVLQR5tnG6Z034KONjf5MVHZ96VtG0ldySE7kxSFtqhtsX3ngPiCR7MOr4rb5zx2c1hwapdKSZjWQQEAv_5BCwYAiJGZEsMBQ2-S42ZuK_PsJDGyF0WRVGMW7fkElK4xejJ5H-21qBBQ9HBWzqqvXyJ_g8EupCAE9gABGXCMs3sAFWXrnuN7bpamkxFCRX4DYpbzSPi6xJAHao6IOX0Gi8Gu6xdAEWQr6hC2ZiuD1OGqIxb8owpvFd00/https%3A%2F%2Fmnot.net%2Fblog%2F2012%2Fapi-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> > > <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]
