[Json] How to argue about I-JSON

[Tim Bray <[e-mail]>]

This is an attempt to leap in front of the debate, use the take-aways from
the very useful London f2f, and make our time arguing about I-JSON
maximally
​productive
.  There are plenty of bikesheds out there, but I think the number of
useful arguments is limited and the issues in them pretty clear.

Argument 1 - Media types?

Should there be an I-JSON media type, or a application/*+i-json suffix?
 draft i-json-01 calls for it, but this is at best controversial.  My
suggestion is that people who still think this is a good idea
​need to speak up.  (I won’t.)

Argument 2 - Top-level

draft-i-json-01 says the top level is an object (but doesn’t say MUST,
eek).  I have heard arguments for allowing arrays too​; anyone who thinks
that is a good idea should speak up. (I won’t.)

Argument 3 - Unicode

draft-i-json-01 excludes the use of, and I quote, “Surrogates or
Noncharacters”.   Is that the right use of Unicode nomenclature?  This
really matters and I think it’s OK now, but first-class Unicode lawyering
is required here.

Argument 4 - Software behavior

Section 3 of draft-json-01 implies draconian error handling - when a
message is specified to be i-json but the receiver finds, for example, a
dupe key, it is required to halt and catch fire. There’s a chance that this
will be interpreted as “tbray poisons JSON with XML draconianism”. People
with alternate language should suggest it. (I probably won’t argue this one
either way.)

Argument 5 - Numbers

draft-i-json-01 says that you MUST not put in a string representing a
number with greater precision/magnitude than IEEE754 doubles can support.
I think this is a good idea but I'm a little nervous because I’ve never
written the code, if this is unreasonably hard at either the sending or
receiving end someone should  say so.

...... aaaaaaand, that’s all folks.   I’m optimistic that we can zero in on
this one quickly.