Pawel, My understanding of the goal of draft-ietf-regext-rdap-extensions is to provide clarification of the language in the base RFCs and not to define new extension functionality that is best suited for an extension, such as draft-ietf-reget-rdap-versioning for versioning. Extensions can have dependencies on other extensions, as is the case for draft-ietf-reget-rdap-versioning and draft-ietf-regext-rdap-x-media-type, and what can be the case for extensions that use semantic (or renamed to point) versioning in draft-ietf-reget-rdap-versioning. I address each of the sub-sections of section 5.4 below. I believe these sub-sections need to be removed from draft-ietf-regext-rdap-extensions.
Section 5.4.1 "Non-overlapping Successors" This section is recommending that a successor extension be backward compatible with the predecessor extension. Backward compatibility is ideal, but I don't believe draft-ietf-regext-rdap-extensions needs to state the obvious. An example, of a successor extension could be to the redacted extension in RFC 9537, where the intent may be to remove backward compatibility by removing support for the JSONPath expressions. This section doesn't contain any normative language, but I wouldn't want draft-ietf-regext-rdap-extensions to somehow be interpreted as disallowing a successor extension from breaking backward compatibility of a predecessor extension. Section 5.4.2 "Overlapping Successors" I don't agree with the concept of intermingling of an extension successor with its predecessor via inheritance, where they should be independent with the relationships only based on meta-data. We have never seen this use case, and I would not provide guidance in draft-ietf-regext-rdap-extensions to support it. Section 5.4.3 "Breaking Changes in Successors" This section is defining what does not exist in RDAP, where there is no signaling in RDAP on breaking changes. The makeup of an extension, based on its extension identifier, is defined in its specification. I don't see any real guidance of value in this section, where the considerations are addressed by draft-ietf-reget-rdap-versioning. Should we add additional signaling meta-data to draft-ietf-reget-rdap-versioning for opaque versioning or in addition to the semantics included in the semantic versioning? 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. 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, 8:34 AM, "Pawel Kowalik" <[email protected] <mailto:[email protected]>> wrote: Hi Jim, Extensions draft shall be dealing with the extensibility of RDAP, even if draft-ietf-reget-rdap-versioning would not exist. From this perspective for me it now strikes a right balance by clarifying potential issues, misunderstanding or misconceptions by extension authors. draft-ietf-reget-rdap-versioning cannot cover for those issues as it would be an extension. Kind Regards, Pawel On 10.12.25 13:40, Gould, James wrote: > My prior feedback > athttps://mailarchive.ietf.org/arch/msg/regext/-R3YfbuEUyhLIiSSJkUn3Nll9dw/ > andhttps://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 _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
