The IETF just pub­lished RFC 8259 (al­so known as “STD 90”). Edi­tor, yr hum­ble ser­van­t. The legacy-ASCII full text is here and there’s a nice-looking HTML ve­ri­on here. I think this is the last spec­i­fi­ca­tion of JSON that any­one will ev­er pub­lish.

The sto­ry of how we got to RFC 7159, this RFC’s pre­de­ces­sor, is told in JSON Re­dux AKA RFC7159 and I won’t re-tell it. The rea­son 8259 ex­ists is that the ECMAScript gang went and wrote their own ex­treme­ly min­i­mal spec, Stan­dard ECMA-404: The JSON Da­ta In­ter­change Syn­tax, and there was rea­son for con­cern over du­el­ing stan­dard­s. But, af­ter a cer­tain amount of standards-org elephant-gavotte, each of ECMA 404 and RFC 8259 nor­ma­tive­ly ref­er­ences the oth­er and con­tains a com­mit­ment to keep them con­sis­tent in case any er­rors turn up. Which is a good thing, but this text has been re-examined and re-polished so many times that I doubt ei­ther side will ev­er re­vis­it the ter­ri­to­ry, thank good­ness.

8259 con­tains one new sen­tence: “JSON text ex­changed be­tween sys­tems that are not part of a closed ecosys­tem MUST be en­cod­ed us­ing UTF-8 [RFC3629].” Giv­en that, by 2017, an at­tempt to ex­change JSON en­cod­ed in any­thing but UTF-8 would be ir­ra­tional, this hard­ly needs say­ing; but its ab­sence felt like an omis­sion.

Which spec should you use? · If you want to un­der­stand JSON syn­tax, you still can’t beat Doug Crockford’s orig­i­nal for­mu­la­tion at JSON.org. If you want to use an RFC as foun­da­tion for a REST API or some oth­er In­ter­net pro­to­col, I ac­tu­al­ly don’t rec­om­mend 8259, I rec­om­mend I-JSON, RFC 7493, which de­scribes ex­act­ly the same syn­tax as all the oth­er specs (by ref­er­enc­ing 7159), but ex­plic­it­ly rules out some legal-but-dumbass things you could do that might break your pro­to­col, for ex­am­ple us­ing any­thing but UTF-8 or hav­ing du­pli­cate mem­ber names in your ob­ject­s.

What nex­t? · I wouldn’t be sur­prised if the IETF JSON Work­ing Group shut down forever. On the oth­er hand, we still lack a de­cent high-quality JSON Schema lan­guage. Al­so, JSONPath, which is damn use­ful, doesn’t have a prop­er def­i­ni­tion any­where. So there’s work to be done if any­one wants to do it.

Thanks and apolo­gies · To the work­ing group, its chairs and Area Direc­tors and mem­ber­s. Al­so, at one point in the pro­cess 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 In­ter­net owes them thanks.



Contributions

Comment feed for ongoing:Comments feed

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]

author · Dad · software · colophon · rights
picture of the day
December 14, 2017
· Technology (81 fragments)
· · Software (63 more)

By .

I am an employee
of Amazon.com, but
the opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.