IETF Logo Mail Archive

Re: [Json] [Technical Errata Reported] RFC8259 (6208)

Nico Williams <nico@cryptonector.com> Wed, 10 June 2020 16:08 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21233A098E for <json@ietfa.amsl.com>; Wed, 10 Jun 2020 09:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 y5ixKBQANvd5 for <json@ietfa.amsl.com>; Wed, 10 Jun 2020 09:08:51 -0700 (PDT)
Received: from cadetblue.birch.relay.mailchannels.net (cadetblue.birch.relay.mailchannels.net [23.83.209.28]) (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 8C6993A098C for <json@ietf.org>; Wed, 10 Jun 2020 09:08:50 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 035BC34110D; Wed, 10 Jun 2020 16:08:49 +0000 (UTC)
Received: from pdx1-sub0-mail-a78.g.dreamhost.com (100-96-22-28.trex.outbound.svc.cluster.local [100.96.22.28]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EDC1A3416B7; Wed, 10 Jun 2020 16:08:47 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a78.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Wed, 10 Jun 2020 16:08:48 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Thread-Minister: 64dd3e362dbb3f23_1591805328408_1859209844
X-MC-Loop-Signature: 1591805328408:883194591
X-MC-Ingress-Time: 1591805328407
Received: from pdx1-sub0-mail-a78.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a78.g.dreamhost.com (Postfix) with ESMTP id 982E881A47; Wed, 10 Jun 2020 09:08:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=F5097fNnsSlU2i4/Hc7JLqmb+8c=; b=c2fSZwhphdU hgbqbtpMpw2nLTuUIE+pt6Uea+Nwnifp65xYOs+mpelKaaCvmPPLmiD9OOf+O0qF Ll0k4H80yrDsALsE4dKc3VOvFx9DPDTMrpCzdzEjUuwSB0uU9yClbgx+3nHE+Y0j PMwpFeHdQzPwvyFqw+KN4GxBjr9rOw/o=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a78.g.dreamhost.com (Postfix) with ESMTPSA id A30FA81A4A; Wed, 10 Jun 2020 09:08:43 -0700 (PDT)
Date: Wed, 10 Jun 2020 11:08:40 -0500
X-DH-BACKEND: pdx1-sub0-mail-a78
From: Nico Williams <nico@cryptonector.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, json@ietf.org, superuser@gmail.com, tbray@textuality.com, xdg@xdg.me, barryleiba@computer.org, linuxwolf+ietf@outer-planes.net
Message-ID: <20200610160838.GF3100@localhost>
References: <20200610133258.D4B85F4073D@rfc-editor.org> <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudehiedgleelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuggftrfgrthhtvghrnhepgedviedvgefgtdfhtefghfeuffeglefggefhvdfgtdffhfevffeiheffieeuudefnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/ENkZMCySSB5srXbArCjN1mlAESE>
Subject: Re: [Json] [Technical Errata Reported] RFC8259 (6208)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2020 16:08:53 -0000

On Wed, Jun 10, 2020 at 03:43:57PM +0200, Carsten Bormann wrote:
> The WG had pretty strong consensus that BOMs don’t belong on JSON.
> This “MAY” prepares implementations for the presence of other implementations that do not heed that consensus.  No functionality is assigned by this MAY.

And the proposed edit merely says what the existing MAY implies.

> Since Errata are not intended to unravel WG decisions: Reject.

+1

> Apart from that, I seriously don’t understand what the "indicate an
> alternate encoding” would be — the JSON text already is UTF-8?

UTF-16, presumably.

No BOM is needed for that anyways.  One can unambiguously detect both,
the use of UTF-16 (and even UTF-32) and the byte endianness used.  At
any rate, for Internet purposes, we don't care one iota for any UTF
other than UTF-8, and we don't care about non-Unicode.  So, reject.

Nico
--

v2.23.0 | Report a Bug | By Email