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

Paul Hoffman <paul.hoffman@icann.org> Fri, 18 September 2020 14:45 UTC

Return-Path: <paul.hoffman@icann.org>
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 ACD263A0B6F; Fri, 18 Sep 2020 07:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvI98Dixv1dr; Fri, 18 Sep 2020 07:45:19 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EA43A0B69; Fri, 18 Sep 2020 07:45:19 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) 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 MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) 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 MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0659.006; Fri, 18 Sep 2020 07:45:17 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "cbor@ietf.org" <cbor@ietf.org>
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: <E2C5EB38-72FD-4055-BCC1-BE24271984F3@icann.org>
References: <159951641517.13535.7424396818917958932@ietfa.amsl.com>
In-Reply-To: <159951641517.13535.7424396818917958932@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
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: <https://mailarchive.ietf.org/arch/msg/cbor/Fqqce9OSOYt2i8pwVgYdyLvWMpQ>
Subject: Re: [Cbor] [Ext] Benjamin Kaduk's Discuss on draft-ietf-cbor-7049bis-14: (with DISCUSS and COMMENT)
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: 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 <noreply@ietf.org> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-cbor-7049bis-14: Discuss
> 
> […]
> ----------------------------------------------------------------------
> 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 <https://github.com/cbor-wg/CBORbis/pull/210> 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
<https://github.com/cbor-wg/CBORbis/pull/212>.

> 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 <https://github.com/cbor-wg/CBORbis/pull/212>.

> 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: http://eel.is/c++draft/basic.fundamental

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 <https://github.com/cbor-wg/CBORbis/pull/208>.

> 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: http://eel.is/c++draft/expr.shift Also now referenced in 1.2
in <https://github.com/cbor-wg/CBORbis/pull/208>.

> 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 <https://github.com/cbor-wg/CBORbis/pull/208>.