The I-JSON Message Format
Extracted elements (19)
A good way to support Must-Ignore in I-JSON protocol designs is to require top-level protocol elements to be JSON objects and to specify that unrecognized member names MUST be ignored.
An I-JSON sender cannot expect a receiver to treat an integer whose absolute value exceeds 9007199254740991 (outside [-(2**53)+1, (2**53)-1]) as an exact value, due to the limited precision of JavaScript/IEEE 754 double numbers.
I-JSON restricts JSON to a profile that avoids language idioms and text encoding patterns that historically caused interoperability problems and software breakage, particularly when JSON is mapped into native programming-language structures or database records.
The Must-Ignore policy (ignoring unrecognized protocol elements rather than treating them as errors) has proven advantageous in practice because it allows protocol evolution without disrupting existing software; the contrasting Must-Understand policy has been found overly restrictive and brittle.
Paired surrogate escapes such as '\uD800\uDEAD' are legal in I-JSON, but lone surrogates like '\uDEAD' are invalid. Implementations must distinguish paired from unpaired surrogates when validating.
Some JSON implementations coded to the older RFC 4627 specification only accept JSON objects or arrays at the top level. Protocol designers should avoid top-level scalars to maintain compatibility with these implementations.
Designers of protocols using I-JSON SHOULD provide a way for a receiver of erroneous data to signal the problem to the sender.
For applications requiring exact interchange of numbers with greater magnitude or precision than IEEE 754 double, it is RECOMMENDED to encode them in JSON string values, requiring the receiver to understand the intended semantic.
I-JSON messages MUST be encoded using UTF-8 (RFC 3629). This requirement applies to the entire message.
I-JSON messages SHOULD NOT include numbers that express greater magnitude or precision than an IEEE 754 double precision (binary64) number provides, for example 1E400 or 3.141592653589793238462643383279.
Object member names and string values MUST NOT include code points that identify Surrogates or Noncharacters as defined by Unicode. This applies to both directly encoded characters and escaped sequences; e.g., '\uDEAD' is invalid as an unpaired surrogate.
Objects in I-JSON messages MUST NOT have members with duplicate names. 'Duplicate' means names are identical sequences of Unicode characters after processing any escaped characters.
Protocol designers SHOULD NOT use top-level JSON texts that are neither objects nor arrays, to maximize interoperability with implementations coded to the older RFC 4627 specification.
Timestamp and duration data items in I-JSON protocols are RECOMMENDED to be expressed as string values in ISO 8601 / RFC 3339 format, using uppercase letters, including the timezone, and including optional trailing seconds even when '00'.
Under a Must-Ignore policy, when an implementation encounters an unrecognized protocol element, it MUST NOT treat this as an error condition; it should act as if the new element simply did not appear.
When an I-JSON protocol element must contain arbitrary binary data, it is RECOMMENDED that the data be encoded as a base64url string value per Section 5 of RFC 4648.
An I-JSON message is any JSON text (as defined by RFC 7159) that additionally satisfies the I-JSON constraints: UTF-8 encoding, no surrogates or noncharacters, numbers within IEEE 754 double range, and no duplicate object member names.
The order of object members in an I-JSON message does not change the meaning of the message. A receiving implementation MAY treat two I-JSON messages as equivalent if they differ only in object member order.
All security considerations that apply to JSON (RFC 7159) apply equally to I-JSON. There are no additional security considerations specific to I-JSON. Because I-JSON forbids JSON idioms that can lead to unpredictable behavior in receiving software, it may be a more secure basis for Internet protocols.