Hi Mario, I have created a PR to hopefully address the issues you raised, and some of the other issues brought up on the list.
https://github.com/anewton1998/draft-regext-rdap-extensions/pull/87 -andy On 7/8/26 3:26 AM, Mario Loffredo wrote: > Hi Andy, > > Il 07/07/2026 21:45, Andy Newton ha scritto: >> Hi Mario, >> >> inline... >> >> On 7/7/26 6:42 AM, Mario Loffredo wrote: >>> Hi, >>> >>> Section 5.4 cites MNOT-VERSIONING and lists two general principles for >>> versioning RDAP extensions. I suggest adding a third principle that >>> captures the granularity aspect of the referenced guidance: >>> >>> * The impact of a change should be limited to the RDAP extension >>> feature, protocol element, or resource whose semantics are being >>> changed; unrelated features of the same RDAP extension should not be >>> versioned or replaced solely because of that change. >> Can this be reworded to "Changes should be kept to a minimum and to only the >> protocol elements necessary to affected the needed change." ? > > [ML] The first part of the sentence seems unnecessary to me because I assume > that any change to an extension is made with a purpose. > > The meaning of the second part isn't clear to me. > > If it means that the scope of a change ought to be limited only to the > affected extension components, then I agree. > > Otherwise, if it means that the scope of a change always affects the entire > extension, I disagree because it's impractical and not in line with REST API > management best practices. > > The part of my sentence after the semicolon clarified this point. > >>> AFAIU, MNOT-VERSIONING argues against applying versioning to a whole web >>> API surface when the actual change is local. It notes that putting a >>> version identifier into a URI causes even minor changes to mint an entire >>> new set of resources, with consequences for caches, links, and deployed >>> clients. It also gives a more granular example: >>> >>> "/rather than bumping a version when you want to modify how a resource >>> handles query parameters, you mint a new, sibling resource with a different >>> name that takes the alternate query parameters./" >> Another good example for 5.4.3.2. >> >>> I believe this principle is especially relevant to RDAP extensions, because >>> Section 5.4 already defines compatibility in terms of specific protocol >>> elements, such as JSON names and values, query paths and parameters, and >>> other. >>> >>> Therefore, the draft should make clear that the impact of a change ought to >>> be limited to the affected extension feature, and should not unnecessarily >>> force unrelated features of the extension to be versioned or replaced. >> That speaks to the need for the overlapping extension as described in >> 5.4.3.2. >> >> As an aside, I think we got the terminology wrong. We should use >> "superseder" instead of "replacement" because the successor may be >> complementing rather replacing. And as with a revision, you actually don't >> know when something is no longer used. > > [ML] Complementarity implies that multiple extensions are needed to obtain > all the information, that is, information that logically should be > transmitted through a single extension is instead split among multiple > extensions (theoretically unrelated) that could coexist in parallel forever. > > This seems like a solution (IMHO not very elegant) to solve the problem of > duplicating huge extensions in transitions. > > I support managing the transition in-the-small rather than in-the-large. > >>> Also, here are two small typos: >>> >>> 1) Add commas to separate the values of the array below: >>> >>> "description": >>> [ >>> "Query the database." >>> "JSON replaces the Whois." >>> "Structured data flows." >>> ] >>> >>> >>> 2) Add a closing curly brace as shown below >>> >>> { >>> "rdapConformance": [ >>> "rdap_level_0", >>> "exampleExt" >>> ], >>> "exampleExt_authorSearchResult": [ >>> { >>> "objectClassName": "exampleExt_author", >>> "author": >>> { >>> "firstInitial": "R", >>> "lastName": "SomePerson" >>> } >>> }, >>> { >>> "objectClassName": "exampleExt_author", >>> "author": >>> { >>> "firstInitial": "J", >>> "lastName": "SomePerson" >>> } >>> >>> <=== put a closing curly bracket here >>> ] >>> ] >>> } >>> >> I noted this in the issue tracker. Thanks. > > {ML] OK. > > > Best, > > Mario > >> -andy >> > -- > Dott. Mario Loffredo > Senior Technologist > Technological Unit “Digital Innovation” > Institute of Informatics and Telematics (IIT) > National Research Council (CNR) > Address: Via G. Moruzzi 1, I-56124 PISA, Italy > Phone: +39.0503153497 > Web: http://www.iit.cnr.it/mario.loffredo > _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
