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

Nico Williams <> Wed, 12 March 2014 05:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C6DDB1A07D5 for <>; Tue, 11 Mar 2014 22:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.101
X-Spam-Level: ***
X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.347, RDNS_NONE=0.793] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QvB6m9y95Nod for <>; Tue, 11 Mar 2014 22:03:19 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id E879D1A055D for <>; Tue, 11 Mar 2014 22:03:18 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id A6BA12005D10A for <>; Tue, 11 Mar 2014 22:03:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=ZGJ6xXE7eGGhNkM4Tv80 xYv2Fgs=; b=qkHRO0WQGGVHPBWiUul9GEgzjI/nrrF32Vz83fyxJO9Ayn4FhEyP sNmD7jnwcgIHYJuPRGfhjMdC16I+CkHA1aZvnIuu+Zj7HIPLDB9IjpglgAhraNFt Ufe7WlGWZYFLHAafC9Hgu26Hg7PR4k7gztXxr96MPnPepoy+sEYrDQc=
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 5AD962005D109 for <>; Tue, 11 Mar 2014 22:03:11 -0700 (PDT)
Received: by with SMTP id x13so11056482wgg.14 for <>; Tue, 11 Mar 2014 22:03:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gfeZHvVmrzaMU4B068z51tyRdyE9NfIaJ+tD4V+wQqw=; b=YXisZ0wQYwz783EKuJijkbtyUtjNlMCNdMQTBfWJvuEkUpn7doCabWO6UeCCx+RTkP 4JoUGRFVq4uA2BA+jkXzVNt220HDxjq4SSjWQmOjWlUapsulg3lGOjtpPotVzQW/MLrf 1RsX1av3ldWQOqaAS93uHlb+S7lkSzb9C9tYg3BUDYxmNJll1AqbucRTL/+C1PRuA/r3 gqCG5DTUYSOjixvblRWCEONgbMfndLLqqxfuak0dLd6gu/fuyqWLca6fJVvuvZ9Nr+JI NbkVkNwvxSRF+mMq5S32EZQJYxd5Gmg5AfwC7joPdX2+L8ww87/7ZQAGL53btIyQDMxq b5qw==
MIME-Version: 1.0
X-Received: by with SMTP id e5mr39109454wjr.32.1394600590101; Tue, 11 Mar 2014 22:03:10 -0700 (PDT)
Received: by with HTTP; Tue, 11 Mar 2014 22:03:10 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Wed, 12 Mar 2014 00:03:10 -0500
Message-ID: <>
From: Nico Williams <>
To: Tim Bray <>
Content-Type: multipart/alternative; boundary=047d7ba979dac6d60304f461c055
Cc: Nico Williams <>, "Manger, James" <>, "" <>
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: Wed, 12 Mar 2014 05:03:21 -0000

On Tuesday, March 11, 2014, Tim Bray <> wrote:

> Except for, in this kind of application, I think it’s really foolish to
> write out anything but objects. In which case you could theoretically have
> no separators.

I don't think that's going to change running code.  Indeed, this is about
writing down what's actually been implemented and deployed that doesn't
suffer from ambiguities.  You also seem to want all JSON texts to be
objects, but wanting ain't getting :)

> I lean to \s+ because as soon as you see the first char, you’re at the
> start of the next legal JSON text.

The separator can be whitespace.  It can be any whitespace recognized as
such in the JSON ABNF.  It could be a subset of that.  It also could be any
character or string of them that can't start a JSON value's encoding.
 Since in practice existing apps use whitespace, we should use whitespace.
 If other apps can be found using ", " or "," or whatever, we might be able
to require parser support for all of them or else define multiple MIME

Since any contiguous sequence of separators cannot yoeld an empty JSON text
(since we've not defined the meaning of such a thing), And given what apps
like jq apps do, I think any number of contiguous separators must be
equivalent to just one.

Also, it's much better to follow a text with a separator than to only
precede them with a separator.  This is so parsers needn't wait for the
next text or EOF before yielding a true/false/null/numeric top-level value.

Finally, I think we should require that sequence parsers be able to handle
missing separators where they aren't necessary to disambiguate texts.