Andy, You are correct, thank you. As stated in my response to Pawel, I don't have any major issues with section 5.4.1 except for it stating the obvious, section 5.4.2 describes a bad practice that we should not encourage, section 5.4.3 is something that we may want to look to address for Opaque versioning signaling in the versioning extension draft, and section 5.4.4 runs into issues for draft extensions without a dependency on the versioning extension draft.
-- 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/11/25, 4:43 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, Inline... On 12/10/25 11:41 AM, Gould, James wrote: > Section 5.4.4 "Evolving Extensions without Signaling Changes" > > This section is pretty much saying that draft-ietf-reget-rdap-versioning MUST > NOT be implemented by combining paragraph 1 and the last paragraph, which is > something that I don't support. The extension signaling of the > rdapComformance is coarse grained and doesn't contain any explicit version, > as stated in Section 5.4. Implementing a more advanced form of versioning > (e.g., semantic) with signaling is supported in > draft-ietf-reget-rdap-versioning that can be leveraged by an extension. The > extension developer can decide to use opaque versioning or semantic > versioning based on draft-ietf-reget-rdap-versioning. It's not the role of > draft-ietf-regext-rdap-extensions to disallow implementing a more advanced > form of versioning via draft-ietf-reget-rdap-versioning. Quite the opposite. It says, or atleast intends to say, that an extension MUST NOT be evolved without a signaling mechanism such as rdap-versioning. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
