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

Christian Amsüss <christian@amsuess.com> Wed, 16 June 2021 10:25 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8990D3A0FDE; Wed, 16 Jun 2021 03:25:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyycxPAy_ej9; Wed, 16 Jun 2021 03:25:00 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501F33A0FD7; Wed, 16 Jun 2021 03:24:59 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id A3F4A408B4; Wed, 16 Jun 2021 12:24:56 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D2E43D7; Wed, 16 Jun 2021 12:24:55 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:d54e:296d:8a96:b348]) by poseidon-mailbox.amsuess.com (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 =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: cbor@ietf.org, draft-ietf-cbor-cddl-control@ietf.org
Message-ID: <YMnRd6nrn8DT42Md@hephaistos.amsuess.com>
References: <162257177227.3108.15057636687346300680@ietfa.amsl.com> <YLZ9s74sRa+ivAEe@hephaistos.amsuess.com> <670FD4AE-B34D-4910-A5A3-CDDE29C493FE@tzi.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MCbWmozqgOeHvttu"
Content-Disposition: inline
In-Reply-To: <670FD4AE-B34D-4910-A5A3-CDDE29C493FE@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/xp9zn8qicAzCItKIpD7t5pg2xew>
Subject: Re: [Cbor] =?utf-8?q?=F0=9F=94=94_WGLC_with_request_for_reviews_on_c?= =?utf-8?q?bor-cddl-control-03?=
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=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.

BR
Christian

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