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

["Gould, James" <[e-mail]>]

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
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 7/19/22, 10:43 AM, "Andrew Newton" <[e-mail]> wrote:


    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