Pawel, Sorry for the delay in my response.
> Yes, these 3 sections are maybe stating the obvious, but a lot of the > aspects do not seem to be that obvious even to people as deeply involved > in RDAP, as members of this WG. For me there is a clear value in giving > guidance and structure to extension authors as long as the text is not > telling anything false or promoting dangerous patterns. We may argue if > "Overlapping Successors" is a valid pattern or not, but it as long as it > is not breaking interoperability where is the problem? The problem is that even though these sub-sections contain no normative language, I don't want new extensions that don't follow the considerations or that include a case not covered by a consideration to be considered non-conformant. It's very difficult to consider the design needs of future extensions if there are not predefined extension points with normative language in the base protocol. It's best to clarify what is supported in the base protocol and stay away from projecting guidance on future extension designs in draft-ietf-regext-rdap-extensions. Of the sections, I have no real issue with section 5.4.1 other than it stating the obvious. The overlapping concept of section 5.4.2 has never come up, and I view as a bad practice that should not be encouraged. For section 5.4.3, the versioning extension should be referenced for the signaling and we may want to add additional meta-data in the versioning extension for opaque versioning related to backward compatibility or breaking changes. > I agree fully that 5.4.4 in the current proposed text is not helpful. > See my other email on this. Andy is correct that the versioning extension is not included in the MUST NOT, since it's included in the "without" clause of the sentence, but one of my concerns is how we evolve draft versions of an extension that uses Opaque versioning. Does draft-ietf-regext-rdap-extensions only apply to RFCs, or does it also apply to extension drafts? The versioning extension does support signaling for draft extensions. If section 5.4.4 applies to all extensions (draft and RFC), then it poses an issue to draft extensions without adding a dependency to the versioning extension to provide the required signaling. -- 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, 3:20 AM, "Pawel Kowalik" <[email protected] <mailto:[email protected]>> wrote: Hi Jim, On 10.12.25 17:41, Gould, James wrote: > 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? Yes, these 3 sections are maybe stating the obvious, but a lot of the aspects do not seem to be that obvious even to people as deeply involved in RDAP, as members of this WG. For me there is a clear value in giving guidance and structure to extension authors as long as the text is not telling anything false or promoting dangerous patterns. We may argue if "Overlapping Successors" is a valid pattern or not, but it as long as it is not breaking interoperability where is the problem? > 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. > I agree fully that 5.4.4 in the current proposed text is not helpful. See my other email on this. Kind Regards, Pawel _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
