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

Peter Cordell <petejson@codalogic.com> Mon, 13 March 2017 16:40 UTC

Return-Path: <petejson@codalogic.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D0A1296E3 for <ietf@ietfa.amsl.com>; Mon, 13 Mar 2017 09:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.919
X-Spam-Level:
X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Duo2EEb5vPC8 for <ietf@ietfa.amsl.com>; Mon, 13 Mar 2017 09:40:17 -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 ED54512951F for <ietf@ietf.org>; Mon, 13 Mar 2017 09:40:16 -0700 (PDT)
Received: (qmail 27794 invoked from network); 13 Mar 2017 16:26:18 +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); 13 Mar 2017 16:26:18 +0000
Subject: Re: [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Ned Freed <ned.freed@mrochek.com>
References: <otwresf20y4vnpmoboqqjnux.1489359742487@email.android.com> <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <f63c6a4a-dfbb-e03a-ea1e-38002f81ced8@it.aoyama.ac.jp>
From: Peter Cordell <petejson@codalogic.com>
Message-ID: <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com>
Date: Mon, 13 Mar 2017 16:33:33 +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: <f63c6a4a-dfbb-e03a-ea1e-38002f81ced8@it.aoyama.ac.jp>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/1_dS6WC9JtT0WklGU6arpUIuYbM>
Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" <json@ietf.org>, ietf@ietf.org, secdir@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2017 16:40:18 -0000

On 13/03/2017 07:51, Martin J. Dürst wrote:
> My personal opinion is that we could try to fix this by changing the
> following:
>
>>>>>
>    JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE]
>    (Section 3).  The default encoding is UTF-8, and 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 (such as UTF-16 and UTF-32).
>>>>>
>
> to something like the following:
>
>>>>>
>    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 (such as UTF-16 and UTF-32). JSON text MAY be encoded in
>    UTF-16 or UTF-32 [UNICODE] (Section 3) if the sender is sure that
>    the intended recipients can read them.
>>>>>

My only thought is to perhaps reflect that JSON isn't only transmitted, 
and JSON can be used for file based configuration etc, (even if this 
isn't strictly IETFs concern).  So perhaps s/sender/encoder/ in the last 
sentence, plus a few other tweaks yielding something like:

     There are many implementations that cannot successfully read texts
     in other encodings (such as UTF-16 and UTF-32 [UNICODE]).  JSON
     text MAY be encoded in other encodings if the encoder is sure that
     the intended recipients can read them.

Pete.
-- 
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
http://json-content-rules.org/
---------------------------------------------------------------------