Re: [abnf-discuss] ABNF/RFC7405/ Update: EBNF syntactic exception

Carsten Bormann <cabo@tzi.org> Tue, 12 July 2022 15:11 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: abnf-discuss@ietfa.amsl.com
Delivered-To: abnf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B113C14F747 for <abnf-discuss@ietfa.amsl.com>; Tue, 12 Jul 2022 08:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
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 yFvM1HLnNh7V for <abnf-discuss@ietfa.amsl.com>; Tue, 12 Jul 2022 08:11:02 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (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 863FCC14F743 for <abnf-discuss@ietf.org>; Tue, 12 Jul 2022 08:11:01 -0700 (PDT)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Lj42V2msqzDCtj; Tue, 12 Jul 2022 17:10:58 +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: <SA1PR07MB87076C9E814E3BF762E51500B8869@SA1PR07MB8707.namprd07.prod.outlook.com>
Date: Tue, 12 Jul 2022 17:10:58 +0200
Cc: "abnf-discuss@ietf.org" <abnf-discuss@ietf.org>
X-Mao-Original-Outgoing-Id: 679331457.963941-abc0bbadce1cfc947b51a671085f3b87
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1F03FBC-9082-438E-B0D0-C0526728A071@tzi.org>
References: <20220710005652.5B4A04532DCC@ary.qy> <D4CD5CBA-AB51-4490-A630-54DD27BD37F1@tzi.org> <f4bd8b47-bd02-418e-d152-84432f5db6a1@taugh.com> <18F74DA7-DAAB-4F59-A546-2CFA050ED58C@tzi.org> <SA1PR07MB8707B60B050232E1FD4D3678B8879@SA1PR07MB8707.namprd07.prod.outlook.com> <CCFBEF01-2A8D-4B76-A0F8-24A3D4F9E4AF@tzi.org> <SA1PR07MB870714CA865CEDCD0D0A0EC6B8879@SA1PR07MB8707.namprd07.prod.outlook.com> <SA1PR07MB87072BEC97CE54313A2CFC12B8869@SA1PR07MB8707.namprd07.prod.outlook.com> <9719119D-01DB-4D0B-9221-D360C763C6E2@tzi.org> <SA1PR07MB8707941CC717F15ECBFA9A1FB8869@SA1PR07MB8707.namprd07.prod.outlook.com> <SA1PR07MB87076C9E814E3BF762E51500B8869@SA1PR07MB8707.namprd07.prod.outlook.com>
To: Jacob Friedman <jfriedman@virgilsystems.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/abnf-discuss/9e1lyggI7dUg4XLqOfj2kjUgskc>
Subject: Re: [abnf-discuss] ABNF/RFC7405/ Update: EBNF syntactic exception
X-BeenThere: abnf-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "General discussion about tools, activities and capabilities involving the ABNF meta-language" <abnf-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abnf-discuss>, <mailto:abnf-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/abnf-discuss/>
List-Post: <mailto:abnf-discuss@ietf.org>
List-Help: <mailto:abnf-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abnf-discuss>, <mailto:abnf-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2022 15:11:05 -0000

On 2022-07-12, at 17:03, Jacob Friedman <jfriedman@virgilsystems.com> wrote:
> 
> Which is backwards-compatible

But not forward compatible.
We have to rewrite all our tools to accommodate the extension.
And move on to different supporting theories in the process.

(Big deja-vu here: W3C tried to add subtraction to their regexps, in a much simpler way [just for character classes].  And by this created a big obstacle to taking up W3C regexps.  That’s why we are proposing not to provide subtractions in iregexps [1].)

Grüße, Carsten

[1]: https://www.ietf.org/archive/id/draft-ietf-jsonpath-iregexp-01.html