Visual RFC.
ALL RFCs / RFC 8259
Read the RFC ↗
RFC 8259 / INTEROPERABLE EXCHANGE

Interoperability checks

06

Small choices around names, strings, numeric limits, and media type determine whether independent implementations agree.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 8.2 ↗
RFC 8259 · § 8.2EXAMPLE
3 / 3
Interoperability checksAn ambiguous duplicate member splits consumers into conflicting interpretations; a revised object with unique names produces agreement.Independent consumers should agreeIllustrative role-member ambiguity{"role":"reader", "count":3}Consumer AConsumer Brole = readerrole = readerUnique names remove the ambiguous mappingSame decoded strings, values, and agreed numeric rangeConsumers can agree on the interpreted values
03
Compare independent interpretations.

The consumers agree on the name/value mappings and decoded string content.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

Prefer data that independent consumers interpret alike.

  • Use unique member names and Unicode strings without broken surrogate pairs.
  • Agree on useful numeric ranges; do not rely on object-member order or raw escape spelling.
  • The registered media type is application/json with no defined optional charset parameter.
DETAILS

JSON does not supply a domain schema, date type, canonical serialization, or cryptographic signature format. Applications must define those conventions when they need them.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. A tree of JSON values
  2. Objects and arrays
  3. Strings and Unicode
  4. Numbers and precision
  5. Parsing and generating
  6. Interoperability checks
RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗