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

[Tim Bray <[e-mail]>]

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