Re: [Cbor] Glitch in cddl-control AUTH48

Barry Leiba <> Thu, 09 December 2021 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F1C93A0C38 for <>; Thu, 9 Dec 2021 11:52:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GDTzFxXEuh8F for <>; Thu, 9 Dec 2021 11:52:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D78DD3A0C34 for <>; Thu, 9 Dec 2021 11:52:39 -0800 (PST)
Received: by with SMTP id o1so12900552uap.4 for <>; Thu, 09 Dec 2021 11:52:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DKZvBvudOzHlVCRbytSTnK11G0kSMURtrLSd8Jj3B+I=; b=KLY/W6+AZU9TRGWDJVCoQsJRpudTjocwnC6UBtv0Rug/hJVHymM4t6JL3i4HTdV/ur YAaeOLIlMD/m9jpv1uhbGu4rsWLQyNFSKh/6jG3qWnxeydECFwRY6CVMHmHtAYvGsOen WtwpU5swOwBAnDYc/p3hau1vPzGKByuHSu+10g2YGvcpygtioaddzvNpH7XEMnve7z8a iZ1SIWxrhr9zNKp2lSBpmCZrTAmVSzIARgR3nuaZ489Xt6ggqpv0MuB61g371tkw6TP2 NWpxs09DUdrckpzwiEYH7M9NyCenFAoVY1xej0vI7uuGzkiNA07/H7KGIs7mtV0pecJH 8SJg==
X-Gm-Message-State: AOAM5337VURslP/BNPu6nzANgSD6597CNhGpmCea6+kKg/zhu+2ghykB kCJ4HLj7I6kSn7XT75eHnYDwPpuXLDvgbDg+qlRvRY+M
X-Google-Smtp-Source: ABdhPJx8yGMBNdX4aLFArzDKfwy2bociab2St1rqBiZbW2Dl8eRVFTR8m/sPUpyttd73QlforyWTI2ZQymkLv+qHLFw=
X-Received: by 2002:ab0:7c56:: with SMTP id d22mr21992195uaw.74.1639079558624; Thu, 09 Dec 2021 11:52:38 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Thu, 09 Dec 2021 14:52:27 -0500
Message-ID: <>
To: Carsten Bormann <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Cbor] Glitch in cddl-control AUTH48
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: Thu, 09 Dec 2021 19:52:44 -0000

Thanks for posting this, Carsten, and thanks to Ira for a quick
response.  So as not to leave this open ended, I'm going to put a
deadline of 16 Dec on comments.  Lacking objections by then, we will
consider this accepted.  Please speak up now if you have a problem
with it.


On Tue, Dec 7, 2021 at 4:13 PM Carsten Bormann <> wrote:
> Hi,
> In the last step (“AUTH48”) before a document like cddl-control becomes an RFC, the author(s) are supposed to do a full reread to capture any problems that remained hidden during the incremental development of the I-D.
> Normally, we find a few editorial problems (which we did; they since have been dealt with).
> This time, however, there is also a technical contradiction between an illustration (Figure 4) and the normative text that would need to be considered in making up the example in the illustration (
> Background: cddl-control deliberately allows byte string literals in places where text string literals would really make more sense.  The reason is that the content of these literals often is specification text (ABNF) with embedded newlines, which are much easier to write as byte strings (where embedded newlines are allowed in RFC 8610) than as text strings (which inherit the JSON syntax that requires replacing every newline with a linear \n, creating essentially unreadable source text).  This is demonstrated in Figure 2:
> >    c = "foo" .cat '
> >      bar
> >      baz
> >    '
> >    ; on a system where the newline is \n, is the same string as:
> >    b = "foo\n  bar\n  baz\n"
> >
> >        Figure 2: An Example of Concatenation of Text and Byte Strings
> So we handled that properly for .cat and .det, but it turns out we did not for .abnf and .abnfb themselves.  Here, bullet 1 (which mostly is about the target and its interpretation) in Section 3 tersely says:
> >    The controller string MUST be a text string.
> This is not only not what is implemented in the cddl tool (which accepts a byte string just fine), it is also directly contradicting Figure 4:
> >    oid = bytes .abnfb 'oid
> >    oid = 1*arc
> >    roid = *arc
> >    arc = [nlsb] %x00-7f
> >    nlsb = %x81-ff *%x80-ff
> >    '
> >
> >              Figure 4: Dedenting example: result of first .det
> To me, this is an oversight where we simply didn’t update that sentence to the more useful way of accepting byte strings just for their better syntax handling newlines.  So I am suggesting we change the sentence to:
> > The controller MUST be a string.  When a byte string, it MUST be valid UTF-8 and is interpreted as the text string that has the same sequence of bytes.
> … which I’m suggesting as a fix in the excerpt of the AUTH48 processing mail copied below.  I apologize for not seeing this earlier.
> Our AD Francesca brought to my attention that is not copied on AUTH48 processing; I had forgotten that (other WGs do that copying habitually).  So I didn’t think to bring this up separately here, which I am now doing.
> You can find the text that will be published if we do make the last-minute change, at the end of the bullet:
> (Note that this text is an RFC-to-be, not the final RFC, please don’t start citing it as an RFC before it has been published.)
> Does anybody in the CBOR WG see a technical problem coming up with making this last minute fix?  If you see a problem (with implementation or use of byte string literals not only in the controller arguments of .cat/.det, but also in those of .abnf/.abnfb), please speak up quickly; this is the last item standing in the way towards publishing this RFC.
> Grüße, Carsten
> > Begin forwarded message:
> >
> > From: Carsten Bormann <>
> > Date: 2021-12-04 at 17:00:03 CET
> > To: <>
> > Cc:,, Christian Amsüss <>,
> > Message-Id: <>
> >
> […]
> > (0)
> > The last sentence in the first bullet in 3 says "The controller string MUST be a text string.”.
> > However, the previous section’s example in Figure 4 happens to use a byte string literal, and leniently allowing both kinds of strings is also what is implemented.
> > I believe loosening this up has the upside of simplifying cases such as in Figure 4, and no downside, so I would suggest:
> >
> > OLD:
> > The controller string MUST be a text string.
> > NEW:
> > The controller MUST be a string.  When a byte string, it MUST be valid UTF-8 and is interpreted as the text string that has the same sequence of bytes.
> […]
> _______________________________________________
> CBOR mailing list