[Cbor] Bignums and the generic data models (Re: 🔔 WGLC on draft-ietf-cbor-7049bis-09)

[Carsten Bormann <[e-mail]>]

On 2019-11-24, at 12:23, Jeffrey Yasskin <[e-mail]> wrote:
> 
> 3.4.4.  Bignums
> 	[…]
> 	• "and preferred encoding never makes use of bignums that also can be expressed as basic integers (see below)." <- This seems inconsistent with "In the generic data model, bignum values are not equal to integers from the basic data model". If they're not the same value at the data model level, they can't be alternate encodings of each other.

Hi Jeffrey,

of your many useful comments in that message, let me pick this one because answering it is a prerequisite to getting the map validity text right.

Indeed, in the basic (unextended) generic data model, bignums are different from (mt0/1) integers.

The extended generic data model for tag 2/3 changes this.  It has to.  Consider:

2(h'00112233445566778899')
and
2(h'112233445566778899')

These are different in the basic generic data model, but both mean 316059037807746189465 in the extended generic data model, so that has to be different from the basic one.  

So given that we already had to extend the generic data model with the values (types) specific to the tag semantics, we also can (and should!) say that

2(h'12')

means 18 in the extended generic data model, the preferred encoding of which is 0x12 and not 0xc24112.

For a generic codec, both options are available for a specific tag number:

- offer the basic generic data model.  This leaves it to the application to build the tag content in the way that fits to the tag definition and to interpret it this way.  It is then also up to the application to take care of map validity (e.g., by not using both 2(h'00112233445566778899’) and 2(h'112233445566778899’) as keys in the same map), and to issue preferred serialization if desired.
— process the tag, i.e., offer the extended generic data model.  Now the generic codec can do all that work; for the example at hand, at the codec API you only see integers.

This is the direction in which I think we need to go if we want to enable tag processing in generic codecs.

(The cognitive dissonance here is maybe with ECMAscript bigints, which are a separate type from numbers.  But sending a bignum is not on its own a good way to distinguish a number as a ES bigint; probably a language-specific tag is a better way to make that language-specific distinction.)

Grüße, Carsten