Check the input first
01Canonical means one repeatable representation of parsed data. First exclude ambiguous names, invalid characters and unsupported numbers.
Separate input -0: the parser generates an error and stops, following both SHOULDs in erratum 7920. This is not a new MUST.
Source for this drawing: RFC 8785 · Read RFC section 3.1 ↗
New to this? Start hereA quick picture + helpful background
First, agree how to read the message.
An encoding tells a reader how to interpret bytes. A format tells it how values fit together. Correctly reading a value does not make that value trustworthy.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Deterministic output starts with unambiguous input.
- Input MUST be adapted to I-JSON: no duplicate object names, Unicode string data, and numbers expressible as IEEE 754 double precision (binary64). I-JSON also excludes Unicode noncharacters.
- Duplicate names are compared after decoding escapes. A parser that silently keeps the last value cannot establish that the original input had no duplicates. Lone surrogates, NaN and Infinity MUST terminate JCS processing with an error.
- Verified erratum 7920 adds a SHOULD: a parser encountering -0 SHOULD generate an error, which SHOULD stop processing. The underlying number serializer still maps negative zero to 0; these are different stages.
Four separate input cases are shown, not a stream of repairs. The negative-zero case follows the recommended rejection. This Informational, Independent Submission uses BCP 14 requirements for conforming implementations; it is not an IETF Standards Track publication. See https://www.rfc-editor.org/errata/eid7920 .
Read the RFC section ↗