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]
