Re: [regext] Extension Prefixes, JSON Values, and URI Path Segments

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

Scott,



With the potential impacts to draft-ietf-regext-rdap-redacted, I did a review of the referenced RFC language for the Extension Prefixes, JSON Values, and URI Path Segments.  I provide my interpretation embedded below for consideration.  To provide a concrete example of the proposed changes to draft-ietf-regext-rdap-redacted, I list them below:



  1.  For the Extension Prefix, I believe that we need to register the “redacted” Extension identifier in the RDAP Extensions Registry instead of the versioned value “redacted_X.X”.
  2.  For the RDAP Conformance, as defined in Section 4.1 “RDAP Conformance”, I believe that we can follow the pattern of “rdap_level_0”, but leverage the pointed version number until the draft exits WGLC.
     *   Change references of “redacted_0.1” to “redacted_level_0.1”; although I believe we will need to bump it up to “redacted_level_0.2” based on adding the Redaction by Replacement Value Method that will be included in draft-ietf-regext-rdap-redacted-04 .
  3.  The “redacted” JSON response member will match the “redacted” extension identifier that will be registered in the RDAP Extensions Registry.

     *   The language of RFC 9083 “MUST use a string prefixed with the appropriate identifier from the IANA RDAP Extensions registry specified in [RFC7480].”, I believe the RFC will be met since a registered prefix should be able to be combined with a NULL suffix, meaning the member can match the registered extension identifier.  The key is that there are no conflicts with the members returned in the response, which is handled by the registration of the “redacted” extension identifier.



So, the only required changes to draft-ietf-regext-rdap-redacted is the extension identifier registered in the RDAP Extension Registry (“redacted” instead of “redacted_X.X”), and the RDAP Conformance value being changed to “redacted_level_X.X”.  The RDAP response member can remain “redacted”, since it will match the registered extension identifier (e.g., registered prefix with NULL suffix).



--



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 4/28/22, 10:27 AM, "regext on behalf of Hollenbeck, Scott" <[e-mail] on behalf of shollenbeck=[e-mail]> wrote:



    Since this topic is coming up in the reverse search discussion, but isn't

    unique to reverse search, I thought it best to start another topic.



    Section 6 of RFC 7480 introduces the concept of "an IANA registry for prefixes

    used in JSON [RFC7159] data serialization and URI path segments (see Section

    8)". "lunarNic" is given as an example in Section 8. I cannot, though, find

    any mention of a MUST when it comes to using these prefixes for data

    structures or URI path segments, though Section 8.1 says this:



    "The extension identifier is used as a prefix in JSON names and as a prefix of

    path segments in RDAP URLs."



    RFC 9083 is more definitive. From Section 4.1:



    "When custom JSON values are inserted into responses, conformance to those

    custom specifications MUST use a string prefixed with the appropriate

    identifier from the IANA RDAP Extensions registry specified in [RFC7480].  For

    example, if the fictional Registry of the Moon wants to signify that their

    JSON responses are conformant with their registered extensions, the string

    used might be "lunarNIC_level_0"."



JG – My interpretation is that the registered extension prefixes used in the URI path segments and JSON response members need to be used, but it doesn’t specify the suffix that must be used.  The suffix could be NULL, and therefore the URI path segment and the JSON response members can match the registered extension prefixes.  The reference to “lunarNIC_level_0” looks to be relevant for a rdapConformance value, since the rdapConformance member has the purpose of signaling conformance in the response, and not the names of the RDAP response members themselves.  I believe the goal is to ensure that there is no conflict in URI Path Segments and JSON response members, which is met based on ensuring to use registered extension prefixes, which and I believe most likely will have a null suffix for the path segments and JSON response members.



    Note the use of MUST here. Section 5 of RFC 9082 contains similar text:



    "Custom path segments can be created for objects not specified here using the

    process described in Section 6 of "HTTP Usage in the Registration Data Access

    Protocol (RDAP)" [RFC7480].



    Custom path segments can be created by prefixing the segment with a unique

    identifier followed by an underscore character (0x5F). For example, a custom

    entity path segment could be created by prefixing "entity" with "custom_",

    producing "custom_entity"."



JG – This is not normative and covers a corner case of define a custom object of one that already exists.  Defining a new custom object (e.g., “foo” for the Foo object or “bar” for the Bar object) that doesn’t already exist would not require the use of an underscore character, since there would be no conflict with other path segments.  The custom path segment would match the registered RDAP extension identifier.  A custom entity object would not be able to use the path segment “entity”, so instead it differentiates the entity path segment using it’s registered extension identifier prefix.



    After re-reading all of this, my take is that extensions MUST tag new data

    structures and path segments with the prefix that's registered with IANA. That

    means I'm going to have to change the data structures and path segments in

    draft-ietf-regext-rdap-openid (I'm probably going to change the prefixes to

    something shorter to make them a bit less clunky). Other extension

    authors/editors should review their documents and provide their own

    assessments.



    Scott



    _______________________________________________

    regext mailing list

    [e-mail]

    https://secure-web.cisco.com/10mX5xspvc-CplH__kACOPD_MQa73oefUXn9viMqhxjrTvYuTo_t-S7CGnbci1ilq715uayoGpxBTFESCwtUSSzWUMi78Nv4FQfkTsB1MOO6UUM97ePFhV7zZJEmk0lKjItjm799a9SMSdp5Q0Hyfp_sGJDmES9vAI2uRMDbROH-cUeV8EeTbe8nLywXjQOndYdYzCrOCALfOj0sozHZ73hC-GtqysPlWX6PS1P6nVkxuMsRCuAcDcLzDFU0kTTKX/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext