[Cbor] Reviewing cbor-cddl-control
Christian Amsüss <christian@amsuess.com> Mon, 26 July 2021 14:39 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 8383B3A167E; Mon, 26 Jul 2021 07:39:19 -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 g4p-XMDJvAdZ; Mon, 26 Jul 2021 07:39:14 -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 AE4373A167D; Mon, 26 Jul 2021 07:39:14 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 4701F401B5; Mon, 26 Jul 2021 16:39:11 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 75298D0; Mon, 26 Jul 2021 16:39:10 +0200 (CEST)
Received: from hephaistos.amsuess.com (91.141.53.23.wireless.dyn.drei.com [91.141.53.23]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C0D4C101; Mon, 26 Jul 2021 16:39:09 +0200 (CEST)
Received: (nullmailer pid 2947159 invoked by uid 1000); Mon, 26 Jul 2021 14:39:05 -0000
Date: Mon, 26 Jul 2021 16:39:05 +0200
From: Christian Amsüss <christian@amsuess.com>
To: draft-ietf-cbor-cddl-control@ietf.org, cbor@ietf.org
Message-ID: <YP7JCZPXLwuIK+Gi@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="j3Lywp3L1RfS0en1"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/GfZOP6SNthNTLZlgAZbdoAhrbmU>
Subject: [Cbor] Reviewing cbor-cddl-control
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: Mon, 26 Jul 2021 14:39:20 -0000
Hello Carsten, as part of my shepherd writeup I'm also doing a full review of cbor-cddl-control, in the version d85f6530 from the wglc branch that already addresses Henk's comments. I find this document well rounded and readable, with most items more curious pokings at the mechanisms than necessary changes. * Two editorial items are better handled as a PR: https://github.com/cbor-wg/cddl-control/pull/8 * Numeric addition: While well-defined as written, implicit mixing of integers and floats feels a bit inconsistent with CDDL's take on ranges (which is more type strict in that respect in its section 2.2.2.1). Is there a particular reason to implicitly cast here? * In Section 2.2 String Concatenation, it is pointed out that the sides are not necessarily unique. The mental example forming here for me is ((bstr .abnfb "reg-name") .cat ': ') .cat (bstr .regexp some-expression) that make the "not all tools may be able to work with" easy to understand. Conceptualy, the same would apply to numeric addition; for example, parts of the CoAP block-wise option could be expressed as szx = uint .le 6 szx .add (uint .bits &(m: 4)) although one'd pretty quickly run into the need for a .mul / .shift. If such constructions are legal, shouldn't the remark on the targets and controllers being (non-unique) types apply to all of the computed literals? * On the concatenation conversion between byte and text strings: A corner use case of this would be type conversion, eg. label_unicode = "hello" label_binary = '' .cat label A potential application is constraining a byte-string to valid UTF-8 encodings: option_value = '' .cat ("" .cat bstr) ... but I doubt it warrants pointing out. I'm starting the shepherd writeup next; from the looks of it this will be ready to leave the WG with the next published version. Best regards, and thanks to everyone involved in getting this text where it is now Christian -- You don't become great by trying to be great. You become great by wanting to do something, and then doing it so hard that you become great in the process. -- Marie Curie (as quoted by Randall Munroe)
- [Cbor] Reviewing cbor-cddl-control Christian Amsüss
- Re: [Cbor] Reviewing cbor-cddl-control Carsten Bormann
- Re: [Cbor] Reviewing cbor-cddl-control Christian Amsüss
- Re: [Cbor] Reviewing cbor-cddl-control Carsten Bormann