Jasdip, How about adding Approach C: decouple the extension identifier in the rdapConformance from the set of path segment, JSON response member, and objectClassName prefix values?
The ABNF for an element (path segment, JSON response member, objectClassName), based on the registration of an extension prefix. More than one prefix can be registered in a single specification, like creating an extension for the 5 objects in RFC 9082 and 9083. element = prefix [ suffix ] prefix = name suffix = “_” name name = ALPHA *( ALPHA / DIGIT / “_” ) ; format from RFC 7480 The rdapConformance value is an identifier that provides signaling for supporting a version of an extension. The format defined in RFC 7480 is flexible enough to support a versioned identifier with: name = ALPHA *( ALPHA / DIGIT / “_” ) My recommendation is to follow the pattern defined in RFC 9083 for the rdapConformance value with the ABNF, but I would not make this a requirement. identifier = name “_level_” version version = DIGIT [ “_” DIGIT ] name = ALPHA *( ALPHA / DIGIT / “_” ) ; format from RFC 7480 I don’t believe the intent is to model XML namespace URIs, namespace prefixes, and element names in REST, but to ensure that there is no conflict across the RDAP extensions when it comes to rdapConformance identifiers, path segments, JSON response members, and objectClassName values. The rdapConformance value is meant for signaling the support for an extension and therefore should support versioning. The path segments, JSON response members, and objectClassName values need to be ensure uniqueness and are not meant for signaling, where there is no requirement that implies a linkage with the rdapConformance identifier. When defining a new object with a registered “objectClassName” value, there is no need to define all of the unique object RDAP response members in the RDAP Extension Registry, since the “objectClassName” ensures uniqueness with other objects. An extension can be created that includes a single versioned rdapConformance value and a set of path segments, JSON response members, and objectClassName prefix values. Imagine an RDAP extension that contains multiple objects, like how RFC 9082 and 9083 supports 5 objects. Based on Approach A and B, there needs to be a mapping of the rdapConformance identifier with all 5 objects, which is unnatural for a REST interface. We need to ensure that there is version signaling in the rdapConformance and ensure uniqueness of path segments, JSON response members, and objectClassName values across a variety of RDAP extensions (e.g., extending existing objects and defining new objects). I believe Approach C will satisfy it. -- JG [cid:[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext <[email protected]> on behalf of Jasdip Singh <[email protected]> Date: Thursday, May 19, 2022 at 8:52 PM To: "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Analysis of tight coupling between extension identifier and rdapConformance, versus lack of 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 <[email protected]> on behalf of Jasdip Singh <[email protected]> Date: Thursday, May 19, 2022 at 2:15 PM To: "[email protected]" <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/regext
