Thanks Andy, this make a lot of sense. I added some other cases to the PR as comments.
Kind Regards, Pawel On 11.06.26 18:39, Andy Newton wrote:
Pawel, On 6/11/26 11:15 AM, Pawel Kowalik wrote:What I notice now is that draft-ietf-regext-rdap-extensions-12 is in fact referring to a breaking change without really defining it. Only 5.4.2. is specifying what is a non-breaking change, which may imply that anything else is breaking. This may be fine, as long as 5.4.1 would tell it explicitly.I think you have a good point. I have a PR open here to address things in -13 which now covers this: https://github.com/anewton1998/draft-regext-rdap-extensions/pull/84/changes The summary is to add this to the top of 5.4.1: A breaking change (also known as a backwards-incompatible change) occurs when a modification in a successor extension with respect to the predecessor extension causes clients conforming to the predecessor extension to malfunction, experience degradation of functionality, or fail to interoperate in some other manner. And then add this to the bottom: The following is a non-exhaustive list of other types of breaking changes: - Changing the data-type of a protocol element such as a JSON value or query parameter value (e.g., "hello": 1 to "hello": "world"); - Changing the name of an identifier; - Expanding the expected range to be found in a protocol element (e.g. 0 to 9 becomes 0 to 10); - Expanding the set of values to be found in a protocol element when not defined in an IANA registry; - Removing a required protocol element from a response; - Changing a required protocol element in a response to optional; and - Requiring new protocol elements in a request. If anything else comes to mind, let me know. -andy
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
