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

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

I agree with Mario that we need to first consider the approaches presented (approach A, B, and C) prior to determining what changes need to be made to the existing RFCs.  I believe that the use of the "lunarNIC_level_0" identifier is appropriate for the RDAP Conformance value in RFC 9083 to signal support for the specification.



The gap that exists in the RFCs is how to support versioning of the RDAP extensions.  The RDAP conformance identifiers can support versioning, with "rdap_level_0" providing the base identifier for RDAP itself.  There is nothing that explicitly ties the prefix registrations with the RDAP conformance identifier registrations, where the prefixes define new path segment and response elements, and the RDAP conformation identifier signals the support for a specification.  I believe the RDAP Conformance identifiers should include the versioning, like the namespace URI in XML, and the prefixes should not include versioning, like the namespace prefix in XML.   If we consider the versioning of RDAP extensions, I include an example of each approach in the drafts below:



  1.  Approach A - https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-openid-15
     *   Registration of versioned extension prefix “roidc1”, that is used for the RDAP conformance and used as an RDAP prefix, as in “roidc1_session”, “roidc1_deviceInfo”, “roidc1_openidcConfiguration”.
     *   If the version changes, all the extension elements (RDAP conformance and the RDAP prefixes elements will change), and there is no formal format for the version number.
  2.  Approach B - https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted-04#section-6
     *   Registration of the extension prefix “redacted”, which is used for the new response member and used as the prefix used in the versioned RDAP conformance value “redacted_level_0.2”.  Note, the use of “.” does not match RFC 7480, so the versioned RDAP Conformance value should have been “redacted_level_0_2”.
     *   The version of the RDAP Conformance is defined in the associated specification, but it will use the unique prefix registered in the RDAP Extension Registry.
     *   This provides the linkage similar to Approach A, but doesn’t cascade versioning into the prefix and the extension elements.
  3.  Approach C - https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-redacted-07
     *   Registration of the extension prefix “redacted” and the versioned extension identifier “redacted_level_0_3”, where there can be more than one extension prefix “redacted”, “redacting”, “redaction” registered along with the versioned extension identifier “redacted_level_0_3”.  The RDAP conformance identifier is used for signaling only and the registered prefixes ensure uniqueness with other RDAP extensions.



I’m starting to think that Approach B may satisfy both requirements of those advocating for Approach A and those advocating for Approach C, where there is a linkage between the RDAP conformation value and the RDAP prefixed in Approach A, and there is versioning support that is isolated to the RDAP conformance in Approach C.  The RFCs mix of the term prefix and identifier would need to be clarified and how versioning is handled needs to be defined.



--



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 6/16/22, 10:08 AM, "regext on behalf of Mario Loffredo" <[e-mail] on behalf of [e-mail]> wrote:



    Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.



    Hi Scott,



    Il 16/06/2022 15:30, Hollenbeck, Scott ha scritto:

    >> -----Original Message-----

    >> From: regext <[e-mail]> On Behalf Of Mario Loffredo

    >> Sent: Thursday, June 16, 2022 2:57 AM

    >> To: [e-mail]

    >> Subject: [EXTERNAL] Re: [regext] OK, What Next? (was RDAP Extensions

    >> Approach Analysis v2)

    >>

    >> Caution: This email originated from outside the organization. Do not click

    >> links

    >> or open attachments unless you recognize the sender and know the content

    >> is safe.

    >>

    >> Hi folks,

    >>

    >> I invite you to consider that, currently, rdap-reverse-search and,

    >> potentially,

    >> three other RDAP-related docs are blocked waiting for the end of this

    >> discussion.

    > [SAH] There's no reason for the documents to be blocked if you adopt the

    > practice described in 9083. Look at Section 2.1 (Naming):

    >

    > "Servers that insert such unspecified members into JSON responses SHOULD have

    > member names prefixed with a short identifier followed by an underscore

    > followed by a meaningful name"

    >

    > We need an identifier for "unspecified members" (extension elements) that's to

    > be used as a prefix. Further:

    >

    > "If The Registry of the Moon desires to express information not found in this

    > specification, it might select "lunarNIC" as its identifying prefix and

    > insert, as an example, the member named "lunarNIC_beforeOneSmallStep" to

    > signify registrations occurring before the first moon landing and the member

    > named "lunarNIC_harshMistressNotes" that contains other descriptive text."

    >

    > This example shows the identifying prefix being used in two examples. This

    > begs the question: "What is registered with IANA and returned in the

    > rdapConformance data structure?". Section 4.1 (RDAP Conformance) has the

    > answer:

    >

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

    > custom specifications MUST be indicated by including a unique string literal

    > value registered in 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"."

    >

    > This unambiguously tells us that the value registered with IANA is included in

    > the rdapConformance data structure. If you consider the text from Section 2.1,

    > the only thing that make sense is if these identifiers are one and the same.

    > That's why I'm saying that the example in 4.1 is incorrect and needs to be

    > fixed. It should be "lunarNIC" to be consistent with Section 2.1 such that the

    > identifier used with "unspecified members" is the same identifier that's

    > returned in the rdapConformance data structure and the same identifier that's

    > registered with IANA.

    >

    >> In addition, it seems to me more logical, first, to decide how RDAP

    >> exentions

    >> must be treated and, then, correct RFC 9083 to make it consistent with what

    >> decided.

    > [SAH] 9083 already describes how extensions must be treated. If there's

    > anything unclear about that description, that lack of clarity should be

    > addressed first. If the WG wants to *change* that description, that's a

    > different discussion.



    [ML] Whatever will be the approach (A,B, or C) we'll agree on, RFC 9083

    needs to be updated.



    But depending on the approach agreed, the corrections needed will be

    different and they wiil involve either the definitions or the examples

    or both.



    Likewise, the elected approach could imply possible changes to the

    existing documents.





    Best,



    Mario



    > Scott

    > _______________________________________________

    > regext mailing list

    > [e-mail]

    > https://secure-web.cisco.com/1Kzc-Qe6UgjV-R9D2TuSkCiAafVeiC69srrhOy-YfkUT4wEoM6P4tZxle5nMP2p-grJmL0sN3MargRWKU2K-ElZjgbuj8xU0cvmNj4uqkkc-SjTa-BGR0IOlyGCdhl8Rj9Qc4NbyS0UjRXvGNXAdDDEQCMhMe8cYtnDL9tvmCrGYtXWO7-oBuJQybPtdjJkCPzkggPpEpCWOmAnGfc1Uufdspuxdz1Xt0F6s6QQBVHkVvoZ9TnNImAB3s5ENwyL9_/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext



    --

    Dr. Mario Loffredo

    Technological Unit “Digital Innovation”

    Institute of Informatics and Telematics (IIT)

    National Research Council (CNR)

    via G. Moruzzi 1, I-56124 PISA, Italy

    Phone: [phone]

    Web: http://secure-web.cisco.com/14ojfrPjCC0uZKbflsEuxNfFgHKsAz5anzd-kaxzeNZsRbCoDuDjpzlEzWIzaM5MM8XZjqFJHKfGDDPcnA6dr_GgY2-CXYGZieUsDALj1M9E2Fmebwzya7Wp3wKKqZ0rg6uy10EnPPBNDdD83p4kCSKx4Cll-08iXc0jKVi-322wXWyKG1ITCW0m1sdJEkipnozrferGaRL91A5v6j0PkC4lg_f2Dh9-sN84qFT8BhMJeNh1aHQvYc0Sp-Lh9J7D3/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo



    _______________________________________________

    regext mailing list

    [e-mail]

    https://secure-web.cisco.com/1Kzc-Qe6UgjV-R9D2TuSkCiAafVeiC69srrhOy-YfkUT4wEoM6P4tZxle5nMP2p-grJmL0sN3MargRWKU2K-ElZjgbuj8xU0cvmNj4uqkkc-SjTa-BGR0IOlyGCdhl8Rj9Qc4NbyS0UjRXvGNXAdDDEQCMhMe8cYtnDL9tvmCrGYtXWO7-oBuJQybPtdjJkCPzkggPpEpCWOmAnGfc1Uufdspuxdz1Xt0F6s6QQBVHkVvoZ9TnNImAB3s5ENwyL9_/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext