- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Mon, 25 Nov 2013 18:37:43 +0900
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- CC: Tim Bray <tbray@textuality.com>, 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>
On 2013/11/23 1:54, Allen Wirfs-Brock wrote: > > 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. 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.
Received on Monday, 25 November 2013 09:39:18 UTC