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

[Andrew Newton <[e-mail]>]

On Fri, Jul 15, 2022 at 8:13 AM Gould, James <[e-mail]> wrote:
>

>
> In the case of Approach B and C, the values registered in the RDAP Extension Registry guarantee uniqueness, and the RDAP Conformance value has the sole responsibility of signaling the version of the extension without cascading down to the extension elements.  I prefer the flexibility of Approach C, but Approach B will work.  One side effect of Approach C is that we still need to support the registration of fully versioned identifiers to capture policy signaling, such as the case of the RDAP Profile identifiers "icann_rdap_response_profile_0" and "icann_rdap_technical_implementation_guide_0".
>

I don't know if I fully understand the difference between approaches B
& C, but policy signalling seems important. My preference is not to
break that.

For adding on to an existing extension, one approach might be to list
the new sub-members separately. For example, "exampleNicV1" is created
and listed in the rdapConformance. So for example:

{
     "rdapConformance" : [ "rdap_level_0", "exampleNicV1"],
     "exampleNicV1_foo": {
          "bar": "buz"
     }
     ....
}

Now, an addition is desired, so "exampleNicV1_modA" is created:

{
     "rdapConformance" : [ "rdap_level_0", "exampleNicV1", "exampleNicV1_modA"],
     "exampleNicV1_foo": {
          "bar": "buz",
          "exampleNicV1_modA_bar": "bazz",
     }
     ....
}

This works because "Clients of these JSON responses SHOULD ignore
unrecognized JSON members in responses." (Section 2.1 of RFC 9083).

-andy