- From: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Date: Wed, 13 Nov 2013 18:35:06 -0800
- To: Joe Hildebrand (jhildebr) <jhildebr@cisco.com>
- Cc: John Cowan <cowan@mercury.ccil.org>, IETF Discussion <ietf@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>, Anne van Kesteren <annevk@annevk.nl>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
On Nov 13, 2013, at 3:51 PM, Joe Hildebrand (jhildebr) wrote: > On 11/13/13 3:47 PM, "John Cowan" <cowan@mercury.ccil.org> wrote: > >> It's not clear that 404 disallows it, since 404 is defined in terms of >> characters, and a BOM is not a character but an out-of-band signal. However, for example, a conforming implementation of the ECMAScript JSON.parse function would reject any string passed to it that starts with a U+FFEF code point because the unquoted occurrence of that code point does not conform to the ECMA-252, 5th Edition or Ecma-404 JSON grammar. In order to be successfully processed, that code point would have to be stripped from the string prior to calling JSON.parse. Allen > > Agree. However, that signal would be a part of the 4627bis octet stream, > so a little interop guidance would likely be useful. Something like: > > "Some producers of JSON produce JSON-text that starts with a redundant > U+FEFF (ZERO WIDTH NO-BREAK SPACE, previously known as BYTE ORDER MARK) > with the ostensible purpose of signaling the encoding of the text to > follow. Since JSON has other mechanisms to determine encoding, this is > not required. Receiving applications MAY safely ignore this initial > character without generating an error. Implementations that do not send > U+FEFF are interoperable in the sense that all software implementations > which receive the un-prefixed text will not generate parse errors." > Isn't it an interooperbility issue that many receiving applications do not ignore it. Allen
Received on Thursday, 14 November 2013 02:35:47 UTC