Hi Jim, On 10.12.25 17:41, Gould, James wrote:
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?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?
I agree fully that 5.4.4 in the current proposed text is not helpful. See my other email on this.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.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
