From nobody Mon Apr 17 10:41:38 2017 Return-Path: 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 3D0A31316FB for ; Mon, 17 Apr 2017 10:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 wfm7-Ze91yOL for ; Mon, 17 Apr 2017 10:41:35 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 396881316E8 for ; Mon, 17 Apr 2017 10:41:32 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id b187so149762042oif.0 for ; Mon, 17 Apr 2017 10:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=+U5xzfgQM2gJeFdXYHGnxX1YriZ/3SR3EMdyDUnR3T0=; b=Bl4tyl6iJ0IgEEolW0TS9BvPMQFDn5K/uqrGfrLyLmuCpDPpWUbOpwWlajDkLpEKK4 STauCdSXgbK/PYCOgbZLBPutx/WfeWjT6as4WmEU3C30GPZPzTo3GMVbSQQX3FcYa0wu NxYxmfRqbbrPLCD0BsRIBu406QtSzqffqmMhUIQxiW0inkwGRI+bmSPuZ+84DNIZGKHV nWxFXUyovrs2zWmrBG6AmqFeXoP/76VegBM2VmQnLvKICbWwXJB+jLCdDmCgaonA6/E5 VGIguqVdU17nHLxRAwHyrOO4w0eNTPF3emdt3AfkY7nux6PzRi1UYM9g3lWOtEXA4MbX Q/Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=+U5xzfgQM2gJeFdXYHGnxX1YriZ/3SR3EMdyDUnR3T0=; b=iOYDAoPifUQiYOHFQ9Z1hmX4QJ5vhy2PUfTNb2HjKK+mruVRVYRWuXfxTPxj9WBEDI tS1YJ3omIFrDqm0g+k01g3jFbRrQ7gj5ipDW8VoPWcSHdeBxfACzvvZ6PdtX3u6a18SG MOX1feqHPQZ3aA3SJlF1jJobt0XtO/uIR2fw9fz9nzd/J5w5sNxYBsfpGDN9ApY6qc3i R39Zxz2CcGb0uIVHXCDNIIcpix5Ab00oqwp2hylBHffLE8HeTIkfJOaEUNSg1M/W2Lmc cliwKnjupZet1gGQNbzc1aI65tzUOAxMBXdcogJ0oC/1aps1SxW5QUG757PE71OUSM+2 m7rA== X-Gm-Message-State: AN3rC/7ryk5Z22k5P8yPS8oVGTcxMwfQnAuaUG/Nkl7aKhLZ3QOxl9// RTUukYERl4xVng== X-Received: by 10.202.183.5 with SMTP id h5mr5741964oif.195.1492450891376; Mon, 17 Apr 2017 10:41:31 -0700 (PDT) Received: from [10.6.23.170] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id h189sm5032858oic.37.2017.04.17.10.41.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Apr 2017 10:41:30 -0700 (PDT) Sender: Matthew Miller To: Tim Bray Cc: "json@ietf.org" References: <1fb5849e-8dbf-835d-65b7-2403686248f9@outer-planes.net> <0E32A94D-CE12-4F52-9ED6-8743C49751B4@vpnc.org> <4d2f0fb3-a729-0c17-2394-bc1e005dd612@gmx.de> <804f9930-26a5-a565-0607-452b386cfeb5@outer-planes.net> <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> From: "Matthew A. Miller" Message-ID: Date: Mon, 17 Apr 2017 11:41:29 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="27d8Ibhnlj0TI78usrHRuGfoWJkqTBGaa" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:41:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --27d8Ibhnlj0TI78usrHRuGfoWJkqTBGaa Content-Type: multipart/mixed; boundary="oGLjVhp9QvAJBJJmFslvwjqGPWILQ6gBe"; protected-headers="v1" From: "Matthew A. Miller" To: Tim Bray Cc: "json@ietf.org" Message-ID: Subject: Re: [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding" References: <1fb5849e-8dbf-835d-65b7-2403686248f9@outer-planes.net> <0E32A94D-CE12-4F52-9ED6-8743C49751B4@vpnc.org> <4d2f0fb3-a729-0c17-2394-bc1e005dd612@gmx.de> <804f9930-26a5-a565-0607-452b386cfeb5@outer-planes.net> <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> In-Reply-To: --oGLjVhp9QvAJBJJmFslvwjqGPWILQ6gBe Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 17/03/27 22:48, Tim Bray wrote: > First of all, let me say that I=E2=80=99m delighted with, and fully sup= port, the > promotion of the status of UTF-8 in the JSON RFC to MUST. I suspect > this steps way outside the JSONbis charter, but that=E2=80=99s a proble= m for > chairs and ADs, not yr humble editor. >=20 > Comments on Matt's proposed text: >=20 > 1. How about a very short historical note, along the lines of: =E2=80=9C= Previous > specifications of JSON, including the predecessor RFCs, have not > required the use of UTF-8 for use with the application/json media type.= =20 > However, implementors of JSON-based software have overwhelmingly chosen= > to use the UTF-8 encoding, to the extent that it is the only realistic > way to achieve interoperability in software which generates or consumes= > JSON.=E2=80=9D >=20 > ... moving on... >=20 > =E2=80=8B=E2=80=8B > O > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > n Mon, Mar 27, 2017 at 1:04 PM, Matthew A. Miller > > wrote: > =E2=80=8B=E2=80=8B >=20 > =E2=80=8B=E2=80=8B > JSON text SHOULD be encoded in UTF-8 (Section 3 of [UNICODE]); JSON= > =E2=80=8B=E2=80=8B > text MAY be encoded in UTF-16 or UTF-32 if the generator is certain= > =E2=80=8B=E2=80=8B > the intended recipients can process it. JSON text MUST NOT be encod= ed > =E2=80=8B=E2=80=8B > in any encoding other than UTF-8, UTF-16, or UTF-32. When used with= > =E2=80=8B=E2=80=8B > media type "application/json" the JSON text MUST be encoded as UTF-= 8. >=20 >=20 > =E2=80=8B2. Seriously, why the =E2=80=9CJSON text MAY be encoded in=E2=80= =A6 can process it =E2=80=8B=E2=80=9D > phrase? It=E2=80=99s a distraction, and if people want to do that, we = can=E2=80=99t > stop them, but we shouldn't waste RFC space talking about practices tha= t > are not remotely interoperable. The I in IETF stands for Internet, and= > JSON on the Internet is UTF-8, end of story. > =E2=80=8B=E2=80=8B >=20 > Recipients that wish to support Unicode encodings other than UTF-8 > can do this using a detection mechanism that is based on the fact > that the first character will always have a Unicode code point > greater than 0 and less than 128, thus the UTF-16/32 variants can > be detected by inspecting the first octets for nulls. >=20 >=20 > =E2=80=8B3. Is it just me, or does it feel really dorky to talk mysteri= ously > about this detection mechanism without providing details? On top of > which, anyone who's writing the kind of software that might lead one to= > consult =E2=80=8Ban RFC first shouldn't bloody well use anything but UT= F-8. If > people really want to have this, I think we owe the world an outline of= > the algorithm, maybe in an appendix. I'll volunteer to make my best > effort to draft it and try to get consensus that it's correct.. If we > can't, that's a powerful symbol that we shouldn't have this language.=20 > But that's my fallback position; my real request to the group is that w= e > just take this out. >=20 [ /me doffs hat ] Thinking about this more, putting an encoding detection algorithm as an appendix seems like a reasonable compromise to me. To start, how about removing the detection text from Section 8.1 and have an appendix that starts with that text plus the table? Assuming the above, what does everyone think of the following for Section 8.1? """ JSON text SHOULD be encoded in UTF-8 (Section 3 of [UNICODE]). JSON text MUST NOT be encoded in any encoding other than UTF-8, UTF-16, or UTF-32. When used with media type "application/json" the JSON text MUST be encoded as UTF-8. Previous specifications of JSON have not required the use of UTF-8 with the "application/json" media type. 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. """ - m&m Matthew A. Miller --oGLjVhp9QvAJBJJmFslvwjqGPWILQ6gBe-- --27d8Ibhnlj0TI78usrHRuGfoWJkqTBGaa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY9P5JAAoJEOz0ck4QngW7mKYIAISFg6jlVXVnfyH9/Wvud48m At4DG2MEdVcopXRvLsSpY1Pfuqt1Zrdm6UIAGl5QKXO9orp+Dt5w3NRsevvjbvur QqoyRUqEAbEDOc+/XDK1w6lgnkQZmD/V4q4vEsj8zUUsER2PAGWDenlzkgzDxvu5 6xeo6fyVHiZFz+mWlP1uZuShwCWcE2WaM/tjw8N2Z2iolzbK6ougdXnIi8ZPJz8z hAfSF4GO3ho/q2idXXbCqrM+0B5Fe55JykwGY2sqt6ADc4V1PZiVGqPpPFwOaSW1 xVByZqoT2bDOaeb/wJRv5QA2vz2AYe3uQ4USaxpP6sJiehj/5i7iYpK0mjrejms= =gd74 -----END PGP SIGNATURE----- --27d8Ibhnlj0TI78usrHRuGfoWJkqTBGaa-- From nobody Mon Apr 17 10:56:58 2017 Return-Path: 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 6CD5413172A for ; Mon, 17 Apr 2017 10:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham 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 kWY_ekhhfcXU for ; Mon, 17 Apr 2017 10:56:56 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4A5131758 for ; Mon, 17 Apr 2017 10:56:32 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 6756DA00CEC2; Mon, 17 Apr 2017 10:56:31 -0700 (PDT) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id F1EB8A000B32; Mon, 17 Apr 2017 10:56:30 -0700 (PDT) Date: Mon, 17 Apr 2017 12:56:28 -0500 From: Nico Williams To: "Matthew A. Miller" Cc: Tim Bray , "json@ietf.org" Message-ID: <20170417175627.GK23461@localhost> References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:56:57 -0000 On Mon, Apr 17, 2017 at 11:41:29AM -0600, Matthew A. Miller wrote: > [ /me doffs hat ] > > Thinking about this more, putting an encoding detection algorithm as an > appendix seems like a reasonable compromise to me. To start, how about > removing the detection text from Section 8.1 and have an appendix that > starts with that text plus the table? Or we could even just assert that such an algorithm is possible, and that implementors MAY implement one. > Assuming the above, what does everyone think of the following for > Section 8.1? +1. Nico -- From nobody Mon Apr 17 12:09:08 2017 Return-Path: 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 7C85213178C for ; Mon, 17 Apr 2017 12:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 B1TBrIlLTjko for ; Mon, 17 Apr 2017 12:08:56 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66D4131784 for ; Mon, 17 Apr 2017 12:08:56 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3HJ5ARo034915; Mon, 17 Apr 2017 15:08:52 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 29w19ugy9w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Apr 2017 15:08:52 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3HJ8qBh010161; Mon, 17 Apr 2017 15:08:52 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3HJ8aXQ009478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Apr 2017 15:08:47 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Mon, 17 Apr 2017 19:08:30 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.214]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0319.002; Mon, 17 Apr 2017 15:08:30 -0400 From: "HANSEN, TONY L" To: Nico Williams , "Matthew A. Miller" CC: Tim Bray , "json@ietf.org" Thread-Topic: [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding" Thread-Index: AQHSt61rncR3U2Zdz0+qv2Tts8xqGqHJ7LSA Date: Mon, 17 Apr 2017 19:08:30 +0000 Message-ID: References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> In-Reply-To: <20170417175627.GK23461@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.110.223] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-17_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704170168 Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 19:09:01 -0000 DQoNCk9uIDQvMTcvMTcsIDE6NTYgUE0sICJqc29uIG9uIGJlaGFsZiBvZiBOaWNvIFdpbGxpYW1z IiA8anNvbi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBuaWNvQGNyeXB0b25lY3Rvci5j b20+IHdyb3RlOg0KDQogICAgT24gTW9uLCBBcHIgMTcsIDIwMTcgYXQgMTE6NDE6MjlBTSAtMDYw MCwgTWF0dGhldyBBLiBNaWxsZXIgd3JvdGU6DQogICAgPiBbIC9tZSBkb2ZmcyBoYXQgXQ0KICAg ID4gDQogICAgPiBUaGlua2luZyBhYm91dCB0aGlzIG1vcmUsIHB1dHRpbmcgYW4gZW5jb2Rpbmcg ZGV0ZWN0aW9uIGFsZ29yaXRobSBhcyBhbg0KICAgID4gYXBwZW5kaXggc2VlbXMgbGlrZSBhIHJl YXNvbmFibGUgY29tcHJvbWlzZSB0byBtZS4gIFRvIHN0YXJ0LCBob3cgYWJvdXQNCiAgICA+IHJl bW92aW5nIHRoZSBkZXRlY3Rpb24gdGV4dCBmcm9tIFNlY3Rpb24gOC4xIGFuZCBoYXZlIGFuIGFw cGVuZGl4IHRoYXQNCiAgICA+IHN0YXJ0cyB3aXRoIHRoYXQgdGV4dCBwbHVzIHRoZSB0YWJsZT8N CiAgICANCiAgICBPciB3ZSBjb3VsZCBldmVuIGp1c3QgYXNzZXJ0IHRoYXQgc3VjaCBhbiBhbGdv cml0aG0gaXMgcG9zc2libGUsIGFuZA0KICAgIHRoYXQgaW1wbGVtZW50b3JzIE1BWSBpbXBsZW1l bnQgb25lLg0KICAgIA0KICAgID4gQXNzdW1pbmcgdGhlIGFib3ZlLCB3aGF0IGRvZXMgZXZlcnlv bmUgdGhpbmsgb2YgdGhlIGZvbGxvd2luZyBmb3INCiAgICA+IFNlY3Rpb24gOC4xPw0KICAgIA0K ICAgICsxLg0KDQoNCknigJl2ZSBhcmd1ZWQgYmVmb3JlIGZvciBoYXZpbmcgdGhlIGVuY29kaW5n IGRldGVjdGlvbiBhbGdvcml0aG0gcHV0IGludG8gYW4gYXBwZW5kaXguIElmIGl0IHdlcmUsIEkg YWxzbyB2b3RlICsxIHRvIHRoZSByZXdvcmRpbmcuDQoNCglUb255IEhhbnNlbg0KDQo= From nobody Mon Apr 17 13:47:32 2017 Return-Path: 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 027F712946A for ; Mon, 17 Apr 2017 13:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 4ER2YFGpdQl4 for ; Mon, 17 Apr 2017 13:47:29 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F287F127977 for ; Mon, 17 Apr 2017 13:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3HKlQOk008486; Mon, 17 Apr 2017 22:47:26 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w6L1B0tznzDHZL; Mon, 17 Apr 2017 22:47:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <20170417175627.GK23461@localhost> Date: Mon, 17 Apr 2017 22:47:25 +0200 Cc: "json@ietf.org" X-Mao-Original-Outgoing-Id: 514154845.386077-d3cecfa11bde7041eb62cc206db2b592 Content-Transfer-Encoding: quoted-printable Message-Id: <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> To: "Matthew A. Miller" X-Mailer: Apple Mail (2.3273) Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 20:47:31 -0000 On Apr 17, 2017, at 19:56, Nico Williams wrote: >=20 >> Thinking about this more, putting an encoding detection algorithm as = an >> appendix seems like a reasonable compromise to me. To start, how = about >> removing the detection text from Section 8.1 and have an appendix = that >> starts with that text plus the table? >=20 > Or we could even just assert that such an algorithm is possible, and > that implementors MAY implement one. Indeed. Broken record mode: =E2=80=94 writing up the algorithm sounds like encouraging = implementation. We *don=E2=80=99t* want people to implement this! (The whole interminable non-UTF-8 saga probably just was a nod from = the RFC 4627 authors to the remnants of UTF-16 land, which mostly have = died off since. Why resurrect?) - there have been about 15 attempts to define this algorithm on the = mailing list. All were wrong. An Internet Standard should contain tried and true material, not = errata fodder. - an implementer is in a much better position to get this right than the = standard, because they can write unit tests. >=20 >> Assuming the above, what does everyone think of the following for >> Section 8.1? >=20 > +1. +1 Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 17 22:22:35 2017 Return-Path: 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 114F3126CC7 for ; Mon, 17 Apr 2017 22:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 I3zjtsc7rsTc for ; Mon, 17 Apr 2017 22:22:31 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0116.outbound.protection.outlook.com [104.47.92.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0765F129415 for ; Mon, 17 Apr 2017 22:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z0HKLlucBDL9MpSkZFi3FRhGo6kkwX6fPIaHF2KXXw0=; b=AWs7fjSmbDWrpiITbuuzPG7Sn15vHF3THer3R6TwbOGDqsTaQs+LtKhOpZA/DlWqJdjFfAnGmSIGVUwVHYgd5qAOvw79/73fUwP4ccWa72z2P4HM72kpeFCLv/pe9/G1YjuAOKnhJZCHo/ehHEtJyaNiV++NtzV9+bDpXkOc4x8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0644.jpnprd01.prod.outlook.com (10.167.176.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Tue, 18 Apr 2017 05:22:25 +0000 To: Carsten Bormann , "Matthew A. Miller" References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> CC: "json@ietf.org" From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Tue, 18 Apr 2017 14:22:22 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0040.jpnprd01.prod.outlook.com (10.164.161.150) To OS2PR01MB0644.jpnprd01.prod.outlook.com (10.167.176.142) X-MS-Office365-Filtering-Correlation-Id: e2fa32ed-7329-401c-6c83-08d4861ae695 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:OS2PR01MB0644; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0644; 3:pqlV3cYT9zCUvNN6/xF9QnsZL9iUtbDJLb3W2H0RGt7dDrft4w29Uup++P3dlNp255u/h5yRmy/DIvDY9lfE5SrOjEPVhXFWGp3vymunWUK4Jr2i1kpWHLeJK6gpXLb8nDZY/beMTRlHyEEeGknu4R2w5tkwd/AUPFu6dD/mmDibxyCro2iVrf/YQE3gy9TnuTYMf8RL+piIhuEUyFUBADir3Fh1y1CIrpq51yDipEgbIU+l4McCkUUn2qYeagf1IYDVQWitCfcB3TpcdRsDgMHp9BEATnkRTX5DuwvrEF+IwYd8IU4BNk/+gOVASybXOX2uRmjSldX5AYj7hYao2w==; 25:tqV3AJv65/WlDJSqHtcFkcFXAVCpWs19T4KsykNH3r+S1xc+VpAqkFrbIjWFed/1lBgeycIKoehdfVpURlI+POkhFoD7DA0iM4Axm+Q/13gCiY6QSL1ePlyaYtDPbR0Wc0fqa1OUxfee8d7psu48CZy16rsSy/HqiMTMb7C0vMbUpL9Kp/auApgl2gk1drvQ/7aeqKEAFSiNOEj0vvrIA+kW5tNGCzsCfqNSZgJ6sWcG+FkoMKNIkFmRsZUynk6bEY7GwgMjRaJ/yybHYJ59f5txS1ztLB1lh9Qz6vDvJ/NXfyYPhdSp5ZUtlLWI9tvhIajollxpoBcdlkWZJYl4f6c0MxpHI+pfxiEQByyZJsBGdEdn9WmdrctUiRZbDQSKiw/FRtg7bpZWqAa+8az1oye+DACuIUXVsf8IsceqFWx5/NPFWDsiXRjpTDo6EDfVr595EPqt4sBr2TVHJYQm3g== X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0644; 31:bA5R330JcHQBsg9dOiJZohVBAHst75WxR/XmDvt88RRNGADhyb6yIzrUm2D+N/DjRRA6sJJJeTJXgoovXUOg/J0clRD2zJ7BfQzCfaws93eW3J3IMvQmluH6+VVlr6gafITiWY3mHKLAbw5103T+N2wNWN3PjGK10eRg0eruRmUL6uBH3PQywRHTjgWslDXg0G7X8sOTWcLt5tVUwU25MXnyRfHS6oCZzCl1M0bDocopcNQoH4jWKNcyeRzhrtoNJjTCC5vMNxVDckyS+FqQHg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:OS2PR01MB0644; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0644; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0644; 4:YIidxQjfA3NMp2ReTjoOp9T0oDZW0Y50vzXcsQwUG1jMhVzzMCIZIZ251kxSwTkYCeYbh9Dtn3dqoNsqti7gdjOf5U/xreWuympur4JGRMHW/FMFKpsQn6g88czSwT8mSYv49jp9M/eDS6fSP1tU2KaP1c/q+kGVTtW/74/ZznzdDDcsHxxX4odsJG7fXfe9VAJRzQQqbn4Zuw07RnodCAPUiMiO09MxBuQVuVROALHynitjuDhoeMrTnY/gBGy+UBd6HVEr6Y4Aq1NlC25sWUzXc8vkc44E4vUk8qKpcgIGcca49hcIcuAaTSc4wqV+QT9skXPgHs1cHsEricrhYYR/A/3oSHknGu+AZJkIGoDxHl4AoBaOuDYtlwkLuprPOZXXqn5Ue2I1FQ2nj/gBJsBGEdkrRRcMUWFTvC+Eca1rY9DBsP4/j4tLb0NWI5NsSgceqGMOjJQwspvNw0sr5DyQwW8sJ0EwQUUCSuIdEvoMEjzRH9QXSJ5jXKJBPV6K4kO/mFLqKziCUPLDlHndxHX565Y+iKfRQb0owlMqm2pxREPMUEyW0KHxrbhrFwzvrBqQBAKiSAuVVVYl8bQ4zCcIYaAR3HL696WkUrevvUTW3FLwlYRGf/zpzfrZ57pvWCGezbziv8+XiF2LEsiLcjXcPMp+qChpcsD6TnZxwFJfAsN5T6rRgOE9dZ40tA+R35m/T8u3nVMzxwtgk3Vz6+2VsPakHqFbFLfjI3p0hX481OTEU6loHN3TqSgMRXeIWv8IKcrHmkr2/BGIjM7MTg== X-Forefront-PRVS: 028166BF91 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39400400002)(39410400002)(39450400003)(39830400002)(24454002)(42882006)(81166006)(25786009)(65956001)(65826007)(76176999)(54356999)(66066001)(2950100002)(53546009)(47776003)(7736002)(4326008)(6246003)(189998001)(305945005)(23676002)(8676002)(50466002)(83506001)(53936002)(33646002)(42186005)(3846002)(86362001)(2906002)(74482002)(31696002)(38730400002)(6666003)(31686004)(90366009)(4001350100001)(5660300001)(229853002)(50986999)(6486002)(93886004)(2870700001)(6116002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0644; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwNjQ0OzIzOkxjS2FVb2ZPNUZ6TytxZWVpbFJ2L3dTRTl6?= =?utf-8?B?aURlbEhPTS95OEZoSkdlZFMwUUpyaG1uVi84SXB3WEp4enVhREVJQW1NQ3BC?= =?utf-8?B?dFcrSDlHeVdaS25UUDljZHEvK0x0S0tUTHNNcU0xN3dycG5rTnVPTytrcUM3?= =?utf-8?B?SldOSFdGaVY1RlRObEZQRTZXMXhHeGhYTTdSWVdWSEhhajhOUzR1bTJlRlp4?= =?utf-8?B?eUhZbjgvRzg2Q1BuUmZCUmQyNjcvdWxnOUNCK0N4d3MxVHk2MGdFUTRJdGdC?= =?utf-8?B?c3U0Z1NCYUdwYzZXMFVjeWM2elUwOGY2OXRkZ3FFZEM5czFTbDNpL0xDZS93?= =?utf-8?B?cDN3MjAyWEZtdHU5S2tzTzVVUnVtTDZ3TUJJZXcvY2pKUkRYa3FteGU0V0lo?= =?utf-8?B?ZklNMkRZQk9GVlRUa3FoSDFtODJSSGNlMnp1VTdjdTNacUYrSi8zN244bUxp?= =?utf-8?B?Sm1BZ3laQWhhSnRWKzJzdDZOdkVOREJjY1pDcVNFdld3SXZlNzBnbVByaTdO?= =?utf-8?B?MTVJSlEvRWphVitZbzdZKzlGb1M3aUhGSE8xaytRcDkzaDRKVk11ZzBNNXFM?= =?utf-8?B?VnZSNlZMT0VLRGJnSTNwbTY4bVlxWDBUTkNBeWdwU0I2alhzMDRQd2Z6a3lK?= =?utf-8?B?VHNxSVVHcVMyUlFHc3pQZlhhanprQ1dMaDVGVnVKdnhNVUpQcVZ1SHJFakN4?= =?utf-8?B?dVVYMlJ0c3E2TXArbk5LaHA0YmV6ZVNKajEzM2dlZFh1UUFNU0R1VWttS0ZR?= =?utf-8?B?UUw1VUxxQlQ4WWVDQXF2MVoyK010TEUrdjUzWmc1TjNpbUxRd0kxMmYxWXVs?= =?utf-8?B?dGpRbkNKYUtQdi92Mkl2VUp2M2ltODRqRURvbGk4aGVYTVMzakthaFlXZGlm?= =?utf-8?B?U0dXcEN4cmJtdzZjRjdCQUtBUGZDU2k4VlpWY1piM21PSFUvcStaMXpvcEx4?= =?utf-8?B?NjlhcWkyeXRZdzNiUlcrYm0vZjRGWVdDQmxGN1hkVE15dzZiOUxUaGRjYSsx?= =?utf-8?B?bHRYenFsVmlWZUZUWTJ6WnIvbng1Sm9heDE0eTFHK2RaQktycFI0bVErSGVw?= =?utf-8?B?dE1wSXNyS2hNUUUwcm5lZ1BtQ3VYUlhXWWhMSkhudk9BRjhRZTlPeVZVRkVU?= =?utf-8?B?RGpUL1B0V2ZDTUZ6Qm9UTVJFbEJ3dG1EL3c3ZmQrRVRGcXlrdHh1bE4zdjJQ?= =?utf-8?B?UFpwbGwzem1EOE4yaHg3TWZYaFpMbzdqTVNKNFR3RUd4QmVrSDBiT2xzT3Nj?= =?utf-8?B?b0JqTmtuWnJTdjNLU255ak9tTkNjeGhkVkI3UkN6eE80QzRDbGl2SkdDeUNK?= =?utf-8?B?aWQ1NVFXR2J6NUlLaXUrVDczL2M1NDQ1RWVYMWFWOGRNV0h0Q0xjcWZqVmQ3?= =?utf-8?B?R1hpd0wxVlIrOVFtdS9xbUFWTjRhMHpBblliZXltWFZMcWhxTjVCNDhkWjc3?= =?utf-8?B?ZjRERnErYU9UVkhoYlZYZUVMU2Z0L2IxajRIVWdqWkJlbjMzM0U0UTM0c1FI?= =?utf-8?B?VTZoNGtXT3NpeGxrZFNQRjRXL0x2TVU4VHZaRDF4Mk5XZGs0bFBrRUM2b2RN?= =?utf-8?B?UXlRNVhweG1mZ0NaT25NV2FqSXM1VkhzMjkzblV6TFA4eHJPb0g5V0t5NWEv?= =?utf-8?B?bUFhWmZsQS8wcGNOOURPZVNrRXNiZm14ZjVPR0tVR1llOVRzZDkra3F3PT0=?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0644; 6:zzb1DwAOl8PQnNkagRUoCXaaGOp0m7cpvUZEyLKMwk4SRechfHYAkZH3Rp4leZ0AOJ6wYTZo5g6A8ChL75mA2ww8WFvZIdS6PMHUD50qS9jPT7yy5L3qmAuqneRxXv/46H7jzj+woXSixlwBxlEO6c53pyyCrnaahcNXRIZEA0fazsoiyNuerjjjno1CG4fyyTFmPALVrXUQqNM5RWsXSSQsfO3eTcUFvs+BHsiEekolbxugWkCG7KFO7HKczumdqcg4hhtlvroq0kOhswBB8toaepDASt4aNxQ0dpkp5Kp6MMMGwqQPx1+DvaAr0DYnAGx6KrGxrTjUDlX9rV2+p2CH2HcdWQT7hO5wbLQpcT8MyhhdWfbEigdjDKrjOo2qTTJ8hi+ra12rXqCZDpt41sC0zlG6zDklGRJ0CX2/SY3EL+YXJzClCL0DwbBmy+hHNRdNQN1BEx2V/oF5wQFNnQ==; 5:/cwjYSt1CLB4xCZ+Xb6SW70/IMAPjfA2BKO4NO6RiDNUebHmmm/W/LwVjKC+CBD0mazFozzt0kGwqWFk+fwukgpHN9Z7qs9s7L43aVU9iOhgC2/Kks4xtx8Ge7Gpsf1akEdym1Wd+UFhvR0HHBTGNA==; 24:i3kMXtk0YSiIGtrftbhtMdQmNzTEwkCM5AhmClryd5NBs+s/f81embzCezpItR/dHgOsP9z4I0P4Fum78tveLwOJTDhVH+OnIjlUPvXgGFs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0644; 7:UagRzc7oPxAof3KbDZ74Q6SJ8FRpQG/MKU2BvL+0o762opOK9cAqj1/PCO7EXSRmWBbJtb11tsoBT84wvqJEA0EB9Sf299fisunx4k6yet7du3loqlz9hEpl3g/GNheC6ygBhVUuaGHzs1f8dzKwoCK2vew32WCzsbbTxeOm+buUPpcbNXvDRoQXoiFZYxWTYTvjXlYm6dHqCgIAH5ywC2/0dF9goaF08OY1ruqE/3mNMujK0pESWltCz82dR9DFJZ41XmrIn0Q4/+VODK2OndiAmNcfI+ZtdnScxYlVKqhTCKQC+LnnrKV5jeKjVTfBZst9e8WkfK0Zzdq2nUr9Ww== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2017 05:22:25.6782 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0644 Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 05:22:34 -0000 On 2017/04/18 05:47, Carsten Bormann wrote: > On Apr 17, 2017, at 19:56, Nico Williams wrote: >> >>> Thinking about this more, putting an encoding detection algorithm as an >>> appendix seems like a reasonable compromise to me. To start, how about >>> removing the detection text from Section 8.1 and have an appendix that >>> starts with that text plus the table? >> >> Or we could even just assert that such an algorithm is possible, and >> that implementors MAY implement one. > > Indeed. > > Broken record mode: > > — writing up the algorithm sounds like encouraging implementation. > We *don’t* want people to implement this! > (The whole interminable non-UTF-8 saga probably just was a nod from the RFC 4627 authors to the remnants of UTF-16 land, which mostly have died off since. Why resurrect?) > > - there have been about 15 attempts to define this algorithm on the mailing list. > All were wrong. > An Internet Standard should contain tried and true material, not errata fodder. > > - an implementer is in a much better position to get this right than the standard, because they can write unit tests. I completely agree with Carsten. As far as I know, and as far as we have been told on this list, if some JSON isn't in UTF-8, then it simply will not interoperate. In my view, the only reason to still have a MAY for UTF-16/32 is that this will avoid questions like: "I have a JSON parser in language FOO, it can take a string or an input stream as an argument. In FOO, strings are UTF-16, but the JSON RFC doesn't seem to allow this. What should I do." This may look far-fetched to some of you (and I agree it is), but I remember having dealt with such questions when I was at W3C. Regards, Martin. From nobody Mon Apr 17 23:29:33 2017 Return-Path: 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 C2FB7129426 for ; Mon, 17 Apr 2017 23:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sXaKwCOqoXIa for ; Mon, 17 Apr 2017 23:29:30 -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 00470128796 for ; Mon, 17 Apr 2017 23:29:29 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id 194so36889284pfv.3 for ; Mon, 17 Apr 2017 23:29:29 -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=i+TNpn2bR+U1yQANMlkZS1LV6UB5LU76g1AYy0bcMD0=; b=nIkMsxBZAThqH4zLwzeAcqz5QfolJzvZMygES+BliAxdLH63EBJ+jyAd8D514lcW35 wrHmoSyuBxlFUhaX58RtLsBjQtocL6V1TX/Rb9v0GU5rU201XfgYgIJUe5bRYxSiq91k CmPoI/sswjt0FwIdDU+pspnbs7TKB5+WGsGwvtThgzdPnALX2Mf3i5peYRU8RnUvHR/a Td5a2ujSX8n5zEA9gnWzNAwfbVTWy0EkzmDPMlrUsQapCu2Yqrv6JSR5kqScIuBv32ro Ts6j3eXlV9Npnki+uNbPgSnjnBoKjwVWowm+ZlcoHdk5LonUjDnR3tk+yfItdfICBWPV CyPA== 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=i+TNpn2bR+U1yQANMlkZS1LV6UB5LU76g1AYy0bcMD0=; b=RKslXS1N7/HUoJ0a7ReLTwjeYFLYn1e3ys1PTmJg1NjS5AkaOV6cbvYFdxtSdRlECS VdtZI0asfb0l70oWGakwwu59+iccYoF6+h9ZClJ7f2DVwqWVa9aoEprQj5g4YJx8xLxj ot9LiJfWl85iwpm+9RV7Z5UoNKQuZ1sZ3iSa6/YfxhU17nnqBIUBX9ae8dFaGC/x0tR0 lu+JHjTSIIOTYs7iyCWXz8HPN7VOYpp6pPWz6mRB6BPPj+GAVSg6vUNGmyHeVWznmPID OGb8AOEkH3VwrbQxTFrt5tpqI9YHmfpuJbqFXZNL6/g/nCAG9sFTfwAtKTm61kySahuZ GJrw== X-Gm-Message-State: AN3rC/7ELcss4kur1EccLQc/UI6KWrF5us43B17lPKL0rliP+nrMJMYn FkiIndVOFqAwu9hmAJEOWx9U0FkGsQ== X-Received: by 10.98.131.197 with SMTP id h188mr15612517pfe.99.1492496969457; Mon, 17 Apr 2017 23:29:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.99 with HTTP; Mon, 17 Apr 2017 23:29:08 -0700 (PDT) X-Originating-IP: [24.86.134.32] In-Reply-To: <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> From: Tim Bray Date: Mon, 17 Apr 2017 23:29:08 -0700 Message-ID: To: Carsten Bormann Cc: "Matthew A. Miller" , "json@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c11b6feb17f7a054d6b07d4 Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 06:29:32 -0000 --94eb2c11b6feb17f7a054d6b07d4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My position is the same as Carsten=E2=80=99s. On Mon, Apr 17, 2017 at 1:47 PM, Carsten Bormann wrote: > On Apr 17, 2017, at 19:56, Nico Williams wrote: > > > >> Thinking about this more, putting an encoding detection algorithm as a= n > >> appendix seems like a reasonable compromise to me. To start, how abou= t > >> removing the detection text from Section 8.1 and have an appendix that > >> starts with that text plus the table? > > > > Or we could even just assert that such an algorithm is possible, and > > that implementors MAY implement one. > > Indeed. > > Broken record mode: > > =E2=80=94 writing up the algorithm sounds like encouraging implementation= . > We *don=E2=80=99t* want people to implement this! > (The whole interminable non-UTF-8 saga probably just was a nod from the > RFC 4627 authors to the remnants of UTF-16 land, which mostly have died o= ff > since. Why resurrect?) > > - there have been about 15 attempts to define this algorithm on the > mailing list. > All were wrong. > An Internet Standard should contain tried and true material, not errata > fodder. > > - an implementer is in a much better position to get this right than the > standard, because they can write unit tests. > > > > >> Assuming the above, what does everyone think of the following for > >> Section 8.1? > > > > +1. > > +1 > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --94eb2c11b6feb17f7a054d6b07d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My = position is the same as Carsten=E2=80=99s.

On Mon, Apr 17, 2017 at 1:47 PM, Carst= en Bormann <cabo@tzi.org> wrote:
On Apr 17, 2017, at 19:56, Nico Williams <nico@cryptonector.com> wrote:
>
>> Thinking about this more, putting an encoding detection algorithm = as an
>> appendix seems like a reasonable compromise to me.=C2=A0 To start,= how about
>> removing the detection text from Section 8.1 and have an appendix = that
>> starts with that text plus the table?
>
> Or we could even just assert that such an algorithm is possible, and > that implementors MAY implement one.

Indeed.

Broken record mode:

=E2=80=94 writing up the algorithm sounds like encouraging implementation.<= br> =C2=A0 We *don=E2=80=99t* want people to implement this!
=C2=A0 (The whole interminable non-UTF-8 saga probably just was a nod from = the RFC 4627 authors to the remnants of UTF-16 land, which mostly have died= off since.=C2=A0 Why resurrect?)

- there have been about 15 attempts to define this algorithm on the mailing= list.
=C2=A0 All were wrong.
=C2=A0 An Internet Standard should contain tried and true material, not err= ata fodder.

- an implementer is in a much better position to get this right than the st= andard, because they can write unit tests.

>
>> Assuming the above, what does everyone think of the following for<= br> >> Section 8.1?
>
> +1.

+1

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json



--
=
- Tim Bray (If you=E2=80=99d like to send me a private messag= e, see https://key= base.io/timbray)
--94eb2c11b6feb17f7a054d6b07d4-- From nobody Tue Apr 18 04:55:53 2017 Return-Path: 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 9EA1212EB37 for ; Tue, 18 Apr 2017 04:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-org.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 F9ITXoTKQmnY for ; Tue, 18 Apr 2017 04:55:51 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 00E22129B84 for ; Tue, 18 Apr 2017 04:55:50 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id w64so54325367wma.0 for ; Tue, 18 Apr 2017 04:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GUhKuFj96PRneH1tohRSwss7tCNo+nB5k5bdBR8yGmc=; b=eu/IHeRcIpjno5I77+mTkIdKcRXvnjghuQEGLRuEE9pKta2mi3A7gKHOOTsWJKWD9M Ub9sOoUDpWRmV+Kf1e+DuTNQt0B6WNUBgZo3rmbROepq2tBr3gtl0trq1X5jdeaCNtY7 HTtN9qbtpiTB/Yn8gJntA26iBs9cdNsn9RL832mln2/RlrvbLHlCuxCwKHmYb82k/2gx xA+yT9DxmmYMkM3cTgrjPeUScl9TY8OBDNDY9iFeyXYXL1TlUPOvxbrzmHl1d81v5+6q LtW6Cm5817TGa1MwAMBp51z2gbo0ZR8mnDTE2a8G3nWy+VwiPywlnzBbXMeY4h22ZkMp dk2g== 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=GUhKuFj96PRneH1tohRSwss7tCNo+nB5k5bdBR8yGmc=; b=W1ipy0HptpcEcea39YOec7zJu8WgYOWs35SPOn1hM+hWXELoqSJV1Ol4FpGS8jY8Af 0blGFSQfQivgb0hi3xR1F9XSS+of8MnHs+D2XLWC2QnXyvwmUxEmCBinAC63qbzzPDQh zy4M7ePxXbRjAdpqziHPnzz6e+x3R8Kj/lzb86bmozZMWTHBkcwg7uasABgAX+NqCt1a q1LfDOBfNGO51gcZzeNge0IwUmPWe5CpFjVk4xBBniIt7idN13hDKjZDr+ophnQRaEGy bPvAGsqt8GCBAgfT1jkR8Qq+AeKzfeV1XkhSmkr+fT4ni9TEkz1RssRx2Xjw4K9ErlSQ Pncw== X-Gm-Message-State: AN3rC/4jv/mug3Q1t616PEQ0J+fczP5VGR6TC7QVovpflcDFVSRvReVv ZGKuFW3kalusUsE9Hyi/fp53Qb27jOoMJ8M= X-Received: by 10.28.236.135 with SMTP id h7mr13042778wmi.74.1492516549145; Tue, 18 Apr 2017 04:55:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.126.4 with HTTP; Tue, 18 Apr 2017 04:55:28 -0700 (PDT) In-Reply-To: References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> From: John Cowan Date: Tue, 18 Apr 2017 07:55:28 -0400 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Cc: Carsten Bormann , "Matthew A. Miller" , "json@ietf.org" Content-Type: multipart/alternative; boundary=001a1147128abbd05d054d6f96c1 Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 11:55:53 -0000 --001a1147128abbd05d054d6f96c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 18, 2017 at 1:22 AM, Martin J. D=C3=BCrst wrote: In my view, the only reason to still have a MAY for UTF-16/32 is that this > will avoid questions like: "I have a JSON parser in language FOO, it can > take a string or an input stream as an argument. In FOO, strings are > UTF-16, but the JSON RFC doesn't seem to allow this. What should I do." The answer to that is something like this: "In the IETF, we do interchange standards. What you do with JSON internally to your system is your own business." --=20 John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org Said Agatha Christie / To E. Philips Oppenheim "Who is this Hemingway? / Who is this Proust? Who is this Vladimir / Whatchamacallum, This neopostrealist / Rabble?" she groused. --George Starbuck, Pith and Vinegar --001a1147128abbd05d054d6f96c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Apr 18, 2017 at 1:22 AM, Martin J. D=C3=BCrst <= ;duerst@it.aoya= ma.ac.jp> wrote:

In my view, the only reason to st= ill have a MAY for UTF-16/32 is that this will avoid questions like: "= I have a JSON parser in language FOO, it can take a string or an input stre= am as an argument. In FOO, strings are UTF-16, but the JSON RFC doesn't= seem to allow this. What should I do."

The answer to that is something like this: =C2=A0"In the IETF, we do= interchange standards.=C2=A0 What you do with JSON internally to your syst= em is your own business."

--=C2=A0
= John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://vrici.lojban.org/~cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0= cowan@ccil.org
Said Agatha = Christie / To E. Philips Oppenheim
"Who is this Hemingway? /= Who is this Proust?
Who is this Vladimir / Whatchamacallum,
This neopostrealist / Rabble?" she groused.
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 --George Starbuck, Pith and Vinegar=C2=A0

<= /div>


--001a1147128abbd05d054d6f96c1-- From nobody Tue Apr 18 06:01:34 2017 Return-Path: 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 B9CAE12EBBE for ; Tue, 18 Apr 2017 06:01:31 -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 I065_AAfelXv for ; Tue, 18 Apr 2017 06:01:29 -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 4086112EBBB for ; Tue, 18 Apr 2017 06:01:29 -0700 (PDT) Received: (qmail 15939 invoked from network); 18 Apr 2017 13:53:55 +0100 Received: from host86-182-43-169.range86-182.btcentralplus.com (HELO ?192.168.1.72?) (86.182.43.169) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 18 Apr 2017 13:53:55 +0100 To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Carsten Bormann , "Matthew A. Miller" References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> Cc: "json@ietf.org" From: Pete Cordell Message-ID: <6eb23f90-6623-7888-bc1c-6640a9dababc@codalogic.com> Date: Tue, 18 Apr 2017 14:01:28 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:01:32 -0000 On 18/04/2017 06:22, Martin J. Dürst wrote: > On 2017/04/18 05:47, Carsten Bormann wrote: >> On Apr 17, 2017, at 19:56, Nico Williams wrote: >>> >>>> Thinking about this more, putting an encoding detection algorithm as an >>>> appendix seems like a reasonable compromise to me. To start, how about >>>> removing the detection text from Section 8.1 and have an appendix that >>>> starts with that text plus the table? >>> >>> Or we could even just assert that such an algorithm is possible, and >>> that implementors MAY implement one. >> >> Indeed. >> >> Broken record mode: >> >> — writing up the algorithm sounds like encouraging implementation. >> We *don’t* want people to implement this! >> (The whole interminable non-UTF-8 saga probably just was a nod from >> the RFC 4627 authors to the remnants of UTF-16 land, which mostly have >> died off since. Why resurrect?) >> >> - there have been about 15 attempts to define this algorithm on the >> mailing list. >> All were wrong. >> An Internet Standard should contain tried and true material, not >> errata fodder. >> >> - an implementer is in a much better position to get this right than >> the standard, because they can write unit tests. > > I completely agree with Carsten. As far as I know, and as far as we have > been told on this list, if some JSON isn't in UTF-8, then it simply will > not interoperate. +1 If we do do this, I think we could add some example test messages to helps with the development, e.g.: {"Example":1} {} "Example" "" "U+0100" (where U+0100 is the UTF form of the character, not ASCII) 1 > In my view, the only reason to still have a MAY for UTF-16/32 is that > this will avoid questions like: "I have a JSON parser in language FOO, > it can take a string or an input stream as an argument. In FOO, strings > are UTF-16, but the JSON RFC doesn't seem to allow this. What should I do." IMO the answer to that is, "that's why it says 'JSON text _SHOULD_ be encoded in UTF-8'". I agree with John Cowen, that use of UTF-16/32 is purely for internal scenarios; not on the Internet. As such, I believe the IETF is going beyond its remit to say you can use UTF-16/32 for your internal purposes that I know nothing about and care nothing about, but you're not allowed to use other encodings that maybe more natural for your system. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From nobody Tue Apr 18 11:25:04 2017 Return-Path: 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 D62771293E4 for ; Tue, 18 Apr 2017 11:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.38 X-Spam-Level: X-Spam-Status: No, score=-4.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham 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 NO9q7IuIVCNt for ; Tue, 18 Apr 2017 11:25:01 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF4212FEAA for ; Tue, 18 Apr 2017 11:24:58 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v3IIHOPR015878 for ; Tue, 18 Apr 2017 14:24:55 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 29wqn98v03-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 18 Apr 2017 14:24:55 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3IIOsiP002078 for ; Tue, 18 Apr 2017 14:24:54 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v3IIOmEB001966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 18 Apr 2017 14:24:52 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Tue, 18 Apr 2017 18:24:39 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.214]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 14:24:38 -0400 From: "HANSEN, TONY L" CC: "json@ietf.org" Thread-Topic: [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding" Thread-Index: AQHSuHEJncR3U2Zdz0+qv2Tts8xqGg== Date: Tue, 18 Apr 2017 18:24:38 +0000 Message-ID: References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> In-Reply-To: <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.110.241.22] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-18_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704180143 Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:25:03 -0000 T24gNC8xNy8xNywgNDo0NyBQTSwgImpzb24gb24gYmVoYWxmIG9mIENhcnN0ZW4gQm9ybWFubiIg PGpzb24tYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2Fib0B0emkub3JnPiB3cm90ZToN CiANCiAgICBCcm9rZW4gcmVjb3JkIG1vZGU6DQogICAgDQogICAg4oCUIHdyaXRpbmcgdXAgdGhl IGFsZ29yaXRobSBzb3VuZHMgbGlrZSBlbmNvdXJhZ2luZyBpbXBsZW1lbnRhdGlvbi4NCiAgICAg IFdlICpkb27igJl0KiB3YW50IHBlb3BsZSB0byBpbXBsZW1lbnQgdGhpcyENCiAgICAgIChUaGUg d2hvbGUgaW50ZXJtaW5hYmxlIG5vbi1VVEYtOCBzYWdhIHByb2JhYmx5IGp1c3Qgd2FzIGEgbm9k IGZyb20gdGhlIFJGQyA0NjI3IGF1dGhvcnMgdG8gdGhlIHJlbW5hbnRzIG9mIFVURi0xNiBsYW5k LCB3aGljaCBtb3N0bHkgaGF2ZSBkaWVkIG9mZiBzaW5jZS4gIFdoeSByZXN1cnJlY3Q/KQ0KICAg IA0KICAgIC0gdGhlcmUgaGF2ZSBiZWVuIGFib3V0IDE1IGF0dGVtcHRzIHRvIGRlZmluZSB0aGlz IGFsZ29yaXRobSBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KICAgICAgQWxsIHdlcmUgd3JvbmcuDQog ICAgICBBbiBJbnRlcm5ldCBTdGFuZGFyZCBzaG91bGQgY29udGFpbiB0cmllZCBhbmQgdHJ1ZSBt YXRlcmlhbCwgbm90IGVycmF0YSBmb2RkZXIuDQogICAgDQogICAgLSBhbiBpbXBsZW1lbnRlciBp cyBpbiBhIG11Y2ggYmV0dGVyIHBvc2l0aW9uIHRvIGdldCB0aGlzIHJpZ2h0IHRoYW4gdGhlIHN0 YW5kYXJkLCBiZWNhdXNlIHRoZXkgY2FuIHdyaXRlIHVuaXQgdGVzdHMuDQoNCg0KSXTigJlzIGV4 YWN0bHkgPmJlY2F1c2U8IGl04oCZcyBoYXJkIHRoYXQgaXQgc2hvdWxkIGJlIGRvbmUgb25jZS4g SGVyZSBpcyBteSBzdWdnZXN0aW9uIGZvciB0aGUgd29yZGluZyBvZiB0aGUgYXBwZW5kaXguDQoN CkFwcGVuZGl4IE4NCg0KQXMgc3RhdGVkIGFib3ZlLCBpbXBsZW1lbnRhdGlvbnMgZ2VuZXJhdGlu ZyBpbnRlcm9wZXJhYmxlIEpTT04gTVVTVCBOT1Qgc2VuZCBVVEYtMTYsIGFuZCBpbXBsZW1lbnRh dGlvbnMgcmVjZWl2aW5nIGludGVyb3BlcmFibGUgSlNPTiBpcyBOT1QgUkVRVUlSRUQgdG8gYWNj ZXB0IFVURi0xNi4gSWYgYW4gaW1wbGVtZW50YXRpb24gbmVlZHMgdG8gcmVjb2duaXplIFVURi0x NiBKU09OIHRvIGRlYWwgd2l0aCBsZWdhY3kgZmlsZXMsIHRoZSBmb2xsb3dpbmcgYWxnb3JpdGht IHdpbGwgZGlmZmVyZW50aWF0ZS4gKHByb3ZpZGUgYWxnb3JpdGhtIGhlcmUpDQoNCg0KCVRvbnkg SGFuc2VuDQoNCg== From nobody Tue Apr 18 11:34:43 2017 Return-Path: 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 2B9BD1293DA for ; Tue, 18 Apr 2017 11:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 AR7EDL4bYGB4 for ; Tue, 18 Apr 2017 11:34:40 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15DF0126C23 for ; Tue, 18 Apr 2017 11:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3IIYY3N029704; Tue, 18 Apr 2017 20:34:34 +0200 (CEST) Received: from [192.168.217.113] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3w6v1Q0YCdzDJ7X; Tue, 18 Apr 2017 20:34:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 18 Apr 2017 20:34:33 +0200 Cc: "json@ietf.org" X-Mao-Original-Outgoing-Id: 514233273.427647-8f3fe8b3f41c10dc3b0e17b6e07b216f Content-Transfer-Encoding: quoted-printable Message-Id: <25918E62-CF34-4A31-95F5-97ED42D2EA4F@tzi.org> References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> To: "HANSEN, TONY L" X-Mailer: Apple Mail (2.3273) Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 18:34:42 -0000 On Apr 18, 2017, at 20:24, HANSEN, TONY L wrote: >=20 > It=E2=80=99s exactly >because< it=E2=80=99s hard that it should be = done once. I was trying to say it should not be done at all. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 19 00:36:24 2017 Return-Path: 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 A52D813153B for ; Wed, 19 Apr 2017 00:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 Cqwtvt94Ogxs for ; Wed, 19 Apr 2017 00:36:20 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0098.outbound.protection.outlook.com [104.47.92.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6841314B4 for ; Wed, 19 Apr 2017 00:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1TxYnHJ8clfxdFEXhkEiy8wClVosWLDhm9U+37EEOaQ=; b=Bxq8Ul92+ztL/3vAOJErqI4xUE2NIGgXaqhqsfEZ91oto9uVSdK3KAwNlrpwuYyZiyRDS6ElbYK2aJL4dUyRQV3huxs3uIfm/5YQgzNLlmM8HkfLJ1+A0XwW9CUo21vfh5zd/JpoJTk4ceC0jRAFf7hpcfKY2UpiAz6Cwop4PoE= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [100.70.12.254] (133.2.59.38) by TY1PR01MB0651.jpnprd01.prod.outlook.com (10.167.158.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Wed, 19 Apr 2017 07:36:17 +0000 To: Pete Cordell , Carsten Bormann , "Matthew A. Miller" References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> <6eb23f90-6623-7888-bc1c-6640a9dababc@codalogic.com> CC: "json@ietf.org" From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Wed, 19 Apr 2017 16:36:16 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6eb23f90-6623-7888-bc1c-6640a9dababc@codalogic.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.59.38] X-ClientProxiedBy: KAWPR01CA0053.jpnprd01.prod.outlook.com (10.174.229.141) To TY1PR01MB0651.jpnprd01.prod.outlook.com (10.167.158.14) X-MS-Office365-Filtering-Correlation-Id: 5aead4a8-d75e-4c0c-f615-08d486f6c415 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:TY1PR01MB0651; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 3:bs45MoWdrntDtf1zWk0mTXMxlOOiAHS3qH+zm3QKFHGxrirn8zoQ0PP1obAspWDw8AaWfHTiTaXOwGHX2s8sdKzJ5jyO/uNBBw1Sq170oargFSxVMiIYw9xwNxsLMpzGo+KKuUudfPCWAsj4SQ+U3v9pDIkoXIlLZZuYTklYfAn0WGvgMrPqHPV3VUx6ELo2sBbxNF0p+TgDgxe4g4XC3ceO4ZklJLwZLpaB5/N0uYcFS2SBfGayNFJ+sKsXS5e54xasf6RHtqnIbDIvPksw+YKOiV2CktcKUOuanpxhA8uYtKs53iuRZDXoPG2F03tBlkK7TgNCyI8Xj7NEky8o2A==; 25:FAZckheuyWIBqVTu461NBtfJOWugYzgjy6Pw67T4hq8fL55DLfUYy5gNzpey3jsPMdqtk2oDIJTZ4d1kHHDaOo/caFaoQZUfpFktvHOhOvAVuoKLzZEHl4zDODVIj4mmN5l05ePkk4dj/61vRuq/7XQHCX0ms9SHJR02jJ+sJItuJAj3IuI6KKV1fb9or/h3uutJD4yloIECKLl5UN4pUAqIIrtWNzD3pEsTqGNe9jMV/WXkdA0mGFbhjmR5pAndgZzFOFLsE6XzDEMxqZ5/2Ak34t+wlAnXl4Irncfmi7OZfDV3sI8Mg5zssR+cQn5AdKGly8p/hjzxdMHLBp2YrzEZRujkCVAbnHXzXZSByV/M1ULQdVIn2tfBqBN03vCVGhEhMxSkCrCLELC6kZi1sycundIrRhwPl3vSBska91ZbgLLwGr525HeB4ibmVNy70MDNYdO4zu1rosn399N3hQ== X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 31:BNgwtTs1aPWZX06NzE3jtyXL6E1GnXw6sRNNn0V/VwXXTeZf0FgzlAjwAkrmkmMtuMjnp3PPJb0dwHmUyUfLNq0UyMZ5Jany3nuxgpTso5m5dTCotciXCbF14mfSyTvbBezvZ5AFe0/fPI+U14PjW/81y3DfSQ28UnsAfCGpcQ56VI/81RhYhaduqjlW8iMSupTymwpD1ttpWXPSm6R33qWt+5pANQgKBwcbKGKK/401UUN/NHj374iOAOgxJKkf X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281529075)(201703061421075)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:TY1PR01MB0651; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0651; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 4:/hkk+sSfRWtcy5G1370+keJQgdGm0sY7Ycp9fcmpzotxunCVW2svAFe9MqX1CDMSZbOs1Je4FBHq5+/zxQ9A5BuJzo7IwqaojTT4hc5GNqYpXG25noTUKhn9rFae4xQIxMbutoIoSw6wOwi/1zkztYzNwVxrtIQE8QLJGqNlWutbZWNKRoN2mPRni1cS0X8XWDqpjS/KuZFnp3sPnWgl0hTbrTIZB0HP9ej3lrFHmgoG27Dg1pEnimyfpZ2+BuLMhbuaT2aURb6/a9AG7aBMzIIo2ditGv3I2sg1HPMh9kL3njlDCE8iQT8Onmj02e1bU6nrmdRGpVpJCErWJl3aeu/Y7fN+KOQD7X+P8VXi6sx5de2qEm5V+taPNxgjWZSz95jRltGJ+idOb/Q+hPKjlFxSzxohMRwFWXJ9vSjFROhyVEuggErVAwQB32uKiy/zMbptzUjaZJ0VZqrXUo99paT5/+8qABvhwhmQB/HBl/KTq6gX5yONRCIpVx43SHLvCRjhfS7YRZ3UGuxN7ayizufRbiDpn/1adxzw1ansxSlSfhWD7DgbfkgWxT6OaMxteTaP1+CP10w0DqwlmpjEg/UQ54uSB39r1Gmoewy+yET+/8qItXeGkwJzYaMPs2gwvfkSLPaMbOKLUuADSaShLmwnCbHaDvuNn2Fd8sgH6orjXFaP4pROA8g6QfygNJ/UdBsaS4e6DZY4imsUreLrKNBv9vEA+VgPpEqfFtmgItdFtGzGuisdsLwhxu5EcoXq X-Forefront-PRVS: 028256169F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39400400002)(39450400003)(24454002)(93886004)(50986999)(229853002)(76176999)(54356999)(23676002)(65806001)(53936002)(42882006)(47776003)(38730400002)(64126003)(3846002)(86362001)(31696002)(83506001)(2950100002)(66066001)(25786009)(6486002)(53546009)(4326008)(6116002)(50466002)(65956001)(7736002)(5660300001)(8676002)(31686004)(81166006)(33646002)(42186005)(305945005)(189998001)(2906002)(4001350100001)(90366009)(65826007)(74482002)(2870700001)(78286005); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0651; H:[100.70.12.254]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwNjUxOzIzOmFoWUFjTnJock1oR29YU01CdUYwWS93RkZD?= =?utf-8?B?b2NmU1hWdzc1OFdtY2gxTVNLRFVPcDZmbUpCM1VyMmFiZGJEMkdvZUswQzl5?= =?utf-8?B?RzdwOGRURmNVL1B3MHBPMmk0UVljOHVCS1lhL1JucmJTQTViWE14Ni9BL3lk?= =?utf-8?B?dnFOUlFCeFNTSzdWdXlXTXR3dm5zWW04dnZtRmxIaGFSbjNucnpmUFQ1bW56?= =?utf-8?B?VFpWcWlpL3I0ZHFqME1nTzg4d0dINGVBMUtwcVJkUmltcTNSMzBlY0RXUlVm?= =?utf-8?B?STlkckx0dU5FWmtRQkpvRFVPR1kxeWY2YUc3N2NJcGExTlVKbEcxb1FaQ0sy?= =?utf-8?B?dC9zWHo5VHlGeUFIOENBKzBBV0wrSWJhNmlzUjUxRjNWVWFaL0FJNCtiMEg4?= =?utf-8?B?YndKN2Z2Y01mcFhNWlRlYUl4VWVTS2h2M3Z4SHkrTk5xaUVKR3hraE9RYmpv?= =?utf-8?B?WUhBTEVBQkRyUm9LM1RiMFh4YkIwSjJlYTBhcWsrQ0ZuVXc5ekhzL2ZIckMy?= =?utf-8?B?dXkySDdSYlRodk1LWm8zWDYyTHNyWlBreWdPWDRESVhHTGdJYmwycDlEaW9C?= =?utf-8?B?UW5BdXJncTVwWFd5Um1JTEx0bC8wWDBhZi9FMXZKeHl6SlI0YVE4TVVKOEFL?= =?utf-8?B?MnA4ZXZzUjdLUlRZbjI2ZUpzNEdoMTZXNHkxV2ZCTnowT1JnMFh3RlVITWZu?= =?utf-8?B?RmpZdnd0eHF1QlprekVDNHZMSDVUVW5EUHJIRXEwenVkWW45NkZ1SkxsMEZl?= =?utf-8?B?TytCTGp6MXB4UHowdGNZbWRPZzArc3crR2JYa0tQcDQvSHJ1MEhWRlFZK2RI?= =?utf-8?B?VnVmQitjemhNakNnSStrdVgvU01pQ1ZGb1BiajMyTElkQmRQbk1Qb3dZWUw0?= =?utf-8?B?eG9XZi9HV2dHTjZ0czIvUWJwVUl6QjIvWnhCT0Q4bmp1NFMrcGN2UFluNTY3?= =?utf-8?B?c2RhSDRqSDNZQjUzcTdqS000U2NmZEdTa0tOQkZXWFBjSXBJRGtyZFVuNnBB?= =?utf-8?B?Q1BEc2hKM3JUUFUrUlZoUUFPNE5uTlM3eldzUW5TNkRya3FFWkJvdHVpbWdG?= =?utf-8?B?d0dJTTNKTlJ3UHRSTUs1amc1N2lMcStTZ3Q0em5RV2Y4TXFXc2hVekkyYjdh?= =?utf-8?B?eGt5WUtudE5raDBhSS8xbDJPNzBBSlZsQ0tOeXlFOUFCU0ZQZGx2ZzEwanBk?= =?utf-8?B?WEdlVys0MDR1M2VEQXJjc2FuRmlHUy9UYUR3UVVyWCt3dC9vSVYrbmsySGRV?= =?utf-8?B?Z1BOellMald1RFF4Ui9LVWVMZG0rNkRmWUVRb2pLdTN4V3lIMUE0eWhQOVJT?= =?utf-8?B?MkcxRU9KNGtnci80bkhJeTRvQ3MxREhCV0E0QlRqUFJBWlRNZzZ4VHhZQjkv?= =?utf-8?B?bHFDOHg4OFpCYVl4ZittanVhalVEK0c3ZG4wdGYyYTJGZXB5WWVwUFllVUt2?= =?utf-8?B?UTRHcVdKdTB2UGtrN2lmd296ZEtvYXZ5OTZxdEtRYWEvYnJGZU5hN0ZZdHM1?= =?utf-8?B?Z0RtT0dVd2JSWXRJZ3ViVUh5T0lkUHJLL3BHWE9lVFo2eG1CdmdsbmFiWW5u?= =?utf-8?B?RXpQc21kWEZ0Ty94K2wrSVNmZ2plZFE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 6:4nPeiweCMZI45Agnk+X23prdCZnsyaLb3JSd28t4nAWlHEKF/H97O+VCR3UAs0/4xwBtZ2gRS9p1gMK4eYlc0Ouw7d+98Yj4TzmHXU6RKd64YYwLQMUlVqOy7NNLd2TLWJ2AS0dCLTXjTt/BDKmW3+9ecBuZLT4evyH37rV+vaghbIY5Np+TS8SRy3Y7AYV3WacexR9vbKfQZB522Qf+Dyrr6W6I0jsNB2PD1Ci8gf+bAFlwAh6kYVMuK5dGM0o6I7DPb/UaZvMD44YFeYNP/wYSflpEIbkY2eYDI6Etb6yQFCDA1ybu0wSFvRIkMnv1xDrWd3wtkGFUwRpMD3Su8By9D6psljTNkv8Zi5fPQMNkV0i+tr3W1gaXpTKWMETTGucxhSCJWO4IrtnXE0w81nq0tG4lKi5UgBsYqPdnOBeUiygc6X0HJU0RRN1BXgs4fvbiqLYDtqHKyXUSIx2+qg==; 5:EDXoQkYGewdbHStvYnAtYNCSXB111xZrYmvbN2y8IUckwu/13fvRbdhIC57pfd0aW2TgvEHI/KQ7vDaDLefqTh1lsNeltShwdVFDzo6eSkpLN7UjpBMsvkgm55545aKF8UvN+D+K6gR0pxd4C8HKfA==; 24:r4JPEUPkhUiHnpzKhLsrU54tH2Jz09b1CbVFKS33wmYR28fYvY5cnjSx6jQQFlC870b6zypMcyrwKVIDqp1bgFpc9tXKUGK0u1Zkn84lnqw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 7:fL9OT6aKVVrqvM9GjJOr6yqrOBSv9Fk0KG2o3QD8derkHS99SskafDQgUyGOO+xXrvkAX/1R1o2KHp2nlewzkaN0V7WNZ2kLhTeOE+c3awrxSFmQU7GBydfIRcdycgFf6q7ExJusnwxIMtJeBQ6f2Vlw9RX2+ptXqnblP/phsYHCrIll2t2bc7TNeKfAddExaw3ba4leLnpLSUA5v73K+mOk4uRx/mRJWx+1HlZoFkvKJzkymPhO0RHxDBrdrXw7dNkqGK8TMT+8LPvCT56v1Zo1VT21dGN8/8waoeWAdyAiy0KtCl4MGcpKIHFusx11O1o+k/pIxcV4BoNv9CUiZA== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2017 07:36:17.0518 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0651 Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 07:36:23 -0000 On 2017/04/18 22:01, Pete Cordell wrote: > If we do do this, I think we could add some example test messages to > helps with the development, e.g.: > > {"Example":1} > {} > "Example" > "" > "U+0100" (where U+0100 is the UTF form of the character, not ASCII) > 1 I don't mind adding examples, although it's getting a bit late for this. However, if we want something like "U+0100" (where U+0100 is the UTF form of the character, not ASCII) I suggest to use the facility that the RFC Editor and others have worked long and hard now, and use the actual character: "Ā" (string with the single character LATIN CAPITAL LETTER A WITH MACRON (U+0100)) Maybe a longer string would be better. Regards, Martin. From nobody Wed Apr 19 02:50:20 2017 Return-Path: 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 A458112947F for ; Wed, 19 Apr 2017 02:50:19 -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 hVD_BkhApPRn for ; Wed, 19 Apr 2017 02:50: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 7ADAD1267BB for ; Wed, 19 Apr 2017 02:50:17 -0700 (PDT) Received: (qmail 11150 invoked from network); 19 Apr 2017 10:42:43 +0100 Received: from host109-147-221-151.range109-147.btcentralplus.com (HELO ?192.168.1.72?) (109.147.221.151) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 19 Apr 2017 10:42:43 +0100 To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> <6eb23f90-6623-7888-bc1c-6640a9dababc@codalogic.com> Cc: "json@ietf.org" From: Pete Cordell Message-ID: Date: Wed, 19 Apr 2017 10:50:16 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 09:50:20 -0000 On 19/04/2017 08:36, Martin J. Dürst wrote: > However, if we want something like > > "U+0100" (where U+0100 is the UTF form of the character, not ASCII) > > I suggest to use the facility that the RFC Editor and others have worked > long and hard now, and use the actual character: > > "Ā" (string with the single character LATIN CAPITAL LETTER A WITH MACRON > (U+0100)) I'd missed the memo on non-ASCII characters in RFCs. This sounds great to me. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From nobody Thu Apr 27 02:15:25 2017 Return-Path: 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 1CE13128896 for ; Thu, 27 Apr 2017 02:15:24 -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 aT_QuimvLCN3 for ; Thu, 27 Apr 2017 02:15:22 -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 8EE721274D2 for ; Thu, 27 Apr 2017 02:15:21 -0700 (PDT) Received: (qmail 24071 invoked from network); 27 Apr 2017 10:07:37 +0100 Received: from host109-156-176-225.range109-156.btcentralplus.com (HELO ?192.168.1.72?) (109.156.176.225) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 10:07:37 +0100 To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Carsten Bormann , "Matthew A. Miller" References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> <6eb23f90-6623-7888-bc1c-6640a9dababc@codalogic.com> Cc: "json@ietf.org" From: Pete Cordell Message-ID: <61bfad2b-850d-a11f-e80b-d5ed9ccb4dc9@codalogic.com> Date: Thu, 27 Apr 2017 10:15:11 +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: <6eb23f90-6623-7888-bc1c-6640a9dababc@codalogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 09:15:24 -0000 I seem to have killed this thread off again. Sorry about that. Any conclusions? Cheers, Pete. On 18/04/2017 14:01, Pete Cordell wrote: > On 18/04/2017 06:22, Martin J. Dürst wrote: >> On 2017/04/18 05:47, Carsten Bormann wrote: >>> On Apr 17, 2017, at 19:56, Nico Williams wrote: >>>> >>>>> Thinking about this more, putting an encoding detection algorithm >>>>> as an >>>>> appendix seems like a reasonable compromise to me. To start, how >>>>> about >>>>> removing the detection text from Section 8.1 and have an appendix that >>>>> starts with that text plus the table? >>>> >>>> Or we could even just assert that such an algorithm is possible, and >>>> that implementors MAY implement one. >>> >>> Indeed. >>> >>> Broken record mode: >>> >>> — writing up the algorithm sounds like encouraging implementation. >>> We *don’t* want people to implement this! >>> (The whole interminable non-UTF-8 saga probably just was a nod from >>> the RFC 4627 authors to the remnants of UTF-16 land, which mostly have >>> died off since. Why resurrect?) >>> >>> - there have been about 15 attempts to define this algorithm on the >>> mailing list. >>> All were wrong. >>> An Internet Standard should contain tried and true material, not >>> errata fodder. >>> >>> - an implementer is in a much better position to get this right than >>> the standard, because they can write unit tests. >> >> I completely agree with Carsten. As far as I know, and as far as we have >> been told on this list, if some JSON isn't in UTF-8, then it simply will >> not interoperate. > > +1 > > If we do do this, I think we could add some example test messages to > helps with the development, e.g.: > > {"Example":1} > {} > "Example" > "" > "U+0100" (where U+0100 is the UTF form of the character, not ASCII) > 1 > >> In my view, the only reason to still have a MAY for UTF-16/32 is that >> this will avoid questions like: "I have a JSON parser in language FOO, >> it can take a string or an input stream as an argument. In FOO, strings >> are UTF-16, but the JSON RFC doesn't seem to allow this. What should I >> do." > > IMO the answer to that is, "that's why it says 'JSON text _SHOULD_ be > encoded in UTF-8'". > > I agree with John Cowen, that use of UTF-16/32 is purely for internal > scenarios; not on the Internet. As such, I believe the IETF is going > beyond its remit to say you can use UTF-16/32 for your internal purposes > that I know nothing about and care nothing about, but you're not allowed > to use other encodings that maybe more natural for your system. > > Pete Cordell > Codalogic Ltd > C++ tools for C++ programmers, http://codalogic.com > Read & write XML in C++, http://www.xml2cpp.com > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Thu Apr 27 09:23:49 2017 Return-Path: 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 0E60D1270A7 for ; Thu, 27 Apr 2017 09:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 km6OQZCxYP35 for ; Thu, 27 Apr 2017 09:23:45 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 D60C7129646 for ; Thu, 27 Apr 2017 09:21:36 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id h41so4497089ioi.1 for ; Thu, 27 Apr 2017 09:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=pVEbxSbB/ymQ+IiH/TUQU+xXjv9QYpTpqy6PWzAolJU=; b=kJnqdSkzSyrVSIs54jZepZkMUtfg1Wh5j2p3aE9j7Bb+sYG4Ves9HnK9ggn/SFxFOq JYM9wRmsJwKozDQCm5GyHuqFz/it7GaYlYZq84XIm+k2h1exgMHR0VBMdqnJXkF4n2bP x/RnVuX6O5zqoqQ9drp4bXyppdWaKnkRDWgSomcoQA4/uTOB5p1rzIIBS3Kv4oNbz/qw e8pAqKHLRGr9RMNS86ppAC6D3x50LF4BwzV2xHj61Y5RRiZ3CLGWT8PqdV8dkhxLpG4k 9QZy9aoXbag+D4DG0DkTu3rbrzZ15K8HgNwaidp1jvnFisbEMGfBSShUV0dGKtBlBeu8 KC3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=pVEbxSbB/ymQ+IiH/TUQU+xXjv9QYpTpqy6PWzAolJU=; b=lJ1n1hVqoML0iC2E0VD/GT6kMBq3GYXUE5idB6VM4PXQIF7OilsoLHMU/b2iRAk7pm 7mquP7Hy+4JAwhGFeQhz+s5ohJp6Yz6m1Qg4PxUhMfosrA+2v3Jkm1jQhzVTWoR3ZhTK vUaLASIK9ehFLbDkAE0qbysy8OL0Jou3H6ylcPhBFp+hxGxe/ERNmkEP6XgRjoi/iOV7 WETqNd/7LBysX6UO6BjUtyvwWt7hXbOJy1hnUtYnmjfo7AAXtYodiW5gIrmw7wDd4A2L Iv0ZtfnAFXlx8HBKuX0jT0LzkmXshnsgTOPr3ToB9ZxduOqo2+YNaH8+mJBo8E3dJGru 8/1A== X-Gm-Message-State: AN3rC/5W3AmwhAQSeFx+CGkufIwQEAMIftC/y0VTk5iZ5gmtKmp65s3d suEouShUUyic4jtJfBE= X-Received: by 10.157.47.173 with SMTP id r42mr418577otb.63.1493310095660; Thu, 27 Apr 2017 09:21:35 -0700 (PDT) Received: from [10.6.23.170] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id a40sm1385419oic.11.2017.04.27.09.21.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 09:21:34 -0700 (PDT) Sender: Matthew Miller To: Pete Cordell , =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Carsten Bormann Cc: "json@ietf.org" References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> <6eb23f90-6623-7888-bc1c-6640a9dababc@codalogic.com> <61bfad2b-850d-a11f-e80b-d5ed9ccb4dc9@codalogic.com> From: "Matthew A. Miller" Message-ID: <08a88696-65ef-da05-0d77-1a07d04ebfc8@outer-planes.net> Date: Thu, 27 Apr 2017 10:21:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Thunderbird/53.0 MIME-Version: 1.0 In-Reply-To: <61bfad2b-850d-a11f-e80b-d5ed9ccb4dc9@codalogic.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Xj81pJuWNNW2MfxwgdlagLjKV9dpLjWuv" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 16:23:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xj81pJuWNNW2MfxwgdlagLjKV9dpLjWuv Content-Type: multipart/mixed; boundary="ioD1kXm7wdKTdKhf4xpOh0QuttIbNP3wl"; protected-headers="v1" From: "Matthew A. Miller" To: Pete Cordell , =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Carsten Bormann Cc: "json@ietf.org" Message-ID: <08a88696-65ef-da05-0d77-1a07d04ebfc8@outer-planes.net> Subject: Re: [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding" References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> <6eb23f90-6623-7888-bc1c-6640a9dababc@codalogic.com> <61bfad2b-850d-a11f-e80b-d5ed9ccb4dc9@codalogic.com> In-Reply-To: <61bfad2b-850d-a11f-e80b-d5ed9ccb4dc9@codalogic.com> --ioD1kXm7wdKTdKhf4xpOh0QuttIbNP3wl Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I see consensus for text in Section 8.1 pending an Appendix on encoding detection, but nothing for the Appendix itself. Looking deeper in the threads again, it appears to me that: * There is consensus to say "just use UTF8" in many (most) scenarios * There is rough consensus to say "always use UTF8", but concern this change goes beyond the charter * There is no consensus on a detection algorithm While the charter calls for "absolute minimal changes", it calls out RFC 7159 (and its -bis) as documenting "interoperability concerns when exchanging JSON over a network". Documenting this interoperability is one of its primary goals. Therefore, the argument is made that a change to the effect of "JSON text MUST be encoded as UTF-8" is considered an "absolute minimum change" in order to achieve the goal of network interoperability. To the working group: * Is there strong objection to mandating only UTF-8? * Does anyone have suggested text to that effect? - m&m Matthew A. Miller JSONbis Chair On 4/27/17 3:15 AM, Pete Cordell wrote: > I seem to have killed this thread off again. Sorry about that. >=20 > Any conclusions? >=20 > Cheers, >=20 > Pete. >=20 > On 18/04/2017 14:01, Pete Cordell wrote: >> On 18/04/2017 06:22, Martin J. D=C3=BCrst wrote: >>> On 2017/04/18 05:47, Carsten Bormann wrote: >>>> On Apr 17, 2017, at 19:56, Nico Williams wro= te: >>>>> >>>>>> Thinking about this more, putting an encoding detection algorithm >>>>>> as an >>>>>> appendix seems like a reasonable compromise to me. To start, how >>>>>> about >>>>>> removing the detection text from Section 8.1 and have an appendix >>>>>> that >>>>>> starts with that text plus the table? >>>>> >>>>> Or we could even just assert that such an algorithm is possible, an= d >>>>> that implementors MAY implement one. >>>> >>>> Indeed. >>>> >>>> Broken record mode: >>>> >>>> =E2=80=94 writing up the algorithm sounds like encouraging implement= ation. >>>> We *don=E2=80=99t* want people to implement this! >>>> (The whole interminable non-UTF-8 saga probably just was a nod fro= m >>>> the RFC 4627 authors to the remnants of UTF-16 land, which mostly ha= ve >>>> died off since. Why resurrect?) >>>> >>>> - there have been about 15 attempts to define this algorithm on the >>>> mailing list. >>>> All were wrong. >>>> An Internet Standard should contain tried and true material, not >>>> errata fodder. >>>> >>>> - an implementer is in a much better position to get this right than= >>>> the standard, because they can write unit tests. >>> >>> I completely agree with Carsten. As far as I know, and as far as we h= ave >>> been told on this list, if some JSON isn't in UTF-8, then it simply w= ill >>> not interoperate. >> >> +1 >> >> If we do do this, I think we could add some example test messages to >> helps with the development, e.g.: >> >> {"Example":1} >> {} >> "Example" >> "" >> "U+0100" (where U+0100 is the UTF form of the character, not ASCII= ) >> 1 >> >>> In my view, the only reason to still have a MAY for UTF-16/32 is that= >>> this will avoid questions like: "I have a JSON parser in language FOO= , >>> it can take a string or an input stream as an argument. In FOO, strin= gs >>> are UTF-16, but the JSON RFC doesn't seem to allow this. What should = I >>> do." >> >> IMO the answer to that is, "that's why it says 'JSON text _SHOULD_ be >> encoded in UTF-8'". >> >> I agree with John Cowen, that use of UTF-16/32 is purely for internal >> scenarios; not on the Internet. As such, I believe the IETF is going >> beyond its remit to say you can use UTF-16/32 for your internal purpos= es >> that I know nothing about and care nothing about, but you're not allow= ed >> to use other encodings that maybe more natural for your system. >> >> Pete Cordell >> Codalogic Ltd >> C++ tools for C++ programmers, http://codalogic.com >> Read & write XML in C++, http://www.xml2cpp.com >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json --ioD1kXm7wdKTdKhf4xpOh0QuttIbNP3wl-- --Xj81pJuWNNW2MfxwgdlagLjKV9dpLjWuv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZAhqOAAoJEOz0ck4QngW7FDIH/1iaeAJ7qr1XM8Z4lxZJMfpQ I4WVV5BYhFQ6md8Pwb0iMZvEVbdZz00sxQLk/lo0KplcyCdfL0eOx3kQx2ZbUI8U 6HMdCSHxzOxNrqlXA787Vl+bP9IdSGjJWroYg5pJamy7bMyIuJwcZ73pwhhzFA73 2B2vTF57wbJOeWrRoJJJzAuWyzN1FzRDQge9Z+Wa3M1yV1H7z9e12z8QuVDMu27l YNPzBRh2D/JY8ynQnUZne55D6Wk/2/W2iCpd46pbhzhoM5axm244KLhWHPqAjY3l HN34thflk6+UUoySD0zvMC9tGro6gSJk1WmSzaGBNKzqWjwvuCw+5BAb4DOxK1w= =iGIq -----END PGP SIGNATURE----- --Xj81pJuWNNW2MfxwgdlagLjKV9dpLjWuv-- From nobody Fri Apr 28 07:28:22 2017 Return-Path: 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 88BDA1294CD for ; Fri, 28 Apr 2017 07:28:20 -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 UqYjaXTgYWwv for ; Fri, 28 Apr 2017 07:28:19 -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 D414112EAA4 for ; Fri, 28 Apr 2017 07:23:48 -0700 (PDT) Received: (qmail 6253 invoked from network); 28 Apr 2017 15:16:10 +0100 Received: from host109-156-176-225.range109-156.btcentralplus.com (HELO ?192.168.1.72?) (109.156.176.225) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 28 Apr 2017 15:16:10 +0100 To: "Matthew A. Miller" References: <14252631-AD76-4537-89BF-6368F4A8CDF4@att.com> <7e6af21f-16ea-a3bc-9c01-595ae8acebba@gmx.de> <05100401-88D4-4158-A3FF-3EF144D85449@att.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> <20170417175627.GK23461@localhost> <10B651F1-7FE0-484D-BD2E-FD146BC5FB04@tzi.org> <6eb23f90-6623-7888-bc1c-6640a9dababc@codalogic.com> <61bfad2b-850d-a11f-e80b-d5ed9ccb4dc9@codalogic.com> <08a88696-65ef-da05-0d77-1a07d04ebfc8@outer-planes.net> Cc: "json@ietf.org" From: Pete Cordell Message-ID: Date: Fri, 28 Apr 2017 15:23:45 +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: <08a88696-65ef-da05-0d77-1a07d04ebfc8@outer-planes.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 14:28:20 -0000 Thanks. I agree with your summary. If you removed the sentence which mentions "UTF-16, or UTF-32" from the text that you proposed on 17 April, I'd be happy with that text. Thanks again, Pete. On 27/04/2017 17:21, Matthew A. Miller wrote: > I see consensus for text in Section 8.1 pending an Appendix on encoding > detection, but nothing for the Appendix itself. > > Looking deeper in the threads again, it appears to me that: > > * There is consensus to say "just use UTF8" in many (most) scenarios > * There is rough consensus to say "always use UTF8", but concern this > change goes beyond the charter > * There is no consensus on a detection algorithm > > While the charter calls for "absolute minimal changes", it calls out RFC > 7159 (and its -bis) as documenting "interoperability concerns when > exchanging JSON over a network". Documenting this interoperability is > one of its primary goals. > > Therefore, the argument is made that a change to the effect of "JSON > text MUST be encoded as UTF-8" is considered an "absolute minimum > change" in order to achieve the goal of network interoperability. > > To the working group: > > * Is there strong objection to mandating only UTF-8? > * Does anyone have suggested text to that effect? > > > - m&m > > Matthew A. Miller > JSONbis Chair