Andy, Thanks for guidance on how to provide the feedback.
We need to ensure that the draft-ietf-regext-rdap-extensions Extension Versioning section 5.4 is compatible with the features being considered in draft-ietf-regext-rdap-versioning and ensure that the approaches outlined have been fully reviewed and discussed on the mailing list. This should not be a challenge if draft-ietf-regext-rdap-extensions if it's focused on clarifying confusion in the base RFCs and not attempting to define new versioning concepts that is in scope of draft-ietf-regext-rdap-versioning. I have reviewed the sub-sections of section 5.4 in the past and provided feedback on the mailing list. I don't believe any material changes have been made, but I'll verify that with my re-review. 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 6/18/26, 8:45 AM, "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. Hi Mario and James, Any constructive and concrete discussion of the draft text is welcome. When doing so, please clearly quote the draft text and suggested changes. Using OLD and NEW text blocks is a common way for doing this in the IETF. You may also use the IDNITS tool to grab line numbers, which is very helpful. Alternatively, you can submit a PR in GitHub. That said, the issue you note below is NOT in the extensions draft. Finally, it very unfair to the author team and the working group for you to hold up this document based on your versioning draft. Since adoption, the versioning draft has radically changed, moving from semantic versioning to maturity versioning to point versioning and now a new theory called embedded versioning. It is a meandering, moving target with a lot of complexity. So that this does not spiral further, it would be best if the chairs stepped in now. -andy On 6/18/26 5:07 AM, Mario Loffredo wrote: > > Il 17/06/2026 19:22, Gould, James ha scritto: >> Andy, >> >> I'll do a fresh review of draft-ietf-regext-rdap-extensions-13 and provide >> feedback. I don't believe draft-ietf-regext-rdap-extensions is ready for >> WGLC until the versioning topic is fully addressed. >> >> Thanks, > > +1 > > I believe complete convergence between rdap-extensions, > rdap-x-media-type, and rdap-versioning is desirable. > > I'd like to point out the inconsistency that seems most glaring to me. > > Section 5.4 of rdap-extensions considers the case where an extension > might use a versioning method like that described by rdap-versioning. > > But section 2 of rdap-x-media-type requires that the ext_list parameter > can only include extension identifiers. > > This not only seems to me a clear inconsistence between the two > documents but eliminates the possibility that the versioning parameter > could be removed in order to make clients use only exts_list to signal > the desired extensions. > > > Best, > > Mario > >> _______________________________________________ regext mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
