Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard

"Manger, James" <> Tue, 11 March 2014 23:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 265041A0888 for <>; Tue, 11 Mar 2014 16:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IwhBOQQpMTJw for <>; Tue, 11 Mar 2014 16:01:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 62B491A088D for <>; Tue, 11 Mar 2014 16:01:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,634,1389704400"; d="scan'208";a="191106882"
Received: from unknown (HELO ([]) by with ESMTP; 12 Mar 2014 10:01:11 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,7374"; a="157239432"
Received: from ([]) by with ESMTP; 12 Mar 2014 10:01:11 +1100
Received: from ([]) by ([]) with mapi; Wed, 12 Mar 2014 10:01:11 +1100
From: "Manger, James" <>
To: Nico Williams <>
Date: Wed, 12 Mar 2014 10:01:11 +1100
Thread-Topic: [Json] Proposal: JSON text sequence MIME type and Proposed Standard
Thread-Index: Ac89a8+Am9XXEQ08Sgmfh22qtrI9KAAEfvWO
Message-ID: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Json] Proposal: JSON text sequence MIME type and Proposed Standard
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: Tue, 11 Mar 2014 23:01:21 -0000

A short spec on JSON sequences is a good idea, Nico.

I agree that a newline is the best separator for creators to include, and always including it is best.

Some (most?) receivers will be more lenient and accept values separated by any whitespace, or with no separator (for objects, arrays, and/or strings). Perhaps it is best for interop to say receivers MUST be this lenient.

James Manger

On 12 Mar 2014 07:52, Nico Williams <> wrote:
On Tue, Mar 11, 2014 at 1:20 PM, Nico Williams <> wrote:
> Details:
>  - the newline is REQUIRED when following any of "true", "false",
> "null", or any numeric value, otherwise it is RECOMMENDED (but
> optional)

Just to clarify: it should be possible to build a JSON text sequence
parser given the above and any existing JSON parser, even when the
JSON texts do have embedded newlines (e.g., between array elements,

The rationale for using a newline is twofold:

 - it's roughly how text-based log files tend to work;
 - there's always a "readline" primitive about that can be used to
build a JSON text sequence parser (in conjunction with a JSON parser,
of course).

And, of course, these are _texts_, so newlines help readability.

And this:

>  - it will be RECOMMENDED that JSON texts written to JSON text
> sequences be encoded with no newlines in the encoding.

would only help implementors who lack an incremental JSON parser, but
it would only help them if this were a requirement, which it shouldn't
be, thus there's no point to this recommendation, so I'll just remove


json mailing list