Re: [Cbor] 🔔 WGLC with request for reviews on cbor-cddl-control-03

Christian Amsüss <> Wed, 16 June 2021 10:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8990D3A0FDE; Wed, 16 Jun 2021 03:25:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RyycxPAy_ej9; Wed, 16 Jun 2021 03:25:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 501F33A0FD7; Wed, 16 Jun 2021 03:24:59 -0700 (PDT)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by (Postfix) with ESMTPS id A3F4A408B4; Wed, 16 Jun 2021 12:24:56 +0200 (CEST)
Received: from ( [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by (Postfix) with ESMTP id D2E43D7; Wed, 16 Jun 2021 12:24:55 +0200 (CEST)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:d54e:296d:8a96:b348]) by (Postfix) with ESMTPSA id 9E3F37D; Wed, 16 Jun 2021 12:24:55 +0200 (CEST)
Received: (nullmailer pid 546012 invoked by uid 1000); Wed, 16 Jun 2021 10:24:55 -0000
Date: Wed, 16 Jun 2021 12:24:55 +0200
From: Christian Amsüss <>
To: Carsten Bormann <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="MCbWmozqgOeHvttu"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Cbor] 🔔 WGLC with request for reviews on cbor-cddl-control-03
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: Wed, 16 Jun 2021 10:25:14 -0000

Hello Carsten, hello CBOR group,

> The biggest confusion was created in one case where part of the spec
> said
> 	.feature “1.1”
> while another said
> 	.feature 1.1
> (yes, the floating point number.)
> The cddl tool treats these as different features (which they obviously
> are), but generates exactly the same output for these.
> This led to a little goose hunt…

The current draft text describes the features to "usually be a string",
ands adds that arrays can make sense too.

> So my provisional thinking is that this should be handled by better
> tool support and maybe adding a little warning text in the draft.

The text sounds good to me; a message produced by the tool ("Warning:
CDDL feature {} is neither a string nor an array. This is allowed but
unusual.") should catch floating features before they come into use.

> [on .det ]
> Well, after some use it turns out that it is much more likely that one
> needs both sides dedented, so maybe we switch to this [...]

This really sounds to me like it should be a unary control. We
don't have them, so either of the current proposals is viable for me --
but playing a bit with the unary control (more spitballing than actually
suggesting): We *can* have empty groups on the RHS, right? So could we
emulate unary operators by adopting a method-call-like pseudosyntax?

  cbor-tags-oid = '
    oid = 1*arc
    roid = *arc
    arc = [nlsb] %x00-7f
    nlsb = %x81-ff *%x80-ff
  ' .det ()

would read like any other language's method call. Granted, the same
parallel would be seen as terribly confusing, and 

    cbor-tags-oid-decrypted = cbor-tags-oid .det () .rot13 ()

as I understand wouldn't even make the dedented text available to the
obfuscating rot13 control.


To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom