Re: [Cbor] [Ext] Benjamin Kaduk's Discuss on draft-ietf-cbor-7049bis-14: (with DISCUSS and COMMENT)

Paul Hoffman <> Fri, 18 September 2020 14:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACD263A0B6F; Fri, 18 Sep 2020 07:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SvI98Dixv1dr; Fri, 18 Sep 2020 07:45:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 43EA43A0B69; Fri, 18 Sep 2020 07:45:19 -0700 (PDT)
Received: from ( []) by ( with ESMTPS id 08IEjI8O003120 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Sep 2020 14:45:18 GMT
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.659.4; Fri, 18 Sep 2020 07:45:17 -0700
Received: from ([]) by ([]) with mapi id 15.02.0659.006; Fri, 18 Sep 2020 07:45:17 -0700
From: Paul Hoffman <>
To: Benjamin Kaduk <>
CC: The IESG <>, "" <>
Thread-Topic: [Ext] Benjamin Kaduk's Discuss on draft-ietf-cbor-7049bis-14: (with DISCUSS and COMMENT)
Thread-Index: AQHWhWM26/+FCmYP7UiGNgB86FbldKlu/zaA
Date: Fri, 18 Sep 2020 14:45:17 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_F3160899-25F4-4C17-B284-BA5D21C073B9"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-18_14:2020-09-16, 2020-09-18 signatures=0
Archived-At: <>
Subject: Re: [Cbor] [Ext] Benjamin Kaduk's Discuss on draft-ietf-cbor-7049bis-14: (with DISCUSS and COMMENT)
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: Fri, 18 Sep 2020 14:45:21 -0000

Thank you for the extensive review! We'll respond to the DISCUSS parts of the
ballot here; a later response will cover the COMMENTs.

--Paul Hoffman

On 2020-09-08, at 00:06, Benjamin Kaduk via Datatracker <> wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-cbor-7049bis-14: Discuss
> […]
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thanks for this document; it's generally well-written and the changes
> since 7049 are helpful.  I do have a few points that may need discussion
> before publication, though.
> Let's discuss whether the framing of tag number 35 for "regular
> expressions that are roughly in [PCRE] form or a version of the
> JavaScript regular expression syntax" meets the interoperability
> expectations for Internet Standard status (bearing in mind that we are
> defining a data format and not a protocol).  I note that it is okay
> to leave the codepoint allocated with the current meaning and the
> previous document as its reference, but decline to discuss it in the
> document going for STD (we are in the process of doing that with COSE
> countersignatures at the moment).

* — tag 35

Please see <> for the proposed
resolution. This PR is currently open.

> The example in Section 5 of "the item is a map that has byte strings for
> keys and contains at least one pair whose key is 0xab01" seems to be in
> violation of the definition of a valid map, since applications are not
> allowed to rely on invalid behavior.  (That is, the implied "more than
> one pair whose key is 0xab01" would be invalid.)

We have now changed this to "...and contains a pair whose key is 0xab01..." in

> I think that the new deterministic encoding rules for sorting map keys
> should be clear about whether "no content" sorts before or after
> "content present" -- that is, how 0x10 and 0x1020 are ordered when the
> 0x10 byte is identical and we have to compare \<nothing> with 0x20.

We have now added an implementation note at the end of 4.2.1
in <>.

> The discussion in Appendix C suggests that C (programming language)
> implementations all use two's-complement representation of signed
> integers; this requirement is present in POSIX but not C itself (I
> verified this for C99 and C11).

Indeed. This no longer useful variation allowed by C finally seems to be fixed
in draft C++ 20, which unanimously passed its final technical approval ballot
on September 4, 2020:

We agree the best way to handle this is to make this requirement explicit.
C++20 is now referenced in new text in the part of the terminology section that
talks about C-style notation in <>.

> Additionally, the encode_sint() function (also Appendix C) relies on C
> implementation-defined behavior while right-shifting a signed integer.

Similarly, this needless wart in C finally seems to be fixed in draft C++ 20 as
well: Also now referenced in 1.2
in <>.

> The C decode_half() function in Appendix D assumes that 'int' is wider
> than 16 bits (since assigning a value to an int16_t variable when the
> value is not representable in int16_t incurs implementation-defined
> behavior).  Given that this spec is specifically targetting constrained
> devices, it's not clear that such an assumption is justified.  (It also
> right shifts a signed integer, incurring the same implementation-defined
> behavior mentioned above.  (The bitwise AND against 0x8000 is also
> problematic for an int16_t.))

Good point.  This can easily be fixed by declaring all the ints in that fragment as unsigneds instead.
Done in <>.