Scott, Let’s dig a little deeper on this approach. I have some follow-up questions embedded below.
-- 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: Scott Hollenbeck <[email protected]> Organization: SAHollenbeck LLC Date: Monday, July 13, 2026 at 5:22 PM To: James Gould <[email protected]>, "[email protected]" <[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. From: Gould, James <[email protected]> Sent: Monday, July 13, 2026 4:08 PM To: [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 Scott, Ok, let’s get a concrete example to see how this would work in a fictitious example of the “fictitious” extension: 1. A server decides to implement the “fictitious” RDAP extension first as a proprietary extension with the specifications fictitious-0.0.pdf and with an update with fictitious-0.1.pdf. * Would the extension identifier be something like “providerFictitious00” and “providerFictitious01” since they are not IETF drafts yet? [SAH] They could be draftProviderFicticious00 and draftProviderFicticious01. [JG1] A proprietary extension would use the “draft” reserved prefix? How about support for providers to register their own prefixes, in a similar fashion to the EPP repository identifiers in https://www.iana.org/assignments/epp-repository-ids/epp-repository-ids.xhtml? 1. A server then decides to create a standard for the “fictitious” RDAP extension for “providerFictitious01” as an individual IETF draft with the name draft-author-regext-fictitious-00. * Would the extension identifier be something like “draftFictitious00”? [SAH] No, it could become something like draftAuthorRegextFicticious00. Each specification gets a unique identifier. [JG1] Ok, so the author or author(s) would be added to the prefix for an individual draft. So, the mapping is to convert what could be called “dash case” of the IETF draft to camel case for the extension identifier, which is what you did by converting draft-author-regext-fictitious-00 to draftAuthorRegextFicticious00. 1. What happens when the “fictitious” RDAP extension does a ping update or a bit update and it gets updated to draft-author-regext-fictitious-01? * Does the extension identifier get bumped to “draftFictitious01”? [SAH] Yes, it could be bumped to draftAuthorRegextFicticious01. Right, so the draft to extension mapping stays aligned even though there is no was no interface of the extension. All server implements and subsequently client implements would be locked to the draft version independent of interface changes and whether or not the change is breaking. 1. The “fictitious” RDAP extension becomes a REGEXT working group document with the name draft-ietf-regext-fictitious-00, but with no other changes. * Would the extension identifier go back to “draftFictitious00” or is there some separate value to reflect it has become a working group document, such as “draftRegextFictitious00”? [SAH] It could become draftIETFRegextFicticious00. [JG1] If you stick with the “dash case” to “camel case” conversion, shouldn’t it be “draftIetfRegextFicticious00”? 1. If the working group draft has 10 draft updates, does that result in 10 unique extension identifiers “draftRegextFictitious00” to “draftRegextFictitious10”)? [SAH] Yes, but your example would actually require 11 identifiers (0-10 -> 11 digits). [JG1] Right, there would be 11 extensions (OBO error) following the “dash case” to “camel case” conversion of “draftIetfRegextFicticious00” to “draftIetfRegextFicticious10”. 1. What is the final extension identifier set to in the IANA considerations section when the draft gets past WGLC? * Does it become “fictitious1”? [SAH] Yes, it could. So, the IANA considerations registration would be independent of the extension identifiers used during development of the extension. It would be good for the extension draft to explicitly identify the extension identifier type used during the development and for the versioning extension to reference the supported type. Do you have a better name than “Embedded Versioning”, since this is a type of versioning that would need to be formally defined. The versioning extension can support the relationship of the supported extensions (e.g., “draftProviderFicticious01” is a predecessor to “draftAuthorRegextFicticious01”, which is predecessor of “draftRegextFictitious05”, which is a predecessor of the final “fictitious1”). This is a different type of extension versioning to opaque versioning and point versioning since the extension identifier does include a predefined versioning scheme, but it’s embedded into the extension identifier instead of being an extension to the extension identifier. Every change to the extension would be considered a breaking change since it would change the extension prefix.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
