Re: [Cbor] Review of draft-bormann-cbor-cddl-control-01

Carsten Bormann <> Wed, 02 September 2020 11:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0E403A0EEA; Wed, 2 Sep 2020 04:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ufh6m5zH0ASC; Wed, 2 Sep 2020 04:02:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B82D73A0EE9; Wed, 2 Sep 2020 04:02:39 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4BhLct1HXSzyY6; Wed, 2 Sep 2020 13:02:38 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <01b601d67e79$594d2960$0be77c20$>
Date: Wed, 2 Sep 2020 13:02:37 +0200
X-Mao-Original-Outgoing-Id: 620737357.553142-17c2b2fb8bf3381136985158db309c15
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <01b601d67e79$594d2960$0be77c20$>
To: Jim Schaad <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] Review of draft-bormann-cbor-cddl-control-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Sep 2020 11:02:43 -0000

Hi Jim,

thank you for the comments!

> On 2020-08-30, at 04:57, Jim Schaad <> wrote:
> A couple of comments on this document.  It is very possible that I have
> already made this comments and they are on your to do list.
> 1.  Abstract needs to be expanded to identify what operators are in this
> document.


> 2. Bikeshed topic - I don't really like the name of the .feature control.
> The problem is that the definition of a feature is not at all clear from the
> name of the control.  Among other things it does not say which extension
> points are targeted.   I don't know that I have a good suggestion at this
> point but something long the lines of .map-extensions is a much tighter
> description of what is here.

I really like that name, and (once you know what the .feature control does) something clumsy like map-extensions is further away from being readable than .feature.

> 3.  Section 2.1 - I just ran into a potential issue with RFC 8610 that is
> highlighted here.    On my system I would expect the result to be b =
> "foo\r\n  bar\r\n  baz\r\n".  Both "\n" and "\r\n" are considered as legal
> inside of a byte string value and I did not find text to resolve it for the
> non-hex/base64 case (where it is not relevant).  

Indeed, this is not specified in RFC 8610, which I consider a todo.
I wrote draft-bormann-dispatch-modern-network-unicode to address this class of problem, but that hasn’t seen recent updates (it will, soon).
For now, I have updated the comment to say that the equivalent is for \n-newline systems.

> 4. Section 4 - Define behavior .feature is referenced outside of a map key.
> Or are there other places where it can be used and thus these need to be
> enumerated.

It can be used anywhere.
No need to enumerate because it literally is anywhere.

Where does it say map key?
Oh, that’s the example.

(The biggest real-life example that I know of, , also uses keys map entries, but also map values and generic values in an any-like construct.)
I copied over a type extension example.

> 5. Acknowledgements - I think this does not read correctly as it says that I
> suggested improvements on .feature rather than the document as a whole which
> is what I think you meant to say.


> 6. Section 3 - The description says that following is legal, but does not
> give a clue on what the correct behavior would be:
> Value = text . abnf "full-date\n"
> The text says that it is followed by zero or more rules, I would assume that
> at least one rule would be required and the given target name must exist as
> a rulename for a rule.  I think you might want to switch from element to
> rulename in this text as well.  Element would allow for
> Value = text .abnf "(WSP / CRLF WSP”)

(If WSP and CRLF are defined below(*) and the position of the quote is fixed.)
Is that a problem?

Zero rules make sense in very simple applications such as:

Number = text .abnf “1*%x30-39"

If we change element to rulename, that usage of course goes away.

(*) Added a sentence making this clearer.

Changes are in

Grüße, Carsten