Andy, >> JG - This is defining a new mechanism for auto-discovery.
> I don't believe it is new as the rdapConformance array has been > present from the inception of RDAP. Can you explain your thoughts > here? The rdapConformance array in RFC 9083 is defined as: The data structure named "rdapConformance" is an array of strings, each providing a hint as to the specifications used in the construction of the response. Since rdapConformance is defined as an array of strings, adding the sub-element definition in the rdapConformance is something new. My recommendation is if additional information is needed for auto-discovery, it is best to include that in a new extension. That extension may become complex based on the different forms of extensions (extending objects, extending path segments / query parameters, extending response members) that can be defined, the supported server policies, and the detail that is needed to support auto-discovery. -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/19/22, 10:43 AM, "Andrew Newton" <a...@hxr.us> wrote: On Tue, Jul 19, 2022 at 9:43 AM Gould, James <jgo...@verisign.com> wrote: > > JG - This is defining a new mechanism for auto-discovery. I don't believe it is new as the rdapConformance array has been present from the inception of RDAP. Can you explain your thoughts here? > > JG - This issue that we're tackling is how to not break clients when introducing a new version of an extension, where new unrecognized JSON members SHOULD be ignored but removing existing members with a version change can certainly cause an issue for the client. A server can't introduce a backward compatible enhancement without forcing all clients to change and the server may have no visibility into what the client supports since there may be no client-side version signaling available. An example is draft-ietf-regext-rdap-redacted, which only extends the response members of the response. Approach B and C mitigate the interoperability risk by only embedding the version into the RDAP Conformance value. What is the advantage of embedding the version into the prefix in Approach A for the client? As with any protocol, if there are breaking changes then that should be signaled with an entirely new, major version. Practically speaking, I doubt this is a real problem as generally items of a programmatic contract are "deprecated" in minor version bumps. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
