How about CBOR RFC(7049->8949)

[Anton-Latukha]

While, RFC8948 is also equally named Concise Binary Object Representation (CBOR) & published on December 2020.

It has a section on changes from the previous RFC: https://datatracker.ietf.org/doc/html/rfc8949#appendix-G

It is probably logical to start thinking to provide support for the new CBOR RFC also in the scope of the cbor.

[Anton-Latukha]

Since:

As discussed in the introduction, this document formally obsoletes
RFC 7049 while keeping full compatibility with the interchange format
from RFC 7049. This document provides editorial improvements, added
detail, and fixed errata. This document does not create a new
version of the format.

It may be as simple, as claiming the new RFC support also.

[bgamari]

I have read Appendix G and as far as I can tell there are very few changes that would affect the codec implementation. The one thing I am a bit uncertain of is whether the Canonical CBOR implementation is consistent with the new Section 4.2. @dcoutts could speak to this.

[dcoutts]

Looks like I'll have to read the new RFC then :-)

I should note that supporting canonical CBOR (as the original RFC calls it) is not automagic using the cborg library. It requires the library user to write their decoder in particular ways, and not just using the right primitives.

Also, the library has never had support for the bonkers recommendation in the RFC for the sort order of keys in maps/sets: it recommends using the order of the CBOR encoding of the key, rather than the logical sort order of the key.