From nobody Wed Jun 10 06:33:26 2020 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 85FC23A086C for ; Wed, 10 Jun 2020 06:33:25 -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, 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 plnXd3cMonFi for ; Wed, 10 Jun 2020 06:33:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6D83A0853 for ; Wed, 10 Jun 2020 06:33:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D4B85F4073D; Wed, 10 Jun 2020 06:32:58 -0700 (PDT) To: tbray@textuality.com, superuser@gmail.com, barryleiba@computer.org, linuxwolf+ietf@outer-planes.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: xdg@xdg.me, json@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200610133258.D4B85F4073D@rfc-editor.org> Date: Wed, 10 Jun 2020 06:32:58 -0700 (PDT) Archived-At: Subject: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 13:33:26 -0000 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 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 From nobody Wed Jun 10 06:44:08 2020 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 E8E043A0886 for ; 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 ; 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 ; 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 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 X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 13:44:06 -0000 The WG had pretty strong consensus that BOMs don=E2=80=99t belong on = JSON. This =E2=80=9CMAY=E2=80=9D 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=E2=80=99t understand what the "indicate = an alternate encoding=E2=80=9D would be =E2=80=94 the JSON text already = is UTF-8? Gr=C3=BC=C3=9Fe, Carsten > On 2020-06-10, at 15:32, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC8259, > "The JavaScript Object Notation (JSON) Data Interchange Format". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6208 >=20 > -------------------------------------- > Type: Technical > Reported by: David Golden >=20 > Section: 8.1 >=20 > Original Text > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > 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. >=20 > 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. >=20 > 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. >=20 > 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > 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 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Wed Jun 10 07:37:41 2020 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 468803A08F6 for ; Wed, 10 Jun 2020 07:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 z0W8OLpuuFbI for ; Wed, 10 Jun 2020 07:37:38 -0700 (PDT) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) (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 E35603A08F3 for ; Wed, 10 Jun 2020 07:37:37 -0700 (PDT) Received: by mail-il1-f176.google.com with SMTP id h3so2084815ilh.13 for ; Wed, 10 Jun 2020 07:37:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8DgVhWjlsu8bpg1rxMTkfIr+v4Iz1geCT9yS6TiZq1A=; b=a3QPLEspnj2A002wMyuP1kcWh7VNKJreEz3HJH19ojNUra2CkD6wAssMMs3wRcz0Ha DrIedDMgbsxXgK8F6FCK2ApTJSkNgTq0+lR6QXQrnmMN2oFWP+IKvltyChAn0FygE1AD uemYvZB7stKfahXRYNqlb4mh7NQJxL9SrjPVZ9VpzkUqI6nU3TYWjEq/xQZ+Ua/8m+aw 3tYzPTwTFgVxrzx28v7Gq3e9h4bH7pMDmHF0ja6QakrqXtWkEMjLfLwF1j+EA0V++FOr pJSdRC7A5SUcRequNtX0llAaUq5OYSyWYUgRlgQkj3dE0jVRbHzEazVToe+Okl/tVEO/ vuBw== X-Gm-Message-State: AOAM532joQuHXLiWNV0Hm3t8pMrpnE9+MRZPmjK14Cz0+yOqsWUDtbfl uUKTKCKBJiSlBC9C2XJRLfvuBJ+m4hK+oQ9icwXvhEYN X-Google-Smtp-Source: ABdhPJy7CeXT7gAmlryckRbF27ofaykS9LeHrMHHIbDrIbrkLcItpLi1Gu0LJNDiYO4OPjOex2NljnjxSjWGy3zSyos= X-Received: by 2002:a05:6e02:10c:: with SMTP id t12mr3183503ilm.187.1591799856849; Wed, 10 Jun 2020 07:37:36 -0700 (PDT) MIME-Version: 1.0 References: <20200610133258.D4B85F4073D@rfc-editor.org> <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org> In-Reply-To: <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org> From: Barry Leiba Date: Wed, 10 Jun 2020 10:37:25 -0400 Message-ID: To: Carsten Bormann Cc: RFC Errata System , Tim Bray , Murray Kucherawy , "Matthew A. Miller" , xdg@xdg.me, json@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 14:37:39 -0000 Yes, I agree: this is asking to revisit what we had consensus on, not reporting an error in the RFC. Off to reject it now. Barry On Wed, Jun 10, 2020 at 9:44 AM Carsten Bormann wrote: > > The WG had pretty strong consensus that BOMs don=E2=80=99t belong on JSON= . > This =E2=80=9CMAY=E2=80=9D prepares implementations for the presence of o= ther 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=E2=80=99t understand what the "indicate = an alternate encoding=E2=80=9D would be =E2=80=94 the JSON text already is = UTF-8? > > Gr=C3=BC=C3=9Fe, Carsten > > > > On 2020-06-10, at 15:32, RFC Errata System = 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 > > > > Section: 8.1 > > > > Original Text > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > In the interests of interoperability, implementations that parse JSON t= exts MAY ignore the presence of a byte order mark rather than treating it a= s an error. > > > > Corrected Text > > -------------- > > In the interests of interoperability, implementations that parse JSON t= exts MAY ignore the presence of a byte order mark or MAY interpret a byte o= rder mark to indicate an alternate encoding rather than treating it as an e= rror. > > > > Notes > > ----- > > The original line is copied from previous RFCs that specifically allowe= d alternate encodings. In the context of a new, UTF-8 only restriction, in= teroperability provisions should also address interpreting legacy formats t= hat predate the restriction. By omission, readers may conclude that the *o= nly* 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 Interc= hange 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 > From nobody Wed Jun 10 07:39:11 2020 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 F14AA3A08FA; Wed, 10 Jun 2020 07:39:04 -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, 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 dDNRk9ERD4XP; Wed, 10 Jun 2020 07:39:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236AF3A08EF; Wed, 10 Jun 2020 07:39:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 98151F40716; Wed, 10 Jun 2020 07:38:37 -0700 (PDT) To: xdg@xdg.me, tbray@textuality.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: barryleiba@computer.org, iesg@ietf.org, json@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200610143837.98151F40716@rfc-editor.org> Date: Wed, 10 Jun 2020 07:38:37 -0700 (PDT) Archived-At: Subject: [Json] [Errata Rejected] RFC8259 (6208) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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, 10 Jun 2020 14:39:05 -0000 The following errata report has been rejected 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 -------------------------------------- Status: Rejected Type: Technical Reported by: David Golden Date Reported: 2020-06-10 Rejected by: Barry Leiba (IESG) 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. --VERIFIER NOTES-- This is asking to revisit what we have consensus on, not a report of an error in the RFC. The working group had extensive discussions on BOMs, and chose this particular working purposefully. -------------------------------------- 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 From xdg@xdg.me Wed Jun 10 07:38:16 2020 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 DF4603A08F3 for ; Wed, 10 Jun 2020 07:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=xdg-me.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 RrTQCbHQkoXo for ; Wed, 10 Jun 2020 07:38:14 -0700 (PDT) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::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 85E9B3A08EF for ; Wed, 10 Jun 2020 07:38:14 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id n23so2769286ljh.7 for ; Wed, 10 Jun 2020 07:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xdg-me.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NXqOLy3qqrTFvAmrxCBpQ85Vvdz8B/Ms45CuYq0pTbI=; b=gGjb5REXAIKCHJkR+7swfcNkrTqFH3TCdYV4omLaTy0hmRUU+97bKtLuvwOMEFD95Q g39mpjkW9uQJcNS8MNSQq/UN05qxOzguxAoaRqaJw62HJL+R6ir1NvsuanDOayK/9nQm AFs+W3i6esvhIalr8JAXK47cu/Q2DTvgyDARf50/NJ6Gh2qI0hxUb3AGMwQErSRF4tgr RpmVgvegj3ZT0q5QegJOnfQGWC+HuBiFsCrsAOTKXwWPz18rE7BYnWnLGQpzcCEjNUhp Jpe0HYmAlGhNShALIzLuc63Yn8qP92rJgSZ99ecuDsxnO1tbzchbNpnEne5yiJoxyBAO WkVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NXqOLy3qqrTFvAmrxCBpQ85Vvdz8B/Ms45CuYq0pTbI=; b=LtgbPPvVuhfa3C6bTnd9CxuuxbbkS5SBbwjWTcqV/NZfKV3uxIMSVVFa+qrjgYSKQb aEfSnD9odmIFPm7Ppbk4DFJctIM5hFDGV8aAOP2BElNIfupN59oMYoP1qM9suxZPoorN Cyv+pETJyhvFTpAy8Gkf1dAfWKT2Z+g23OeGkbyfZmBPi2OFGS4I9qeEi10tyDm+NzKd IHTvYiQudyUxs38WcMuhNdUanIkyH/ObpegjN3hk95BUw5hR54LetoC+n17GSliMeUG4 qenAoE6xoFxkzTMgpjBJrUXG81BfQscQUu8eb7LVwRSmEyXw9MlzgQ6w9vTOQzCd6d6C mVHw== X-Gm-Message-State: AOAM5321n8XNNusdBV8gm9JicrwBE5PfFvD2d6dP0oTF8ox9zyYQYiKj bYHnud81DPA0NhmFLyqyPlX1ocOThlXU5REojlVB4w== X-Google-Smtp-Source: ABdhPJyeTbcwatVcWgcBFIpUE9vQ3lwTAH35a2MkEEhYNQyxcQSC+/qHgR27wjqyAC6XW4s+ZeYtIEYBbS6YZVjkIL0= X-Received: by 2002:a2e:6a05:: with SMTP id f5mr2018062ljc.272.1591799892520; Wed, 10 Jun 2020 07:38:12 -0700 (PDT) MIME-Version: 1.0 References: <20200610133258.D4B85F4073D@rfc-editor.org> <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org> In-Reply-To: <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org> From: David Golden Date: Wed, 10 Jun 2020 10:37:46 -0400 Message-ID: To: Carsten Bormann Cc: RFC Errata System , tbray@textuality.com, superuser@gmail.com, barryleiba@computer.org, linuxwolf+ietf@outer-planes.net, json@ietf.org Content-Type: multipart/alternative; boundary="00000000000025cdae05a7bbcbf3" Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2020 07:42:21 -0700 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 14:40:12 -0000 --00000000000025cdae05a7bbcbf3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree that BOMs don't belong on JSON, but three prior RFC allowed them. (The first one even specified how to do so.) Given a JSON text generated under a previous specification with a UTF-16/32 BOM, ignoring the BOM is incorrect behavior. As currently written -- copied verbatim from the prior two RFCs when BOMs were legal -- the only interoperability suggestion is to ignore a BOM. My proposal does not encourage the use of BOMs or unravel the WG consensus (which I fully support). It merely prepares implementations for the presence of other implementations that predate the current, more restrictive specification. Respectfully yours, David On Wed, Jun 10, 2020 at 9:43 AM Carsten Bormann wrote: > The WG had pretty strong consensus that BOMs don=E2=80=99t belong on JSON= . > This =E2=80=9CMAY=E2=80=9D prepares implementations for the presence of o= ther > 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=E2=80=99t understand what the "indicate = an > alternate encoding=E2=80=9D would be =E2=80=94 the JSON text already is U= TF-8? > > Gr=C3=BC=C3=9Fe, Carsten > > > > On 2020-06-10, at 15:32, RFC Errata System > 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 > > > > Section: 8.1 > > > > Original Text > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > In the interests of interoperability, implementations that parse JSON > texts MAY ignore the presence of a byte order mark rather than treating i= t > 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 byt= e > order mark to indicate an alternate encoding rather than treating it as a= n > error. > > > > Notes > > ----- > > The original line is copied from previous RFCs that specifically allowe= d > alternate encodings. In the context of a new, UTF-8 only restriction, > interoperability provisions should also address interpreting legacy forma= ts > 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 > > --=20 David Golden =E2=80=A2 https://xdg.me/ =E2=80=A2 Twitter/GitHu= b: @xdg --00000000000025cdae05a7bbcbf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that BOMs don't belong on JSON, but three= prior RFC allowed them.=C2=A0 (The first one even specified how to do so.)=

Given a JSON text generated under a previous spec= ification with a UTF-16/32 BOM, ignoring the BOM is incorrect behavior.=C2= =A0 As currently written -- copied verbatim from the prior two RFCs when BO= Ms were legal -- the only interoperability suggestion is to ignore a BOM.

My proposal does not encourage the use of BOMs = or unravel the WG consensus (which I fully support).=C2=A0 It merely prepar= es implementations for the presence of other implementations that predate t= he current, more restrictive specification.

Respec= tfully yours,
David

On Wed, Jun 10, 2020 at 9:43 AM Cars= ten Bormann <cabo@tzi.org> wrote:=
The WG had pret= ty strong consensus that BOMs don=E2=80=99t belong on JSON.
This =E2=80=9CMAY=E2=80=9D prepares implementations for the presence of oth= er implementations that do not heed that consensus.=C2=A0 No functionality = is assigned by this MAY.

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

Apart from that, I seriously don=E2=80=99t understand what the "indica= te an alternate encoding=E2=80=9D would be =E2=80=94 the JSON text already = is UTF-8?

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


> On 2020-06-10, at 15:32, RFC Errata System <rfc-editor@rfc-editor.org> w= rote:
>
> The following errata report has been submitted for RFC8259,
> "The JavaScript Object Notation (JSON) Data Interchange Format&qu= ot;.
>
> --------------------------------------
> 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
> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
> 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 allow= ed alternate encodings.=C2=A0 In the context of a new, UTF-8 only restricti= on, interoperability provisions should also address interpreting legacy for= mats that predate the restriction.=C2=A0 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<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC8259 (draft-ietf-jsonbis-rfc7159bis-04)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Java= Script Object Notation (JSON) Data Interchange Format
> Publication Date=C2=A0 =C2=A0 : December 2017
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: T. Bray, Ed.
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : INTERNET STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Javascript Ob= ject Notation Update
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Applicat= ions and Real-Time
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> _______________________________________________
> json mailing list
> json@ietf.org > https://www.ietf.org/mailman/listinfo/json



--
David Golden <xdg= @xdg.me> =E2=80=A2 htt= ps://xdg.me/ =E2=80=A2 Twitter/GitHub: @xdg
--00000000000025cdae05a7bbcbf3-- From nobody Wed Jun 10 07:42:40 2020 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 EF10F3A0982 for ; Wed, 10 Jun 2020 07:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 JFhb1XoS2eE6 for ; Wed, 10 Jun 2020 07:42:23 -0700 (PDT) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) (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 60FDC3A0922 for ; Wed, 10 Jun 2020 07:42:23 -0700 (PDT) Received: by mail-io1-f65.google.com with SMTP id i25so2491845iog.0 for ; Wed, 10 Jun 2020 07:42:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=z7nDG9I+kJQP8y6mjdUf53l6kSNKC9sov2ObIf+SsrA=; b=EbsleH34qW20A21TcKHHH84A/cQaM7J31SgQeA0zpWzC4qk/RCbTCjBTESAIMnaH0M mBCSIcxo8GH/O/HFLmWpFSbp1a0YMA9a+rMD+zhYrf0V519inaCX7MHA7QlfDRevLbag 4L132FG4+Aj55pABUBl6GCdnS2xMkmelJR4VfklZKHz3LNunDziAmu1lacHjtegzLCCW Xy0TYreG3ssIFPyd8CUW+IgzK25A9R4RkrWkFBeaGtk0eh//zX9CWi90KaiDjvLgDPds 2KMAK56zkNQAinOaxKsH7IWoKUJu2fKkdhZRMaailB0Wlu1r5BFkvVgVQhZ8qluATtMM XPeg== X-Gm-Message-State: AOAM533UCheSIZcMsLdUyV5dA/9cpOVds/XGKWy6U+Bl6Bw53HXXLhSU WSyCgq9l/qRJYoVHZX+3TNdZRtJfvCK5cy1CkkE= X-Google-Smtp-Source: ABdhPJyNK3NX9Jv7Q3x22FjV/WFuSLQOytHRhApdoiA1XV2rW6hq1AOHAm/lIMx0lWMdiiASs58wCgAsrrSsttFqALc= X-Received: by 2002:a05:6602:13c6:: with SMTP id o6mr3539781iov.84.1591800142494; Wed, 10 Jun 2020 07:42:22 -0700 (PDT) MIME-Version: 1.0 References: <20200610133258.D4B85F4073D@rfc-editor.org> <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org> In-Reply-To: From: Barry Leiba Date: Wed, 10 Jun 2020 10:42:11 -0400 Message-ID: To: David Golden Cc: Carsten Bormann , RFC Errata System , Tim Bray , Murray Kucherawy , "Matthew A. Miller" , json@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 14:42:38 -0000 David, I understand that it might be worth having further discussion about the issue. The problem *here* is that there is not an error in the RFC: the RFC accurately reflects the consensus of the working group and the text that was reviewed and agreed on at the time. So it's not in scope for an errata report. Discussion about whether or not to revisit this and to publish an RFC that says something different is... a separate discussion. Barry, ART AD On Wed, Jun 10, 2020 at 10:38 AM David Golden wrote: > > I agree that BOMs don't belong on JSON, but three prior RFC allowed them.= (The first one even specified how to do so.) > > Given a JSON text generated under a previous specification with a UTF-16/= 32 BOM, ignoring the BOM is incorrect behavior. As currently written -- co= pied verbatim from the prior two RFCs when BOMs were legal -- the only inte= roperability suggestion is to ignore a BOM. > > My proposal does not encourage the use of BOMs or unravel the WG consensu= s (which I fully support). It merely prepares implementations for the pres= ence of other implementations that predate the current, more restrictive sp= ecification. > > Respectfully yours, > David > > On Wed, Jun 10, 2020 at 9:43 AM Carsten Bormann wrote: >> >> The WG had pretty strong consensus that BOMs don=E2=80=99t belong on JSO= N. >> This =E2=80=9CMAY=E2=80=9D 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=E2=80=99t understand what the "indicate= an alternate encoding=E2=80=9D would be =E2=80=94 the JSON text already is= UTF-8? >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> >> > On 2020-06-10, at 15:32, RFC Errata System = 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 >> > >> > Section: 8.1 >> > >> > Original Text >> > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >> > 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 allow= ed alternate encodings. In the context of a new, UTF-8 only restriction, i= nteroperability 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 Inter= change 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 >> > > > -- > David Golden =E2=80=A2 https://xdg.me/ =E2=80=A2 Twitter/Git= Hub: @xdg From nobody Wed Jun 10 07:51:12 2020 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 1D4BA3A0045 for ; Wed, 10 Jun 2020 07:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=xdg-me.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 Tbd6ibdZDIAp for ; Wed, 10 Jun 2020 07:50:16 -0700 (PDT) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::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 B9F703A005B for ; Wed, 10 Jun 2020 07:50:15 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id x18so2853656lji.1 for ; Wed, 10 Jun 2020 07:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xdg-me.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5BjEUWeavWJN6pY0gayfF2yp2hpwp8EII5UGuR6N0cc=; b=qd26vEgth47xF7R4p06+0tY17XzSU7u5KSseRQ95/gaKrOQubE0BnpjJfceqNpBK8k QBXcxcON8PGvqR7oLgcJj1aPB6VjDyxbpF25p2YewYE11HxrCBAQ2bIuCUG7ZGzH+Dc6 +OA98gBSEpa2HwwhaxBIaTfxwxUcP9qQXoDSkGrSk42r+A5juMS3h9Z/bwgEubQeBGpv 1PEJXvbHPuZKfQdi/kp9HYH4beYUAK0iX8psMbPJf6wdauu9+h2bUVAHAGMcKksD4U7F N91iZUwHweeaY5HUxPCDeSplUH0y3b5jQRX90osthHhhBypMGnNUC85DY5l916i7dkBZ nDBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5BjEUWeavWJN6pY0gayfF2yp2hpwp8EII5UGuR6N0cc=; b=NLcj3gsVaC1Z2aAHBYd65LSzo/JTxyp+76Z1ak6/U8ShWCiWl4puI7lu9o6VuVppvJ x/F4Hyj6a5a3BdisCXcSB65u5he3gF+KEDbB9IcAIoAzJJ+PzMppcvsQ/GzLQu0B1k7O 2YWmuaEfi+qiKvRziKm1qI8SQGRzco/9pDHWG+3z/MtmwpKFZUDVhzw/JnQ8Rvx4ihJm XUX+2RwCcc6QF1HauDlqnBUUwsLMrsX82fk+9SSWzNNk2YZymjkAEs5xkaYauoIXftHc mzRlhz2+CGD8/6N1IRDtpIGw+42ET3DAFsO8PN3Na9Af6dxTqkMyUfk0Rl/yiCGFtpM9 LvFw== X-Gm-Message-State: AOAM532f3nc5ZQb1ACWYJ1VIdk3nvvJE/Ll2kGPLxTWTjZlPfMn5JLD0 /DlLx53NtREej8xZMX4KdZZXNk707K2DzuOgAj1Zog== X-Google-Smtp-Source: ABdhPJz/Gdnn1ywuekU02Dr0BfB6EvfSQ4dZjcwLl003z+loOCab8CyFcMnDOY4S8FlZjXxHsSpICfnMMZ1aCp4P6ig= X-Received: by 2002:a2e:b5c8:: with SMTP id g8mr2194528ljn.61.1591800613743; Wed, 10 Jun 2020 07:50:13 -0700 (PDT) MIME-Version: 1.0 References: <20200610133258.D4B85F4073D@rfc-editor.org> <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org> In-Reply-To: From: David Golden Date: Wed, 10 Jun 2020 10:49:47 -0400 Message-ID: To: Barry Leiba Cc: Carsten Bormann , RFC Errata System , Tim Bray , Murray Kucherawy , "Matthew A. Miller" , json@ietf.org Content-Type: multipart/alternative; boundary="00000000000022c54a05a7bbf6ad" Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2020 07:51:10 -0700 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 14:50:18 -0000 --00000000000022c54a05a7bbf6ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I understand. Would it be more appropriate then to limit the "may ignore a BOM" to "may ignore a UTF-8 BOM" so that the interop suggestion does not inadvertently encourage incorrect decoding? That would be consistent with the UTF-8 only restriction and leave legacy encoding/BOM considerations out of scope. I realize this may seem picky, but this stems from discussions at work about whether/how to support legacy BOMs and people have interpreted the RFC differently. I was hoping to create clarity consistent with the intent of the working group, whatever that turns out to be. David On Wed, Jun 10, 2020 at 10:42 AM Barry Leiba wrote: > David, I understand that it might be worth having further discussion > about the issue. The problem *here* is that there is not an error in > the RFC: the RFC accurately reflects the consensus of the working > group and the text that was reviewed and agreed on at the time. So > it's not in scope for an errata report. Discussion about whether or > not to revisit this and to publish an RFC that says something > different is... a separate discussion. > > Barry, ART AD > > On Wed, Jun 10, 2020 at 10:38 AM David Golden wrote: > > > > I agree that BOMs don't belong on JSON, but three prior RFC allowed > them. (The first one even specified how to do so.) > > > > Given a JSON text generated under a previous specification with a > UTF-16/32 BOM, ignoring the BOM is incorrect behavior. As currently > written -- copied verbatim from the prior two RFCs when BOMs were legal -= - > the only interoperability suggestion is to ignore a BOM. > > > > My proposal does not encourage the use of BOMs or unravel the WG > consensus (which I fully support). It merely prepares implementations fo= r > the presence of other implementations that predate the current, more > restrictive specification. > > > > Respectfully yours, > > David > > > > On Wed, Jun 10, 2020 at 9:43 AM Carsten Bormann wrote: > >> > >> The WG had pretty strong consensus that BOMs don=E2=80=99t belong on J= SON. > >> This =E2=80=9CMAY=E2=80=9D prepares implementations for the presence o= f 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=E2=80=99t understand what the "indica= te an > alternate encoding=E2=80=9D would be =E2=80=94 the JSON text already is U= TF-8? > >> > >> Gr=C3=BC=C3=9Fe, Carsten > >> > >> > >> > On 2020-06-10, at 15:32, RFC Errata System > 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 > >> > > >> > Section: 8.1 > >> > > >> > Original Text > >> > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > >> > In the interests of interoperability, implementations that parse JSO= N > texts MAY ignore the presence of a byte order mark rather than treating i= t > as an error. > >> > > >> > Corrected Text > >> > -------------- > >> > In the interests of interoperability, implementations that parse JSO= N > texts MAY ignore the presence of a byte order mark or MAY interpret a byt= e > order mark to indicate an alternate encoding rather than treating it as a= n > 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 > >> > > > > > > -- > > David Golden =E2=80=A2 https://xdg.me/ =E2=80=A2 Twitter/G= itHub: @xdg > --=20 David Golden =E2=80=A2 https://xdg.me/ =E2=80=A2 Twitter/GitHu= b: @xdg --00000000000022c54a05a7bbf6ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand.=C2=A0 Would it be more appropriate then= to limit the "may ignore a BOM" to "may ignore a UTF-8 BOM&= quot; so that the interop suggestion does not inadvertently encourage incor= rect decoding?=C2=A0 That would be consistent with the UTF-8 only restricti= on and leave legacy encoding/BOM considerations out of scope.
I realize this may seem picky, but this stems from discussions = at work about whether/how to support legacy BOMs and people have interprete= d the RFC differently.=C2=A0 I was hoping to create clarity consistent with= the intent of the working group, whatever that turns out to be.
<= div>
David

On Wed, Jun 10, 2020 at 10:42 AM Barry Le= iba <barryleiba@computer.org<= /a>> wrote:
D= avid, I understand that it might be worth having further discussion
about the issue.=C2=A0 The problem *here* is that there is not an error in<= br> the RFC: the RFC accurately reflects the consensus of the working
group and the text that was reviewed and agreed on at the time.=C2=A0 So it's not in scope for an errata report.=C2=A0 Discussion about whether = or
not to revisit this and to publish an RFC that says something
different is... a separate discussion.

Barry, ART AD

On Wed, Jun 10, 2020 at 10:38 AM David Golden <xdg@xdg.me> wrote:
>
> I agree that BOMs don't belong on JSON, but three prior RFC allowe= d them.=C2=A0 (The first one even specified how to do so.)
>
> Given a JSON text generated under a previous specification with a UTF-= 16/32 BOM, ignoring the BOM is incorrect behavior.=C2=A0 As currently writt= en -- copied verbatim from the prior two RFCs when BOMs were legal -- the o= nly interoperability suggestion is to ignore a BOM.
>
> My proposal does not encourage the use of BOMs or unravel the WG conse= nsus (which I fully support).=C2=A0 It merely prepares implementations for = the presence of other implementations that predate the current, more restri= ctive specification.
>
> Respectfully yours,
> David
>
> On Wed, Jun 10, 2020 at 9:43 AM Carsten Bormann <cabo@tzi.org> wrote:
>>
>> The WG had pretty strong consensus that BOMs don=E2=80=99t belong = on JSON.
>> This =E2=80=9CMAY=E2=80=9D prepares implementations for the presen= ce of other implementations that do not heed that consensus.=C2=A0 No funct= ionality is assigned by this MAY.
>>
>> Since Errata are not intended to unravel WG decisions: Reject.
>>
>> Apart from that, I seriously don=E2=80=99t understand what the &qu= ot;indicate an alternate encoding=E2=80=9D would be =E2=80=94 the JSON text= already is UTF-8?
>>
>> Gr=C3=BC=C3=9Fe, Carsten
>>
>>
>> > On 2020-06-10, at 15:32, RFC Errata System <rfc-editor@rfc-editor.org<= /a>> 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
>> > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
>> > In the interests of interoperability, implementations that pa= rse JSON texts MAY ignore the presence of a byte order mark rather than tre= ating it as an error.
>> >
>> > Corrected Text
>> > --------------
>> > In the interests of interoperability, implementations that pa= rse JSON texts MAY ignore the presence of a byte order mark or MAY interpre= t 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 specifica= lly allowed alternate encodings.=C2=A0 In the context of a new, UTF-8 only = restriction, interoperability provisions should also address interpreting l= egacy formats that predate the restriction.=C2=A0 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 ver= ified or
>> > rejected. When a decision is reached, the verifying party
>> > can log in to change the status and edit the report, if neces= sary.
>> >
>> > --------------------------------------
>> > RFC8259 (draft-ietf-jsonbis-rfc7159bis-04)
>> > --------------------------------------
>> > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The JavaScript Object Notation (JSON) Data Interchange Format
>> > Publication Date=C2=A0 =C2=A0 : December 2017
>> > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: T. Bray, = Ed.
>> > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : INTERNET = STANDARD
>> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Java= script Object Notation Update
>> > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := Applications and Real-Time
>> > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF=
>> > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>> >
>> > _______________________________________________
>> > json mailing list
>> > json@ietf.= org
>> > https://www.ietf.org/mailman/listinfo/json
>>
>
>
> --
> David Golden <xdg@x= dg.me> =E2=80=A2 https://xdg.me/ =E2=80=A2 Twitter/GitHub: @xdg


--
David Golden <xdg= @xdg.me> =E2=80=A2 htt= ps://xdg.me/ =E2=80=A2 Twitter/GitHub: @xdg
--00000000000022c54a05a7bbf6ad-- From nobody Wed Jun 10 08:00:30 2020 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 18BD73A094E for ; Wed, 10 Jun 2020 08:00:19 -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 g5WCGUioF5nJ for ; Wed, 10 Jun 2020 08:00:13 -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 CF6813A08C6 for ; Wed, 10 Jun 2020 08:00:06 -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 49hqsb3mqDzyS4; Wed, 10 Jun 2020 17:00:03 +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 In-Reply-To: Date: Wed, 10 Jun 2020 17:00:03 +0200 Cc: json@ietf.org, superuser@gmail.com, tbray@textuality.com, barryleiba@computer.org, linuxwolf+ietf@outer-planes.net, RFC Errata System X-Mao-Original-Outgoing-Id: 613494003.0700999-21a8823c413b7a0c1a9fb88e72eee235 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200610133258.D4B85F4073D@rfc-editor.org> <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org> To: David Golden X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Json] Sticking to the past -- Re: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 15:00:26 -0000 Hi David, In the spirit of Barry=E2=80=99s point that this is no longer about the = Errata Report, I=E2=80=99m changing the subject. The question at hand really is whether we can ever fix mistakes in a = protocol specification. The 2006 RFC (4627) didn=E2=80=99t take benefit of the observation that = JSON is used with UTF-8 in the wild. With 7159 (2014) and 8259 (2017) = we progressively did. The question really is how much of a backward compatibility onus we = impose on implementers. The reality is that JSON works well in the Internet Standard (RFC 8259, = 2017) form, and there is no point for implementers to bow to what = wasn=E2=80=99t really the reality in 2006 anyway. So adding any verbiage that could be misused to pressure implementers to = implement the deprecated stuff would be counter-productive. Yes, it = might still be a good idea for a JSON implementers to accept BOMs (and = "JSON comments", and trailing commas, and all the other cruft that we do = to "increase interoperability" and that then hurts interoperability = because other people come to rely on that lenience (*)), but the JSON = Standard doesn=E2=80=99t have to (even mildly) encourage that. There are no standard JSON supersets (at least not ones that can be = called =E2=80=9CJSON=E2=80=9D (**)). Gr=C3=BC=C3=9Fe, Carsten (*) a.k.a. =E2=80=9Csoup=E2=80=9D (**) (CBOR diagnostic notation clearly is a JSON superset) > On 2020-06-10, at 16:37, David Golden wrote: >=20 > I agree that BOMs don't belong on JSON, but three prior RFC allowed = them. (The first one even specified how to do so.) >=20 > Given a JSON text generated under a previous specification with a = UTF-16/32 BOM, ignoring the BOM is incorrect behavior. As currently = written -- copied verbatim from the prior two RFCs when BOMs were legal = -- the only interoperability suggestion is to ignore a BOM. >=20 > My proposal does not encourage the use of BOMs or unravel the WG = consensus (which I fully support). It merely prepares implementations = for the presence of other implementations that predate the current, more = restrictive specification. >=20 > Respectfully yours, > David >=20 > On Wed, Jun 10, 2020 at 9:43 AM Carsten Bormann wrote: > The WG had pretty strong consensus that BOMs don=E2=80=99t belong on = JSON. > This =E2=80=9CMAY=E2=80=9D prepares implementations for the presence = of other implementations that do not heed that consensus. No = functionality is assigned by this MAY. >=20 > Since Errata are not intended to unravel WG decisions: Reject. >=20 > Apart from that, I seriously don=E2=80=99t understand what the = "indicate an alternate encoding=E2=80=9D would be =E2=80=94 the JSON = text already is UTF-8? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On 2020-06-10, at 15:32, RFC Errata System = wrote: > >=20 > > The following errata report has been submitted for RFC8259, > > "The JavaScript Object Notation (JSON) Data Interchange Format". > >=20 > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6208 > >=20 > > -------------------------------------- > > Type: Technical > > Reported by: David Golden > >=20 > > Section: 8.1 > >=20 > > Original Text > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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 =20 > > can log in to change the status and edit the report, if necessary.=20= > >=20 > > -------------------------------------- > > 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 > >=20 > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json >=20 >=20 >=20 > --=20 > David Golden =E2=80=A2 https://xdg.me/ =E2=80=A2 = Twitter/GitHub: @xdg > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Wed Jun 10 08:01:12 2020 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 DCC283A0400 for ; Wed, 10 Jun 2020 08:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 (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 qGwbzme-HPly for ; Wed, 10 Jun 2020 08:01:06 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 D9F803A0544 for ; Wed, 10 Jun 2020 08:01:05 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id u16so1634617lfl.8 for ; Wed, 10 Jun 2020 08:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jHMLG7MqLdTwNOV+wzddeValdlzNj/XuOkXMiUeU4Hg=; b=pkkkha/Dqmqib2Kevo1a8TiNNsWJAWXzQ3jRec4oHdg50btZMiCOWMrXEBz6/eqeqW KmoGXaj7uavBGWYZvQMRUyoKXc/Ddef/Pg0ytjV1id+G9CCJQil6DYET28UJH/GH097q UPca0g4G8gwQQ117IY7bf2NLN0kANZoMQy3Tr1tu8BjM+QEtNuDyh/rv5IYnGf0kc+4M R4VaX2nXLNtyDsOchZ0uq5DnvogOYK4LtKi/PmsvVkOADpK4R+mBDM8obVrlK/xzIRF/ GXo5dzMiFOG0my9/+0HYENuawchi0TbiPH78GK7wrioHLFv1STM79PfjU9H+nexQeY4g ea2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jHMLG7MqLdTwNOV+wzddeValdlzNj/XuOkXMiUeU4Hg=; b=cGMmpaSjr862miAbdB3udZ4J6+AVrvAUm2GrBWxFol6s6fqUEEQiAu/YEN0aRm714m tQUFa/PIqNszm1jOCl8CFOvLajbkqGpqfub3ksaJA+PBFWzEqHKPG2onWcN71NR/eLdc L/QhI2vdC0cE8kuuh6o3ZlTUqRqfDidt0I3V80q43b1xyzH2Z+XCa4qsw0A7/Ss0IJ6s wlza7FyAQ56OSYo71jzdAa8IFrYC0rBlCrFKIgG2uh7fVTYwKrD2P7xpBZpc6SJdX6C3 Kxtr2C9jIAtEaEfQv3ai1k5H8csNisLKRbFiDuxzz2K5E2oiOu3haRq/ZFx64cFtTfkF n13w== X-Gm-Message-State: AOAM533X2bfQ2ZywXKO24pamToiEhp/ydm/G6mGNnkvjdfFM6VaqyI9W sue0AwqrwNeiRdXNn6KPkOg7TAN0k2eTA/9ukSvYyQ== X-Google-Smtp-Source: ABdhPJzpLcfVpQ7ED1XKD8RKfvwfhddbER1cBEY8Qcf0GbuwC0fPn8VO7Ce0QwMxFDVy1onByldt1hdpyp45EVRZyXI= X-Received: by 2002:a19:f508:: with SMTP id j8mr1923356lfb.146.1591801262308; Wed, 10 Jun 2020 08:01:02 -0700 (PDT) MIME-Version: 1.0 References: <20200610133258.D4B85F4073D@rfc-editor.org> <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org> In-Reply-To: From: Tim Bray Date: Wed, 10 Jun 2020 08:00:51 -0700 Message-ID: To: David Golden Cc: Barry Leiba , Carsten Bormann , RFC Errata System , Murray Kucherawy , "Matthew A. Miller" , JSON WG Content-Type: multipart/alternative; boundary="000000000000cb11a205a7bc1cbe" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 15:01:11 -0000 --000000000000cb11a205a7bc1cbe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The erratum would have been more convincing had it described any plausible course of action other than rejecting or silently accepting the BOM. I can't think of anything useful that software could do. That doesn't mean there isn't anything, but a suggestion would be helpful. On Wed, Jun 10, 2020 at 7:50 AM David Golden wrote: > I understand. Would it be more appropriate then to limit the "may ignore > a BOM" to "may ignore a UTF-8 BOM" so that the interop suggestion does no= t > inadvertently encourage incorrect decoding? That would be consistent wit= h > the UTF-8 only restriction and leave legacy encoding/BOM considerations o= ut > of scope. > > I realize this may seem picky, but this stems from discussions at work > about whether/how to support legacy BOMs and people have interpreted the > RFC differently. I was hoping to create clarity consistent with the inte= nt > of the working group, whatever that turns out to be. > > David > > On Wed, Jun 10, 2020 at 10:42 AM Barry Leiba > wrote: > >> David, I understand that it might be worth having further discussion >> about the issue. The problem *here* is that there is not an error in >> the RFC: the RFC accurately reflects the consensus of the working >> group and the text that was reviewed and agreed on at the time. So >> it's not in scope for an errata report. Discussion about whether or >> not to revisit this and to publish an RFC that says something >> different is... a separate discussion. >> >> Barry, ART AD >> >> On Wed, Jun 10, 2020 at 10:38 AM David Golden wrote: >> > >> > I agree that BOMs don't belong on JSON, but three prior RFC allowed >> them. (The first one even specified how to do so.) >> > >> > Given a JSON text generated under a previous specification with a >> UTF-16/32 BOM, ignoring the BOM is incorrect behavior. As currently >> written -- copied verbatim from the prior two RFCs when BOMs were legal = -- >> the only interoperability suggestion is to ignore a BOM. >> > >> > My proposal does not encourage the use of BOMs or unravel the WG >> consensus (which I fully support). It merely prepares implementations f= or >> the presence of other implementations that predate the current, more >> restrictive specification. >> > >> > Respectfully yours, >> > David >> > >> > On Wed, Jun 10, 2020 at 9:43 AM Carsten Bormann wrote: >> >> >> >> The WG had pretty strong consensus that BOMs don=E2=80=99t belong on = JSON. >> >> This =E2=80=9CMAY=E2=80=9D 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=E2=80=99t understand what the "indic= ate an >> alternate encoding=E2=80=9D would be =E2=80=94 the JSON text already is = UTF-8? >> >> >> >> Gr=C3=BC=C3=9Fe, 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 >> >> > >> >> > Section: 8.1 >> >> > >> >> > Original Text >> >> > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >> >> > 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 i= t >> 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 interpretin= g >> 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, pleas= e >> >> > 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 >> >> >> > >> > >> > -- >> > David Golden =E2=80=A2 https://xdg.me/ =E2=80=A2 Twitter/= GitHub: @xdg >> > > > -- > David Golden =E2=80=A2 https://xdg.me/ =E2=80=A2 Twitter/Git= Hub: @xdg > --000000000000cb11a205a7bc1cbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The= erratum would have been more convincing had it described any plausible cou= rse of action other than rejecting or silently accepting=C2=A0the BOM.=C2= =A0 I can't think of anything useful=C2=A0that software could do. That = doesn't mean there isn't anything, but a suggestion would be helpfu= l.

On Wed, Jun 10, 2020 at 7:50 AM David Golden <xdg@xdg.me> wrote:
I understand.=C2=A0 Would it be= more appropriate then to limit the "may ignore a BOM" to "m= ay ignore a UTF-8 BOM" so that the interop suggestion does not inadver= tently encourage incorrect decoding?=C2=A0 That would be consistent with th= e UTF-8 only restriction and leave legacy encoding/BOM considerations out o= f scope.

I realize this may seem picky, but this s= tems from discussions at work about whether/how to support legacy BOMs and = people have interpreted the RFC differently.=C2=A0 I was hoping to create c= larity consistent with the intent of the working group, whatever that turns= out to be.

David

On Wed, Jun 10, 202= 0 at 10:42 AM Barry Leiba <barryleiba@computer.org> wrote:
David, I understand that it might be= worth having further discussion
about the issue.=C2=A0 The problem *here* is that there is not an error in<= br> the RFC: the RFC accurately reflects the consensus of the working
group and the text that was reviewed and agreed on at the time.=C2=A0 So it's not in scope for an errata report.=C2=A0 Discussion about whether = or
not to revisit this and to publish an RFC that says something
different is... a separate discussion.

Barry, ART AD

On Wed, Jun 10, 2020 at 10:38 AM David Golden <xdg@xdg.me> wrote:
>
> I agree that BOMs don't belong on JSON, but three prior RFC allowe= d them.=C2=A0 (The first one even specified how to do so.)
>
> Given a JSON text generated under a previous specification with a UTF-= 16/32 BOM, ignoring the BOM is incorrect behavior.=C2=A0 As currently writt= en -- copied verbatim from the prior two RFCs when BOMs were legal -- the o= nly interoperability suggestion is to ignore a BOM.
>
> My proposal does not encourage the use of BOMs or unravel the WG conse= nsus (which I fully support).=C2=A0 It merely prepares implementations for = the presence of other implementations that predate the current, more restri= ctive specification.
>
> Respectfully yours,
> David
>
> On Wed, Jun 10, 2020 at 9:43 AM Carsten Bormann <cabo@tzi.org> wrote:
>>
>> The WG had pretty strong consensus that BOMs don=E2=80=99t belong = on JSON.
>> This =E2=80=9CMAY=E2=80=9D prepares implementations for the presen= ce of other implementations that do not heed that consensus.=C2=A0 No funct= ionality is assigned by this MAY.
>>
>> Since Errata are not intended to unravel WG decisions: Reject.
>>
>> Apart from that, I seriously don=E2=80=99t understand what the &qu= ot;indicate an alternate encoding=E2=80=9D would be =E2=80=94 the JSON text= already is UTF-8?
>>
>> Gr=C3=BC=C3=9Fe, Carsten
>>
>>
>> > On 2020-06-10, at 15:32, RFC Errata System <rfc-editor@rfc-editor.org<= /a>> 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
>> > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
>> > In the interests of interoperability, implementations that pa= rse JSON texts MAY ignore the presence of a byte order mark rather than tre= ating it as an error.
>> >
>> > Corrected Text
>> > --------------
>> > In the interests of interoperability, implementations that pa= rse JSON texts MAY ignore the presence of a byte order mark or MAY interpre= t 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 specifica= lly allowed alternate encodings.=C2=A0 In the context of a new, UTF-8 only = restriction, interoperability provisions should also address interpreting l= egacy formats that predate the restriction.=C2=A0 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 ver= ified or
>> > rejected. When a decision is reached, the verifying party
>> > can log in to change the status and edit the report, if neces= sary.
>> >
>> > --------------------------------------
>> > RFC8259 (draft-ietf-jsonbis-rfc7159bis-04)
>> > --------------------------------------
>> > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The JavaScript Object Notation (JSON) Data Interchange Format
>> > Publication Date=C2=A0 =C2=A0 : December 2017
>> > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: T. Bray, = Ed.
>> > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : INTERNET = STANDARD
>> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Java= script Object Notation Update
>> > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := Applications and Real-Time
>> > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF=
>> > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>> >
>> > _______________________________________________
>> > json mailing list
>> > json@ietf.= org
>> > https://www.ietf.org/mailman/listinfo/json
>>
>
>
> --
> David Golden <xdg@x= dg.me> =E2=80=A2 https://xdg.me/ =E2=80=A2 Twitter/GitHub: @xdg


--
David Golden <= xdg@xdg.me> =E2=80= =A2 https://xdg.me/ =E2= =80=A2 Twitter/GitHub: @xdg
--000000000000cb11a205a7bc1cbe-- From nobody Wed Jun 10 09:03:25 2020 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 434EB3A08AA for ; Wed, 10 Jun 2020 09:03:24 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 elCDIWenL6U2 for ; Wed, 10 Jun 2020 09:03:22 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E33FC3A0916 for ; Wed, 10 Jun 2020 09:03:01 -0700 (PDT) Received: (qmail 93838 invoked from network); 10 Jun 2020 16:03:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16e83.5ee10434.k2006; i=johnl-iecc.com@submit.iecc.com; bh=27XhCf3jlCp80aoDA3A0kU3DmOonOCGK/+k9X2iFXBI=; b=bxouH2PJbaq/4/iFyVTM+5fElYFMePt0yiuOYO1eTv1Gp3bHsXqKtePRQscpLW0V9xoFMbdGyMsWrejTe4lTSOkT3ldvgrAJZn0gmb9NkfoURlX6rYWkMIOk+DrhsfsHSQW5afdmlGXh6OEibkd+hJqjYnSDvn+KrJzEn93+RtLzSkLuCIVe73Zw+GjkMAdSwxUgvRkJdVjWE2lRkrfDn3tMTI3bGxzny4Xyk8F9gUsew9VBHr8GrBJKi2Tlrf2O Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 10 Jun 2020 16:03:00 -0000 Date: 10 Jun 2020 12:03:00 -0400 Message-ID: From: "John R. Levine" To: "Carsten Bormann" , "RFC Errata System" Cc: tbray@textuality.com, superuser@gmail.com, barryleiba@computer.org, linuxwolf+ietf@outer-planes.net, xdg@xdg.me, json@ietf.org In-Reply-To: <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org> References: <20200610133258.D4B85F4073D@rfc-editor.org> <19B4CC94-8752-46AF-95A2-6BB25E480A24@tzi.org> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1876560340-1591804980=:62250" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 16:03:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1876560340-1591804980=:62250 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > Apart from that, I seriously don’t understand what the "indicate an alternate encoding” would be — the JSON text already is UTF-8? if it's a UTF-16BE BOM, quite possibly the text is encoded as UTF-16BE. But I agree we're deep into "don't do that" territory. R's, John >> On 2020-06-10, at 15:32, RFC Errata System 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 >> >> 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 > > Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly --0-1876560340-1591804980=:62250-- From nobody Wed Jun 10 09:08:54 2020 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 D21233A098E for ; 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 ; 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 ; 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 To: Carsten Bormann Cc: RFC Errata System , 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: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=E2=80=99t belong on JS= ON. > This =E2=80=9CMAY=E2=80=9D 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=E2=80=99t understand what the "indicat= e an > alternate encoding=E2=80=9D would be =E2=80=94 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 --=20