There also needs to be some way to indicate that a JSON construct is a Set, Map, plain object, or array. You’d want a date/time type as well.
Without breaking existing JSON parsers, the way to do that is to add metadata like a _type
field to an object, or to add a “sidecar” object like superjson does. Which works but is ugly IMO.
Then there’s BSON, YAML, JSON Schema, and the one we don’t mention ₓₘₗ. To my knowledge all of those could be extended in a way to support new types, but require the producer and consumer to both understand and follow whatever convention you use. They lack the universal interchangeability of JSON.
This draft spec was eventually published as RFC 9562. Compared to the previous spec it adds versions 6, 7, and 8, plus best practices guidance.
Basically, there are a bunch of UUID alternatives that arose to fix the problem that UUIDs are bad for use as database keys in large tables (here’s the perspective of MySQL experts Percona). A bunch of these alternatives are actually linked from the RFC, which I haven’t seen done before. Version 7, in particular, is meant to address this use case.