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

"Martin J. Dürst" <> Fri, 23 May 2014 06:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 35F391A00DF for <>; Thu, 22 May 2014 23:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j3GwKSmmEMaf for <>; Thu, 22 May 2014 23:53:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E80241A004D for <>; Thu, 22 May 2014 23:53:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BB1A832E4F0; Fri, 23 May 2014 15:53:49 +0900 (JST)
Received: from (unknown []) by with smtp id 0d95_9506_50e356ce_f542_4336_a9f7_1e7ff56ae989; Fri, 23 May 2014 15:53:49 +0900
Received: from [IPv6:::1] (unknown []) by (Postfix) with ESMTP id 04F63C0234; Fri, 23 May 2014 15:53:49 +0900 (JST)
Message-ID: <>
Date: Fri, 23 May 2014 15:53:36 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Paul Hoffman <>, IETF JSON WG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 23 May 2014 06:53:54 -0000

I have said so earlier, and will say it here again: I consider this a 
*terrible idea*, because JSON in and by itself is perfectly able to 
represent sequences (using arrays).

The two things needed for making this work are changing the delimiter 
from a line break to a comma (trivial) and to start the thing with a '[' 
and end it with ']'. Only the ending part is non-trivial, but there are 
many ways to deal with it, depending on the parser at hand. These are 
very similar to the problems that some parsers will have with 
"overfeeding" them with more than a single JSON text.

The scarcity of actual use cases and the negligible amount of mostly 
just perceived difficulties with the main format (JSON) stand in stark 
contrast with the costs of *yet another format* (YAF, anybody?).

Questions, comments, and confusions such as "No, this isn't JSON, it's a 
JSON text sequence." or "Do we use JSON, or JSON text sequences?" and so 
on can best be avoided by just forgetting about JSON text sequences once 
and for all. Also, JSON text sequences aren't recursively composible.

So my baseline proposal is for the WG to just abandon this work item. 
It's in the charter, but at least that part of the charter came as a 
surprise and didn't have too many active proponents. It's better to 
acknowledge a mistake later than never.

If the WG can't get to such a conclusion, I alternatively propose to 
degrade the document to Experimental. That might make it possible to 
evaluate the actual need for such a format and balance it against the 
potential confusion.

I also propose that if the document moves forward with publication, it 
contain very clear text in the abstract, the introduction, the security 
section and potentially elsewhere to the effect that this is NOT JSON, 
and shouldn't be confused with JSON. It should also say that whenever 
there's a choice between JSON and JSON text sequences, the former 
(potentially with an array at the top) should be chosen unless there is 
an unrefutable reason for the later (this will increase interoperability).

The introduction also should tone down the discussion about problems 
with parsing a one-million value array. If that's a practical problem, 
then it's not too difficult to parse the delimiters separately and only 
have the values parsed by a JSON parser (the availability of a JSON 
parser that stops when having finished reading a single value is assumed 

Regards,    Martin.

On 2014/05/23 06:00, Paul Hoffman wrote:
> This begins a two-week Working Group Last Call on draft-ietf-json-text-sequence <>. We are seeking any and all comments on the document in order to assess the strength of consensus for it. If you are on this mailing list and have not yet read the document, please do so now, and then comment on the list. If you have already read the draft and commented, please feel free to do so again.
> As a reminder, comments can be anywhere in the continuum of "looks fine" to "terrible idea"; they can include questions; they can include suggestions for singificant editorial changes; they can include minor editorial notes.
> --Matt Miller and Paul Hoffman
> _______________________________________________
> json mailing list