Re: [Json] Proposed document set from this WG

[R S <[e-mail]>]

Paul Hoffman wrote:
> 1) JSON base, 4627bis
>   Target: current JSON users
>   Current: grammar, encoding, parser rules, generator rules, MIME type registration)
>   New: Internet transfer rules, list of changes from 4627

My suggestion is for the WG to target this use case only, and to treat
the JSON processing rules in ECMAScript 5, Section 15.12 (The JSON
Object) as the baseline for rules regarding encoding and decoding,
rather than RFC4627.

The motivation for this recommendation is that it's impractical to
make breaking change to this algorithm on a reasonable time scale.
But JSON RFC readers will expect to interoperate with web browsers
and other JavaScript embeddings.

The most significant delta concerns this line from RFC4627:
> A JSON parser MAY accept non-JSON forms or extensions.

ES5 parsers must raise an error when they encounter deviations from
the grammar defined in ES5:
"It is not permitted for a conforming implementation of JSON.parse to
extend the JSON grammars."

Tim Bray wrote:
> \uxxxx is only allowed for chars that must be escaped per the JSON spec
> \uxxxx is freely allowed, but the \uxxxx is considered to represent a single codepoint, and all comparison/hashing
> operations have to be conducted codepoint-by-codepoint

ES5 mandates \uxxxx for certain control characters and allows it for
all (so does RFC4627 "Any character may be escaped.").  JavaScript
strings are composed of code units. Consider JSONKit's behavior when
serializing escaped Unicode:

"When JKSerializeOptionEscapeUnicode is enabled, JSONKit will encode
Unicode code points that can be encoded as a single UTF16 code unit as
\uXXXX, and will encode Unicode code points that require UTF16
surrogate pairs as \uhigh\ulow."
<https://github.com/johnezang/JSONKit>

json ⊄ js: <https://medium.com/joys-of-javascript/42a28471221d>
> The problem comes down to two unicode characters that are considered line terminators
> in JavaScript: the line separator \u2028 and the paragraph separator \u2029.

Recommend that encoders escape these characters.

Paul Hoffman wrote:
> If we are supposed to be keeping backwards compatibility, then yes, it's too late.
> The same is true for changing SHOULD not have duplicate names in objects.

ES5 mandates behavior here:
"In the case where there are duplicate name Strings within an object,
lexically preceding values for the same key shall be overwritten."

- Rob