Hi Mario, On Wed, May 25, 2022 at 08:21:45PM +0200, Mario Loffredo wrote: > I'm concerned about injecting the version information into > prefixes/identifiers as I see some drawbacks in dealing with non-breaking > changes, which hopefully should be the majority and usually don't require to > manage a deprecation process. > > For example, introducing a new property into a response extension would > result in returning the same information twice (e.g. the response field > "ext1_..." and response field "ext2_..." resulting from adding the new > property to "ext1_..") . > > To ensure interoperability, both the response fields should coexist for a > period time so that the RDAP server could manage the sunset and then the > deprecation of "ext1_..." as smoothly as possible. > > Furthermore, according to a largely used best practice in versioning REST > APIs, breaking changes should always result in a change to the major version > number while non-breaking changes, such as adding new endpoints or new > response parameters, do not require a change to the major version number. > > Unfortunately, injecting the version information into the > prefixes/identifiers means that every change would break the RDAP server and > would result in a change of the major version number !?!?
If you make a backwards-compatible change, like addition of a new field, I think one option is to update the existing specification document by noting that there is a new 'version' of the specification that uses the existing rdapConformance value (and prefixes, etc.) but also includes that new field. In the case where a single field is added, the presence or absence of that field is as good as an updated rdapConformance value for determining which 'version' of the specification is in use. If more complicated changes are introduced, the specification could add its own versioning field inside a custom element that it returns. (To avoid any doubt, I'm not advocating for this long-term, I'm just noting that it's possible to make backwards-compatible changes in accordance with a 'strict' reading of the current text without changing the names used throughout the extension.) -Tom _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
