On Nov 13, 2013, at 3:51 PM, Joe Hildebrand (jhildebr) wrote: > On 11/13/13 3:47 PM, "John Cowan" <cowan@xxxxxxxxxxxxxxxx> 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