W3C home > Mailing lists > Public > www-tag@w3.org > November 2013

Re: [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft)

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Fri, 22 Nov 2013 08:54:46 -0800
Cc: Pete Cordell <petejson@codalogic.com>, John Cowan <cowan@mercury.ccil.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>, Henri Sivonen <hsivonen@hsivonen.fi>, "Joe Hildebrand \(jhildebr\)" <jhildebr@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-Id: <EF7034DE-EA4D-43E4-9A5A-159E4A9DAB02@wirfs-brock.com>
To: Tim Bray <tbray@textuality.com>

On Nov 22, 2013, at 8:39 AM, Tim Bray wrote:

> Iíve been using JSON for quite a few years, but hardly ever in either a to-browser or from-browser role; what I care about is mostly its use in RESTful APIs generally and identity APIs specifically.  In those scenarios, it would be seen as wildly inappropriate to use anything but UTF-8; Iíve never actually seen anything else.  In practice, it would be very unlikely for anyone to deploy UTF-16 or any other non-UTF-8 flavor in a non-browser scenario.
> Having said that, Iím still, hundreds of messages later, not 100% sure what our draft should say about BOMs :(

You should say it that it is not an actual issue of the JSON format whose grammar clearly defines the handling of the 0xfeff code point.  Rather it is an upstream data interchange issue that should be dealt with in exactly the same way as with any other data interchange on a similar channel.  Say whatever you think is appropriate about BOMs in the transmission of data conforming to the "application/json" MIME type.  Just be clear that whatever you decide has nothing to do with the abstract, grammar-based interpretation of the actual JSON payload.

Received on Friday, 22 November 2013 16:55:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:00 UTC