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

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

Andy,

Thanks for your response.  My feedback is embedded below.

-- 
 
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/18/22, 4:02 PM, "Andrew Newton" <[e-mail]> wrote:

    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.

JG - The difference between Approach B and C is the coupling between the RDAP Conformance value and the extension elements, where Approach B uses the registered prefix value for the versioned RDAP Conformance value ("redacted" registered prefix and the RDAP Conformance value "redacted_level_X" defined within the specification).  Approach C decouples them and supports the registration of the versioned RDAP Conformance identifier ("redacted_level_X" registered for the specification version and the registration of one or more prefixes defined within the specification, such as "redacted").  The versioned RDAP Conformance is associated with hinting the specification supported by the server, where there is no hard requirement to couple the RDAP Conformance value with the prefixes defined within the specification.  Approach A couples the RDAP Conformance value with the prefix value used for the extension elements.  Both Approach B and C support version signaling only in the RDAP Conformance value and allow the extension elements to be unchanged with version changes.  

    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",
         }
         ....
    }

JG - This is defining a new mechanism for auto-discovery.  My recommendation is to separate auto-discovery capabilities from the hinting provided by the RDAP Conformance values, where the RDAP Conformance values are only used for signaling the specification versions supported by the server.  I have experience with attempting to provide an auto-discovery capability in EPP with the Registry Mapping (https://datatracker.ietf.org/doc/html/draft-gould-carney-regext-registry), which was very ambitious for EPP and I believe will be very ambitious and more complex then you may think for RDAP.     

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

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?       

    -andy