- From: Norbert Lindenberg <ecmascript@norbertlindenberg.com>
- Date: Mon, 20 Feb 2012 17:27:36 -0800
- To: Wes Garland <wes@page.ca>
- 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>
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 http://www.json.org/ 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). Norbert 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