The IETF just published RFC 8259 (also known as “STD 90”). Editor, yr humble servant. The legacy-ASCII full text is here and there’s a nice-looking HTML verion here. I think this is the last specification of JSON that anyone will ever publish.
The story of how we got to RFC 7159, this RFC’s predecessor, is told in JSON Redux AKA RFC7159 and I won’t re-tell it. The reason 8259 exists is that the ECMAScript gang went and wrote their own extremely minimal spec, Standard ECMA-404: The JSON Data Interchange Syntax, and there was reason for concern over dueling standards. But, after a certain amount of standards-org elephant-gavotte, each of ECMA 404 and RFC 8259 normatively references the other and contains a commitment to keep them consistent in case any errors turn up. Which is a good thing, but this text has been re-examined and re-polished so many times that I doubt either side will ever revisit the territory, thank goodness.
8259 contains one new sentence: “JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [RFC3629].” Given that, by 2017, an attempt to exchange JSON encoded in anything but UTF-8 would be irrational, this hardly needs saying; but its absence felt like an omission.
Which spec should you use? · If you want to understand JSON syntax, you still can’t beat Doug Crockford’s original formulation at JSON.org. If you want to use an RFC as foundation for a REST API or some other Internet protocol, I actually don’t recommend 8259, I recommend I-JSON, RFC 7493, which describes exactly the same syntax as all the other specs (by referencing 7159), but explicitly rules out some legal-but-dumbass things you could do that might break your protocol, for example using anything but UTF-8 or having duplicate member names in your objects.
What next? · I wouldn’t be surprised if the IETF JSON Working Group shut down forever. On the other hand, we still lack a decent high-quality JSON Schema language. Also, JSONPath, which is damn useful, doesn’t have a proper definition anywhere. So there’s work to be done if anyone wants to do it.
Thanks and apologies · To the working group, its chairs and Area Directors and members. Also, at one point in the process I got all grumpy and sulky and they didn’t let that get in the way, just went ahead and got the job done. The Internet owes them thanks.
Contributions
Comment feed for ongoing:
From: David Magda (Dec 15 2017, at 04:02)
HTML version:
* https://tools.ietf.org/html/rfc8259
[link]
From: espadrine (Dec 15 2017, at 08:57)
You mention JSONPath not having a proper definition.
JSON Pointer, aka. RFC 6901, does.
Its purpose is similar enough that it could be extended to own the other JSONPath features we relish.
[link]
From: Phil Pennock (Dec 15 2017, at 14:57)
nb: the links through to 7159 on the earlier post reference http://rfc7159.net/rfc7159 which is returning 403, as is the top URL for that domain.
[link]
From: Julian Reschke (Dec 16 2017, at 09:55)
Here's a "pretty" HTML version: https://www.greenbytes.de/tech/webdav/rfc8259.html
[link]
From: Simon (Dec 17 2017, at 06:14)
I think there's still room for extensions of JSON, like, you know, a comment syntax. HJSON basically, I guess.
[link]
From: Kevin Marks (Dec 18 2017, at 11:31)
I'm not sure that leaving duplicate key behaviour undefined is helpful, given that there are exploits that use it. Is there a way to converge this?
[link]
From: Walter Underwood (Dec 21 2017, at 08:28)
Thanks.
Writing standards is a huge amount of work, and coordinating between two standard bodies is something I don't want to contemplate.
The lack of comments continues to be really annoying, but adding them would break pretty much everything, so I'll live with it.
wunder
[link]