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

On Mon, Apr 8, 2024, 23:29 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?
>

https://cbor.me

> 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.
>

dCBOR only needs to specify Numeric Reduction.

> 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 spec. is as it is.

>
> 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.
>

I would strongly object to such a change.

> 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.
>

The best would be to drop dCBOR alltogether.  Gordian Envelopes work just
fine using CDE "as is".

Anders

> 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
>