Summary

The Extended JSON specifications allows generators to emit any raw Decimal128 as a $numberDecimal string with no requirement to check if it is illegal per IEEE 754, which could allow users to produce Extended JSON that would later fail to parse. For example, in the Go Driver: https://go.dev/play/p/FgV82UGH3i9

Motivation

A user of the Go Driver has voiced concern that being able to marshal invalid Decimal128 into extended JSON violates the robustness principle. See here for comment.

If the problem does occur, what are the consequences and how severe are they?

This isn't a bug and not validating on generation is probably the best solution. IEEE 754 also doesn't suggest validation on illegal input.

Is this issue urgent?

No

Acceptance Criteria

Determine if drivers should validate against illegal Decimal128 when generating extended JSON. If not, update the Q&A section with the reason. For example:

Drivers should not validate against illegal Decimal128 when generating, preferring instead to error against the creation of invalid Decimal128. It is acknowledged that users of some drivers can create custom serialization solutions that will result in illegal Decimal128 that will not be validated in the "encoding" portion when round-tripping.

Additionally, if we decide that Decimal128 should be validated at the constructor-level then the bson-decimal128 specifications should be updated. For example:

When constructing Decimal128 from raw 128 bits, the driver MUST validate that the bit pattern creates valid Decimal128 per IEEE 754.