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

Carsten Bormann <cabo@tzi.org> Wed, 16 June 2021 11:31 UTC

Return-Path: <cabo@tzi.org>
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 9D3113A127D; Wed, 16 Jun 2021 04:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1enVp3P3DzUv; Wed, 16 Jun 2021 04:31:54 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF05E3A1281; Wed, 16 Jun 2021 04:31:53 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4G4jh651YYz2xJ4; Wed, 16 Jun 2021 13:31:50 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_5C01BBAC-3DD7-4A89-94E7-21DFDA2E734C"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <YMnRd6nrn8DT42Md@hephaistos.amsuess.com>
Date: Wed, 16 Jun 2021 13:31:50 +0200
Cc: cbor@ietf.org, draft-ietf-cbor-cddl-control@ietf.org
X-Mao-Original-Outgoing-Id: 645535909.506411-8ead0cf3aeb0e9c2e1e3e31a77eda721
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A3EF9E0-F1E9-47D0-A42B-AB4A9D505CAA@tzi.org>
References: <162257177227.3108.15057636687346300680@ietfa.amsl.com> <YLZ9s74sRa+ivAEe@hephaistos.amsuess.com> <670FD4AE-B34D-4910-A5A3-CDDE29C493FE@tzi.org> <YMnRd6nrn8DT42Md@hephaistos.amsuess.com>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/UpXwgAHfjF3KkvQh64nuBBzb05o>
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 11:31:59 -0000

Hi Christian,

> On 2021-06-16, at 12:24, Christian Amsüss <christian@amsuess.com> wrote:
> 
> Signed PGP part
> 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.

Good point; a warning has been added in 0.8.25.

>> [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?

Unfortunately, the RHS needs to be a type (as does the LHS).
That is a limitation of control operators; they operate on types only.

> 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 ()

(Even [] doesn’t work with the current tool as .det complains about its RHS not being a string.  Creating a special case just so we can avoid ‘’ or “” doesn’t strike me as a great solution.)

> 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 ()

Control operators are non-associative, so you'd have to spend a few pairs of parentheses, which give you control over:

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

Grüße, Carsten