On Tue, Jul 19, 2022 at 9:43 AM Gould, James <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/regext
