[Json] Actual interoperability issues

[Carsten Bormann <[e-mail]>]

From the 1093 JSON messages in my mailbox, I find discussion of the
following issues that appear to be relevant for interoperability:

Group 1: Overall format of JSON documents

   (This group is about the sequence of characters that make up the
   actual JSON document, i.e. native Unicode characters/code points,
   not escape sequences etc.)

1.1) Ill-formed Unicode in JSON documents

     (Unpaired surrogates in UTF-16, CESU-8 surrogates, etc.)

1.2) Use of non-characters (Unicode term) in a JSON document

     (Is that an actual interoperability issue?  I haven't seen it.)

1.3) Use of non-yet-assigned characters in a JSON document

     (Is that an actual interoperability issue?  I haven't seen it.)

1.4) Usage of LS/PS (U+2028/U+2029) in JSON documents

     (I.e., native LS/PS; escapes are not a problem.  This hurts newer
     JavaScript implementations if they still want to eval things.
     Probably easy to solve: this just needs to be discouraged)

1.5) BOMs in JSON documents

1.6) usage of UTF-16 and UTF-32 based character encoding schemes (and
     which ones?) for JSON documents

1.7) non-BMP characters in JSON documents

     (I have heard about implementations that have trouble with this,
      maybe because of assuming CESU-8 instead of UTF-8, but have
      never been able to pin them down.  May be a non-issue, more
      study required.)

1.8) Combining characters after markup

     (Another issue that was mentioned, but for which I'm not aware of
      an actual interoperability problem.)

Group 2: Syntax, overall data model

2.1) Top-level data items beyond arrays and maps (JSON "objects")

     (and the potential interaction with 1.5/1.6; with streaming; with
     detection of truncation)

Group 3: Interpretation of data in JSON documents

3.1) Ill-formed Unicode constructed from escape sequences in strings

     (This is about escape sequences that generate unpaired surrogates.)

3.2) Construction of non-characters (Unicode term) from escape sequences in strings

     (Is that an actual interoperability issue?  I haven't seen it.)

3.3) Construction of non-yet-assigned characters from escape sequences in strings

     (Is that an actual interoperability issue?  I haven't seen it.)

3.4) Non-unique ("duplicate") keys in maps (JSON "objects")

3.5) Equivalence of native and (variants of) escaped representations
     of characters in map keys

     (Is that an actual interoperability issue?  I haven't seen it.)

3.6) Equivalence of canonical-equivalent (Unicode term) characters in
     map keys

     (Is that an actual interoperability issue?  I haven't seen it.)

3.7) Assumptions on the semantics of ordering of entries in maps

     (also in conjunction with 3.4)

3.8) Assumptions about (range and) precision of numbers

     (E.g., the twitter ID issue)

3.9) Handling of NaNs in numbers

     (I'm not quite sure what the issue was, but it was mentioned)

So much for the content of 1093 messages.  (Most of these are almost
trivial to resolve/clarify from what we already know, and should be,
so each spec referencing JSON doesn't need to supply its own 18
answers to these questions.)

Am I missing any issues?

(For now, as long as the issue is about interoperability, I don't care
about "standard" vs "implementation guide" issues; we can sort that
one out later, including whether we want to address the issue at all.)

Grüße, Carsten

PS.: There also was a feature request, for a "profile" parameter of
the media type.  Any feature requests that I'm missing?