Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03

Peter Cordell <> Thu, 16 March 2017 10:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BF88127333 for <>; Thu, 16 Mar 2017 03:28:40 -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 zuq-wtH66IL5 for <>; Thu, 16 Mar 2017 03:28:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B131A127735 for <>; Thu, 16 Mar 2017 03:28:37 -0700 (PDT)
Received: (qmail 25859 invoked from network); 16 Mar 2017 10:21:12 +0000
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 16 Mar 2017 10:21:12 +0000
To: John Cowan <>, Carsten Bormann <>
References: <> <> <> <> <> <> <> <>
Cc:,, "" <>
From: Peter Cordell <>
Message-ID: <>
Date: Thu, 16 Mar 2017 10:28:28 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Mar 2017 10:28:40 -0000

On 14/03/2017 13:58, John Cowan wrote:
> In my opinion, we should either take all references to UTF-16 or UTF-32
> out, or add back a correct detection algorithm. UTF-8 is what is
> actually interoperable, and interoperability is what RFCs are supposed
> to be all about.

Combining the original (Tim's) & Martin's proposal with my tweak, plus 
John & Carsten's direction, how about:

8.1.  Character Encoding

    JSON text SHOULD be encoded in UTF-8 [UNICODE] (Section 3).  JSON
    texts that are encoded in UTF-8 are interoperable in the sense that
    they will be read successfully by the maximum number of

    There are many implementations that cannot successfully read texts
    in other encodings.  JSON text MAY be encoded in other encodings if
    the generator is sure that the intended parsers can read them.

    Implementations MUST NOT add a byte order mark to the beginning of a
    JSON text.  In the interests of interoperability, implementations
    that parse JSON texts MAY ignore the presence of a byte order mark
    rather than treating it as an error.

Are "generator" and "parser" the correct terms to use in this instance, 
or does that functionality sit above the character encoding layer?

Pete Cordell
Codalogic Ltd
Rules for Describing JSON Content,