Re: [Json] What are we trying to do?

Peter brooks <> Wed, 03 July 2013 05:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3861021F9C69 for <>; Tue, 2 Jul 2013 22:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9pzpP9LNumL1 for <>; Tue, 2 Jul 2013 22:32:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::229]) by (Postfix) with ESMTP id 7D19621F9C66 for <>; Tue, 2 Jul 2013 22:32:09 -0700 (PDT)
Received: by with SMTP id y10so5141914wgg.0 for <>; Tue, 02 Jul 2013 22:32:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=TkfmYShkI76dc5dXX+5l8hE89HfAZxOEjPt3/yHwkOU=; b=uADis82/gljII61rt11RMsbLkFrGpoaUp2gXaK6KV2DKQcwZ47nrgIzk3RYGyBT4fc SiA/1wVBNE7+3FjDNYPQXqlUubm9NkmAbXgkCQU3IYBTIf7+2hVIxxAgpIh/FqvAmcxv X3cvTiFZiaFkOzgAq90ClopOQxYuzPZhiO8QT+AMZL2S2hkwsTRLHdXroEMkHbB3V7Hr jHjL2RMd82PHaN87UmqoY1KgniuU7AsOrrw/1thMFXBLiSJyb2q0dTWHGAoJEGFM32/n 7jg1bbget+Y3h82HUJVPFOrDJeSHNkex3xj9DktYLrb+nYhCIeU7OHiM7DTiYwFrTy7Y zMlg==
X-Received: by with SMTP id x17mr17018042wie.47.1372829527442; Tue, 02 Jul 2013 22:32:07 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id nb12sm26392926wic.7.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 22:32:06 -0700 (PDT)
References: <>
In-Reply-To: <>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="cp932"
Message-Id: <>
X-Mailer: iPad Mail (10B329)
From: Peter brooks <>
Date: Wed, 03 Jul 2013 07:32:00 +0200
To: Tim Bray <>
Cc: "" <>
Subject: Re: [Json] What are we trying to do?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Jul 2013 05:32:10 -0000

Excellent points, Tim! I support this.

Sent from my iPad

On 3 Jul 2013, at 07:01, Tim Bray <> wrote:

> I’m having trouble dealing with the recent proposals from our co-chairs because I don’t think I understand what they’re trying to achieve.  Just to refresh, our charter says 
> “The work is essentially a reclassification in place, with minimal changes. The working group will   eview errata and update the document as needed to incorporate those, and will correct significant  errors and inconsistencies, but will keep changes to a minimum.
> It is acknowledged that there are differences between RFC 4627 and the ECMAScript specification  in the rules for parsing JSON. Any changes that break compatibility with existing implementations of  either RFC 4627 or the ECMAScript specification will need to have very strong justification and broad support. ”
> The changes proposed by the chairs are pretty big. Maybe the problem is that any change which would actually CORRECT the two biggest errors/inconsistencies in 4267 would necessarily be pretty significant. When your charter is self-contradictory, you can either re-charter or decide to ignore one of the two contradictory directives.
> I was getting really comfortable with the minimal proposal, which noted that while the spec more or less means what it says (strings should be Unicode, objects should have unique keys), there are other standards with different interpretations.  Also, there is variation among observed behavior in software, when the JSON RFC’s high-level directives are contravened.
> What the industry really needs is a document normatively describing JSON-as-best-practiced, with an RFC number.  It would say that senders MUST NOT do X and Y, and that receivers, upon encountering X OR Y, MUST DO Z.  Thus  other spec writers can say “Do what RFCXXXX says” and not have to resort to the sort of drafting pain that the people in Jose are experiencing right now in order to avoid attacks on cryptographically signed protocol elements by exploiting variation in dupe-key handling.
> Is it the sense of the WG that such a document is within our mandate?  -T
> _______________________________________________
> json mailing list