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

[Carsten Bormann <[e-mail]>]

On 9. May 2023, at 00:42, Wolf McNally <[e-mail]> wrote:
> 
>> Because of this incompatibility between the CBOR and standard representations, dCBOR disallows encoding negative integer values in the range [CBOR_NEGATIVE_INT_MAX ... STANDARD_NEGATIVE_INT_MAX - 1]: conformant encoders MUST never encode these values and conformant decoders MUST reject these values as invalid.
>> 
>> Implementations that support BIGNUM are able to encode and decode these values as BIGNUM.
> 

How is 

"c3 48 89 ab cd ef 01 23 45 67"

a better encoding of -9920249030613615976 than

"3b 89 ab cd ef 01 23 45 67”

?

I think what you are trying to say is the obvious fact that int64 does not include -2**64 to -2**63-1.
The is nothing wrong with encoding values in this range with major type 3, these are just outside the range of int64.
Same with int64, 2**63 to 2**64-1 and major type 1, by the way (these do fit in a uint64, though).

Similar considerations apply to int32, if your applications need that type; there will be some CBOR major type 0 and major type 1 values that your application cannot process where int32 is required.

There is no incompatibility between CBOR and “standard representations”, it just so happens that the boundaries between int8, int16, int32, int64 are not one-to-one with the boundaries between the various lengths of integers that CBOR can express.
So if int64 happens to be your largest native signed integer, you need big integer support (or a third choice in addition to uint64 and int64) for handing around -2**64 to -2**63-1.
This does not mean you cannot (or should not) encode these non-int64 integers as “3b 80…” to “3b ff…”.

Grüße, Carsten