Re: [Json] [Technical Errata Reported] RFC8259 (7650)

Carsten Bormann <cabo@tzi.org> Wed, 20 September 2023 16:04 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52677C151061 for <json@ietfa.amsl.com>; Wed, 20 Sep 2023 09:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable 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 yxnjzNOUpHMX for <json@ietfa.amsl.com>; Wed, 20 Sep 2023 09:04:54 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (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 D8381C14CE31 for <json@ietf.org>; Wed, 20 Sep 2023 09:04:53 -0700 (PDT)
Received: from [192.168.217.124] (p548dc15c.dip0.t-ipconnect.de [84.141.193.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4RrNds2Jm1zDCfp; Wed, 20 Sep 2023 18:04:49 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <lGNo9VERN-EwB6GH-pB04uUsrul7JEEIKo7ARPkLzu3rkxizItep_OJ340aqIis-M-xqeD-rADfCh4TFLnJJn27n3FcrjtLZMVnSYhcwIzY=@protonmail.com>
Date: Wed, 20 Sep 2023 18:04:46 +0200
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Tim Bray <tbray@textuality.com>, superuser@gmail.com, Francesca Palombini <francesca.palombini@ericsson.com>, linuxwolf+ietf@outer-planes.net, json@ietf.org
X-Mao-Original-Outgoing-Id: 716918686.7172559-4c10b6fadee0b00f8652b26638447e13
Content-Transfer-Encoding: quoted-printable
Message-Id: <45509B37-1D47-44C2-8C91-554EAA00602E@tzi.org>
References: <20230920145716.EEC11E5EAB@rfcpa.amsl.com> <2E8A9E99-D72C-40C9-BA39-CFAE0743E977@tzi.org> <lGNo9VERN-EwB6GH-pB04uUsrul7JEEIKo7ARPkLzu3rkxizItep_OJ340aqIis-M-xqeD-rADfCh4TFLnJJn27n3FcrjtLZMVnSYhcwIzY=@protonmail.com>
To: Lucas TESSON <lucastesson@protonmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/BS0akxysdRO7lmjaWS_8-jnvJXA>
Subject: Re: [Json] [Technical Errata Reported] RFC8259 (7650)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Sep 2023 16:04:58 -0000

On 2023-09-20, at 17:46, Lucas TESSON <lucastesson@protonmail.com> wrote:
> 
> It has been widely accepted that ABNF Core rules always lie in the grammar, leading to this errata.

As Julian mentioned, implicit importing is not that widely accepted.

> Note that the BAP tool used by the IETF to validate ABNF grammar don't raise an error on this, which may be an actual issue in its implementation.

ABNF in reality is almost as much defined by BAP as by RFC 5234.
Generations of spec writers have used BAP to check their ABNF.

Of course, you can extract the ABNF from RFC 5234 B.1, put it into core-rules.abnf, and do a

   aex rfc8259.txt | bap -i core-rules.abnf

to see the problem (*), but who knows that?

My point is that if using the core rules requires explicit action in the most widely used ABNF tool, implicit importing can’t be that wide-spread.

Grüße, Carsten

(*)
stdin(53:29): warning: rule CHAR defined on line 4 referred to as char
stdin(66:0): error: Rule char previously defined as CHAR on line 4
stdin(66:0): error: Rule char was already defined on line 4 of core-rules.abnf