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

Peter Cordell <petejson@codalogic.com> Thu, 16 March 2017 10:28 UTC

Return-Path: <petejson@codalogic.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70B7127097 for <json@ietfa.amsl.com>; Thu, 16 Mar 2017 03:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUbDqhWzKwu9 for <json@ietfa.amsl.com>; Thu, 16 Mar 2017 03:28:38 -0700 (PDT)
Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1266127333 for <json@ietf.org>; Thu, 16 Mar 2017 03:28:37 -0700 (PDT)
Received: (qmail 25859 invoked from network); 16 Mar 2017 10:21:12 +0000
Received: from host109-158-230-32.range109-158.btcentralplus.com (HELO ?192.168.1.72?) (109.158.230.32) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 16 Mar 2017 10:21:12 +0000
To: John Cowan <cowan@ccil.org>, Carsten Bormann <cabo@tzi.org>
References: <otwresf20y4vnpmoboqqjnux.1489359742487@email.android.com> <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <f63c6a4a-dfbb-e03a-ea1e-38002f81ced8@it.aoyama.ac.jp> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> <cf6e35ba-6a67-4b35-d4e1-e99fee6e9f19@gmx.de> <1F1D1DCB-767F-490D-A425-AB5E66D51D3E@tzi.org> <CAD2gp_R7raq0mzfhATTYONdowBm0HvVHFAqJqoVcLmYABrgPpA@mail.gmail.com>
Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, secdir@ietf.org, "json@ietf.org" <json@ietf.org>
From: Peter Cordell <petejson@codalogic.com>
Message-ID: <c20a17b7-0329-db5b-0983-23ebe11720f2@codalogic.com>
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: <CAD2gp_R7raq0mzfhATTYONdowBm0HvVHFAqJqoVcLmYABrgPpA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/hnrdlbXRIhcekdWVSSlVxWclhAs>
Subject: Re: [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=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
    implementations.

    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, http://json-content-rules.org