Subject: [Cbor] Reviewing cbor-cddl-control

From: Christian Amsüss <[email-masked]>
Date: Mon, 26 Jul 2021 16:39:05 +0200

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)

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Jul 2021 16:57:08 +0200

Hi Christian,

> On 2021-07-26, at 16:39, Christian Amsüss <[email-masked]> wrote:
> 
> Hello Carsten,
> 

Approved PR, would like one more pair of eyes before merging.

>  2.2.2.1). Is there a particular reason to implicitly cast here?

Only that there is no other way to do it (the same as with strings below).

>      szx .add (uint .bits &(m: 4))

I hope we never reach the point that the C++ template language people reached when they suddenly noticed that it is now Turing equivalent, and that people had started programming in that new programming sublanguage.

But the above is fine if one or more intermediate rules are added — these can make it more obvious what is happening.

>  although one'd pretty quickly run into the need for a .mul / .shift.

I could have used that in draft-ietf-ace-aif, why didn’t you tell me earlier?
(Just kidding.)

>  and controllers being (non-unique) types apply to all of the computed

Yes!

>      option_value = '' .cat ("" .cat bstr)

I’m not sure we should let you near a CDDL tool any more.

>  ... but I doubt it warrants pointing out.

It will be an idiom in no time (the "Amsüss hairpin"?).
The nice thing is that idioms like this can be encapsulated in a generic rule, so you could have:

Valid-utf-8-bytes<T> = ‘’ .cat (“” .cat T)

and live happy ever after…

> be ready to leave the WG with the next published version.

I’ll try my best to get this done by the end of IETF week (not necessarily by the end of IETF).

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 26 Jul 2021 21:01:49 +0200

Hello Carsten,

brief follow-up from during the shepherd write-up:

there's some inconsistency in that the `foo = { kind: bar` example and
the `JC<J,C>` one do not exist as a figure but just as pre-formatted
text; I think they should have numbers and labels as well.

(The `CRLF = ` line falls in the same category in theory, but being a
single line it can probably stay as it is).

BR
Christian

-- 
Yesterday is history, tomorrow is a mystery, and today is a gift. That
is why it is called the present.
  -- ancient saying

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 31 Jul 2021 03:14:29 +0200

> text; I think they should have numbers and labels as well.

Fixed in -04.

> single line it can probably stay as it is).

Indeed, but added sourcecode-type `abnf`.

> and controllers being (non-unique) types apply to all of the computed

Yes!  Moved the text up to the introduction of Section 2 and expanded it a little bit.

Grüße, Carsten