Subject: [Json] People reading ECMA 262

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Sep 2013 10:58:55 +0200

The below message in JOSE is a current example of a recurring,
interoperability-bug causing problem I have seen a lot:

>> Correct. 34 chars must be escaped to comply with JSON, including U+0000 to U+001F.
> 
> I will update the scheme but I'm a bit unsure on the result:
> 
> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
> "a Unicode escape sequence occurring within a string literal in an
>  ECMAScript program always contributes a character to the String value
>  of the literal and is never interpreted as a line terminator or as a
>  quote mark that might terminate the string literal"

This message is an instance of a general problem: People read ECMA 262
and think that random statements in there about ECMAscript change the
definition of JSON.

(This becomes a problem because JavaScript is a non-trivial language
and there is a lot of text in ECMA 262 that needs to read and
understood in context to make sense.  ECMA 262 is a rather good spec,
but if people are picking statements there and try to interpret them
as normative statements about JSON out of context of the JavaScript
specification, this leads to peculiar results.  For instance, one guy
I know thinks there is one sentence in ECMA 262 that establishes that
you can send only BMP characters, not non-BMP characters, unescaped in
JSON strings, which of course is nonsense.)

We need to make very clear in 4627bis that this is not the case:
There is nothing in ECMA 262 that needs to be read or understood to
understand 4627bis.  ECMA 262 does not need to be read together with
4627bis to make sense out of the latter.

In particular, we need to make sure that any reference to ECMA 262 in
4627bis is informative, not normative.

But we also need to make the above clear in explanatory text.  (I'll
leave it to the diplomats in this group to write this text; clearly
this is not trying to put down ECMA 262 in any way.)

(None of this is taking away from the following two facts:
-- Some versions of 262 define their own JSON.  We try to stay
   compatible with that.
-- 262 defines implementation features of the most important subset
   of the JSON implementations out there; it is a good source of
   information for maximizing interoperability.
)

Grüße, Carsten