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

Carsten Bormann <cabo@tzi.org> Wed, 10 June 2020 13:44 UTC

Return-Path: <cabo@tzi.org>
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 E8E043A0886 for <json@ietfa.amsl.com>; Wed, 10 Jun 2020 06:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 4iB65bc0AKlx for <json@ietfa.amsl.com>; Wed, 10 Jun 2020 06:44:03 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FF93A0882 for <json@ietf.org>; Wed, 10 Jun 2020 06:44:03 -0700 (PDT)
Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49hp9p2nPyzytX; Wed, 10 Jun 2020 15:43:58 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20200610133258.D4B85F4073D@rfc-editor.org>
Date: Wed, 10 Jun 2020 15:43:57 +0200
Cc: tbray@textuality.com, superuser@gmail.com, barryleiba@computer.org, linuxwolf+ietf@outer-planes.net, xdg@xdg.me, json@ietf.org
X-Mao-Original-Outgoing-Id: 613489437.918979-14c786ac25a005a082307ff671730e00
Content-Transfer-Encoding: quoted-printable
Message-Id: <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org>
References: <20200610133258.D4B85F4073D@rfc-editor.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/QpwKJ6RAYBCHCZqAa_fuC1Bovt8>
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 13:44:06 -0000

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.

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

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

Grüße, Carsten


> On 2020-06-10, at 15:32, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC8259,
> "The JavaScript Object Notation (JSON) Data Interchange Format".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6208
> 
> --------------------------------------
> Type: Technical
> Reported by: David Golden <xdg@xdg.me>
> 
> Section: 8.1
> 
> Original 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.
> 
> Corrected Text
> --------------
> In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark or MAY interpret a byte order mark to indicate an alternate encoding rather than treating it as an error.
> 
> Notes
> -----
> The original line is copied from previous RFCs that specifically allowed alternate encodings.  In the context of a new, UTF-8 only restriction, interoperability provisions should also address interpreting legacy formats that predate the restriction.  By omission, readers may conclude that the *only* option for a BOM is to ignore or error.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC8259 (draft-ietf-jsonbis-rfc7159bis-04)
> --------------------------------------
> Title               : The JavaScript Object Notation (JSON) Data Interchange Format
> Publication Date    : December 2017
> Author(s)           : T. Bray, Ed.
> Category            : INTERNET STANDARD
> Source              : Javascript Object Notation Update
> Area                : Applications and Real-Time
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json