Speaking personally, I would agree. Jim
On 2 Aug 2022, at 11:51, Gould, James wrote: > Jim, > > For #1, I just want to ensure that " the RDAP protocol and RDAP Extensions > Registry do not directly support versioning of extensions" does not prohibit > the registration of versioned profile extension identifiers, since > "icann_rdap_response_profile_1" and " > icann_rdap_technical_implementation_guide_1" will need to be registered in > the future. The quick answer sounds to be no, so there is no risk of > rejecting the inclusion of "versioning" or "visual versioning" in an > extension identifier. Is that correct? > > -- > > 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 8/2/22, 10:12 AM, "James Galvin" <[email protected]> wrote: > > > On 2 Aug 2022, at 8:16, Gould, James wrote: > > > Jim, > > > > I support the chair's proposal with two comments that I communicated at > the REGEXT meeting during IETF114: > > > > 1. Registration of versioned policy (profile) identifiers will continue > to be allowed in the RDAP Extensions Registry, such as > "icann_rdap_response_profile_0" and " > icann_rdap_technical_implementation_guide_0". > > As a personal observation, I characterize this as “visual versioning”. > If you add a digit(s) to the end of a name then a user looking at it might > interpret it as a version. However, the extension registry would require > each individual identifier to be registered. > > On the other hand, there’s nothing that prevents an extension itself from > defining for itself how it wants to support versioning. This could get > tricky but it’s all doable and allowed, if you really think you need to go in > this direction. > > > > 2. There is the need to address extension versioning in the RDAP > protocol in the future. > > Speaking as a co-Chair, thanks for this. > > Jim > > > > > > 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://secure-web.cisco.com/1m04PmR9XEF1-za7UCKjWju29Q0X4ZlV36kgtkNy_9nrtrfCydLnDDElSTe_CiUylnFPzqFFEwm1yFvZGO0hNmhVs9jKbX_B2vRDmmgL0R-3Ssr7uj0yWSVVHl0GOhhucR_USzgvCu_qDlsJuljoobyjz7DFRUznl0CKPN6ld79cLmPkC4aZYh0-d3QRrvUy-K2MoTcm9quvVB9ky6ogN0p5XWoRarn4I0oXOyeBhZa129i76o8YRGI1U_T1CAMPk/http%3A%2F%2Fverisigninc.com%2F> > > > > On 8/1/22, 9:49 AM, "regext on behalf of James Galvin" > <[email protected] on behalf of [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. > > > > As everyone knows there has been quite some discussion on the > mailing list regarding how to implement rdapConformance. This was a > significant topic of discussion at the REGEXT meeting during IETF114. > > > > Three options were proposed on the mailing list and unfortunately > the Chairs do not believe there was a consensus on the mailing list as to how > to proceed. So, the Chairs developed a proposal for how to proceed and > presented that at the IETF114 meeting. > > > > Since all decision must be made on the mailing list, the purpose of > this message is to state the proposal and ask for support or objections, > similar to how we handle WGLC for documents. Please indicate your support by > replying to this message with a “+1” or explaining any objection you have. > > > > This CONSENSUS CALL will close in two weeks on 15 August 2022 at > close of business everywhere. > > > > This proposal had consensus during the IETF114 meeting and is > summarized as follows. > > > > 1. Given that both RFC7480 and RFC9083 are Internet Standards, the > bar for changes is quite high. > > > > 2. There is a generally accepted consensus for how rdapConformance > is to be used and it is widely deployed today. > > > > 3. Although any one of the three options could be a reasonable > choice, none of them has a broad consensus sufficient to justify changing the > Standard. > > > > 4. The proposal has two parts as follows: > > > > A. Accept that the RDAP protocol and RDAP Extensions Registry do > not directly support versioning of extensions and that both support unique > extension identifiers. > > > > B. Submit Errata to the appropriate RFC in STD95 to harmonize the > example usage of the extension identifiers “lunarNIC” and “lunarNIC_level_0” > to improve clarity on the uniqueness of identifiers. > > > > For additional details working group members are referred to the > slides used by the Chairs during the discussion and recording of the meeting: > > > > SLIDES: > https://secure-web.cisco.com/1lkpF6JHJoUQTmTLz50xTJYofDKJHZalBpkq8fBs57Fp-iIEyMfqRcvwWrL2KpWEP4CCXvsQevy-VDMepiVjghkRpAiKAH9zQPLHZaFjdwjE0R5YAzrQ2CN3Rwm5Bv1eQ_8yV47WFLmW5FVewqKZXOg6XiuD0f7YltIW8-XIkID-gXhEswQCLu7Lz73ec2KHhMdouEhINYZ51cqY21u4-5VULvCWKtn2oBVgHB_wklnye293K-f-KKoQf0yblvFoO/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fslides-114-regext-rdap-extension-identifier-and-rdapconformance%2F > > > > RECORDING: > https://secure-web.cisco.com/1Luzc6oRZhPnmff5v2BR0oDp_RV5XLdOqGaPh5FXetRm57Kd12ozJ2AkngZwdJj4tJX2WAzctukHcbF8elQ8FEFfphJNUIcGuJSINSFd6tXiNdcho375jyDIbh73pdXN5nUPLmEXV1oiOMNPeMs_0BY-hXkZizZhNYlu5qcxWBgSDh6GFOH5KjRow7YFAwb_n1IKwKW_kwO1xrhyAmlxQj9SB_4Qj6lbQpocSVKzQRJTXEPF-cqpgW9-KDDGDMogc/https%3A%2F%2Fwww.meetecho.com%2Fietf114%2Frecordings%23REGEXT > > > > Thanks, > > > > Antoin and Jim > > > > _______________________________________________ > > regext mailing list > > [email protected] > > > https://secure-web.cisco.com/1htlQDwcCta04FTDcDRpbSyA_Yn6KqmoK-BVaOTiv9Ij6SgPdRFFdBmTodbZ87uKykaQ6aLFOvrata5DYpsXO7WcyKQnDsInJA_UITGbPyAIQ77Q6jJQJuEqJqtizIvhTVUSum-hh58yMxE8y-F183olkdUA-2q3O003lpGIK72MwcoQlos9iOpiWgK7RupM1p9nWYx69Lvmifs3YUTox99u6OyGAJaTvUmsyM9j9tfEO9g15XRiCDEugaTPYmltq/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
