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

Tim Bray <tbray@textuality.com> Sat, 13 May 2017 17:40 UTC

Return-Path: <tbray@textuality.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 04DD4129566 for <json@ietfa.amsl.com>; Sat, 13 May 2017 10:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.com
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 FyiXtvRa4o2E for <json@ietfa.amsl.com>; Sat, 13 May 2017 10:40:11 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6D4129439 for <json@ietf.org>; Sat, 13 May 2017 10:37:22 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id m17so43864999pfg.3 for <json@ietf.org>; Sat, 13 May 2017 10:37:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LU+OJM9fBWZTHWbDDvvgntoeGrbetaBecQ9hCTb+QMU=; b=Y43fjSuW4jbyyHmcvuH0hikulRtaGPi/Eev6PPdt0r2YtCfOOmlDVBqEdCGNm9ygYB jOUnePOKYmxZdKrVEoWCsismJcXUyq5pzIrkNA2o/GIebFfbBTuxTDs71RxmGvFuZRRV FDHF9IHi/LKd4Y3YKB7GsIP7gMxjX5x1x49ODoNZx+IM/SAQ0eB1rGHDIU3bvqivIOt2 mip3gFsZk6CG8VYB7DLboAcLvQtfkk70cHErJPsmCuRDlBmPWYfKfY1F1nXWZ88esLRg dIIM6JGZEZJSD9svwRQpLgiGnV+VIknnl/1qFqDUtIPUFdD6BZYlu5TzIR6pk7etqrkx TF5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LU+OJM9fBWZTHWbDDvvgntoeGrbetaBecQ9hCTb+QMU=; b=blZHhaP0HzvKYA3q27DZQ3+DXu9wAnKXmcYOP+Fx12DCiTnYd+JcMmIB6yzZl/skuo z6QQLua9Tn+Bxz+c1OLQPW8vEd45/Z9Iv08Fu74OBQ2yXdyKvegCLozrTsezilykG1JN XhTAhoA/KGB5HTG3Fa+L/d1XiVU1X13HN5gZgMEIXwwzeHLvvqOXEa8s5nl+5HuJah7F QUQuHMZNt+qj1FDHuouaunFq1gLqubaMZxW5MXc3qye9gAtZHi3HM0czKi6rCs9Kq0GD r1F+LGTbiWGH0naN3I9TlsbVKT/JN1tfdSGXZ/anlmYOMyD7BtT6jKiNeT2M3Fu9S5IL 4djA==
X-Gm-Message-State: AODbwcAWsLVDaGRyGC4CGHOtR2K6GJDbdRldbuF87SU6n30FYPYl1NVV 06k8pW4OZNATFwbxKzqffkhoTihctQ==
X-Received: by 10.84.214.22 with SMTP id h22mr13739431pli.96.1494697042145; Sat, 13 May 2017 10:37:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.180.132 with HTTP; Sat, 13 May 2017 10:37:01 -0700 (PDT)
X-Originating-IP: [24.86.134.32]
In-Reply-To: <db3e4d88-d3bc-2ab5-fd8d-0a9ed90865e9@codalogic.com>
References: <e69d7c21-85cb-45f4-c0c2-34c624e63049@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> <44b4523a-5e4b-ccad-af96-931d8b9ad1c2@codalogic.com> <ac1d1b68-67e7-c19f-a556-280df73f465b@outer-planes.net> <db3e4d88-d3bc-2ab5-fd8d-0a9ed90865e9@codalogic.com>
From: Tim Bray <tbray@textuality.com>
Date: Sat, 13 May 2017 10:37:01 -0700
Message-ID: <CAHBU6itmYDyBfz0qqr0LAUTuvdR1oBSUnz7VSie=pZRva=Ynzw@mail.gmail.com>
To: Pete Cordell <petejson@codalogic.com>
Cc: "Matthew A. Miller" <linuxwolf+ietf@outer-planes.net>, Julian Reschke <julian.reschke@gmx.de>, "json@ietf.org" <json@ietf.org>
Content-Type: multipart/alternative; boundary="f403045d26643e8bb6054f6b46ad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/Ke5CdSNeGYWE3I8UZXZdaWBqNno>
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: Sat, 13 May 2017 17:40:14 -0000

​I’m meh on the network-or-not language.

I have one source of heartburn.  The stated purpose of 7159bis is to
achieve harmony with ECMA 404.  That document does *not* constrain JSON
encoding.  I’m fine  with saying that JSON has to be UTF-8, but I think we
should consult with ECMA and see if the goal of spec harmonization is still
possible if we make the UTF-8 restriction.

I’m much more positive about the UTF-8 restriction than the ECMA harmony
(which I think is ridiculous political bushwah) but at least the WG should
know the context before making a call.​

On Wed, May 10, 2017 at 1:30 PM, Pete Cordell <petejson@codalogic.com>
wrote:

> On 10/05/2017 18:13, Matthew A. Miller wrote:
>
>> Assuming the Working Group finds that scope acceptable and finds UTF-8
>> only acceptable, here is a starting proposal for text:
>>
>> """
>> 8.1.  Character Encoding
>>
>> When transmitting over a network protocol, JSON text MUST be
>> encoded in UTF-8 (Section 3 of [UNICODE]).
>>
>> Previous specifications of JSON have not required the use of UTF-8
>> when transmitting JSON text. However, the vast majority of
>> JSON-based software implementations have chosen to use the UTF-8
>> encoding, to the extent that it is the only encoding that achieves
>> interoperability.
>>
>> Implementations MUST NOT add a byte order mark (U+FEFF) 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.
>> """
>>
>> If you find this acceptable, please indicate that.  Otherwise, please
>> provide suggested changes.
>>
>
>
> A strong +1 to the spirit of the proposal.
>
> I realise that the term "network protocol" is necessarily vague, but I
> wonder if it might be possible to avoid some confusion with the likes of
> NetBEUI (if that's still around) with a phrasing something like:
>
>     When transmitted as the syntax of a network protocol, or as a
>     payload of a network protocol intended to be interpreted as part of
>     a protocol, JSON text MUST be encoded in UTF-8 (Section 3 of
>     [UNICODE]).
>
> Thanks,
>
> Pete
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>



-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)