As sort of a 2% project, I’m helping out over in the IETF, working on a revision of the JSON spec.
I wrote back in February about the depressing floppiness of the JSON spec, which allows things that are just bugs to people like me who use JSON always and only to represent hashes and records and suchlike in network APIs. And if the API is a crypto/authentication thing, those bugs can be nasty exploits. (Think “duplicate key” or “naked surrogate”, and shudder.)
What I hadn’t realized was that there actually isn’t a standalone anything you can link to and say “This is the JSON spec”; RFC 4627 is just a mime-type registration. So the IETF made a Working Group to write one, with the constraints that it can’t actually fix the problems with 4627; i.e. anything that is currently considered JSON, no matter how broken, can’t be de-JSON-ified.
What the WG can do is fix a couple of errata, document where the stupid things that 4627 allows can lead to breakage, and turn it into a spec, not just a registration doc. Fair enough.
I pitched in on a low-bandwidth level, suggesting a couple chunks of spec language here and there. I enjoy arguing about markup-language syntax, so it was a pleasant background activity. Anyhow, the time came to produce the next draft, and Douglas Crockford, to whom we all owe a major debt for having crafted JSON, couldn’t be found to do it. So they asked me if I would and I did (real HTML version here); a couple hours work while watching MLB.tv.
No real news of any significance here. But I’m amused, because there’s a file I’m editing called “json.xml”, sort of like how, fifteen years ago, I was putting cycles into editing a file called “xml.xml”.