Re: [Cbor] Using cddl-control to dissect byte strings

Christian Amsüss <> Fri, 30 July 2021 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 614733A2C2E; Fri, 30 Jul 2021 07:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 9LOcTr92ELlu; Fri, 30 Jul 2021 07:37:17 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD4583A2C27; Fri, 30 Jul 2021 07:37:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 16F414013C; Fri, 30 Jul 2021 16:37:14 +0200 (CEST)
Received: from ( [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by (Postfix) with ESMTP id A020BD0; Fri, 30 Jul 2021 16:37:10 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTPSA id 3920F101; Fri, 30 Jul 2021 16:37:10 +0200 (CEST)
Received: (nullmailer pid 3265276 invoked by uid 1000); Fri, 30 Jul 2021 14:36:04 -0000
Date: Fri, 30 Jul 2021 16:36:04 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <>
To: Carsten Bormann <>
Message-ID: <YQQOVDqvdoENl/>
References: <> <> <YQPz8H8WCUDXk/5/> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q4Sn7kRYd5q/s0ec"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Cbor] Using cddl-control to dissect byte strings
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, 30 Jul 2021 14:37:22 -0000


> In this case, there simply is ambiguity where the bytes go (and the number of solutions is exactly the number of input bytes).
> (It is not quite clear how to apply “preferred choice” here; greedy matching might be the equivalent.
> Hope that uncertainty doesn’t stop us from going forward with .cat.)

I don't think so.

First, it talks about validation and not parsing/matching, and there
ambiguity is fine.

And the, it already points out that tooling support is expected to be
limited once the arguments to .cat are not literals.

> But the complexity of regexp code is exactly what I wouldn’t want in CDDL…

I don't see a need to go out of our ways to accommodate creative abuses.
Whoever wants to use it more seriously for these purposes is still
welcome to define controls that suit their needs (but may find that they
don't gain wide traction due to the new complexity).


Beware paths which narrow future possibilities. Such paths divert you
from infinity into lethal traps.
  -- Leto Atreides II