Re: [Json] I-D Action: draft-ietf-jsonbis-rfc7159bis-04.txt

Pete Cordell <> Sat, 22 July 2017 07:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED94F131BC2 for <>; Sat, 22 Jul 2017 00:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NKWjCAM0m2BN for <>; Sat, 22 Jul 2017 00:36:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBC55126B6E for <>; Sat, 22 Jul 2017 00:36:42 -0700 (PDT)
Received: (qmail 10551 invoked from network); 22 Jul 2017 08:28:25 +0100
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 22 Jul 2017 08:28:24 +0100
To: Carsten Bormann <>, Peter Saint-Andre - Filament <>
Cc: Julian Reschke <>,
References: <> <> <> <> <> <> <> <>
From: Pete Cordell <>
Message-ID: <>
Date: Sat, 22 Jul 2017 08:36:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Json] I-D Action: draft-ietf-jsonbis-rfc7159bis-04.txt
X-Mailman-Version: 2.1.22
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, 22 Jul 2017 07:36:45 -0000

On 21/07/2017 17:07, Carsten Bormann wrote:
> It clearly has a nitpicking opportunity, but other attempts to improve the original text so far have made it worse.
> I was mainly trying to point out that the mere fact that one can willfully pretend to misunderstand this (or the previous) text does not mean that it actually is ambiguous to a cooperating reader — the previous version is just a bit hard to read (and shouts out that we had trouble wordsmithing it).  I was then trying to point out what the essence of the statement is: The term JSON when used in a context that implies interchange (as opposed to representing the concept of JSON within a program or single system) also includes its encoding in UTF-8.  But I’m not trying to wordsmith here, I’ll leave that to the native speakers.

You call it nitpicking, but I have struggled more times than I care to 
remember with lazy text in specs and I don't like to knowingly inflict 
it on others.

Your person that is "willfully pretend[ing] to misunderstand" is more 
likely someone who is trying to understand the spec in the first place. 
I find it quite offensive to suggest that anyone that doesn't understand 
the wording the way you do is wilfully trying to misunderstand it.

Here's another attempt, based on the feedback:

     JSON text that is to be machine interpreted in a layer of a protocol
     stack directly related to underlying network activity (e.g.
     JSON text in a REST over HTTP application, as opposed to JSON text
     transported opaquely over a generic data transfer protocol), and
     JSON text identified with the application/json media type, MUST be
     encoded using UTF-8 [RFC3629].

If nothing else, it shouts out better that we had trouble wordsmithing 
it ;-)

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers,
Read & write XML in C++,