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

LL,

It has been our intention from day one that nothing in dCBOR shall conflict with the established requirements of CBOR: all dCBOR MUST be decodable as plain CBOR, and now by extension CDE.

Further, it was never our expectation that -2^64 would be encoded as a float, and in fact we deliberately set no such expectations.

So if dCBOR’s current proscription of type 1 negative 65-bit integers indeed conflicts with this, then it must go. Obviously, this leaves a dangling range of basic integers expressible in dCBOR that are not expressible in either signed or unsigned 64-bit machine integers and which dCBOR (indeed all CBOR) implementations that do not support wider integers will have to reject.

But that, as they say, is the way the cookie crumbles. At least this has the resolution that there is still exactly one way to encode each integer value.

I will be updating the dCBOR I-D and our reference implementations accordingly.

~ Wolf

> On Apr 8, 2024, at 2:29 PM, lgl island-resort.com <lgl@island-resort.com> wrote:
> 
> Right. It’s a requirement. Missed it because it is not mentioned in the section on preferred serialization and I didn’t think to grep RFC 8949 for “preferred".
> 
> (My plan is to read the cbor-diag ruby code in addition to RFC 8949 next time; have started checking other CBOR implementations; so far only cbor-diag and QCBOR implement the big number tags).
> 
> 
> How should -2^64 be encoded in dCBOR?
> 
> Preferred serialization (both RFC 8949 and draft-ietf-cbor-cde-02) requires it to be a type 1 65-bit negative integer. This is in conflict with the prohibition of 65-bit negatives in dCBOR. It is a conflict because dCBOR requires compliance with CDE which requires compliance with preferred serialization.
> 
> Clearly the dCBOR inventors expected it would be encoded as a float.
> 
> However, I think the answer here has to be that dCBOR has to drop the prohibition of 65-bit negatives and that implementations will have to deal with the special case.
> 
> The alternative is to change the requirement in RFC 8949 with errata or a new RFC or something. The problem here is not that big. It’s just more code for a special case that some of us have to write.
> 
> 
> 
> The pseudo-normative rules for Preferred Serialization I previously shared need to be amended:
> 
> If big numbers (tags 2 and 3) are supported, integers that can be encoded as type 0 and 1 MUST NOT be encoded as tag 2 or 3.
> 
> If integers more negative than -2^63 are supported, then decoders MUST accept and correctly process the range [-2^64, -2^63 - 1] encoded as type 1.
> 
> 
> 
> A few more thoughts.
> 
> Any library that does preferred serialization and supports integers beyond -2^63 MUST send 65-bit negs. Some decoders won’t be prepared for this. QCBOR 1.x for example. But, it’s the law of the land.
> 
> It’s super easy to unify with big nums in Ruby or Python because the languages support big integers. The cbor-diag ruby code is super clean and simple.
> 
> This begs the question as to why big floats aren’t unified with regular floats in preferred serialization. Python has big floats. Ruby, however, has big decimals.
> 
> There’s no more rules for Preferred Serialization, right? Grep of RFC 8949 doesn’t turn up any.
> 
> There’s another interesting question for me — what should an implementation that supports both tag 2/3 AND dCBOR do for 2^66 and such Dunno yet.
> 
> LL
> 
> 
> 
> 
> 
>> On Apr 6, 2024, at 11:10 AM, Carsten Bormann <cabo@tzi.org> wrote:
>> 
>> Hi Laurence,
>> 
>> On 6. Apr 2024, at 19:47, lgl island-resort.com <lgl@island-resort.com> wrote:
>>> 
>>> 
>>>> On Apr 6, 2024, at 6:56 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>>>> 
>>>> Although I personally don't find the CBOR int/bignum arrangement ideal, this boat has (since long) already sailed and nobody died.
>>> 
>>> It looks to me that there is a new requirement in draft-ietf-cbor-cde-02 that isn’t in RFC 7049 (canonical CBOR) or RFC 8949 (Preferred Serialization and CDE). The requirement is that no value that can fit into an int64 or uint64 can be sent as a tag 3. That implies 65-bit negatives ints must be sent.
>> 
>> This is not a “new requirement” [1].
>> 
>> [1]: https://www.rfc-editor.org/rfc/rfc8949.html#section-3.4.3
>> 
>> Grüße, Carsten
>> 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor