[regext] [Technical Errata Reported] RFC9083 (7094)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 17 August 2022 14:00 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D15FC1522C3 for <regext@ietfa.amsl.com>; Wed, 17 Aug 2022 07:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Level:
X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdMepEslH_DM for <regext@ietfa.amsl.com>; Wed, 17 Aug 2022 07:00:36 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7433C1522C5 for <regext@ietf.org>; Wed, 17 Aug 2022 06:59:59 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 755C5EEA39; Wed, 17 Aug 2022 06:59:59 -0700 (PDT)
To: shollenbeck@verisign.com, andy@hxr.us, superuser@gmail.com, francesca.palombini@ericsson.com, galvin@elistx.com, ietf@antoin.nl
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: shollenbeck@verisign.com, regext@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20220817135959.755C5EEA39@rfcpa.amsl.com>
Date: Wed, 17 Aug 2022 06:59:59 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/8EnKnpLZy2XlyFSssqMevRfZ5Ak>
Subject: [regext] [Technical Errata Reported] RFC9083 (7094)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2022 14:00:40 -0000

The following errata report has been submitted for RFC9083,
"JSON Responses for the Registration Data Access Protocol (RDAP)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7094

--------------------------------------
Type: Technical
Reported by: Scott Hollenbeck <shollenbeck@verisign.com>

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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
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