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: Mon, 25 Nov 2013 16:29:12 -0800
Cc: John Cowan <cowan@mercury.ccil.org>, Pete Cordell <petejson@codalogic.com>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>, Henri Sivonen <hsivonen@hsivonen.fi>, Tim Bray <tbray@textuality.com>, "Joe Hildebrand \(jhildebr\)" <jhildebr@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-Id: <0021FE1E-FA6D-4410-9CD8-FF3C2775D2A3@wirfs-brock.com>
To: Martin J. Dürst <duerst@it.aoyama.ac.jp>

On Nov 25, 2013, at 1:37 AM, Martin J. Dürst wrote:

> 
> 
> On 2013/11/23 1:54, Allen Wirfs-Brock wrote:
>> 
>>> 
>> 
>> 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.
> 
> That works for ECMA-404. It does not work for the IETF draft, because it is extremely relevant for application/json, which is part of that draft.
> 
> Regards,    Martin.

It still seems pretty clear.  Anything feed as input into an actual parser for the JSON grammar as standardized by ECMA-404 must not contain any U+feff code points other than as part of JSON string values.  If the application/json wire format chooses to to use BOMs, then they must be removed before processing by a standard JSON parser.   From a JSON parser prospect, I think that's pretty much all you need to say. 

allen
Received on Tuesday, 26 November 2013 00:29:59 UTC

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