Re: [Json] Advice on registering JSON Lines (not JSON) as IANA Media Type

Carsten Bormann <> Wed, 30 December 2020 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A87A3A0114 for <>; Wed, 30 Dec 2020 12:25:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tahEqYu3hoiY for <>; Wed, 30 Dec 2020 12:25:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C08A3A0888 for <>; Wed, 30 Dec 2020 12:25:22 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4D5jTD18N4zyXw; Wed, 30 Dec 2020 21:25:20 +0100 (CET)
From: Carsten Bormann <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_168463F5-DE77-4049-A5CE-B2CCC719FA71"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Wed, 30 Dec 2020 21:25:19 +0100
In-Reply-To: <>
Cc: Stefan Hagen <>, Nico Williams <>, "Hlavina, Wratko (NIH/NLM/NCBI) [E]" <>, Douglas Crockford <>, JSON WG <>
To: Tim Bray <>
References: <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Json] Advice on registering JSON Lines (not JSON) as IANA Media Type
X-Mailman-Version: 2.1.29
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, 30 Dec 2020 20:25:33 -0000

On 30. Dec 2020, at 20:49, Tim Bray <> wrote:
> In any case, to answer the original question, to register a media type you need to link to a stable specification.  The contents of <> probably don’t qualify, so the conventional thing would be to write an Internet-Draft which AFAICT would be the same as json-seq only without the leading "ASCII Record Separator (0x1E)" but retaining the trailing \n.

There is a bit more in which the JSON-sequence RFC differs from what would be a JSON-lines specification.

(Author of RFC 8742 here :-), another derivative from the JSON-sequence idea of registering a media type for a sequence.)

JSON sequences are sequences of arbitrary JSON texts, each enveloped in RS/LF.

JSON-lines are a sequence of LF-delimited lines, each of which is interpreted as a JSON text.

So you can’t have a newline in the JSON text that goes into a JSON-line.
(Which is not a big practical problem, as deleting all newlines from a JSON text creates an equivalent JSON text, even if equivalence is not really specified in the JSON specifications.)

We could have gone that way when the design of JSON sequences was still up in the air.
Some of the robustness properties of JSON sequences do come back with disallowing newlines in the JSON texts (which somehow was not something that was being considered very seriously).
As specified, JSON-lines does not have truncation detection; it needs to be changed to make the LF a line terminator, not a delimiter.

A leading RS is a great signature for JSON sequences; JSON-lines has no such thing.

Grüße, Carsten