From nobody Thu Feb 24 19:33:30 2022 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 C1A863A1140 for ; Thu, 24 Feb 2022 19:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=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 01vC8P9SBhGj for ; Thu, 24 Feb 2022 19:33:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ECEF3A113E for ; Thu, 24 Feb 2022 19:33:23 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 499) id ECC44289E1; Thu, 24 Feb 2022 19:33:22 -0800 (PST) To: tbray@textuality.com, superuser@gmail.com, francesca.palombini@ericsson.com, mamille2@cisco.com, paul.hoffman@vpnc.org From: RFC Errata System Cc: rfc7493-errata@chrismorgan.info, json@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20220225033322.ECC44289E1@rfc-editor.org> Date: Thu, 24 Feb 2022 19:33:22 -0800 (PST) Archived-At: Subject: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 03:33:28 -0000 The following errata report has been submitted for RFC7493, "The I-JSON Message Format". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6861 -------------------------------------- Type: Technical Reported by: Chris Morgan Section: 2.1 Original Text ------------- Object member names, and string values in arrays and object members, MUST NOT include code points that identify Surrogates or Noncharacters as defined by [UNICODE]. Corrected Text -------------- Object member names, and string values, MUST NOT include code points that identify Surrogates or Noncharacters as defined by [UNICODE]. Notes ----- The expression “string values in arrays and object members” is overly qualified, excluding cases where the *entire message* is a string value, which should clearly be covered also. So the qualification “in arrays and object members” should be removed. Supporting citations: RFC 7493, section 2: “An I-JSON message is a JSON text, as defined by RFC 7159.” RFC 7159, section 2: “A JSON text is a serialized value. Note that certain previous specifications of JSON constrained a JSON text to be an object or an array. […]” RFC 7159, section 2: JSON-text = ws value ws RFC 7159, section 3: value = false / null / true / object / array / number / string 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. -------------------------------------- RFC7493 (draft-ietf-json-i-json-06) -------------------------------------- Title : The I-JSON Message Format Publication Date : March 2015 Author(s) : T. Bray, Ed. Category : PROPOSED STANDARD Source : JavaScript Object Notation Area : Applications Stream : IETF Verifying Party : IESG From nobody Thu Feb 24 21:14:21 2022 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 725283A11E8 for ; Thu, 24 Feb 2022 21:14:18 -0800 (PST) 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.20210112.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 YyNnKgoEeK7P for ; Thu, 24 Feb 2022 21:14:13 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 824C23A11E7 for ; Thu, 24 Feb 2022 21:14:13 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id y24so7534092lfg.1 for ; Thu, 24 Feb 2022 21:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j0o1kGssxKW1gBWSjlILC8jyurcNUu1BVFolKzBRlYY=; b=2bcDz1nucNlqQf0xtwFZNI1lWte+zEqAmaguIcbd1I7Xh0pvZFlPZv2C/QgmKaS6Ht v6mO2CCr2Js/Ok+/wVHtqSY+RCKOVGSKHytSczTEFZQo2e9r7UgPD1ND7LhVbDCghIZ8 qf5xrJ89CWy7gA9lKZ4YJK4hR6DrZzHs4eI38DnDGHLC/c1mwaFQyFH+y1Lp3obzoEfr gpjvCmgK6QD0ysiC1jPwRBJiv3PWzYQdjMZR04reREgnwMqGqAqNSBN1uctMUkSIPV+U Cw/gfcXj13hKGT7aXlKuvnSC0xHW3hWZImVRicQqpGjyJOIA2vnbjosLMu0Qd2KK3TnW DK5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j0o1kGssxKW1gBWSjlILC8jyurcNUu1BVFolKzBRlYY=; b=0JUiKfKCI4x6mUIbCGLMe60PcUZGCq8mdqeJ3/B6mbW1JhO/NG5YvZ+zu6NTNjGQ+D x6wbp79hLadFJNKmuvb4g0MrsNEciZTiLQkCVYqAlYwk4+A+nh3xhlT/fdhfP9Gwf30R cnbgJNvsBo6v7GVlzzYH55qcFtwTuhnfH1RI7Gpn2ovufULXavupCEkqpXN1CpJDqZlJ +EXUruP9CwtUQYuPiSv9O+VWVq/uiu9qPG+ABQ7WCIqZs+DVWg+cOudkcfsOC0BjR/a/ H9eIryunvlS90gwPkwvdbftdt3+DCqoeyoJhZ8cAdF9U9idg++JLZarbMprJMphtp0W1 Njkw== X-Gm-Message-State: AOAM5324P/zKNRowngEadsV9oTb4kATJ+8YZJksmacyX36T2FRdtoYbN Nn+z0YoZ2iC4Yv0LmI0CnZiltXs1ndInnI1rigDasg== X-Google-Smtp-Source: ABdhPJwmPjcA7xJQBIXifSTaASL/v//zPt4104kvr6ECzbrR4GabspJIG3Lvr3BkP9KMijNbH3w6g00ipH3k65zykzo= X-Received: by 2002:ac2:46c9:0:b0:43b:b45d:56de with SMTP id p9-20020ac246c9000000b0043bb45d56demr3868383lfo.338.1645766050832; Thu, 24 Feb 2022 21:14:10 -0800 (PST) MIME-Version: 1.0 References: <20220225033322.ECC44289E1@rfc-editor.org> In-Reply-To: <20220225033322.ECC44289E1@rfc-editor.org> From: Tim Bray Date: Thu, 24 Feb 2022 21:13:59 -0800 Message-ID: To: RFC Errata System Cc: "Murray S. Kucherawy" , Francesca Palombini , "Matt Miller (mamille2)" , Paul Hoffman , rfc7493-errata@chrismorgan.info, JSON WG Content-Type: multipart/alternative; boundary="000000000000d7fee505d8d0c412" Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 05:14:19 -0000 --000000000000d7fee505d8d0c412 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm inclined to accept this one, can't disagree with the argument. On Thu, Feb 24, 2022 at 7:33 PM RFC Errata System wrote: > The following errata report has been submitted for RFC7493, > "The I-JSON Message Format". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6861 > > -------------------------------------- > Type: Technical > Reported by: Chris Morgan > > Section: 2.1 > > Original Text > ------------- > Object member names, and string values in arrays and object members, > MUST NOT include code points that identify Surrogates or > Noncharacters as defined by [UNICODE]. > > Corrected Text > -------------- > Object member names, and string values, > MUST NOT include code points that identify Surrogates or > Noncharacters as defined by [UNICODE]. > > Notes > ----- > The expression =E2=80=9Cstring values in arrays and object members=E2=80= =9D is overly > qualified, excluding cases where the *entire message* is a string value, > which should clearly be covered also. So the qualification =E2=80=9Cin ar= rays and > object members=E2=80=9D should be removed. > > Supporting citations: > > RFC 7493, section 2: =E2=80=9CAn I-JSON message is a JSON text, as define= d by RFC > 7159.=E2=80=9D > > RFC 7159, section 2: =E2=80=9CA JSON text is a serialized value. Note th= at > certain previous specifications of JSON constrained a JSON text to be an > object or an array. [=E2=80=A6]=E2=80=9D > > RFC 7159, section 2: > > JSON-text =3D ws value ws > > RFC 7159, section 3: > > value =3D false / null / true / object / array / number / string > > 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. > > -------------------------------------- > RFC7493 (draft-ietf-json-i-json-06) > -------------------------------------- > Title : The I-JSON Message Format > Publication Date : March 2015 > Author(s) : T. Bray, Ed. > Category : PROPOSED STANDARD > Source : JavaScript Object Notation > Area : Applications > Stream : IETF > Verifying Party : IESG > --000000000000d7fee505d8d0c412 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I&#= 39;m inclined to accept this one, can't disagree with the argument.

On Thu, Feb 24, 2022 at 7:33 PM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been submitted for RFC749= 3,
"The I-JSON Message Format".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6861

--------------------------------------
Type: Technical
Reported by: Chris Morgan <rfc7493-errata@chrismorgan.info>

Section: 2.1

Original Text
-------------
=C2=A0 =C2=A0Object member names, and string values in arrays and object me= mbers,
=C2=A0 =C2=A0MUST NOT include code points that identify Surrogates or
=C2=A0 =C2=A0Noncharacters as defined by [UNICODE].

Corrected Text
--------------
=C2=A0 =C2=A0Object member names, and string values,
=C2=A0 =C2=A0MUST NOT include code points that identify Surrogates or
=C2=A0 =C2=A0Noncharacters as defined by [UNICODE].

Notes
-----
The expression =E2=80=9Cstring values in arrays and object members=E2=80=9D= is overly qualified, excluding cases where the *entire message* is a strin= g value, which should clearly be covered also. So the qualification =E2=80= =9Cin arrays and object members=E2=80=9D should be removed.

Supporting citations:

RFC 7493, section 2: =E2=80=9CAn I-JSON message is a JSON text, as defined = by RFC 7159.=E2=80=9D

RFC 7159, section 2: =E2=80=9CA JSON text is a serialized value.=C2=A0 Note= that certain previous specifications of JSON constrained a JSON text to be= an object or an array. [=E2=80=A6]=E2=80=9D

RFC 7159, section 2:

=C2=A0 =C2=A0 =C2=A0 JSON-text =3D ws value ws

RFC 7159, section 3:

=C2=A0 =C2=A0 =C2=A0 value =3D false / null / true / object / array / numbe= r / string

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7493 (draft-ietf-json-i-json-06)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The I-JSON Me= ssage Format
Publication Date=C2=A0 =C2=A0 : March 2015
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 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : JavaScript Object = Notation
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Applications<= br> 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
--000000000000d7fee505d8d0c412-- From nobody Fri Feb 25 07:37:00 2022 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 D6DE13A0AA3 for ; Fri, 25 Feb 2022 07:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 PbnJuRm06jJz for ; Fri, 25 Feb 2022 07:36:50 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 CD2C23A09DB for ; Fri, 25 Feb 2022 07:36:50 -0800 (PST) Received: from [10.32.60.156] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 21PFZUQE007504 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Feb 2022 08:35:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] claimed to be [10.32.60.156] From: Paul Hoffman To: Tim Bray Cc: RFC Errata System , "Murray S. Kucherawy" , Francesca Palombini , "Matt Miller (mamille2)" , rfc7493-errata@chrismorgan.info, JSON WG Date: Fri, 25 Feb 2022 07:36:33 -0800 X-Mailer: MailMate (1.14r5798) Message-ID: In-Reply-To: References: <20220225033322.ECC44289E1@rfc-editor.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E78ED109-48BA-45DC-9903-218E9A806ACD_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"plain":[616, 2463], "uuid":"F6FF0FF5-DDB3-4175-B9FD-E5FCB30B3AF0"}] Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 15:36:58 -0000 --=_MailMate_E78ED109-48BA-45DC-9903-218E9A806ACD_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I note that accepting this erratum would be a technical change that would affect interoperability. Without this erratum, a JSON text that is a single JSON string (that is, it begins with a quotation mark) can include surrogates and noncharacters. After this erratum is accepted, such texts would be invalid. It would have been nice for us to have thought of this when we created I-JSON: I would likely have supported the idea. However, errata are not meant to make breaking technical changes to standards. Thus, I would say we need to reject the erratum. --Paul Hoffman On 24 Feb 2022, at 21:13, Tim Bray wrote: > I'm inclined to accept this one, can't disagree with the argument. > > On Thu, Feb 24, 2022 at 7:33 PM RFC Errata System > > wrote: > >> The following errata report has been submitted for RFC7493, >> "The I-JSON Message Format". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6861 >> >> -------------------------------------- >> Type: Technical >> Reported by: Chris Morgan >> >> Section: 2.1 >> >> Original Text >> ------------- >> Object member names, and string values in arrays and object >> members, >> MUST NOT include code points that identify Surrogates or >> Noncharacters as defined by [UNICODE]. >> >> Corrected Text >> -------------- >> Object member names, and string values, >> MUST NOT include code points that identify Surrogates or >> Noncharacters as defined by [UNICODE]. >> >> Notes >> ----- >> The expression “string values in arrays and object members” is >> overly >> qualified, excluding cases where the *entire message* is a string >> value, >> which should clearly be covered also. So the qualification “in >> arrays and >> object members” should be removed. >> >> Supporting citations: >> >> RFC 7493, section 2: “An I-JSON message is a JSON text, as defined >> by RFC >> 7159.” >> >> RFC 7159, section 2: “A JSON text is a serialized value. Note that >> certain previous specifications of JSON constrained a JSON text to be >> an >> object or an array. […]” >> >> RFC 7159, section 2: >> >> JSON-text = ws value ws >> >> RFC 7159, section 3: >> >> value = false / null / true / object / array / number / string >> >> 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. >> >> -------------------------------------- >> RFC7493 (draft-ietf-json-i-json-06) >> -------------------------------------- >> Title : The I-JSON Message Format >> Publication Date : March 2015 >> Author(s) : T. Bray, Ed. >> Category : PROPOSED STANDARD >> Source : JavaScript Object Notation >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >> --=_MailMate_E78ED109-48BA-45DC-9903-218E9A806ACD_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I note that accepting this erratum would be a technical ch= ange that would affect interoperability. Without this erratum, a JSON tex= t that is a single JSON string (that is, it begins with a quotation mark)= can include surrogates and noncharacters. After this erratum is accepted= , such texts would be invalid.

It would have been nice for us to have thought of this wh= en we created I-JSON: I would likely have supported the idea. However, er= rata are not meant to make breaking technical changes to standards. Thus,= I would say we need to reject the erratum.

--Paul Hoffman

On 24 Feb 2022, at 21:13, Tim Bray wrote:

I'm inclined to accept this one, can't disagree with the argum= ent.

On Thu, Feb 24, 2022 at 7:33 PM RFC Errata System <rfc-editor@rfc-editor.org> w= rote:
The following errata report has been = submitted for RFC7493,
"The I-JSON Message Format".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6861

--------------------------------------
Type: Technical
Reported by: Chris Morgan <rfc7493-errata@chrismorgan.info>

Section: 2.1

Original Text
-------------
=C2=A0 =C2=A0Object member names, and string values in arrays and object = members,
=C2=A0 =C2=A0MUST NOT include code points that identify Surrogates or
= =C2=A0 =C2=A0Noncharacters as defined by [UNICODE].

Corrected Text
--------------
=C2=A0 =C2=A0Object member names, and string values,
=C2=A0 =C2=A0MUST NOT include code points that identify Surrogates or
= =C2=A0 =C2=A0Noncharacters as defined by [UNICODE].

Notes
-----
The expression =E2=80=9Cstring values in arrays and object members=E2=80=9D= is overly qualified, excluding cases where the *entire message* is a str= ing value, which should clearly be covered also. So the qualification =E2= =80=9Cin arrays and object members=E2=80=9D should be removed.

Supporting citations:

RFC 7493, section 2: =E2=80=9CAn I-JSON message is a JSON text, as define= d by RFC 7159.=E2=80=9D

RFC 7159, section 2: =E2=80=9CA JSON text is a serialized value.=C2=A0 No= te that certain previous specifications of JSON constrained a JSON text t= o be an object or an array. [=E2=80=A6]=E2=80=9D

RFC 7159, section 2:

=C2=A0 =C2=A0 =C2=A0 JSON-text =3D ws value ws

RFC 7159, section 3:

=C2=A0 =C2=A0 =C2=A0 value =3D false / null / true / object / array / num= ber / string

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, p= lease
use "Reply All" to discuss whether it should be verified or
= rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7493 (draft-ietf-json-i-json-06)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The I-JSON = Message Format
Publication Date=C2=A0 =C2=A0 : March 2015
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 : PROPOSED STANDARD
= Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : JavaScript Objec= t Notation
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Application= s
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
--=_MailMate_E78ED109-48BA-45DC-9903-218E9A806ACD_=-- From nobody Fri Feb 25 07:48:15 2022 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 3B3F63A08FD for ; Fri, 25 Feb 2022 07:48:03 -0800 (PST) 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.20210112.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 4gQulCnE7Q4H for ; Fri, 25 Feb 2022 07:47:58 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 48E883A0C41 for ; Fri, 25 Feb 2022 07:47:58 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id v28so7930665ljv.9 for ; Fri, 25 Feb 2022 07:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H6KJ78iquBMpNS/n36GpvxpHk/FzK1ctnC+zQLOTPZ4=; b=IxmwTUEdEj/WZsvVK4M9rMgbtJeyOS1SgE8rTzfzFQQrBAUuYShxf0X3F3RMWW72rN lLY4NEaCIz01B8ISUKRucgswMgr4H7M1oMM0N+gCLh8ECehCwIhDy8lX1ATYFKwonk+j rNdjUtskuk0CZLtQbgeGFWSq3P/v2nou54bkfH7CnLjBScdip1pD8mD1SJ4pNSd9f2WP ibsmMq5SSnIO+W62aVMP0+/PKAzOAKMMOBZHYS/p2DwKcxpdUUh1T0odYjZwDc5nx9H1 ynrnf4/Ouy65SnYlV2xsgGSzNxb2r/zHWYm1saxeBuZC8rXwWvP5+xuvqWLYWxCxOVWV i6nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H6KJ78iquBMpNS/n36GpvxpHk/FzK1ctnC+zQLOTPZ4=; b=WyqE202VEghaGhmmI3aKRBT8hMUmxIYn76CyXEX4iP/HvpVgkZXhW0H4JBJ+aQ+Gn4 Ov3fenvHOnAjNmKQEKWJ3cKQhmeDJFUmy90abyMNLsq6pI78nVH3lSivIGNcuGBLZKlj Dk0cCpuWVE9HMg3S+6sTHi2LJQVqPYsnKRL9bcupKT9h6jEgdd/cuh7zrCYwKQ2Blzjq lL3HUFW1yMCo576MUgT3FEh+atABhvehxjOe7gUwGygzx0j/ycTJXLYblOyNRj9NIHXN 3o53dmhKgVbzRG4xBSh2ikC8GjJMqoVcKj81WUnCTL3DB4+P6GR8+cdvLj08zB3Qvp5B u2IQ== X-Gm-Message-State: AOAM531dpagMIJoss3V11BBpsFaGVSzCtq9L1sY5MDESVcU3WSfY48xM HRRsgwCDf2yYnfryI3WKa6x5ssNGAXdT/bxnz3X0Cw== X-Google-Smtp-Source: ABdhPJzo3v1n9T9EX7BLnjhonLwGSKcoLbr5Jwdw53nyTUhNssMJXhzWAjQ5t5yfVR49eJyry7DnWDFCzheVI7XyDq4= X-Received: by 2002:a2e:a4dc:0:b0:246:4205:98e7 with SMTP id p28-20020a2ea4dc000000b00246420598e7mr5502234ljm.55.1645804075756; Fri, 25 Feb 2022 07:47:55 -0800 (PST) MIME-Version: 1.0 References: <20220225033322.ECC44289E1@rfc-editor.org> In-Reply-To: From: Tim Bray Date: Fri, 25 Feb 2022 07:47:44 -0800 Message-ID: To: Paul Hoffman Cc: RFC Errata System , "Murray S. Kucherawy" , Francesca Palombini , "Matt Miller (mamille2)" , rfc7493-errata@chrismorgan.info, JSON WG Content-Type: multipart/alternative; boundary="0000000000004e45b405d8d99fee" Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 15:48:13 -0000 --0000000000004e45b405d8d99fee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Whereas you are correct in theory, I am nearly 100% sure that if anyone tried to interchange a JSON text consisting of a single string with an I-JSON capable parser, and that string contained broken surrogates, it would be rejected. Because every parser I have seen (and I've seen a lot) has a "readString()" routine that is used to process object members and array elements. It seems very unlikely to me that anyone would have spotted this goof in the spec and written a separate routine for this special case. Because that would be stupid. On Fri, Feb 25, 2022 at 7:36 AM Paul Hoffman wrote: > I note that accepting this erratum would be a technical change that would > affect interoperability. Without this erratum, a JSON text that is a sing= le > JSON string (that is, it begins with a quotation mark) can include > surrogates and noncharacters. After this erratum is accepted, such texts > would be invalid. > > It would have been nice for us to have thought of this when we created > I-JSON: I would likely have supported the idea. However, errata are not > meant to make breaking technical changes to standards. Thus, I would say = we > need to reject the erratum. > > --Paul Hoffman > > On 24 Feb 2022, at 21:13, Tim Bray wrote: > > I'm inclined to accept this one, can't disagree with the argument. > > On Thu, Feb 24, 2022 at 7:33 PM RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > >> The following errata report has been submitted for RFC7493, >> "The I-JSON Message Format". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6861 >> >> -------------------------------------- >> Type: Technical >> Reported by: Chris Morgan >> >> Section: 2.1 >> >> Original Text >> ------------- >> Object member names, and string values in arrays and object members, >> MUST NOT include code points that identify Surrogates or >> Noncharacters as defined by [UNICODE]. >> >> Corrected Text >> -------------- >> Object member names, and string values, >> MUST NOT include code points that identify Surrogates or >> Noncharacters as defined by [UNICODE]. >> >> Notes >> ----- >> The expression =E2=80=9Cstring values in arrays and object members=E2=80= =9D is overly >> qualified, excluding cases where the *entire message* is a string value, >> which should clearly be covered also. So the qualification =E2=80=9Cin a= rrays and >> object members=E2=80=9D should be removed. >> >> Supporting citations: >> >> RFC 7493, section 2: =E2=80=9CAn I-JSON message is a JSON text, as defin= ed by RFC >> 7159.=E2=80=9D >> >> RFC 7159, section 2: =E2=80=9CA JSON text is a serialized value. Note t= hat >> certain previous specifications of JSON constrained a JSON text to be an >> object or an array. [=E2=80=A6]=E2=80=9D >> >> RFC 7159, section 2: >> >> JSON-text =3D ws value ws >> >> RFC 7159, section 3: >> >> value =3D false / null / true / object / array / number / string >> >> 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. >> >> -------------------------------------- >> RFC7493 (draft-ietf-json-i-json-06) >> -------------------------------------- >> Title : The I-JSON Message Format >> Publication Date : March 2015 >> Author(s) : T. Bray, Ed. >> Category : PROPOSED STANDARD >> Source : JavaScript Object Notation >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >> > --0000000000004e45b405d8d99fee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Whe= reas you are correct in theory, I am nearly 100% sure that if anyone tried = to interchange a JSON text consisting of a single string with an I-JSON cap= able parser, and that string contained broken surrogates, it would be rejec= ted. Because every parser I have seen (and I've seen a lot) has a "= ;readString()" routine that is used to process object members and arra= y elements.=C2=A0 It seems very unlikely to me that anyone would have spott= ed this goof in the spec and written a separate=C2=A0routine for this speci= al case. Because=C2=A0that would be stupid.

On Fri, Feb 25, 2022 at 7:= 36 AM Paul Hoffman <paul.hoffma= n@vpnc.org> wrote:

I note that accepting this erratum would be a technical change= that would affect interoperability. Without this erratum, a JSON text that= is a single JSON string (that is, it begins with a quotation mark) can inc= lude surrogates and noncharacters. After this erratum is accepted, such tex= ts would be invalid.

It would have been nice for us to have thought of this when= we created I-JSON: I would likely have supported the idea. However, errata= are not meant to make breaking technical changes to standards. Thus, I wou= ld say we need to reject the erratum.

--Paul Hoffman

On 24 Feb 2022, at 21:13, Tim Bray wrote:

I'm inclined to accept this one, can't disagree wit= h the argument.

On Thu, Feb 24, 2022 at 7:33 PM RFC Errata System <= rfc-editor@r= fc-editor.org> wrote:
The following errata= report has been submitted for RFC7493,
"The I-JSON Message Format".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6861

--------------------------------------
Type: Technical
Reported by: Chris Morgan <rfc7493-errata@chrismorgan.info>

Section: 2.1

Original Text
-------------
=C2=A0 =C2=A0Object member names, and string values in arrays and object me= mbers,
=C2=A0 =C2=A0MUST NOT include code points that identify Surrogates or
=C2=A0 =C2=A0Noncharacters as defined by [UNICODE].

Corrected Text
--------------
=C2=A0 =C2=A0Object member names, and string values,
=C2=A0 =C2=A0MUST NOT include code points that identify Surrogates or
=C2=A0 =C2=A0Noncharacters as defined by [UNICODE].

Notes
-----
The expression =E2=80=9Cstring values in arrays and object members=E2=80=9D= is overly qualified, excluding cases where the *entire message* is a strin= g value, which should clearly be covered also. So the qualification =E2=80= =9Cin arrays and object members=E2=80=9D should be removed.

Supporting citations:

RFC 7493, section 2: =E2=80=9CAn I-JSON message is a JSON text, as defined = by RFC 7159.=E2=80=9D

RFC 7159, section 2: =E2=80=9CA JSON text is a serialized value.=C2=A0 Note= that certain previous specifications of JSON constrained a JSON text to be= an object or an array. [=E2=80=A6]=E2=80=9D

RFC 7159, section 2:

=C2=A0 =C2=A0 =C2=A0 JSON-text =3D ws value ws

RFC 7159, section 3:

=C2=A0 =C2=A0 =C2=A0 value =3D false / null / true / object / array / numbe= r / string

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7493 (draft-ietf-json-i-json-06)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The I-JSON Me= ssage Format
Publication Date=C2=A0 =C2=A0 : March 2015
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 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : JavaScript Object = Notation
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Applications<= br> 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
--0000000000004e45b405d8d99fee-- From nobody Fri Feb 25 07:56:25 2022 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 6F2AD3A0B1C for ; Fri, 25 Feb 2022 07:56:22 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 NQtYVHCazema for ; Fri, 25 Feb 2022 07:56:17 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 7D43C3A0A6D for ; Fri, 25 Feb 2022 07:56:17 -0800 (PST) Received: from [10.32.60.156] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 21PFt3s9008365 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Feb 2022 08:55:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] claimed to be [10.32.60.156] From: Paul Hoffman To: Tim Bray Cc: RFC Errata System , "Murray S. Kucherawy" , Francesca Palombini , rfc7493-errata@chrismorgan.info, JSON WG Date: Fri, 25 Feb 2022 07:56:07 -0800 X-Mailer: MailMate (1.14r5798) Message-ID: <686AEC59-F051-49A2-A953-B26831E77C3D@vpnc.org> In-Reply-To: References: <20220225033322.ECC44289E1@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 15:56:23 -0000 On 25 Feb 2022, at 7:47, Tim Bray wrote: > Whereas you are correct in theory, I am nearly 100% sure that if > anyone > tried to interchange a JSON text consisting of a single string with an > I-JSON capable parser, and that string contained broken surrogates, it > would be rejected. Because every parser I have seen (and I've seen a > lot) > has a "readString()" routine that is used to process object members > and > array elements. It seems very unlikely to me that anyone would have > spotted this goof in the spec and written a separate routine for this > special case. Because that would be stupid. I agree it would be stupid; it was also kinda stupid for us to have missed this in the creation of I-JSON. I am arguing agains the acceptance of this erratum from the standpoint of the long-established erratum rules, not from whether the proposed change is a good idea. If you feel strongly enough about this, we could revise RFC 7493 (and deal with the other open erratum), and maybe try to get it to be an STD. --Paul Hoffman > > On Fri, Feb 25, 2022 at 7:36 AM Paul Hoffman > wrote: > >> I note that accepting this erratum would be a technical change that >> would >> affect interoperability. Without this erratum, a JSON text that is a >> single >> JSON string (that is, it begins with a quotation mark) can include >> surrogates and noncharacters. After this erratum is accepted, such >> texts >> would be invalid. >> >> It would have been nice for us to have thought of this when we >> created >> I-JSON: I would likely have supported the idea. However, errata are >> not >> meant to make breaking technical changes to standards. Thus, I would >> say we >> need to reject the erratum. >> >> --Paul Hoffman >> >> On 24 Feb 2022, at 21:13, Tim Bray wrote: >> >> I'm inclined to accept this one, can't disagree with the argument. >> >> On Thu, Feb 24, 2022 at 7:33 PM RFC Errata System < >> rfc-editor@rfc-editor.org> wrote: >> >>> The following errata report has been submitted for RFC7493, >>> "The I-JSON Message Format". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid6861 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Chris Morgan >>> >>> Section: 2.1 >>> >>> Original Text >>> ------------- >>> Object member names, and string values in arrays and object >>> members, >>> MUST NOT include code points that identify Surrogates or >>> Noncharacters as defined by [UNICODE]. >>> >>> Corrected Text >>> -------------- >>> Object member names, and string values, >>> MUST NOT include code points that identify Surrogates or >>> Noncharacters as defined by [UNICODE]. >>> >>> Notes >>> ----- >>> The expression “string values in arrays and object members” is >>> overly >>> qualified, excluding cases where the *entire message* is a string >>> value, >>> which should clearly be covered also. So the qualification “in >>> arrays and >>> object members” should be removed. >>> >>> Supporting citations: >>> >>> RFC 7493, section 2: “An I-JSON message is a JSON text, as defined >>> by RFC >>> 7159.” >>> >>> RFC 7159, section 2: “A JSON text is a serialized value. Note >>> that >>> certain previous specifications of JSON constrained a JSON text to >>> be an >>> object or an array. […]” >>> >>> RFC 7159, section 2: >>> >>> JSON-text = ws value ws >>> >>> RFC 7159, section 3: >>> >>> value = false / null / true / object / array / number / string >>> >>> 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. >>> >>> -------------------------------------- >>> RFC7493 (draft-ietf-json-i-json-06) >>> -------------------------------------- >>> Title : The I-JSON Message Format >>> Publication Date : March 2015 >>> Author(s) : T. Bray, Ed. >>> Category : PROPOSED STANDARD >>> Source : JavaScript Object Notation >>> Area : Applications >>> Stream : IETF >>> Verifying Party : IESG >>> >> From rfc7493-errata@chrismorgan.info Fri Feb 25 08:07:37 2022 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 9B6A93A093B for ; Fri, 25 Feb 2022 08:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.1 X-Spam-Level: X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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=chrismorgan.info header.b=Y2k3YTs4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NE1AS/PA 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 VEqIC-pul3RR for ; Fri, 25 Feb 2022 08:07:32 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2F03A091C for ; Fri, 25 Feb 2022 08:07:32 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C34865C0192; Fri, 25 Feb 2022 11:07:31 -0500 (EST) Received: from imap42 ([10.202.2.92]) by compute4.internal (MEProxy); Fri, 25 Feb 2022 11:07:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= chrismorgan.info; h=cc:cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm2; bh=HW73AeraGsZJEvIo3BDhQ11OXV+tRKgLE7/1nyQ1muM=; b=Y2k3Y Ts4qBq/HVPElFcCm+mpnu+TVTOK3v5zxtvEo/MDcw8nzYBVGC4FpTvHI9NanAF2b jCj3BfGzkwygmdPYloNMuM3qz/RTqVlen07pDy1wR1HmC0vnbyB/t5mJMpX3UsL8 83klMHeccRJqOJp2NQGZ7RzE1WpQc9bsKRHH6amVWnm67JBQwRMCzszKN/Pc7Ywd BvyxC1o1Q4hHDhSo/Cpv3xZeZ9KhJB5loqudpDdYRI/xA1uQSjbPHKqG6s0/1l/N EvzHGfBlhzqVHFxilRl9dtoViSsIh2k8jGiuMxakQmt7bEWAHjdLJhJZO61n+NVW vZI/QzaqMmxeXQgyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=HW73AeraGsZJEvIo3BDhQ11OXV+tRKgLE7/1nyQ1m uM=; b=NE1AS/PAGDMZTeYGWG0s2+o51vh3FPsgQdFTkj8Vyo3/YxyB3PpjVl6qx bfraxRSyTNXwgGFxas0qNiIFMwapMsfjLNqcJ8fPZiwAqFLfumOrH0c6v6z1VXJA Z0nz9LmjGr7HwCVzOl6umuRJLvxq33hiemm64SJl2+tq3Gri9uE2lad3XFuDI1m1 jNoxiDJWBKP0vqikEUOeAG0WDTbd4mnMmMs/47WvUEPJlkwchAxhv/e4my4PheHU 75vVJaZoMdK5Yi8daUc2HN0OOku+mHP+2VR+eB5QUSHHExwReQb6jFfVWLZM++lH xp0YC/nWKtmohTjS6Keqh/XqyRJIA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrleeggdekhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdevhhhr ihhsucfoohhrghgrnhdfuceorhhftgejgeelfedqvghrrhgrthgrsegthhhrihhsmhhorh hgrghnrdhinhhfoheqnecuggftrfgrthhtvghrnhepjeevveduhffhjedvffehleelleeg udekjeevueeugffgieefueeukeeufeejleegnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehr fhgtjeegleefqdgvrhhrrghtrgestghhrhhishhmohhrghgrnhdrihhnfhho X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3E06B2180078; Fri, 25 Feb 2022 11:07:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997 Mime-Version: 1.0 Message-Id: In-Reply-To: <686AEC59-F051-49A2-A953-B26831E77C3D@vpnc.org> References: <20220225033322.ECC44289E1@rfc-editor.org> <686AEC59-F051-49A2-A953-B26831E77C3D@vpnc.org> Date: Sat, 26 Feb 2022 03:07:10 +1100 From: "Chris Morgan" To: "Paul Hoffman" , "Tim Bray" Cc: "RFC Errata System" , "Murray S. Kucherawy" , "Francesca Palombini" , "JSON WG" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Fri, 25 Feb 2022 08:36:45 -0800 Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 16:08:49 -0000 On Sat, 26 Feb 2022, at 2:56 AM, Paul Hoffman wrote: > I agree it would be stupid; it was also kinda stupid for us to have > missed this in the creation of I-JSON. I am arguing agains the > acceptance of this erratum from the standpoint of the long-established > erratum rules, not from whether the proposed change is a good idea. As an outsider (so after this I=E2=80=99ll say no more on the matter, de= ferring to you lot), I=E2=80=99m surprised to hear of such a strong position on = such matters. I thought the whole point of the Technical category of errata was for such cases. As the submission page says, =E2=80=9CTechnical is a= n error in the technical content (This includes changes to the usage of RFC 2119 keywords.)=E2=80=9D. This is a case where no reasonable implementer would implement the exact wording even if they grasped the error. (I=E2=80=99m= about to join those ranks via , having no intention as I implement of following the error). > If you feel strongly enough about this, we could revise RFC 7493 > (and deal with the other open erratum), and maybe try to get it to > be an STD. The other erratum is incorrect, by the way. From nobody Fri Feb 25 09:00:56 2022 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 767523A0C41 for ; Fri, 25 Feb 2022 09:00:53 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=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 la23EiOPgTDE for ; Fri, 25 Feb 2022 09:00:48 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9AEA3A12E5 for ; Fri, 25 Feb 2022 09:00:29 -0800 (PST) Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K4wy16CN7zDCby; Fri, 25 Feb 2022 18:00:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <686AEC59-F051-49A2-A953-B26831E77C3D@vpnc.org> Date: Fri, 25 Feb 2022 18:00:25 +0100 Cc: Tim Bray , rfc7493-errata@chrismorgan.info, JSON WG , "Murray S. Kucherawy" , Francesca Palombini , RFC Errata System X-Mao-Original-Outgoing-Id: 667501225.43809-0ab8b507ebe6450f7dcfbf532fed5944 Content-Transfer-Encoding: quoted-printable Message-Id: <1B1A9A76-4960-4410-A077-2F91734A54D4@tzi.org> References: <20220225033322.ECC44289E1@rfc-editor.org> <686AEC59-F051-49A2-A953-B26831E77C3D@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 17:00:54 -0000 On 2022-02-25, at 16:56, Paul Hoffman wrote: >=20 > I agree it would be stupid; it was also kinda stupid for us to have = missed this in the creation of I-JSON. I am arguing agains the = acceptance of this erratum from the standpoint of the long-established = erratum rules, not from whether the proposed change is a good idea. I=E2=80=99m not sure I understand what you mean. This is clearly a case where the English words turn out not to express = what the consensus of the WG was (*). That needs to be fixed, and the = fix is obvious to anyone skilled in the art. Gr=C3=BC=C3=9Fe, Carsten (*) I=E2=80=99m pretty sure that in the record you will find expressions = of the form =E2=80=9Clet=E2=80=99s get rid of invalid Unicode=E2=80=9D, = not of the form =E2=80=9Clet=E2=80=99s get rid of invalid Unicode except = in top-level strings=E2=80=9D. The specific phrasing used may have made = sense with RFC 4627, it doesn=E2=80=99t with 7159/8259. Exactly errata = material. Not a technical change, as the literal implementation is = obvious to an implementer to be broken, as Chris Morgan pointed out. If = something as absurd as =E2=80=9Callowed on Tuesdays=E2=80=9D is actually = meant, a specification needs to spend a few cycles on reconfirming that. From nobody Fri Feb 25 12:49:32 2022 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 71B183A03EC for ; Fri, 25 Feb 2022 12:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=PQzBrY52; dkim=pass (2048-bit key) header.d=taugh.com header.b=m8AaSVDl 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 ji3BU0FYRQ2Z for ; Fri, 25 Feb 2022 12:49:24 -0800 (PST) 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 EA00E3A0060 for ; Fri, 25 Feb 2022 12:49:23 -0800 (PST) Received: (qmail 46618 invoked from network); 25 Feb 2022 20:49:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=b617.621940d1.k2202; bh=MB3K1T1QGh+T0SctaCxWwzJCFp64kYbfEMXfvC4l86M=; b=PQzBrY52IWrlnYVHYs72C8QL//DwVirfKuM9s9VrfOrs0Qft4NS9xP4ijgAqXtJC0dWe78FKJrF0NON/V3U+EHNow/TDm5PVxLwmp9jdOiaZlVIq/jozCrEFXwk/f87KnRLRpGLGNT70hwR+HXPztMjRFWzEiyGQ71F8d2TgPj+eo+Eiq8kxqfE02D56AyhhG0RAua6XCwZlS26bLEKQpq2/Ur3YXsrCn0UAWVPrUGozbUW/f2nQkU1RRAQIM3ON2vxxbsD/5qD0mn3hoh6ZRJ6uqui9Oy0P007tFOeXSilMFhq9tu/4HQYkIANNJre6FRAezWCLwrvGbNYs4LrwzQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=b617.621940d1.k2202; bh=MB3K1T1QGh+T0SctaCxWwzJCFp64kYbfEMXfvC4l86M=; b=m8AaSVDlPbH0MVfFj+mZ/XXlrsA/jCr0asWPNiLTYtoqo23dpSiWfir5k7zxj7FZenJQQ3uWYtF4FjDgxDonYFrfbO0m0OcbTH4s/pKY2+1mNIPcBKzCo2KnF7yj5S79y7INKHGSC0RSY/UUN3Vpa9l6JrFs/QfPIjqJzGUwUb3qrh1a4JvYxgl1+4UB4Xxx7Ii3PI6eW2i0A/sAnpIk2FA04d6NQ14u7Wjcprn+QLFacFtm+HEH3BgFbG91dEPN0G+jF8ULV/PCHBgBCdn+1hKcR3RqD3+DyZHKzuSKJPlOU+DFmA+YDt68d7ti4+v0CU8Mc/qhBerH18Ggkb9jAQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 25 Feb 2022 20:49:21 -0000 Received: by ary.qy (Postfix, from userid 501) id AD30337E87AF; Fri, 25 Feb 2022 15:49:18 -0500 (EST) Date: 25 Feb 2022 15:49:18 -0500 Message-Id: <20220225204920.AD30337E87AF@ary.qy> From: "John Levine" To: json@ietf.org Cc: cabo@tzi.org In-Reply-To: <1B1A9A76-4960-4410-A077-2F91734A54D4@tzi.org> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 20:49:30 -0000 It appears that Carsten Bormann said: >On 2022-02-25, at 16:56, Paul Hoffman wrote: >> >> I agree it would be stupid; it was also kinda stupid for us to have missed this in the creation of I-JSON. I am >arguing agains the acceptance of this erratum from the standpoint of the long-established erratum rules, not from >whether the proposed change is a good idea. > >I’m not sure I understand what you mean. > >This is clearly a case where the English words turn out not to express what the consensus of the WG was (*). That >needs to be fixed, and the fix is obvious to anyone skilled in the art. We get lots of errrata that say the text in the RFC says X but that is clearly wrong, it should say Y. We approve them without any trouble. I don't see why this one is any different. I also concur with the Tim's observation about stray surrogates. In my experience, either the code catches them and returns an error, or it doesn't and it crashes. R's, John From nobody Fri Feb 25 14:33:11 2022 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 8A0C13A08C2 for ; Fri, 25 Feb 2022 14:33:04 -0800 (PST) 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 (2048-bit key) header.d=mnot.net header.b=XbgkboLb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fSlyM1Hq 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 PlMMxAoEe2Za for ; Fri, 25 Feb 2022 14:32:59 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155813A0845 for ; Fri, 25 Feb 2022 14:32:58 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 99CD95C0221; Fri, 25 Feb 2022 17:32:57 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 25 Feb 2022 17:32:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=iLwGg0813LlKKq 5ywpoj8UVYg2lQnhF1R8kl3WGLtPI=; b=XbgkboLb4tMAE0vhdvSH3aS3+AT98x QH5ysiiTCTL3rc6KtvUIURDVOGYQsoIbo4BW4SYY6E57rPxC3HOyR3hfqUOlTX/5 GKEFMiq4YGRU/JuPnIPJnfR9dbCJVWWUUbiPCh/iXi4Dtn4bD7DUL5NmXKp+AnWi /F9c26YCt8JyWzmdDRZ9VaETMy/rJbcxFzlE03BS3qYcoqhD3BQib7A+6tSgHuI/ ZiUXJLHhHv7qO3xaU5YKPfkzxvbyQkgdyp/Tz9kqMTUaqUavhIIdZlSFU8UnxQcn p6KS354K5QtblMhDD1RaHu5xNkhTXmj6fy3rXTj5vmEX6mjkCVokS+qg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=iLwGg0813LlKKq5ywpoj8UVYg2lQnhF1R8kl3WGLt PI=; b=fSlyM1Hq8Xyc/i7m56Y137MqCYdspYNsr8YU2kzmZ4taPLDdDlqLpGQ4+ nkhGNwyC9Wr2Up5UvBXbfVm2SiLHDKE77Te0SrqJ8Fo8vwwHFiAzgMnKC58gS1L+ ekuwWOcidmFahwHxwcFTCeeMAdkm0f4gwvdKPfcMo4t2Cf4tunf9k3n4zVMdlqGk HjEM4M2HOINGRfp+XhXjgYCQQvcvGewB23gmoqXPbp+mYhGg28Us379T7gxxNhQ7 qcaMyyJSFELim3Y+XHEYI6vOtfy6GYFp7S94+BDak1NcFYbAy8LETw81BeH+x8Kt o/AfL1mtMFWNqdA99cPGOjXiFzb0Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrleeggdduiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeefgedvgfejgedvteeuudekveefhfehleeiveejjeekhfffheekjeeikeejtdeh jeenucffohhmrghinhepihgvthhfrdhorhhgpdhmnhhothdrnhgvthenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhn vght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 25 Feb 2022 17:32:55 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: Mark Nottingham In-Reply-To: <20220225204920.AD30337E87AF@ary.qy> Date: Sat, 26 Feb 2022 09:32:52 +1100 Cc: json@ietf.org, cabo@tzi.org Content-Transfer-Encoding: quoted-printable Message-Id: <798F8823-738D-4DC5-AD81-A21630C3A330@mnot.net> References: <20220225204920.AD30337E87AF@ary.qy> To: John Levine X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 22:33:08 -0000 Agreed - they're not rules so much as guidelines.=20 We should check with TC39, of course. > On 26 Feb 2022, at 7:49 am, John Levine wrote: >=20 > It appears that Carsten Bormann said: >> On 2022-02-25, at 16:56, Paul Hoffman wrote: >>>=20 >>> I agree it would be stupid; it was also kinda stupid for us to have = missed this in the creation of I-JSON. I am >> arguing agains the acceptance of this erratum from the standpoint of = the long-established erratum rules, not from >> whether the proposed change is a good idea. >>=20 >> I=E2=80=99m not sure I understand what you mean. >>=20 >> This is clearly a case where the English words turn out not to = express what the consensus of the WG was (*). That >> needs to be fixed, and the fix is obvious to anyone skilled in the = art. >=20 > We get lots of errrata that say the text in the RFC says X but that is > clearly wrong, it should say Y. We approve them without any trouble. I > don't see why this one is any different. >=20 > I also concur with the Tim's observation about stray surrogates. In my > experience, either the code catches them and returns an error, or it > doesn't and it crashes. >=20 > R's, > John >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham https://www.mnot.net/ From nobody Fri Feb 25 14:59:23 2022 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 58AF73A08C1 for ; Fri, 25 Feb 2022 14:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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=gmail.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 npIGKLf0XsLe for ; Fri, 25 Feb 2022 14:59:14 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 B8EE23A08BD for ; Fri, 25 Feb 2022 14:59:13 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id d17so6501851wrc.9 for ; Fri, 25 Feb 2022 14:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J7Pe1Zf/fHnBKOBnUblyLsDBWmTyEwNEn92cjdwIhwU=; b=XGvGDxP4HURd3mYlXc8q2HG73p/AR/BRCfuFRhOe0WtVr97HIiFlLGR2Fp4HYXWKVG 8Nxh5gk85yIKtqObVtlUWUcZfvprBK4wpPjtfLWRMo1MFd3//ha5uKMdYyhGyGmcwupx bGHVhH56GAbQ+dgcnD/WEm4GIehUbKaWkg/0nLYjPPRypV0JGGjIFzDe7GH9otQQDSDN lGtP3aUZ9ZfX84Y9PxA8+4C5lSwK15Yf0bH2IKIefsJzwjHUnE79Lf0hvUC5EUGz85N5 B4P/pNS2i2o7hL2kJp9Nhm70KWdIFcvuLWuDbSBkUmJFQTPa7NNPdjFvTGs3A+ekxMvs GiJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J7Pe1Zf/fHnBKOBnUblyLsDBWmTyEwNEn92cjdwIhwU=; b=eLNwFdkV45pKHq61IvPSrSeaJGZDeRCSrxC+37uZGjZDO0QJ1UsFJfwfvyPZB3Rdru V1eTjvIEiE1qQGEacis34sOqzVUzi53CHCJh1Qt4LjVhPiZgfdpkdX+8QhKp1w0peUCI NMuh1oOtDlsk7EgfXOstuJyfLV4Vg3PRuBLTvE6V7nsDh94U0mgfZwTGuA/jm7p503PS IbZgcHRUJH3r3CoogJlD2JeSRGiqElavmOYjXSOMgEPZRT7491K3zUp4D0+S3U6kJ4DH kN7RjKojRa+TypSwZmBro0SlwY+fxqneYXsZNUMM+AiU4QrfxX+sNz+vUlXQ2z/+sGgD 6Uuw== X-Gm-Message-State: AOAM53349SCjat2dmcUc3A87lTPdceQiHCQMcSM8EGZ11MPAuydjl+49 ZiIBYpdIrEVROIjnWgxsXtKiu0yN2lsBjUsi+gXFhXEr X-Google-Smtp-Source: ABdhPJwA0zXapI3LUc02K0SA12J+IpE243M6vkBF9m9D05KuINAns9sAFon7l9K+tljWU/l3/M5cm4/7rOX7sJwrs5Y= X-Received: by 2002:adf:d1e9:0:b0:1ea:7fc0:6625 with SMTP id g9-20020adfd1e9000000b001ea7fc06625mr7372353wrd.152.1645829951456; Fri, 25 Feb 2022 14:59:11 -0800 (PST) MIME-Version: 1.0 References: <20220225204920.AD30337E87AF@ary.qy> <798F8823-738D-4DC5-AD81-A21630C3A330@mnot.net> In-Reply-To: <798F8823-738D-4DC5-AD81-A21630C3A330@mnot.net> From: Rob Sayre Date: Fri, 25 Feb 2022 14:59:00 -0800 Message-ID: To: Mark Nottingham Cc: John Levine , Carsten Bormann , JSON WG Content-Type: multipart/alternative; boundary="0000000000009e091805d8dfa592" Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 22:59:21 -0000 --0000000000009e091805d8dfa592 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, everything accepts them, unless they are really strict I-JSON ones, but I haven't seen many of these. Nothing crashes. This is not worth working on, imho. There's an understandable mistake here, since top-level primitives were added late in the game, but it doesn't matter. thanks, Rob On Fri, Feb 25, 2022 at 2:33 PM Mark Nottingham wrote: > Agreed - they're not rules so much as guidelines. > > We should check with TC39, of course. > > > > On 26 Feb 2022, at 7:49 am, John Levine wrote: > > > > It appears that Carsten Bormann said: > >> On 2022-02-25, at 16:56, Paul Hoffman wrote: > >>> > >>> I agree it would be stupid; it was also kinda stupid for us to have > missed this in the creation of I-JSON. I am > >> arguing agains the acceptance of this erratum from the standpoint of > the long-established erratum rules, not from > >> whether the proposed change is a good idea. > >> > >> I=E2=80=99m not sure I understand what you mean. > >> > >> This is clearly a case where the English words turn out not to express > what the consensus of the WG was (*). That > >> needs to be fixed, and the fix is obvious to anyone skilled in the art= . > > > > We get lots of errrata that say the text in the RFC says X but that is > > clearly wrong, it should say Y. We approve them without any trouble. I > > don't see why this one is any different. > > > > I also concur with the Tim's observation about stray surrogates. In my > > experience, either the code catches them and returns an error, or it > > doesn't and it crashes. > > > > R's, > > John > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --0000000000009e091805d8dfa592 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, everything accepts them, unless they are really strict= I-JSON ones, but I haven't seen many of these. Nothing crashes. This i= s not worth working on, imho.

There's an understanda= ble mistake here, since top-level primitives were added late in the game, b= ut it doesn't matter.

thanks,
Rob


On Fri, Feb 25, 2022 at 2:33 PM Mark Nottingham <mnot@mnot.net> wrote:
Agreed - they're not rules so = much as guidelines.

We should check with TC39, of course.


> On 26 Feb 2022, at 7:49 am, John Levine <johnl@taugh.com> wrote:
>
> It appears that Carsten Bormann=C2=A0 <cabo@tzi.org> said:
>> On 2022-02-25, at 16:56, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>>
>>> I agree it would be stupid; it was also kinda stupid for us to= have missed this in the creation of I-JSON. I am
>> arguing agains the acceptance of this erratum from the standpoint = of the long-established erratum rules, not from
>> whether the proposed change is a good idea.
>>
>> I=E2=80=99m not sure I understand what you mean.
>>
>> This is clearly a case where the English words turn out not to exp= ress what the consensus of the WG was (*).=C2=A0 That
>> needs to be fixed, and the fix is obvious to anyone skilled in the= art.
>
> We get lots of errrata that say the text in the RFC says X but that is=
> clearly wrong, it should say Y. We approve them without any trouble. I=
> don't see why this one is any different.
>
> I also concur with the Tim's observation about stray surrogates. I= n my
> experience, either the code catches them and returns an error, or it > doesn't and it crashes.
>
> R's,
> John
>
> _______________________________________________
> json mailing list
> json@ietf.org > https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--0000000000009e091805d8dfa592-- From nobody Fri Feb 25 15:23:48 2022 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 50C4A3A0A9A for ; Fri, 25 Feb 2022 15:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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=gmail.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 Ze0UyZr2s4Yl for ; Fri, 25 Feb 2022 15:23:40 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 B90C63A0AA3 for ; Fri, 25 Feb 2022 15:23:39 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id b5so6636814wrr.2 for ; Fri, 25 Feb 2022 15:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8AORVa3mQxCigA12nW9Wvi4l4Eulcc/0Q14ACtAr9Zg=; b=BHA4Ip1PV+cdx/4oo2aCKQ/mPseFzCmepirSfg3Bkvwv3ddQBzNGyn2gmIXDkr9oL2 MOuJTApjtAzi/hynWkVMDrhik1oGVfMLaK2r9j1NDor6RgC5m3uAOpvQpY7qsKRbAAbG hpAAoeJ2cDPvnFUUxsyJ1UESFAhJTVwRk9iDg+sE9bJVBJL1BWta3i5IkRXxRzAB9L01 yErblhgAebwlPAFyCYIQmssT3kOjzLZ4qA+VxFcUcgfUUhTVxQZBkuY4jSiR+/AWZqdS kn+vQZOEhALiTpyeCduS6x5dPXVvU1+imdW3h5Ppf+36wc4JikmsKhQZRlSeDAQGth6j OzGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8AORVa3mQxCigA12nW9Wvi4l4Eulcc/0Q14ACtAr9Zg=; b=d56VmlwndeGPCXQn19R1mTggLpRBuHnLs1VXZPXH9VmBrk6+tCwOhvLIu4G8tJhXpj OAkfb/4vDSQn/I7gv+Y3aM3kFgwd8OXxSqphwaNSHh8odof5khcis0FVjD+yfyqzcNOr Jj+UX1T5xvyCIsPw8x4r9QFFL9BtNyWf984YAbDuCkl/H7i6r+VprKJAkH82b3URp32J 5oDpUc99un/U9DJ+7F+Bo9m9iAD/uO/C690KUY/HzpILZpgX6H7+WNp87U7rbU9QvirQ 04f56XRQPcnjkArBFx2ZxUXeiAS2Ln1FXz6JL3QWTubyQz8YIeLQ0M/eRvaWehKIDMC/ 0yHA== X-Gm-Message-State: AOAM531zYsFHbZ83GxfWaz7uW4uYUlaHQNm0rTyqVMd8c6NKDM7PJ4OT 84hrBqbDQBwNoKAdts7t81zuL+JniZJcYV9ZbXM= X-Google-Smtp-Source: ABdhPJzEQvx0OgjOg+6tSnUjF2J2SWhc2jNF9Vg+ftymEM8t0Ky3jCfZrklYA6i8QkjJNmZTSD0ErNqEWVbpy+UyBLM= X-Received: by 2002:adf:9106:0:b0:1e3:c02a:f4af with SMTP id j6-20020adf9106000000b001e3c02af4afmr7905000wrj.150.1645831417648; Fri, 25 Feb 2022 15:23:37 -0800 (PST) MIME-Version: 1.0 References: <20220225204920.AD30337E87AF@ary.qy> <798F8823-738D-4DC5-AD81-A21630C3A330@mnot.net> In-Reply-To: From: Rob Sayre Date: Fri, 25 Feb 2022 15:23:26 -0800 Message-ID: To: Mark Nottingham Cc: John Levine , Carsten Bormann , JSON WG Content-Type: multipart/alternative; boundary="000000000000025bf205d8dffddb" Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 23:23:46 -0000 --000000000000025bf205d8dffddb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To clarify, since someone asked: There were many deployed JSON parsers by the time it entered standardization both in the IETF and TC39. Originally, it only allowed "{" and "[" as the leading characters. People found this inconvenient, and it was noted that the primitives could be unambiguously expressed without a surrounding data structure, while preserving compatibility with the "eval()" functions in many languages. There was wide agreement, and everyone rearranged their parser state machines. I sincerely doubt anyone has ever written separate Unicode routines for the case the errata mentions. I'd accept the errata but do no further work. thanks, Rob On Fri, Feb 25, 2022 at 2:59 PM Rob Sayre wrote: > No, everything accepts them, unless they are really strict I-JSON ones, > but I haven't seen many of these. Nothing crashes. This is not worth > working on, imho. > > There's an understandable mistake here, since top-level primitives were > added late in the game, but it doesn't matter. > > thanks, > Rob > > > On Fri, Feb 25, 2022 at 2:33 PM Mark Nottingham wrote: > >> Agreed - they're not rules so much as guidelines. >> >> We should check with TC39, of course. >> >> >> > On 26 Feb 2022, at 7:49 am, John Levine wrote: >> > >> > It appears that Carsten Bormann said: >> >> On 2022-02-25, at 16:56, Paul Hoffman wrote: >> >>> >> >>> I agree it would be stupid; it was also kinda stupid for us to have >> missed this in the creation of I-JSON. I am >> >> arguing agains the acceptance of this erratum from the standpoint of >> the long-established erratum rules, not from >> >> whether the proposed change is a good idea. >> >> >> >> I=E2=80=99m not sure I understand what you mean. >> >> >> >> This is clearly a case where the English words turn out not to expres= s >> what the consensus of the WG was (*). That >> >> needs to be fixed, and the fix is obvious to anyone skilled in the ar= t. >> > >> > We get lots of errrata that say the text in the RFC says X but that is >> > clearly wrong, it should say Y. We approve them without any trouble. I >> > don't see why this one is any different. >> > >> > I also concur with the Tim's observation about stray surrogates. In my >> > experience, either the code catches them and returns an error, or it >> > doesn't and it crashes. >> > >> > R's, >> > John >> > >> > _______________________________________________ >> > json mailing list >> > json@ietf.org >> > https://www.ietf.org/mailman/listinfo/json >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > --000000000000025bf205d8dffddb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To clarify, since someone asked:

There = were many deployed JSON parsers by the time it entered standardization both= in the IETF and TC39. Originally, it only allowed "{" and "= [" as the leading characters. People found this inconvenient, and it w= as noted that the primitives could be unambiguously expressed without a sur= rounding data structure, while preserving compatibility with the "eval= ()" functions in many languages.

There was wi= de agreement, and everyone rearranged their parser state machines. I sincer= ely doubt anyone has ever written separate Unicode routines for the case th= e errata mentions. I'd accept the errata but do no further work.
<= div>
thanks,
Rob


On Fri, Feb 25= , 2022 at 2:59 PM Rob Sayre <sayrer@= gmail.com> wrote:
No, everything accepts them, unless they are re= ally strict I-JSON ones, but I haven't seen many of these. Nothing cras= hes. This is not worth working on, imho.

There's an = understandable mistake here, since top-level primitives were added late in = the game, but it doesn't matter.

thanks,
=
Rob


On Fri, Feb 25, 2022 at 2:33 PM Mark Nottingh= am <mnot@mnot.net= > wrote:
Agre= ed - they're not rules so much as guidelines.

We should check with TC39, of course.


> On 26 Feb 2022, at 7:49 am, John Levine <johnl@taugh.com> wrote:
>
> It appears that Carsten Bormann=C2=A0 <cabo@tzi.org> said:
>> On 2022-02-25, at 16:56, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>>
>>> I agree it would be stupid; it was also kinda stupid for us to= have missed this in the creation of I-JSON. I am
>> arguing agains the acceptance of this erratum from the standpoint = of the long-established erratum rules, not from
>> whether the proposed change is a good idea.
>>
>> I=E2=80=99m not sure I understand what you mean.
>>
>> This is clearly a case where the English words turn out not to exp= ress what the consensus of the WG was (*).=C2=A0 That
>> needs to be fixed, and the fix is obvious to anyone skilled in the= art.
>
> We get lots of errrata that say the text in the RFC says X but that is=
> clearly wrong, it should say Y. We approve them without any trouble. I=
> don't see why this one is any different.
>
> I also concur with the Tim's observation about stray surrogates. I= n my
> experience, either the code catches them and returns an error, or it > doesn't and it crashes.
>
> R's,
> John
>
> _______________________________________________
> json mailing list
> json@ietf.org > https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--000000000000025bf205d8dffddb-- From nobody Fri Feb 25 15:24:51 2022 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 3EA733A0B02 for ; Fri, 25 Feb 2022 15:24:38 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OEYskI6Kxic for ; Fri, 25 Feb 2022 15:24:33 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080EB3A0AA3 for ; Fri, 25 Feb 2022 15:24:32 -0800 (PST) Received: from smtpclient.apple (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K55TB31TMzDCbY; Sat, 26 Feb 2022 00:24:30 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_5A6450C6-154E-4A43-A108-9C95E6F6F921" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) From: Carsten Bormann In-Reply-To: Date: Sat, 26 Feb 2022 00:24:29 +0100 Cc: Mark Nottingham , "John R. Levine" , JSON WG Message-Id: References: <20220225204920.AD30337E87AF@ary.qy> <798F8823-738D-4DC5-AD81-A21630C3A330@mnot.net> To: Rob Sayre X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 23:24:40 -0000 --Apple-Mail=_5A6450C6-154E-4A43-A108-9C95E6F6F921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 26. Feb 2022, at 00:23, Rob Sayre wrote: >=20 > I'd accept the errata but do no further work. This. Gr=C3=BC=C3=9Fe, Carsten --Apple-Mail=_5A6450C6-154E-4A43-A108-9C95E6F6F921 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 26. Feb 2022, at 00:23, Rob Sayre <sayrer@gmail.com> wrote:

 I'd accept the errata but = do no further work.

This.

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


= --Apple-Mail=_5A6450C6-154E-4A43-A108-9C95E6F6F921-- From nobody Fri Feb 25 15:27:12 2022 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 637C13A0B02 for ; Fri, 25 Feb 2022 15:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=mnot.net header.b=uuv6x9Mn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FjKDy/bk 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 rnwShEYVuqkb for ; Fri, 25 Feb 2022 15:27:05 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7900E3A0AFE for ; Fri, 25 Feb 2022 15:27:05 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B8FC15C0210; Fri, 25 Feb 2022 18:27:04 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 25 Feb 2022 18:27:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=yXN47Lt7Pjtk7b MIjgRsvWgLHlBpav8BRYEtNLFC8No=; b=uuv6x9MnJaqoH863BwLPHsDweRkS0W F6r4YarPpAV5aXl/vMiAWuWz0j4FrJcYwfOdEzOCKB4Ilaqsvze7Tz3Aia1QeSi0 1osV2T3dXDG3LbKbzf3mEnuxWQJxpiRqrF7E3zuEfOFPjtIbCqDqpW+qkc3KfXv8 YQLHNRkUr1LDX45AA0DFT2yBr/CZpIVLtMyKOujzNLTkB9jo3JnWHw7Ygar8Sy20 md1PxKmTcgS7TCTAJFRFLsySvz4Vh0qFpe6WK6p7+C/MMjlsIGDrFEjTJ/XbeZFz eaMzfx3RFRyHABFoQT9PuOUdFhyCrzZx0QfzIzSxPd2w7MVQiBTfyNWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=yXN47Lt7Pjtk7bMIjgRsvWgLHlBpav8BRYEtNLFC8 No=; b=FjKDy/bkkym93TcavjzPT4li5Pebq8/UtmApbk1K+xHLlCPXbTl1XM3u4 Mw+UOvcXTSUu4uSj191jQeiRhxFW531GWpyTDX6bH/QxZ/Nm/78xe8r5AtQIRBTu DFWAAf9YLgRmZ56c49MR//C2jZvhOZtmohSMABlckUYKyvrUPuH3zjyO47NnR+De EUF9qjC5ZCY1PNlvlC7gVoLKQxam0kGjpafMrS0UcXatkkNDWWh3XQO2taNoMpsb G7qVxSY33bOXHYrLtPEmA+5QgznpQspmEiFS/wRpB2nnbQh7huJ1UTHK+rtI6fOg 1A+M2IW3EkkO5j1EX/2I3ArdEhrxA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrleehgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtgffhggfufffkfhgjvffosegrjehmrehhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeeijeevheeluddvjedujeefuddulefhgeehteeuledtkeeludeuffehgfefgfev necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnoh htsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 25 Feb 2022 18:27:03 -0500 (EST) Content-Type: multipart/alternative; boundary=Apple-Mail-DA791182-B6DC-455C-9CD3-9EB6F6A750B0 Content-Transfer-Encoding: 7bit From: Mark Nottingham Mime-Version: 1.0 (1.0) Date: Sat, 26 Feb 2022 10:26:59 +1100 Message-Id: References: Cc: Rob Sayre , "John R. Levine" , JSON WG In-Reply-To: To: Carsten Bormann X-Mailer: iPhone Mail (19D52) Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 23:27:11 -0000 --Apple-Mail-DA791182-B6DC-455C-9CD3-9EB6F6A750B0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This.=20 Sent from my iPhone > On 26 Feb 2022, at 10:24 am, Carsten Bormann wrote: >=20 > =EF=BB=BFOn 26. Feb 2022, at 00:23, Rob Sayre wrote: >>=20 >> I'd accept the errata but do no further work. >=20 > This. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 --Apple-Mail-DA791182-B6DC-455C-9CD3-9EB6F6A750B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable This. 

Sent fr= om my iPhone

On 26 Feb 2= 022, at 10:24 am, Carsten Bormann <cabo@tzi.org> wrote:

=EF=BB=BFOn 26. Feb 2022= , at 00:23, Rob Sayre <say= rer@gmail.com> wrote:

 I'd accept the errata but do no further w= ork.

This.

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


= --Apple-Mail-DA791182-B6DC-455C-9CD3-9EB6F6A750B0-- From nobody Fri Feb 25 15:33:10 2022 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 6C8F83A0B3D for ; Fri, 25 Feb 2022 15:33:00 -0800 (PST) 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.20210112.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 gXTESIYdTXmo for ; Fri, 25 Feb 2022 15:32:56 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 D33B63A0921 for ; Fri, 25 Feb 2022 15:32:55 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id u11so9433148lju.4 for ; Fri, 25 Feb 2022 15:32:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VXVnwYgsYDSKYiEXQBn5KEmVvmzymOdvNDK0PDYspN8=; b=R5Xnybsxaa1ibByTS69jq0CqQhs6yyHtahyENsYJ0dBEMyj/StKo7J3FF3zhj5bD+N 3JzYKTvTkaIEtqDzsPOKa0NVzZEb34dHiiLUi75XDWhnDC3aW/b+bFWPdxz7ynlcrgTn 20Sb0y3cS+mCbXPJuWX68Ro1bXMfpBus7LPz0h+OIJQKKZMU0pRvuYaBJMt3pMMn5rsI i3PwvqcEEQLzEik4p638FF37Y41j2nSYnMIbCmkd5rAf23bJnlVXhP6ElaK4QIpDm7OF wptqUZlnWn4O2LARbS4wcA+c0+Y8LanAdW0l7KhYUjh/d/44KdPB8fWgG8m2iDX/+rs8 akVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VXVnwYgsYDSKYiEXQBn5KEmVvmzymOdvNDK0PDYspN8=; b=tmUE1/Kdz8Xo0CGy3e6GdFPDIHFy2KtbnyyHOUKPWS+7a4eXSb9BhAS57rwim9wsZq ziGBcS4qsw8wXvbGEjx+w6K66pQsYIqFZp5GmKyfr3U3Lcny1gv9RzMLwJKq7/SndpTW YXzab9Kq6Qw5F3OGIbzdbBAxKbltOPxNOlW0KT2aW3tGHbBXFc3i1iMOBImBdrSLFHax Fv2Kg+6oTwJUuEhbmK214xvNyY0FsByNF643XLC2bgLNOAANyaG5CyAf/TY/ghFwnpT7 N2WSoBc9a73x7IV/vPUCqWic4Ov6sv/qTCUr4apmXwil7F/2repSumxXRZWQvl+uly+K 1BaA== X-Gm-Message-State: AOAM533+wy3M88KEaYGjslbSBfIsupF02v0WDwf/OYEJ7ycdAJyo0hGH zl402Os6ha4NoKlI6E/WY4hoe8pE83d9bY8oQmGpYg== X-Google-Smtp-Source: ABdhPJyt1+E/izHuoQX79p17CWUX/hmFOS98kOmQdkeAt3oGptaN5qBVP9IKro/caylGXWLPJO80A5NOIqOWAOF/njA= X-Received: by 2002:a05:651c:10b:b0:246:280:c7 with SMTP id a11-20020a05651c010b00b00246028000c7mr6751412ljb.126.1645831973602; Fri, 25 Feb 2022 15:32:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Fri, 25 Feb 2022 15:32:42 -0800 Message-ID: To: Mark Nottingham Cc: Carsten Bormann , JSON WG , "John R. Levine" , Rob Sayre Content-Type: multipart/alternative; boundary="00000000000025a37905d8e01e5d" Archived-At: Subject: Re: [Json] [Technical Errata Reported] RFC7493 (6861) 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: Fri, 25 Feb 2022 23:33:08 -0000 --00000000000025a37905d8e01e5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wouldn=E2=80=99t because of grammar pedantry, but I=E2=80=99d accept the = erratum. On Fri, Feb 25, 2022 at 3:27 PM Mark Nottingham wrote: > This. > > Sent from my iPhone > > On 26 Feb 2022, at 10:24 am, Carsten Bormann wrote: > > =EF=BB=BFOn 26. Feb 2022, at 00:23, Rob Sayre wrote: > > > I'd accept the errata but do no further work. > > > This. > > Gr=C3=BC=C3=9Fe, Carsten > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --00000000000025a37905d8e01e5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I w= ouldn=E2=80=99t because of grammar pedantry, but I=E2=80=99d accept the err= atum.

On Fri, Feb 25, 2022 at 3:27 PM Mark Nottingham <mnot@mnot.net> wrote:
This.=C2=A0

Sent from my iPhone<= /div>

On 26 Feb 2022, at 10:2= 4 am, Carsten Bormann <cabo@tzi.org> wrote:

=EF=BB=BFOn 26. Feb 2022, at 00:23, Rob Sayre <sayrer@gmail.com>= ; wrote:

=C2=A0I'd accept the errata but do no further work.

This.

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


___= ____________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--00000000000025a37905d8e01e5d--