Re: [Cbor] Robert Wilton's No Objection on draft-ietf-cbor-7049bis-14: (with COMMENT)

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 23 September 2020 09:08 UTC

Return-Path: <rwilton@cisco.com>
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 BB0D53A0EAB; Wed, 23 Sep 2020 02:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fRA/U7kk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wlX2lnso
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 eARQ1fgwLdM4; Wed, 23 Sep 2020 02:08:08 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8623A0EAA; Wed, 23 Sep 2020 02:08:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15494; q=dns/txt; s=iport; t=1600852087; x=1602061687; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Fxtn2JG6mrxpgEXJP9kcIQaX+SLUmpWavFccrFz81sA=; b=fRA/U7kkveYUFtDsfRrqlQphkywfqwN5H3yT8NeLUi/jb1rC80YrM/Tc thR6Yc58kvByi/JrsvJzEa1RU+RCY1ttS9pd9auT0+GxlVEZiHuDnU7tj Zl9VaeQgTRJueuUoFRH4wnDHaY3jJhFVlJpboHUBhAas/Jj/ll8ycIEvA M=;
IronPort-PHdr: =?us-ascii?q?9a23=3ATzgYfxaIoviJUcL8JTWa4+H/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaRD5nJ6rRDkeWF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGBNT/IVrIrS764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzCQAgEGtf/51dJa1gHgEBCxIMQIM?= =?us-ascii?q?hUQdwWS8sCoQwg0YDjXmBApd0glMDVQsBAQENAQEjCgIEAQGESwIXghMCJDg?= =?us-ascii?q?TAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAQMSEREMAQEyBQELBAIBBgIOAwQ?= =?us-ascii?q?BAQMCJgICAjAVCAgCBA4FCBqDBYJLAy4BAwuaJJBpAoE5iGF2gTKDAQEBBYE?= =?us-ascii?q?zAYN1GIIQAwaBDiqCcYNphlIbgUE/gRFDghg1PoJcAQECAYFegxUzgi2QFIJ?= =?us-ascii?q?mPKJ5gQgKgmeIeZF6gwyJepQClHaIa5UcAgQCBAUCDgEBBYFrI4FXcBWDJFA?= =?us-ascii?q?XAg2OHwkDF4NOgmSCMIVCdDcCBgEJAQEDCXyMUgGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.77,293,1596499200"; d="scan'208";a="581437700"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Sep 2020 09:08:04 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 08N982oI023020 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Sep 2020 09:08:04 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 23 Sep 2020 04:08:01 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 23 Sep 2020 04:08:00 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 23 Sep 2020 05:08:00 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kzPkGPY84JafDEtfx1hOYiV+DEcxk78lpz+IxezK98dfuxaKjSJnLisOpuAdo4VwY1fsyrxpB2VJYV/+Zw2kVYg6XzZLkZGkD2cdrLkJqxcUaCM6m6FwTYTDu5itPg54jSyrKy/0wDbRpYLPcP7K07OSSqmshP7/nmGUY4KIdqaLze5fNbxqAkoaTOaKlw7OdKMZZMllIEvUF6fn7m42UVfElpBOZ/hQIBEVjm/hHGjJHPG+bUSp8Wll7DDRVKFw+hCO0xpgk24pxDD0QW8GEEsn9Pbt7yMShDgbyJNXcvonEQCsSZW6RaUiQw0JvBHOWPUEg98CQQaE69a3X2b8IA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fxtn2JG6mrxpgEXJP9kcIQaX+SLUmpWavFccrFz81sA=; b=NU3fQPaW0hORqUNewD6QFSnRMjirSDZw9wbw8Bk+sSolKi1+NpY/fLTiYkC/GM5BGMhvbrLb/qViOQLzIQLzvpvfbb3VHvtCYutf4UK72f2Xoq15HUEDeuk6ST9vDXTuRPdtsACPYdilmYLTZkcnd/5jpB4Ef8vl3im7T6vuFwF4JlIAJXISla1VQk8ITxh4VfID2ShxUX8SVF4yfU+GKqE4axxY80jKZ5nLOZTAW4vDSOlsa+p3ANRcbW4IhBKE2PQEUGqglXMWn0SFltsthwnk89gAAMnNGOUPXg7Zsh81orAZyq2BQvJJKZN0mzv0b+UXkyY0UJNs3KBMTYuYVA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Fxtn2JG6mrxpgEXJP9kcIQaX+SLUmpWavFccrFz81sA=; b=wlX2lnsoERSRKelaAXSm5LWcPQoOqtL6nR+ezBMaAT2Wwyl5jH87MSg66z8saDnfHyIj0a8iciuHiKwLUMzOrNY83z6USWPSpBqa1unWjujBYcImNwUKeM08K1vXV+xqwRAz9WS8EkypiBZYvTk6MIsMBusVtk2se0VeMuDUmPA=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3138.namprd11.prod.outlook.com (2603:10b6:208:7b::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Wed, 23 Sep 2020 09:07:59 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3391.026; Wed, 23 Sep 2020 09:07:59 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Carsten Bormann <cabo@tzi.org>
CC: "cbor@ietf.org" <cbor@ietf.org>, "draft-ietf-cbor-7049bis@ietf.org" <draft-ietf-cbor-7049bis@ietf.org>, The IESG <iesg@ietf.org>, "Francesca Palombini" <francesca.palombini@ericsson.com>, CBOR Working Group <cbor-chairs@ietf.org>
Thread-Topic: Robert Wilton's No Objection on draft-ietf-cbor-7049bis-14: (with COMMENT)
Thread-Index: AQHWhqAsuA1HuQfPT0GIXJC97/cguKlzmrUAgAJpulA=
Date: Wed, 23 Sep 2020 09:07:59 +0000
Message-ID: <MN2PR11MB4366E469DBA7F74AC045D34EB5380@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <159965254327.29648.15632221792885283453@ietfa.amsl.com> <3647F203-B61C-4096-953D-07A87130D342@tzi.org>
In-Reply-To: <3647F203-B61C-4096-953D-07A87130D342@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.12.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a280c1d1-92ac-4fc8-b9f6-08d85fa02b25
x-ms-traffictypediagnostic: BL0PR11MB3138:
x-microsoft-antispam-prvs: <BL0PR11MB3138EC90BC8ABB6F6393CD82B5380@BL0PR11MB3138.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: qPmeBknQtJTCd5Op4WDvpculrpNd0HRVrd4naVoO6qmvc7Cs97W8jX9pFyQLa0LdTFxEIlkRss7OAVVTNwUovIkOR75oKAVXBhxRXxyQLbOYGs/cRyo2m65I9XJXASqgnHKYMnOWT/RudhPdnZ8xeIbjKJ2RbNau9umCTKEIrW4AmfErTV/Yi1G5WYYQCalJ6H9qTtd1ZUpCVRad9yzwFtgIlxHy2dOr7wgSuhCP3x23LwiO2vJqMN8WOQ8wVAP6kOwKMxvmG31qDfSMZM3wfb5p0Dvi74G2OZxjWVH++mVvlmPHuQIaPJ0hwiihdsae80O9joStXmeyZVLWkr6Ft8DSG99YSiehUOmvwNE6ZyCIz+5PFH2DKweVJR8WkZ401H4IjhCVH6BONPVDELkAUMlAz/Jp8lrtM0u3FEgLSaxxHR774qq0CaEIEuV2HUst
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(39860400002)(396003)(136003)(346002)(2906002)(478600001)(66476007)(5660300002)(8676002)(7696005)(966005)(55016002)(8936002)(9686003)(6916009)(54906003)(33656002)(30864003)(83380400001)(52536014)(71200400001)(64756008)(66446008)(76116006)(186003)(53546011)(316002)(86362001)(6506007)(26005)(4326008)(66946007)(66556008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: +wrPUSbXeFppsl19gUsZktvf7MWxssUy3m6GcQqh8iD1jS4eAo4Y/F95q3i0I3kb0C8yQ8zb2xhvHZswPXQt/WXSnCtLhEhb3GQljFl66o12G6uY2v1R4lmAuCsofuDRIvDhgvB0jvrrSWSLmV8GMB7Y8OL6Yb5YeGcsOI4YiOOOshnF6cc4Uu6PssvsY2cyY0V0xbb7jRA2wenGXX5UTF5ofd5G1e5hPCtm51QS8wPBpaHjRZd6K2RTbmac3xJbsUI9gBBNzhHvgVn51TzbCHQmFhgBB+JQ2+r7mowUEBIDb0L5wVzpCtM3a59DyMcZv7N2RDzhgmArewBD4ejI7UfgyhELEZrXSN15FQI17FVzaMiKcJi+YIb965ggNEiuRJ5ZwR6nYvix2uyQClbMpEpqOm33nGcSDy8LEnIrrElkl8VOIyzv5dNe87X5CpfqV9Wrt6sKGgxHjTVbDTG+SB5zvG+v2SlBSM2Cm5PSD3Ux2VQiguqPpQkDWykMKGLllzeEGXdhVWsgO78g71MiARo4I9a7gr79xzQJVzh9BUoVU+Ql3iWzRBcXfGAnbqUWSOFi0UCjn4Fy8SFRZkDV2+dpN+eLcT57X61Djqm0AMKfE1MlImSZ3WIxq54LHzjcOEaqVKt0ThWolxuVdUwiCg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a280c1d1-92ac-4fc8-b9f6-08d85fa02b25
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2020 09:07:59.5504 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: X85RSX2jvyE461QHIKHXqqM3GFexyUX93Cki/ZBEIGKvPzFm3IinUoNhlVl2rqmktMD/PZVtDECO6fiSzh+eFQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3138
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/5X5j_NOkpbSIL7OjyW9ujxa8pmw>
Subject: Re: [Cbor] Robert Wilton's No Objection on draft-ietf-cbor-7049bis-14: (with 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: Wed, 23 Sep 2020 09:08:11 -0000

Hi Carsten,

All your comments/updates are fine with me.  Thanks for the explanation.

Regards,
Rob


> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of Carsten Bormann
> Sent: 21 September 2020 21:16
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: cbor@ietf.org; draft-ietf-cbor-7049bis@ietf.org; The IESG
> <iesg@ietf.org>rg>; Francesca Palombini <francesca.palombini@ericsson.com>om>;
> CBOR Working Group <cbor-chairs@ietf.org>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-cbor-7049bis-14:
> (with COMMENT)
> 
> Hi Rob,
> 
> thank you for your kind words about CBOR and for mentioning the signed
> integer range issue.
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Hi,
> >
> > Thank you for your work on this document, and bringing this to full
> standard.
> > Since I'm a big fan of CBOR and try to evangelize it whenever possible
> I'm
> > please to see this happening.
> >
> > However, I have one minor annoyance with CBOR, which is the range of
> negative
> > numbers that are encoded in major type 1.  My gripe is that the encoding
> allows
> > for negative integers that are not easily representable in a simple form
> in
> > most programming languages without using something equivalent to
> BigInteger.
> 
> Right.  The underlying observation was that unsigned integers are way more
> likely to be used in constrained environments than signed integers.  We
> didn't want to waste a significant part of the code space, so negative
> integers were designed to be non-overlapping with unsigned ones, and that
> gives us a bit more than the usual bit-stealing sign representation used
> for signed integers.  That may be less familiar than just mapping C's data
> types, but it certainly makes sense for the application.  So you can have
> a range from -256..255 that fits into a single byte (plus the initial
> byte).
> 
> > E.g., all values below -2^63 won't fit into a int64 type, and the value
> 2^64
> > won't even fit into an uint64 that was used to represent a negative
> number
> > (obviously unless it followed the CBOR encoding semantics of being
> offset by 1)
> 
> We don't go into good platform representations of 65-bit signed integers.
> 
> > For a generic decoder I presume that this isn't an issue since it can
> fallback
> > to something like BigInteger.  But for other decoders handling normal
> sized
> > integer datatypes I would presume that they would effectively presumably
> regard
> > anything smaller than -2^63 as not well-formed for their specific
> problem
> > domain.
> 
> Certainly well-formed, but not "expected" according to the set of
> application data models they can support.
> 
> When we do an update of the CDDL spec (RFC 8610), we might spend a little
> more time on explaining why you rarely want to use the full 65-bit signed
> types but instead be more specific about what you need.  But CBOR itself
> simply happily can represent what you give it, and a bit more than you'd
> expect at first.
> 
> > I'm not suggesting that this should be changed (hence comment not a
> discuss),
> > but there are a couple of places in the document that it might be
> helpful to
> > warn implementors about this, that I have mentioned below.
> >
> > Other minor comments:
> >
> >    3.  Specification of the CBOR Encoding
> >
> >       Major type 0:  an integer in the range 0..2**64-1 inclusive.  The
> >          value of the encoded item is the argument itself.  For example,
> >          the integer 10 is denoted as the one byte 0b000_01010 (major
> type
> >          0, additional information 10).  The integer 500 would be
> >          0b000_11001 (major type 0, additional information 25) followed
> by
> >          the two bytes 0x01f4, which is 500 in decimal.
> >
> >       Major type 1:  a negative integer in the range -2**64..-1
> inclusive.
> >          The value of the item is -1 minus the argument.  For example,
> the
> >          integer -500 would be 0b001_11001 (major type 1, additional
> >          information 25) followed by the two bytes 0x01f3, which is 499
> in
> >          decimal.
> >
> > Would writing "0 to 2**64-1" be more clear than 0..2**64-1?
> 
> (Sorry, CDDL thinking here, https://tools.ietf.org/html/rfc8610#section-
> 2.2.2.1.)
> We use this notation some 35 times in the document, so adding some text in
> the terminology section makes sense (now in 1.2).
> (We won't use the opportunity to delete all 4 instances of "inclusive",
> though.)
> 
> > Or otherwise
> > perhaps mention that in the terminology section that "x..y" is used to
> > represent an inclusive range set of all values from x to y, including x
> and y.
> > Also, noting that here where ".." has been used it explicit states that
> it is
> > inclusive, but that doesn't appear to be the case everywhere.
> >
> > I suggest changing "Major type 0:  an integer ..." back to "Major type
> 0:  an
> > unsigned integer", as in RFC7049, because the type is referred to as
> "Unsigned
> > integer".  It also makes it more consistent with the definition of Major
> type 1.
> 
> Indeed; this lack of symmetry already came up in other discussions.
> 
> >    3.2.1.  The "break" Stop Code
> >
> >       The "break" stop code is encoded with major type 7 and additional
> >       information value 31 (0b111_11111).  It is not itself a data item:
> it
> >       is just a syntactic feature to close an indefinite-length item.
> >
> >       If the "break" stop code appears anywhere where a data item is
> >       expected, other than directly inside an indefinite-length string,
> >       array, or map -- for example directly inside a definite-length
> array
> >       or map -- the enclosing item is not well-formed.
> >
> > I was wondering whether it would be helpful to clarify that by
> > indefinite-length string it means text or byte string?  Although this
> becomes
> > clear in section 3.2.3 anyway ...  My thinking is that section 3.2 lists
> 4
> > types that can have indefinite length, and then in this section both
> types are
> > string are treated together.
> 
> When discussing CBOR data models, we tend to group major types 2 and 3
> as "strings", and 4 and 5 as "containers".  We don't use the latter in
> 7049bis; we do use unqualified "string" though.
> 
> We used the end of 3.2 to add another expansion of this term.
> 
> >    3.2.3.  Indefinite-Length Byte Strings and Text Strings
> >
> > Would it be helpful to clarify that the chunks must be the same type.
> E.g. you
> > cannot have a byte string that contains text string chunks and vice-
> versa?
> 
> We do say:
> 
>    If any item between the indefinite-length string indicator
>    (0b010_11111 or 0b011_11111) and the "break" stop code is not a
>    definite-length string item of the same major type, the string is
>    not well-formed.
> 
> https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-
> 7049bis.html#rfc.section.3.2.3
> 
> >
> >    3.4.5.2.  Expected Later Encoding for CBOR-to-JSON Converters
> >
> > "Tags number 21 to 23 ..." => "Tag numbers 21 to 23 ..."
> 
> Fixed.
> 
> >    4.2.1.  Core Deterministic Encoding Requirements
> >
> >          Floating-point values also MUST use the shortest form that
> >          preserves the value, e.g. 1.5 is encoded as 0xf93e00 and
> 1000000.5
> >          as 0xfa49742408.  (One implementation of this is to have all
> >          floats start as a 64-bit float, then do a test conversion to a
> >          32-bit float; if the result is the same numeric value, use the
> >
> > I find this paragraph slightly opaque, and I would suggest spelling out
> that
> > 1.5 has been encoded as a 16 bit IEEE float, whereas 1.00000005 has been
> > encoded as a 32 bit IEEE float.  The same comment applies to 4.2.2 as
> well.
> 
> Added the terms binary16/32/64 as used in other parts of the document.
> 
> > I also noticed that in most places the document refers to "floating-
> point" but
> > in a few places "floating point" is used instead.
> 
> Fixed a few occurrences, thanks.
> (We did this previously, and then Brownian motion crept in.)
> 
> >    5.5.  Numbers
> >
> > As per my top comment, I think that it would be useful to raise in this
> section
> > that CBOR can encode negative values that cannot normally be represented
> in a
> > compact form.
> 
> Added in the middle of the first paragraph:
> 
>   Another example is that, since CBOR keeps the sign bit for its integer
>   representation in the major type, it has one bit more for signed
>   numbers of a certain length (e.g., -2\*\*64..2\*\*64-1 for 1+8-byte
>   integers) than the typical platform signed integer representation of
>   the same length (-2\*\*63..2\*\*63-1 for 8-byte int64_t).
> 
> 
> >    6.1.  Converting from CBOR to JSON
> >
> >       Most of the types in CBOR have direct analogs in JSON.  However,
> some
> >       do not, and someone implementing a CBOR-to-JSON converter has to
> >       consider what to do in those cases.  The following non-normative
> >       advice deals with these by converting them to a single substitute
> >       value, such as a JSON null.
> >
> >       *  An integer (major type 0 or 1) becomes a JSON number.
> >
> > It is worth referencing back to section 5.5 on Javascript numbers and
> > explicitly warn that not all CBOR integers can be precisely represented
> as JSON
> > numbers, and there may be a loss of precision?
> 
> We added a paragraph at the end of 6.1 that points to RFC 7493.
> 
> >    Appendix C.  Pseudocode
> >
> >       Major types 0 and 1 are designed in such a way that they can be
> >       encoded in C from a signed integer without actually doing an if-
> then-
> >       else for positive/negative (Figure 2).  This uses the fact that
> >       (-1-n), the transformation for major type 1, is the same as ~n
> >       (bitwise complement) in C unsigned arithmetic; ~n can then be
> >       expressed as (-1)^n for the negative case, while 0^n leaves n
> >       unchanged for non-negative.  The sign of a number can be converted
> to
> >       -1 for negative and 0 for non-negative (0 or positive) by
> arithmetic-
> >       shifting the number by one bit less than the bit length of the
> number
> >       (for example, by 63 for 64-bit numbers).
> >
> > This was another place where I thought that it might be useful to warn
> the
> > reader about decoding negative integers and the risk of overflow taking
> a major
> > 1 value into an int64 native type.
> 
> This paragraph is about describing the pseudocode that follows, which
> is an encoder.
> 
> We don't have pseudocode that shows how a decoder might range-check
> encoded data items for fit into the receiving data structures; this is
> so platform specific that I don't think we should provide any
> (and certainly not at this stage of the document).
> 
> All these changes are in ae2bab7 and 94f98be, now PR #216 (merged):
> https://github.com/cbor-wg/CBORbis/pull/216
> 
> Grüße, Carsten