Hi Pawel, From: Pawel Kowalik <[email protected]> Date: Friday, December 12, 2025 at 3:59 AM To: Andy Newton <[email protected]>, [email protected] <[email protected]> Subject: [regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-09.txt
On 11.12.25 22:02, Andy Newton wrote: Just to be clear, are you suggesting evolving an extension without an evolution signal should be allowed? In other words, not MUST NOT and not NOT RECOMMENDED? Yes, not MUST NOT and not NOT RECOMMENDED. But RECOMMEND using versioning extension and MUST assure clients do not break, whatever it means if not yet enough specified in STD 95. [JS] To your "assure clients do not break, whatever it means” point, would it help to clarify that in the draft? From a client’s perspective, changes injected into an existing extension (without a successor extension) could fall into: Breaking: new object class, referral with different semantics from another extension, altered JSON member value syntax, new required JSON member, new required query parameter Non-breaking: new JSON member, new query path, new query parameter, new HTTP header Does this change categorization look reasonable? Jasdip
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
