Hi. Honed the analysis a bit more.
Jasdip --- Approach A: Tight coupling between extension identifier and rdapConformance Extension identifier = <prefix>[<version>] [ ] means optional Registered in the IANA RDAP Extensions registry A new spec provided for each new version of the extension rdapConformance = <prefix>[<version>] Extension identifier used in new data members, and in new path segments (including any new query or matrix parameters) Approach B: Lack of tight coupling between extension identifier and rdapConformance Extension identifier = <prefix> Registered in the IANA RDAP Extensions registry rdapConformance = <prefix>[<version>] [ ] means optional Registered in the IANA RDAP Extensions registry (or perhaps another registry for rdapConformance) A new spec provided for each new version of rdapConformance Extension identifier used in new data members, and in new path segments (including any new query or matrix parameters) Comparing the two approaches: Aspect Approach A - tight coupling Approach B - lack of tight coupling Providing a new spec to IANA for a new version Registry stays as-is Registry needs to evolve for: * Versioned rdapConformance * Tying spec to versioned rdapConformance Risk of breaking changes for RDAP clients Yes, if the server now only supports the new version and a client hasn’t evolved yet Data member names and path segments change with each new version but not an issue if clients have re-programmed a priori Clients would knowingly call the versioned path segments — no guesswork If a path segment is not affected by a new version and only a newly versioned data sub-object is added in the response, that could break clients Yes, when a field is removed, or a required field is added, for a new version When a call is made using a non-versioned path segment, the newly versioned rdapConformance would be checked after the fact and that could break the client for above field additions and subtractions if not re-programmed a priori Clients would call non-versioned path segments but could be broken by the new responses Cost of reprogramming clients for the next version of an extension There is cost but not as high as it seems — replacing version in multiple places and accounting for field and query parameter additions and subtractions Longer grace period for clients to reprogram if the server supports multiple versions during transition There is cost — accounting for a field removal or a required field addition Reprogramming could become exigent for clients if the server switches to the new version without supporting the previous version Cost of reprogramming servers for the next version of an extension There is a higher cost — if multiple versions are simultaneously supported during a transition period, replicating code from the previous version and replacing version in multiple places and accounting for field and query parameter additions and subtractions Eventually retiring code for the previous version There is a lower cost — if only the latest version is supported, accounting for a field removal or a required field addition vis-a-vis the previous version Server-side signaling of the next version of an extension Add the new version of the rdapConformance in the help response and related responses Make URLs for new versions of path segments available Add the new version of the rdapConformance in the help response and related responses No change in URLs for the new version of the rdapConformance Potential confusion for clients Zero since the new version is explicitly marked in data members and URLs Not zero since the new version is not marked in data members and URLs, and would only be discovered through the rdapConformance value in a response Aesthetics (does not matter to a machine but could for human friendliness) Less More From: regext <regext-boun...@ietf.org> on behalf of Jasdip Singh <jasd...@arin.net> Date: Thursday, May 19, 2022 at 2:15 PM To: "regext@ietf.org" <regext@ietf.org> Subject: [regext] Analysis of tight coupling between extension identifier and rdapConformance, versus lack of Hi. Not sure if it is totally correct but wanted to input a strawman analysis of the two approaches -- tight coupling between extension identifier and rdapConformance, versus lack of -- to our discussion. Hope this is useful. Thanks, Jasdip --- Approach A: Tight coupling between extension identifier and rdapConformance Extension identifier = <prefix>[<version>] [ ] means optional Registered in the IANA RDAP Extensions registry A new spec provided for each new version of the extension rdapConformance = <prefix>[<version>] Extension identifier used in new data members, and in new path segments (including any new query or matrix parameters) Approach B: Lack of tight coupling between extension identifier and rdapConformance Extension identifier = <prefix> Registered in the IANA RDAP Extensions registry rdapConformance = <prefix>[<version>] [ ] means optional Registered in the IANA RDAP Extensions registry (or perhaps another registry for rdapConformance) A new spec provided for each new version of rdapConformance Extension identifier used in new data members, and in new path segments (including any new query or matrix parameters) Comparing the two approaches: Aspect Approach A - tight coupling Approach B - lack of tight coupling Providing a new spec to IANA for a new version Registry stays as-is Registry needs to evolve for: * Versioned rdapConformance * Tying spec to versioned rdapConformance Risk of breaking changes for RDAP clients Yes, if the server now only supports the new version and a client hasn’t evolved Data member names and path segments change with each new version but not an issue if clients have re-programmed a priori Clients would knowingly call the versioned path segments — no guesswork Even if a path segment is not affected by a new version but only a newly versioned data sub-object is added in the response, that could break clients Yes, when a field is removed, or a required field is added, in a new version When a call is made using a non-versioned path segment, the newly versioned rdapConformance would be checked after the fact and could break the client for above field additions and subtractions if not re-programmed a priori Clients would call non-versioned path segments but could be broken by the new responses Cost of reprogramming clients for the next version of an extension There is cost but not as high as it seems — replacing version in multiple places and accounting for field and query parameter additions and subtractions There is cost but could be higher than it seems - client finds after the fact about a field removal or a required field addition Cost of reprogramming servers for the next version of an extension There is cost but not as high as it seems — replacing version in multiple places and accounting for field and query parameter additions and subtractions There is cost for a field removal or a required field addition Server-side signaling of the next version of an extension Add the new version of the rdapConformance in the help response and related responses Make URIs for new versions of path segments available Add the new version of the rdapConformance in the help response and related responses No change in URIs for the new version of the rdapConformance Potential confusion for clients Zero since the new version is explicitly marked in data members and URIs Not zero since the new version is not marked in data members and URIs Aesthetics (should not matter to a machine but could to a human) Less More
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
