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