Visual RFC.
ALL RFCs / RFC 7493
Read the RFC ↗

RFC 7493 / START HERE

I-JSON interoperable messages, before the details

I-JSON means Internet JSON: a restricted JSON message profile for predictable exchange.

Two programs may parse the same JSON differently. I-JSON fixes UTF-8 encoding and unique decoded member names, and sets realistic number expectations. It also recommends protocol conventions for extensions, times and binary strings.

Start the guide See the 5 chapters ↓

The idea in one picture

  1. Shared contract

  2. Predictable values

  3. Application checks

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

RFC7493 is a March2015 Proposed Standard with no formal updates or obsoletions. It profiles JSON rather than replacing it. It is broader protocol-design guidance than the separate JCS canonicalization guide.

A familiar example

Imagine a fictional picnic API. It rejects a duplicate name before one value overwrites another, carries a large exact ID as an agreed string, and ignores an optional new color field under its protocol contract. None of those checks proves who may use the API.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

JSONRFC 8259 · beginner overview ↗UTF-8RFC 3629 · beginner overview ↗JCSRFC 8785 · beginner overview ↗

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Send UTF-8 and valid Unicode charactersI-JSON means Internet JSON: a JSON profile for predictable exchange between different programs. Its encoding and character rules apply beyond JSON grammar.
  2. Keep number expectations within binary64Different runtimes can round the same JSON number. Separate a recommendation about numbers from a promise of exact identifiers.
  3. Detect duplicate names before building an objectMember names are compared after decoding escapes. A parser that overwrites duplicates may erase the evidence before you check it.
  4. Design an extensible protocol contractTop-level containers help older receivers. A Must-Ignore policy is a protocol design choice with precise behavior once adopted.
  5. Represent time and binary data explicitlyUse agreed strings for time and binary content, then apply the protocol’s own validation and security decisions.
Start with chapter one →

This introduction explains RFC 7493 (2015). Read the original RFC ↗