The Olde ASCII is at rfc7493.txt. I’ll put a nicely-formatted HTML version here as soon as I pull a few pieces together. This is really, really simple stuff and should be about as controversy-free as an RFC can be.
Back story · Basically, RFC 7159 is “the JSON RFC”; it describes the existing panoply of JSON specs, and also more-or-less unifies the (small) incompatibilities between them. The history is here, from which I quote:
If you’re interested, I recommend opening up the HTML version and searching forward for the string “interop”. There are 17 occurrences. If you’re generating JSON — something a lot of us do all the time — and make sure you avoid the mistakes highlighted in those 17 places, you’re very unlikely to cause pain or breakage in software that’s receiving it.
I-JSON is just a note saying that if you construct a chunk of JSON and avoid the interop failures described in RFC 7159, you can call it an “I-JSON Message”. If any known JSON implementation creates an I-JSON message and sends it to any other known JSON implementation, the chance of software surprises is vanishingly small.
Which I think is a good thing to do.
Conformance? · The RFC doesn’t actually describe anything called “I-JSON conformance”. It just specifies an object called an “I-JSON Message”; the idea is that anyone writing an Internet-protocol spec can specify that the payload be an I-JSON Message.
For security geeks · JSON is starting to be used a lot in security-related protocols: Crypto, authentication/authorization, and so on. It turns out that the security people worry about Bad People and Government Employees using Stupid JSON Tricks like duplicate keys and carefully-malformed Unicode to attack these protocols.
So if you specify that your payload MUST be I-JSON message, and the receiver checks that, there’s one particular class of attacks that you no longer have to worry about. Which has to be a good thing.
Bonus: Protocol pointers! · The RFC has a section “4. Recommendations for Protocol Design” that summarize a bunch of lessons hard-won over the years about things that make JSON-based protocols work better and more interoperably.
Things like using RFC3339 dates, making your message’s top level a JSON object so you can have a Must-Ignore policy, being careful with numeric precision and range because JavaScript, and so on. I suspect most readers of this space will nod their heads, unsurprised, at each and every one.
Thanks · To the WG and chairs and Area Directors and IESG and RFC Editor; every step of the IETF process improved the initial draft.
