1bffffffffffffffff has to turn into a BigInteger in JavaScript when decoded. When re-encoded, that turns into c248ffffffffffffffff:

  c2                -- Tag #2
    48              -- Bytes, length: 8
      ffffffffffffffff -- ffffffffffffffff

If I special-case the encoding for BigIntegers that fit into 8 byte normal integers, then c248ffffffffffffffff won't round-trip. My suggestion is to just set roundtrip to false for this case.

appendix_a.json is not terribly interoperable; the big integers lose precision when parsed with ECMAscript's JSON.parse(). RFC 7493 specifies a set of interoperability constraints that would be useful here.

If backward-compatibility is desired, a new property code be added. Example:

  {
    "cbor": "O///////////",
    "hex": "3bffffffffffffffff",
    "roundtrip": true,
    "decoded": -18446744073709551616,
    "decoded2": {
       "type": "bigint",
       "value": "-18446744073709551616"
    }
  },

This still wouldn't be I-JSON compliant, but would allow systems that have the constraints noted there to use this without as many gyrations.

Hi,

Thank you for these test vectors. They are really helpful.
However I am facing a little problem with the tagged items: the decoded value is not only decoded but also modified according to the tag.

For example wkkBAAAAAAAAAAA= is the tagged (2=Positive bignum) byte string 010000000000000000.
It will be great if you could provide the decoded value as is and, if it is tagged, the resulting value.

.. would be nice to enable devs to more easily grasp CBOR. Kudos btw ; )

f818 is not permitted by the RFC. Quoting:

An encoder MUST NOT issue two-byte sequences that start with 0xf8 (major type 7, additional information 24) and continue with a byte less than 0x20 (32 decimal). Such sequences are not well-formed.