It is clearer to update section 4.1 to reference "lunarNIC" instead of "lunarNIC_level_0", since changing section 2.1 to use "lunarNIC_level_0" incorrectly encourages embedding versioning into the registered RDAP identifiers. At IETF 114, the “RDAP Extension Identifier and rdapConformance” topic was discussed and the chairs included the deck (https://datatracker.ietf.org/meeting/114/materials/slides-114-regext-rdap-extension-identifier-and-rdapconformance) with the proposal:
1. Explicit support for version is not an integral part of the extension mechanism 2. Certainly, you can choose to include version inside the specification for your extensions, but in the context of the base protocol an extension is either supported or its not, and when supported it simply means there is a shared understanding of what is to be done between the client and server I believe removing the versioning from the “lunarNIC” identifier in section 4.1 is more in line with the proposal. Mario Loffredo, Dan Keathley and I posted draft-gould-regext-rdap-versioning<https://datatracker.ietf.org/doc/html/draft-gould-regext-rdap-versioning> yesterday to explicitly address versioning of RDAP extensions. Feedback is welcome. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/28/22, 11:17 PM, "regext on behalf of RFC Errata System" <regext-boun...@ietf.org on behalf of rfc-edi...@rfc-editor.org> wrote: The following errata report has been verified for RFC9083, "JSON Responses for the Registration Data Access Protocol (RDAP)". -------------------------------------- You may review the report below and at: https://secure-web.cisco.com/1hpi7wOXCVaN6c8Ayc2mUNTIBliFww16hAlxvYFu3L4Br6vqITHoBMg4EByT6jpw2_cKhl7LTQgkZYDCz-bWIeAVFT4avzcuF6zKGcCr3E2rS8CsFC7nlzW_DpxPNCa_zXG2QqxcGz8kmoHQ8piEXpiFhx0ChsxzH2a4WF9E3sEkViSQ_S_XqFNv3eTj0982ZxKphPSiT4MJsB5bF0mdDQtVILYU2If6pj1kL4ilATTRGQLTtAByDaCk7gRBS360IEtXkfqU4u7eysEYyOhJYzWXdVeWFf3X8AZuoCkFCgM9QFOXA0yymilAPO75Z9mP3/https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid7094 -------------------------------------- Status: Verified Type: Technical Reported by: Scott Hollenbeck <shollenb...@verisign.com> Date Reported: 2022-08-17 Verified by: Murray Kucherawy (IESG) Section: 2.1 Original Text ------------- 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. Consider the following JSON response with JSON names, some of which should be ignored by clients without knowledge of their meaning. { "handle" : "ABC123", "lunarNIC_beforeOneSmallStep" : "TRUE THAT!", "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "lunarNIC_harshMistressNotes" : [ "In space,", "nobody can hear you scream." ] } Figure 2 Corrected Text -------------- If The Registry of the Moon desires to express information not found in this specification, it might select "lunarNIC_level_0" as its identifying prefix and insert, as an example, the member named "lunarNIC_level_0_beforeOneSmallStep" to signify registrations occurring before the first moon landing and the member named "lunarNIC_level_0_harshMistressNotes" that contains other descriptive text. Consider the following JSON response with JSON names, some of which should be ignored by clients without knowledge of their meaning. { "handle" : "ABC123", "lunarNIC_level_0_beforeOneSmallStep" : "TRUE THAT!", "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "lunarNIC_level_0_harshMistressNotes" : [ "In space,", "nobody can hear you scream." ] } Figure 2 Notes ----- The original text uses the string identifier "lunarNIC" as the prefix for an example extension. This is inconsistent with the example given in Section 4.1, where "lunarNIC_level_0" is used as an example of a registered identifier for an RDAP extension. This inconsistency can lead implementers to believe that the registered identifier and the extension prefix can be inconsistent, when the intent of the specification is that they should be consistent. This inconsistency can cause significant misunderstanding of the technical specification and might result in faulty implementations if not corrected. Changing the examples in Section 2.1 aligns the text with the example in Section 4.1, demonstrating that the extension prefix and the registered identifier should be one and the same. -------------------------------------- RFC9083 (draft-ietf-regext-rfc7483bis-05) -------------------------------------- Title : JSON Responses for the Registration Data Access Protocol (RDAP) Publication Date : June 2021 Author(s) : S. Hollenbeck, A. Newton Category : INTERNET STANDARD Source : Registration Protocols Extensions Area : Applications and Real-Time Stream : IETF Verifying Party : IESG _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/11IOOOAIYeFsPwbPADhj4q0RGkka8sLd9TZ6xatPBqavrWchbwQGPUXeatRqHWjzQmLckEUKG10_oM3tzi_FCVmDW_bM_SOSYV-P9hOwaXMPLj96sN4u5XselW1TYB6Z9pYywRIwVL7ZvL-5LZpARQsLVQgau6PGFFE2ZMPkopemG9aNAbkggnt49EjvlMXWbNCxloOwQ9ss5sCjmSKlXvbOJ2BSOWz5d6R6aqTCJL8QQRKTqiZwi69hCV9bJVlRhkfAlIsPeB97y5YbzPW0I19licEYN1aAzEXt771Cz2Rcw1wxupeT8RrM928BSz-pC/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
