Re: [Cbor] cddl 0.8.17: Add .abnf (draft-ietf-cbor-cddl-control)

Carsten Bormann <> Fri, 26 February 2021 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5381F3A13A2 for <>; Fri, 26 Feb 2021 09:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IHVoqiI1v9HU for <>; Fri, 26 Feb 2021 09:42:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B0723A1396 for <>; Fri, 26 Feb 2021 09:42:09 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4DnH656JCLzyXs; Fri, 26 Feb 2021 18:42:05 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Fri, 26 Feb 2021 18:42:05 +0100
X-Mao-Original-Outgoing-Id: 636054125.357831-1d956347614ef570d6a490ffcc16edd9
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Paul Kyzivat <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] cddl 0.8.17: Add .abnf (draft-ietf-cbor-cddl-control)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Feb 2021 17:42:13 -0000

> Perhaps off topic here, but ...

Well, there is no ABNF working group :-)
The CBOR WG with its CDDL work item actually is the closest you get at the moment.

> IMO it would be good to make a revision to 5234 to resolve the leading whitespace issue. As it stands, there must be multitude of hacks to work around it, and AFAIK the assumptions made within those hacks are poorly documented and probably inconsistent.

Yes, and the hacks are so prevalent that I actually had to build a tool based on the ABNF in 5234 to be reminded of it :-)

> The first thing to resolve would be to decide how to resolve the ambiguity when leading whitespace is allowed.

Is there one?
AFAIK, the only “problem” is lack of LL(1) parsing, and I don’t really care that much about that in 2021.

> Unfortunately I don't think there is any backward compatible extension that could itself be defined in abnf.

OK, I don’t think I can parse that before I understand the answer to my previous question.

Grüße, Carsten