Subject: [Json] [Technical Errata Reported] RFC7493 (6861)

From: RFC Errata System <[email-masked]>
Date: Thu, 24 Feb 2022 19:33:22 -0800 (PST)

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 <[email-masked]>

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: Tim Bray <[email-masked]>
Date: Thu, 24 Feb 2022 21:13:59 -0800

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 <[email-masked]>
wrote:

> 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 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:
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 Feb 2022 07:36:33 -0800

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:

>> RFC 7493, section 2: “An I-JSON message is a JSON text, as defined 
>> by RFC
>> 7159.”
>>

---

From: Tim Bray <[email-masked]>
Date: Fri, 25 Feb 2022 07:47:44 -0800

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 <[email-masked]> 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.
>
> meant to make breaking technical changes to standards. Thus, I would say we
> need to reject the erratum.
>
> --Paul Hoffman
>
> On Thu, Feb 24, 2022 at 7:33 PM RFC Errata System <
> [email-masked]> wrote:
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 Feb 2022 07:56:07 -0800

> 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

>> would

---

From: "Chris Morgan" <[email-masked]>
Date: Sat, 26 Feb 2022 03:07:10 +1100

> erratum rules, not from whether the proposed change is a good idea.
As an outsider (so after this I’ll say no more on the matter, deferring
to you lot), I’m 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, “Technical is an error
in the technical content (This includes changes to the usage of RFC 2119
keywords.)”. This is a case where no reasonable implementer would
implement the exact wording even if they grasped the error. (I’m about
to join those ranks via <https://github.com/serde-rs/json/issues/862>,
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: Carsten Bormann <[email-masked]>
Date: Fri, 25 Feb 2022 18:00:25 +0100

On 2022-02-25, at 16:56, Paul Hoffman <[email-masked]> 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.

Grüße, Carsten

(*) I’m pretty sure that in the record you will find expressions of the form “let’s get rid of invalid Unicode”, not of the form “let’s get rid of invalid Unicode except in top-level strings”.  The specific phrasing used may have made sense with RFC 4627, it doesn’t 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 “allowed on Tuesdays” is actually meant, a specification needs to spend a few cycles on reconfirming that.

---

From: "John Levine" <[email-masked]>
Date: 25 Feb 2022 15:49:18 -0500

It appears that Carsten Bormann  <[email-masked]> said:
>> 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.
>
>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: Mark Nottingham <[email-masked]>
Date: Sat, 26 Feb 2022 09:32:52 +1100

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 <[email-masked]> wrote:
> 
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham   https://www.mnot.net/

---

From: Rob Sayre <[email-masked]>
Date: Fri, 25 Feb 2022 14:59:00 -0800

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 <[email-masked]> wrote:

> 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
> >> This is clearly a case where the English words turn out not to express
> what the consensus of the WG was (*).  That

---

From: Rob Sayre <[email-masked]>
Date: Fri, 25 Feb 2022 15:23:26 -0800

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 <[email-masked]> 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.
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 26 Feb 2022 00:24:29 +0100

On 26. Feb 2022, at 00:23, Rob Sayre <[email-masked]> wrote:
> 
>  I'd accept the errata but do no further work.

This.

Grüße, Carsten

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 26 Feb 2022 10:26:59 +1100

This. 

Sent from my iPhone

> On 26 Feb 2022, at 10:24 am, Carsten Bormann <[email-masked]> wrote:
>

---

From: Tim Bray <[email-masked]>
Date: Fri, 25 Feb 2022 15:32:42 -0800

I wouldn’t because of grammar pedantry, but I’d accept the erratum.