Re: [Json] How to argue about I-JSON

John Cowan <> Mon, 28 April 2014 20:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 437A81A6FBA for <>; Mon, 28 Apr 2014 13:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.251
X-Spam-Status: No, score=-5.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0aQMOms8IiDb for <>; Mon, 28 Apr 2014 13:03:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B0F741A03FC for <>; Mon, 28 Apr 2014 13:03:41 -0700 (PDT)
Received: from cowan by with local (Exim 4.72) (envelope-from <>) id 1Werm8-0000kw-LI; Mon, 28 Apr 2014 16:03:40 -0400
Date: Mon, 28 Apr 2014 16:03:40 -0400
From: John Cowan <>
To: Tim Bray <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <>
Cc: "" <>
Subject: Re: [Json] How to argue about I-JSON
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Apr 2014 20:03:45 -0000

Tim Bray scripsit:

> 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.)

If you expect JSON and get I-JSON, all is well, so I see no point in
adding a media type or suffix to actual documents.  It would be marginally
useful to indicate that you expect I-JSON, but surely nobody would be
so foolish at this stage as to insist on I-JSON.  So let's not bother
with these formalities until there is a proven need for them (which may
be never).

> 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.)

As I understand it, the reason for this restriction was to support the
in-band I-JSON signature.  Since this is now dropped, there is no further
reason not to allow the sending of arbitrary JSON values.

> 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.

It should say "code points which represent unpaired surrogates or
noncharacters."  The statement "\uDEAD is always illegal" is incorrect;
it is entirely legal in the sequence "\uD800\uDEAD", which represents
U+102AD CARIAN LETTER T.  Rather it should say that "\uDEAD" is illegal
unless preceded by an escape between "\uD800" and "\uDBFF" inclusive.

> 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.

Most programming language standards don't require accurate and minimal
external representations of floats, Scheme being the exception.  I think
the existing wording is satisfactory.

John Cowan
[P]olice in many lands are now complaining that local arrestees are insisting
on having their Miranda rights read to them, just like perps in American TV
cop shows.  When it's explained to them that they are in a different country,
where those rights do not exist, they become outraged.  --Neal Stephenson