On Fri, Jul 15, 2022 at 8:13 AM Gould, James <[email protected]> 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
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
