Re: [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding"

Pete Cordell <petejson@codalogic.com> Wed, 10 May 2017 14:04 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 9328B129B50 for <json@ietfa.amsl.com>; Wed, 10 May 2017 07:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.78
X-Spam-Level: *
X-Spam-Status: No, score=1.78 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 haPYqxHorrfh for <json@ietfa.amsl.com>; Wed, 10 May 2017 07:04:31 -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 0A901129B45 for <json@ietf.org>; Wed, 10 May 2017 07:04:29 -0700 (PDT)
Received: (qmail 29344 invoked from network); 10 May 2017 14:56:45 +0100
Received: from host109-156-38-129.range109-156.btcentralplus.com (HELO ?192.168.1.72?) (109.156.38.129) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 10 May 2017 14:56:45 +0100
To: Julian Reschke <julian.reschke@gmx.de>, "json@ietf.org" <json@ietf.org>
References: <e69d7c21-85cb-45f4-c0c2-34c624e63049@outer-planes.net> <CAD2gp_T0bfpnsCA_t4BAMtEhr7p8JkZggjnY4F+m9-M2hWLfmw@mail.gmail.com> <1e94516c-9c82-8b0e-0d2d-7dbaa83b21bd@outer-planes.net> <40e3207f-e047-c898-1f0c-4422de1d597a@it.aoyama.ac.jp> <1b3ec14a-927a-8d46-e3d3-9807a9588437@outer-planes.net> <CAHBU6ivsq8+Z=MMkUH+=Q0uwc5NCtaJLYw5cp0Qg8eX2hQQ6sA@mail.gmail.com> <b74cb31b-8e04-17d0-548a-fc164ce07c05@outer-planes.net> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> <eabbccb0-8d15-d595-7cd0-37acc0621c57@it.aoyama.ac.jp> <6eb23f90-6623-7888-bc1c-6640a9dababc@codalogic.com> <61bfad2b-850d-a11f-e80b-d5ed9ccb4dc9@codalogic.com> <08a88696-65ef-da05-0d77-1a07d04ebfc8@outer-planes.net> <bb9fead6-23e7-8c1d-bc80-b60c81c4b89a@codalogic.com> <6f047d01-ad72-59ab-9d34-20a8177ab3af@outer-planes.net> <be4d9f12-a4be-3723-e52a-56a60722a75f@gmx.de> <a3805f67-620b-67f0-9c06-c865b71029e7@codalogic.com> <bb1ef6a8-506c-344b-b903-980ed50ad2d3@gmx.de>
Cc: Matthew Miller <linuxwolf+ietf@outer-planes.net>
From: Pete Cordell <petejson@codalogic.com>
Message-ID: <44b4523a-5e4b-ccad-af96-931d8b9ad1c2@codalogic.com>
Date: Wed, 10 May 2017 15:04:27 +0100
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: <bb1ef6a8-506c-344b-b903-980ed50ad2d3@gmx.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/g4y40L2PVJqBjGrB5tmIjFMDWlo>
Subject: Re: [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding"
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: Wed, 10 May 2017 14:04:31 -0000

On 10/05/2017 14:08, Julian Reschke wrote:
> I believe we should have separate names for JSON represented as a
> sequence of characters (such as in a string variable in a programming
> language) and for a JSON-shaped octet sequence inside a
> "application/json"-typed (HTTP) message. For the latter, enforcing UTF-8
> IMHO is attractive.
>
> I think it's ok for the spec to talk about both, but it really needs to
> be clear what we are talking about in each section.

It's an interesting thought on JSON in programs.  It would be strange to 
be able to say it was not valid JSON if it was encoded in a string 
inside a Shift-JIS encoded Ruby program for example.

My ISO layers are rusty, but it looks like we can talk about JSON 
character sequences somewhere above the transport layer, and JSON 
encoded messages somewhere below the transport layer.  The latter 
possibly being transport specific.

To me it would seem discussion of "JSON" (without any further 
refinement) ought to be independent of the lower layer transport 
encoding aspects.

"application/json" would be one transport specific encoding (for which I 
think most are happy with only UTF-8).  JSON inside a Shift-JIS encoded 
Ruby program is in effect another form of transport for a JSON message.

Cheers,

Pete.