- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 22 Nov 2013 13:26:28 +0100
- To: Robin Berjon <robin@w3.org>, Pete Cordell <petejson@codalogic.com>, Henri Sivonen <hsivonen@hsivonen.fi>, John Cowan <cowan@mercury.ccil.org>
- CC: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, www-tag@w3.org, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>, es-discuss <es-discuss@mozilla.org>
On 2013-11-22 12:47, Robin Berjon wrote: > On 22/11/2013 12:33 , Pete Cordell wrote: >> ----- Original Message From: "Henri Sivonen" >>> On Thu, Nov 21, 2013 at 3:39 PM, Anne van Kesteren <annevk@annevk.nl> >>> wrote: >>>> XHR's responseType = "json" only supports UTF-8 (optionally with a >>>> leading BOM), across the board. >>> >>> Good point. I wrote the code that enforces that constraint, but I >>> forgot. >>> >>> Well, there's an interoperability reason against UTF-16, too, then. >> >> Personally I think we have to be careful not to fall into the trap of >> assuming that the only use-case for JSON will be in "to browser" >> communications. I'm hoping that for the IETFs purposes we'll be looking >> at JSONs wider utility into broader areas, which may even include >> logging to files and interprocess communication where there might be >> sensible reasons to choose something other than UTF-8. > > Sure, but given the prominence of JSON communicated to the browser, it > would be a pretty bad idea to have JSON variants that don't interoperate > there. For some value of "interoperate". Native JSON support in XHR is a relatively new feature (right?), and JSON has been used long before in the browser. Best regards, Julian
Received on Friday, 22 November 2013 12:27:08 UTC