JSON: remove gap between Ecma-404 and IETF draft
# Anne van Kesteren (12 years ago)
To be clear, this is a Last Call comment on tools.ietf.org/html/draft-ietf-json-rfc4627bis-07 The JSON Data Interchange Format (draft-ietf-json-rfc4627bis-07).
# Anne van Kesteren (12 years ago)
On Tue, Nov 12, 2013 at 5:20 PM, "Martin J. Dürst" <duerst at it.aoyama.ac.jp> wrote:
If XMLHttpRequest has reasons to continue allowing it, I'd suggest that:
- It strongly discurages it, and
- It defines processing as something roughly like
- If the first few bytes look like a BOM, ignore them
- Process the rest according to rfc4627bis or ECMA-404 (whichever works better if they are not in full alignment).
That will make sure that variation is confined as locally as possible.
So that is roughly how it is defined. Using the web's "utf-8 text resource decode" method that removes a BOM and then passing the rest to something equivalent to JSON.parse(). However, if we are defining a new text transport format I think it would make sense to allow a leading BOM similar to how text/css, text/html, etc. allow for that.
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.
(Worth pondering about: what to do about a leading BOM, which XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404 allow.)