On 6/9/26 3:07 PM, Gould, James wrote: > Andy, > > I believe we first need to define changes in RDAP are material and may > trigger a change to the Extension Identifier or bumping the point versioning > value. Some options to consider below: > > 1. Is adding any new query features (e.g., path segment, query parameter, > media type parameter) material? > 2. Is removing query features (e.g., path segment, query parameter, media > type parameter) material? > 3. Is renaming query features (e.g., path segment, query parameter, media > type parameter), which equates to a remove and an add material? > 4. Is adding any new JSON members material? > 5. Is removing any JSON members material? > 6. Is renaming JSON members material?
I don't know what you mean by "material". However, if you are talking about breaking vs non-breaking changes (or compatibility between versions), this working group did discuss that topic in much detail. The current outcome is here: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-12#name-extension-versioning > > We have historically kept the Extension Identifier ("exampleExt0" or > "exampleExt1") static through the draft development process, independent of > the interface changes. Except not always. There are two documents currently in-progress right now that have changed their identifiers, one did it twice. > The only RDAP extensions that registered new Extension Identifiers has been > the Profile Extension Identifiers (icann_rdap_response_profile_0 and > icann_rdap_technical_implementation_guide_0 to icann_rdap_response_profile_1 > and icann_rdap_technical_implementation_guide_1, respectively). Isn't this an argument against a complicated versioning scheme? If the only extensions to ever be versioned are profiles which did not actually change any part of the protocol, then it would seem the existing opaque versioning is good enough, and complicated schemes are not necessary. > > We really don't know what would break a client, where should they expect all > the data members to be present, will they expect all the query features to > work? Yes we do. See above. -andy, no hats _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
