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

Lucas TESSON <lucastesson@protonmail.com> Wed, 20 September 2023 15:46 UTC

Return-Path: <lucastesson@protonmail.com>
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 B3CBEC15153E for <json@ietfa.amsl.com>; Wed, 20 Sep 2023 08:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com
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 w_9wyxTxsB4q for <json@ietfa.amsl.com>; Wed, 20 Sep 2023 08:46:48 -0700 (PDT)
Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (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 9EB67C14CE51 for <json@ietf.org>; Wed, 20 Sep 2023 08:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1695224804; x=1695484004; bh=+9sIsKhBcIQnkvmXdYKradXMcBoSMvQaWZ9th28weNI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=V3jxZO7VAMd2QC6syKlnEgIjNgHjJKGsclEr06ZJhbujO3X7RPNhvq1h8eaoH+r5B 0LxofIiUSKQwo5qWs8TEZOR2oZl86xDpJKhqzh1LZ2jq2DtXlFDQ52mPrS7fgPx+D/ E8byH7yDblsa0e9SlehBw5V8F8FbRwit3jW74sPyKYO2WzoImIOREKR0RFA0c91us7 uU0XzYf1HXeogTY+Ay33MhNcuritSlQ0E440WD96BdzUjd4DqZQShA6hobvc6d54Fa Z9+w989wxhOIFI9xOzhhOZLk/Q0/KdZtuiNy0HsU+BXycKWqbHzokY631sZceIS8WV Ab4zwOL5KNFDQ==
Date: Wed, 20 Sep 2023 15:46:30 +0000
To: Carsten Bormann <cabo@tzi.org>
From: Lucas TESSON <lucastesson@protonmail.com>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Tim Bray <tbray@textuality.com>, superuser@gmail.com, francesca.palombini@ericsson.com, linuxwolf+ietf@outer-planes.net, json@ietf.org
Message-ID: <lGNo9VERN-EwB6GH-pB04uUsrul7JEEIKo7ARPkLzu3rkxizItep_OJ340aqIis-M-xqeD-rADfCh4TFLnJJn27n3FcrjtLZMVnSYhcwIzY=@protonmail.com>
In-Reply-To: <2E8A9E99-D72C-40C9-BA39-CFAE0743E977@tzi.org>
References: <20230920145716.EEC11E5EAB@rfcpa.amsl.com> <2E8A9E99-D72C-40C9-BA39-CFAE0743E977@tzi.org>
Feedback-ID: 24375462:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="------cf28d15da097826988d31f7a6111611dcc3480e1f93d9928d8a7d93607101316"; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/v0jsavSCLWhM1FlpzEuapiX8seQ>
X-Mailman-Approved-At: Wed, 20 Sep 2023 09:42:22 -0700
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 15:50:29 -0000

Hi,

thanks for your response.
Indeed it is not clear whether the "core rules" are always present, but I think that is the idea behind the name "core".

For instance, multiple RFCs makes use of those core rules without ever redefining them or clearly define that they "import" it from RFC 5234:
- RFC 5147: DIGIT, HEXDIG
- RFC 5321: CRLF, ALPHA, DIGIT, SP, DQUOTE, HEXDIG
- RFC 5954: DIGIT, HEXDIG
- RFC 6338: ALPHA, DIGIT, HEXDIG
- RFC 5404: HEXDIG, DIGIT
- ... and so on, even in NIST-IR and other specifications
It has been widely accepted that ABNF Core rules always lie in the grammar, leading to this errata.

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.

I still think the "char" rule name should be updated to avoid interpretations or forcing behavior.

Best regards,
   Lucas.

------- Original Message -------
Le mercredi 20 septembre 2023 à 5:10 PM, Carsten Bormann <cabo@tzi.org> a écrit :


> Interesting.
> 

> I don’t read RFC 5234 to imply that Core Rules (B.1) are always present; these are just useful rules that can be imported when needed. (This is supported by B saying "Note that these rules are only valid for ABNF encoded in 7-bit ASCII or in characters sets that are a superset of 7-bit ASCII.”, so these rules appear to have been designed with limited applicability in mind.)
> 

> RFC 8259 does not define DIGIT or HEXDIG; the assumption here seems to be that those come from the Core Rules. This does not appear to be said in the document, which maybe is the real errata behind this report.
> 

> Grüße, Carsten