Re: [Json] Working Group Last Call on draft-ietf-json-text-sequence

Carsten Bormann <> Sat, 24 May 2014 17:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E65DE1A035C for <>; Sat, 24 May 2014 10:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.149
X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BlqOWiyxmBmd for <>; Sat, 24 May 2014 10:02:25 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A72B1A016C for <>; Sat, 24 May 2014 10:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s4OH2Dko029463; Sat, 24 May 2014 19:02:13 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 154C11DD9; Sat, 24 May 2014 19:02:12 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Sat, 24 May 2014 19:02:11 +0200
X-Mao-Original-Outgoing-Id: 422643731.338718-da57f3f51f22e82782e58bdbd5c39c58
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= <>
X-Mailer: Apple Mail (2.1878.2)
Cc: Paul Hoffman <>, IETF JSON WG <>
Subject: Re: [Json] Working Group Last Call on draft-ietf-json-text-sequence
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: Sat, 24 May 2014 17:02:27 -0000

On 23 May 2014, at 08:53, Martin J. Dürst <> wrote:

> it's not too difficult to parse the delimiters separately and only have the values parsed by a JSON parser

Indeed.  I continue to believe that this is the only reasonable way to operate on sequences of JSON instances.

1) use a delimiter that cannot occur in JSON (staying in UTF-8 with ASCII control characters as in NUL, FF or RS; or breaking out of UTF-8 as in using 0xFF bytes);
2) use LF as the delimiter, and remove the LFs from the JSON instances.

Using LFs as inter-stream delimiters, while also retaining their insignificant whitespace role within JSON instances, strikes me as the most complicated way to approach this problem.
There may be practical reasons to use this most-complicated way, but it seems suboptimal to standardize on it.

(I’m not a big fan of wrapping separate JSON instances in outermost JSON arrays for the kinds of applications addressed here.
This can obviously already be used for those cases where it works (no need for concatenation, no need for resilience), but except in those cases where a combined JSON instance had been the right thing to use in the first place, it combines all the same problems of dual-use LFs with the need to add wrapping brackets.)

Grüße, Carsten