Re: [Json] Proposed document set from this WG

R S <> Wed, 20 February 2013 06:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D5EC21F8949 for <>; Tue, 19 Feb 2013 22:41:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XcjYWo02CqH6 for <>; Tue, 19 Feb 2013 22:41:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CCBF121F8947 for <>; Tue, 19 Feb 2013 22:41:27 -0800 (PST)
Received: by with SMTP id o1so5767341wic.17 for <>; Tue, 19 Feb 2013 22:41:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=nrm74NBYA3j38Qr9QaVUfIrZoQcKZQtCthm36l6Bf8g=; b=Y7KeOToJNZoVyKqpporPBuuJAWlC7qJfC8SQuK3+iwKW0ehASEOpQu9j8NndwvEstW HsEn7coaR4gSbNvCNFtvbhsZ/HGrNQxgha3Ovq/arIu1IcEJXcosKxR4ely7eeZchFLt wARFxgT/Kz3mL1bMdR+Wpmf5KLGBGVVyr1DDHK5eYHIgYgg8o346msPJWRPA9QPiMKhI Ub1LwmaXVsHFL8u+r6hx3tun5wkDgo8VEqJkNJOQSnimOS1wgwTX8S7skK+3Qp/cVK4X HjAfhgpBtH/jB0DJ/xoesqfFaLWf/rlR/aX95n8F0EtN/rP2sk+5T61pByuK7l8Xmlrb X4jA==
MIME-Version: 1.0
X-Received: by with SMTP id hn5mr31405659wjb.8.1361342487037; Tue, 19 Feb 2013 22:41:27 -0800 (PST)
Received: by with HTTP; Tue, 19 Feb 2013 22:41:26 -0800 (PST)
Date: Tue, 19 Feb 2013 22:41:26 -0800
Message-ID: <>
From: R S <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 22 Feb 2013 08:24:43 -0800
Subject: Re: [Json] Proposed document set from this WG
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Feb 2013 06:41:29 -0000

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
change this algorithm on a reasonable time scale, and JSON RFC readers
will expect to interoperate with web browsers and other JavaScript

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."

json ⊄ js: <>
> 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