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

[Paul Hoffman <[e-mail]>]

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 <[e-mail]> 
> 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 <
>> [e-mail]> 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 <[e-mail]>
>>>
>>> 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
>>>
>>