My prior feedback at https://mailarchive.ietf.org/arch/msg/regext/-R3YfbuEUyhLIiSSJkUn3Nll9dw/ and https://mailarchive.ietf.org/arch/msg/regext/3JU1wZKk4JrcuBSWn9xkVDOpUT4/ that the content in the sub-sections of section 5.4 as being out-of-scope for draft-ietf-regext-rdap-extensions. Section 5.4 starts by saying that there is no explicit version beyond the extension identifiers (opaque versioning) with a reference to draft-ietf-reget-rdap-versioning, which is as far as draft-ietf-regext-rdap-extensions needs to take it. I will request again for the sub-sections of Section 5.4 to be removed from draft-ietf-regext-rdap-extensions and move the discussion of versioning to draft-ietf-reget-rdap-versioning.
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 12/10/25, 2:02 AM, "Pawel Kowalik" <[email protected] <mailto:[email protected]>> wrote: Hi Andy, I don't think it is a good proposal as it is limiting evolution of extensions too much in the area, where rfc9083 is very explicit about that it is intended to be allowed even with a mention that this method may be used to evolve rfc9083 itself. A given example of new object classes does not resonate to me as a problem, as they will appear under own path segments which won't be a problem for clients not knowing or using them. Extensions draft may at most recommend usage of version signalling facilities, such as ietf-regext-rdap-versioning, but as long as it remains to be an extension and not an update to STD 95 we need to always consider clients which do not implement or understand it. Those clients must be able to work seamlessly (not break at least) also without signalling like ietf-regext-rdap-versioning. Therefore the extensions draft must mandate extensions authors to take care that clients do not break when adding non-braking changes (such as adding JSON fields) and recommend using common signalling facilities (such as ietf-regext-rdap-versioning) for minor version update signalling and/or negotiation. Last but not least, the extension itself may define its own versioning schema and signalling mechanism. Sometimes it may be derived from an existing specification (JSContact for example has own versioning schema). Finally, even an existence of a new field may be considered as signalling, that an aware client may use, so the text in current form is barely enforceable. Kind Regards, Pawel On 04.12.25 21:25, Andy Newton wrote: > Hi all, > > As mentioned at IETF 124, this version updates section 5 based on the > conversations at the IETF and on the mailing list prior. > > I would like to draw your attention to section 5.4. The author team > believes > evolving extensions in that manner should be forbidden, but that's > more of > a proposal. If others have thoughts, please share. > > -andy > > On 04-12-2025 2:40 PM, [email protected] > <mailto:[email protected]> wrote: >> Internet-Draft draft-ietf-regext-rdap-extensions-09.txt is now >> available. It >> is a work item of the Registration Protocols Extensions (REGEXT) WG >> of the >> IETF. >> >> Title: RDAP Extensions >> Authors: Andy Newton >> Jasdip Singh >> Tom Harrison >> Name: draft-ietf-regext-rdap-extensions-09.txt >> Pages: 28 >> Dates: 2025-12-04 >> >> Abstract: >> >> This document describes and clarifies the usage of extensions in >> RDAP. >> >> The IETF datatracker status page for this Internet-Draft is: >> https://secure-web.cisco.com/1aIbuZUeq3I-QdM6GzdLSIxektNB_TdHDA7o3Bf4jPdNs5K8qawqPKRlm2C2Hd4-erbXIqfrn_MIq_La9XhLcS-zHHkyx3T7WxV25A9MB1jiSlUEj-0lIsPRG5k4hJFwzizcTKgFAPIpKG8VgBbBF-dGwUkRttR2-1Im0tFXzbqfGFhEMDt7B1BaxJIfZldtZw7RXubYIozbuAFlLqlE_w_lDluudU7rCbGudYl0Ryh5Jaj4mSvOxWBY-S5Ce8CFmQWDS-8Fmeq15s5Z3bJ71NH-wMS3hQZl4K-LJbHcF2Mg/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-extensions%2F >> >> <https://secure-web.cisco.com/1aIbuZUeq3I-QdM6GzdLSIxektNB_TdHDA7o3Bf4jPdNs5K8qawqPKRlm2C2Hd4-erbXIqfrn_MIq_La9XhLcS-zHHkyx3T7WxV25A9MB1jiSlUEj-0lIsPRG5k4hJFwzizcTKgFAPIpKG8VgBbBF-dGwUkRttR2-1Im0tFXzbqfGFhEMDt7B1BaxJIfZldtZw7RXubYIozbuAFlLqlE_w_lDluudU7rCbGudYl0Ryh5Jaj4mSvOxWBY-S5Ce8CFmQWDS-8Fmeq15s5Z3bJ71NH-wMS3hQZl4K-LJbHcF2Mg/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-extensions%2F> >> >> There is also an HTML version available at: >> https://secure-web.cisco.com/18KqwprTtwutkJajeC815l3SK66Uh003aCr4NxvN27qyN7sv7Ch26vsnbebNjKdBKmDNMBPRvWPdKL1gArmpnlLszR9doWbfX_MsSp6u8PvZmEgoqXDCdXAnH8y4beOifTm0_i55XzQvkNOrwJECiqwoWwMbhK0TjTGU6K1sf8e1gvG6s_kelON23t48qaTmfpBPOa0Uf3iMux6pQw8UK8WnRcyn0i4lqTq3DvUH98C4GkTNGvQLceove0LD8hE25hMlN7oNaOFHIRYFA02u_FyzQZVmKYyU-XZ8xgzrKmqY/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-extensions-09.html >> >> <https://secure-web.cisco.com/18KqwprTtwutkJajeC815l3SK66Uh003aCr4NxvN27qyN7sv7Ch26vsnbebNjKdBKmDNMBPRvWPdKL1gArmpnlLszR9doWbfX_MsSp6u8PvZmEgoqXDCdXAnH8y4beOifTm0_i55XzQvkNOrwJECiqwoWwMbhK0TjTGU6K1sf8e1gvG6s_kelON23t48qaTmfpBPOa0Uf3iMux6pQw8UK8WnRcyn0i4lqTq3DvUH98C4GkTNGvQLceove0LD8hE25hMlN7oNaOFHIRYFA02u_FyzQZVmKYyU-XZ8xgzrKmqY/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-extensions-09.html> >> >> >> >> A diff from the previous version is available at: >> https://secure-web.cisco.com/1vxv-BSOdZZ0PWNEXryWhKPBFtPWAbN-kjODJRyUISdQ9cAa9Slbk8EfeWI77q6GIzSZRUyyzYVUK5RThwwS_dG2QkcjDkaaCxWKRkXH3HpNVRfqxGet0BuTCLWumNMSADsa8sSi9Uu9bV5MXJoPCYi_4uGhrR1RuaWxiFnqVhsR1myrQYoZOd0hFL8ytIUxlzeX_090ZCabQXgHCSGP-vsVGqkl2hySgcg0tOwZ1mK6cuFl67nBTh2TzVRKIZbBVujScaWXiPN0kGdwsbi2fH1CmAis0R--kzTPbPpsGg6g/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-regext-rdap-extensions-09 >> >> <https://secure-web.cisco.com/1vxv-BSOdZZ0PWNEXryWhKPBFtPWAbN-kjODJRyUISdQ9cAa9Slbk8EfeWI77q6GIzSZRUyyzYVUK5RThwwS_dG2QkcjDkaaCxWKRkXH3HpNVRfqxGet0BuTCLWumNMSADsa8sSi9Uu9bV5MXJoPCYi_4uGhrR1RuaWxiFnqVhsR1myrQYoZOd0hFL8ytIUxlzeX_090ZCabQXgHCSGP-vsVGqkl2hySgcg0tOwZ1mK6cuFl67nBTh2TzVRKIZbBVujScaWXiPN0kGdwsbi2fH1CmAis0R--kzTPbPpsGg6g/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-regext-rdap-extensions-09> >> >> >> >> Internet-Drafts are also available by rsync at: >> rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> regext mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > > _______________________________________________ > 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]
