>On Nov 11, 2013, at 11:01 PM, Anne van Kesteren <annevk@xxxxxxxxx> wrote:
>
>> To improve JSON interoperability the IETF should not define a more
>> restricted version of JSON than defined by Ecma-404.
>>
>> Parsers exist that can parse "42" today and parsers that cannot parse
>> "42" today can be meaningfully upgraded to do so too. This would not
>> break those parsers, unless they depend on parsing 42 as an error,
>> which is a far more unlikely scenario than parsing it as 42 given
>> precedence.
I see Anne's input on the top-level grammar as interesting and useful. I
believe that we could choose to be reasonable here by changing the ABNF:
JSON-text = value
and then adding text about interoperability in the same way that we have
approached numbers, strings, and duplicate keys. Protocols that come
after this draft is published as an RFC can safely decide to allow any top
level value. Parsers that claim compatibility with the new doc will allow
any value. For widest interoperability, however, you can't assume that an
unknown receiver will correctly process anything but an object or an array
at the top level.
We would also need to change section 8.1 according to the mechanism that
was previously proposed:
00 00 00 xx UTF-32BE
00 xx ?? xx UTF-16BE
xx 00 00 00 UTF-32LE
xx 00 xx ?? UTF-16LE
xx xx ?? ?? UTF-8
in order to account for strings at the top level whose first character has
a codepoint greater than 127.
It would be awful for there to remain two mutually-incompatible versions
of JSON going forward, and I think we should take this opportunity to
address the biggest incompatibility.
>>(Worth pondering about: what to do about a leading BOM, which
>>XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404
>>allow.)
If 404 doesn't allow it, I don't see a strong need to add it. Parsers can
always be more forgiving of what they will parse than what the spec says,
particularly since section 9 says "A JSON parser MAY accept non-JSON forms
or extensions".
--
Joe Hildebrand