Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

[Andrew Newton <[e-mail]>]

On Tue, Jul 19, 2022 at 9:43 AM Gould, James <[e-mail]> 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