Re: JSON feedback we could submit

On Sun, Nov 10, 2013 at 7:08 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> To improve JSON interoperability the IETF should not define a more
> restricted version of JSON than defined by Ecma-404.
>

The problem is that the IETF already *did* define such a restricted
version, RFC4627, in 2006.  So the interesting argument is whether, in
2013, any increased gain in interoperability due to removing the
restriction overbalances the software pain of people who implemented “JSON
Text” per 4627.

My own feeling is probably influenced by my JSON experience, largely with
usages in application-level network messaging protocols, usually RESTful in
flavor. In this context the interoperability of JSON is superb, and
basically all such protocols require that messages be objects (more
commonly) or arrays (less so). So my inclination would be to retain things
as they are.

Also, the interop problems I’ve observed have all been around dupe keys,
busted unicode, and programmers not understanding how computers store
numbers [sad but true].

Also there’d probably be IETF community pushback against the -bis
introducing an active incompatibility with the 4627, which the WG charter
strongly discourages.

But it wouldn’t be insane to raise the issue in IETF last call, which
should be starting soon.


> (Worth pondering about: what to do about a leading BOM, which
> XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404
> allow.)
>

Yeah.  Maybe spirit-of-Postel’s-law language urging implementors of
generators to avoid these things where possible, and implementors of
parsers to tolerate them where possible?


>
>
> --
> http://annevankesteren.nl/
>
>