Re: [Cbor] 65-bit negatives, big nums conflict between CDE and dCBOR drafts?

[Anders Rundgren <[e-mail]>]

Although I personally don't find the CBOR int/bignum arrangement ideal, this boat has (since long) already sailed and nobody died.

However, when it comes to the various constraints introduced by dCBOR, I disagree with the authors because practically all existing CBOR-using applications (as well as many tools) have explicit or implicit constraints that didn't require a specific encoding standard.  In addition, the integer constraints imposed by dCBOR has (AFAICT...) no impact on determinism; they are rather specific limits for the Blockchain Commons applications.


Numeric Reduction (aka canonicalized numbers) is the (IMO) only thing that needs to depart from CDE in order to achieve determinism.

Anders

On 2024-04-05 22:37, lgl island-resort.com wrote:
> draft-ietf-cbor-cde-02 says:
> 
>     1. The CBOR Common Deterministic Encoding Profile (CDE) turns this recommendation into a mandate: Integers that can be represented by basic major type 0 and 1 are encoded using the deterministic encoding defined for them, and integers outside this range are encoded using the preferred serialization (Section 3.4.3 of RFC 8949 [STD94]) of tag 2 and 3 (i.e., no leading zero bytes).
> 
> 
> There’s no MUST, but it looks to me like CDE requires:
>   - type 1 must be used for the 65-bit negative integers range
>   - tag 2 and 3 must be used for integer values outside of type 0 and 1
> 
> That makes it clear that tag 3 can never be used for 65-bit negative range integers. One could also infer that 2^66 and such must be encoded as a big number, never a float. That is probably not what is intended, though.
> 
> Floats aside, CDE is still unifying the integer number space between type 0 and 1 with tag 2 and 3 for the sake of determinism. It is allowing only one representation of all the integer values. It’s a bit like dCBOR's unification of integer and float number spaces.
> 
> Is that really what we want to do? It seems simpler not to, but if there are clear use cases, maybe it is a good thing.
> 
> 
> On to dCBOR. To comply with CDE, you must either 1) implement 65-bit negative type 1 or 2) declare non-support of that range of negative integers.
> 
> It’s pretty clearly that dCBOR does not want to declare non-support of that range of negative integers, so 65-bit negative type 1 integers must be supported. However dCBOR disallows them (and dCBOR requires compliance with CDE) so there is a conflict between the two documents now.
> 
> Further, if tag 2 & 3 must be used rather than floats for 2^66 and such, there’s another conflict.
> 
> 
> Seems to me we should figure out what CDE should do here first. Figure out whether there is integer number unification or not. If not, then dCBOR is fine as is. If there is integer unification, then dCBOR has to allow 65-bit negatives.
> 
> If integer unification is to be required, then CDE implementations have two choices:
> 
> 1) Avoid it by declaring non-support of integers outside of int64_t/uint64_t.
> 2) Do the unification work.
> 
> The unification work isn’t a lot of code, but does need some thought. Also, with the current text, I think implementors may not realize it needs to be done.
> 
> Also, I suspect some non-CDE decoders that support big numbers might be surprised when 65-bit negative type 1 integers arrive. Those reaching for CDE to have better interoperability might not always get what they want.
> 
> Wait, there’s more…
> 
> We could do integer unification of the number space by requiring the 65-bit negative integer range always be encoded as a tag 3 big number, never as type 1. That is, disallow 65-bit negative type 1 like dCBOR. If we say that those values must be tag 3, then we’re not limiting the data model. And what’s the data model for -2^66? You have to do use tag 3 for it.
> 
> LL
> 
> 
> 
> 
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor