W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

Re: New full Unicode for ES6 idea

From: Norbert Lindenberg <ecmascript@norbertlindenberg.com>
Date: Mon, 20 Feb 2012 17:27:36 -0800
Cc: Norbert Lindenberg <ecmascript@norbertlindenberg.com>, Brendan Eich <brendan@mozilla.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, mranney@voxer.com, es-discuss <es-discuss@mozilla.org>
Message-Id: <F55E1930-1AEB-4D6E-B0CD-C1C5838897EB@norbertlindenberg.com>
To: Wes Garland <wes@page.ca>
As Brendan's link indicates, JSON is specified by RFC 4627, not by the ECMAScript Language Specification. JSON is widely used for data exchange with and between systems that have nothing to do with ECMAScript and the proposed BRS - see the middle section of

So the only thing that can (and must) be done if and when updating the ECMAScript Language Specification for the BRS is to update the JSON section (15.12 in ES5) to describe how to map from the existing JSON syntax to the new BRS-on String representation. Note that JSON.stringify doesn't create Unicode escapes for anything other than control characters (presumably those identified in RFC 4627).


On Feb 20, 2012, at 4:45 , Wes Garland wrote:

>> On 19 February 2012 16:34, Brendan Eich <brendan@mozilla.com> wrote:
>> Wes Garland wrote:
>>> Is there a proposal for interaction with JSON?
>> From http://www.ietf.org/rfc/rfc4627, 2.5
> *snip* - so the proposal is to keep encoding JSON in UTF-16.  What happens if the BRS is set to Unicode and we want to encode the string "\uD834\uDD1E" -- the Unicode string which contains two reserved code points? We do not want to deserialize this as U+1D11E.
> I think we should consider that BRS-on should mean six-character escapes in JSON for non-BMP characters.  It might even be possible to add matching support for JSON.parse() when BRS-off.  The one caveat is that might make JSON interchange fragile between BRS-on systems and ES5 engines.
Received on Thursday, 23 February 2012 09:24:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC