Re: [Cbor] Updated Drafts for dCBOR I-D and Gordian Envelope Structured Data Format I-D & IANA Tag Registration

[Carsten Bormann <[e-mail]>]

On 31. May 2023, at 10:22, Wolf McNally <[e-mail]> wrote:
> 
> *must* support BigNum

A quick comment on this misconception:

“Support BigNum” is not a binary yes/no.

It is in no way harder to decode

1b 00 00 00 10 00 00 00 00

into 68719476736

than it is to decode

c2 45 10 00 00 00 00

into the same number.

(That doesn’t mean that we’d always want to encode things this way; I’m just trying to correct the misconception.
The shortest CBOR encoding of the above mathematical value is

fa 51 80 00 00

but many decoders would present this as a number of a different platform type, 68719476736.0, to the application.)

The discussion here is mostly about how to map application data types into elements of the CBOR generic data model, and back (often on a different platform!).

On some platforms, the mapping is so obvious that it just doesn’t come up as a question.
Some platforms provide challenges, however:

- Lua doesn’t distinguish arrays and maps.  Some heuristic might help, or an explicit indication from the application.

- JavaScript doesn’t distinguish int and float, but then also has another separate int type, bigint.  One might be tempted to map bigint into CBOR bignums, and do a mechanized mapping of the single number datatype into int and float.  One problem with the latter is that not all CBOR integers (even without bignum) can be mapped into JavaScript’s 53-bit numbers.  In any case, this is a challenge where some heuristic might help, or an explicit indication from the application.

In the platform mapping, the question is how the CBOR number types (besides the three I mentioned, there are tag 4 and 5 as well) are related to each other, specifically, how fungible they are.

RFC 7049 was leaning towards placing int and float into the same bin (like dCBOR does), and we learned enough in the first seven years of CBOR that we are no longer favoring this in RFC 8949.  The line between int and bignum was always very thin (we essentially didn’t want to provide i128/u128 as a special case, so put this into bignum); a platform that has i128/u128 might very well map some bignums into these.  Most 64-bit only platforms need separate types for uint64 and int64, and then still need a third for the lower half of nint64.  And so on.

What I’m trying to point out here is that mixing this issue with deterministic encoding might be blurring it more than helping.
In the end, the application is interested in creating interoperable CBOR, and in the most general case it will need API primitives to get some control over what encoding is generated.  We probably want to minimize this, but can’t for all platforms (see Lua).

Grüße, Carsten