Re: [Json] Counterproposal on work items

Paul Hoffman <> Wed, 20 February 2013 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 693D321F8780 for <>; Wed, 20 Feb 2013 09:38:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.586
X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O1fN0nK97twy for <>; Wed, 20 Feb 2013 09:38:21 -0800 (PST)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id 134EE21F87BA for <>; Wed, 20 Feb 2013 09:38:21 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id r1KHcKH7089998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; Wed, 20 Feb 2013 10:38:20 -0700 (MST) (envelope-from
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Wed, 20 Feb 2013 09:38:19 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "" <>
X-Mailer: Apple Mail (2.1499)
Subject: Re: [Json] Counterproposal on work items
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 17:38:22 -0000

On Feb 20, 2013, at 9:27 AM, Tim Bray <> wrote:

> My proposal is: do nothing.
> I use JSON for protocol design and work all the time, and have not observed any interop problems in the wild which originate at the JSON parson or construction level.  I give the incoming text to the library and it Just Works or reliably reports a syntax botch.  I give my data structures to the JSON serializer and cheerfully send off whatever comes out. I read specs and build clients and servers and, when things break, it’s because I’m stupidly using a bogus name or value in some field, not because of the serialization.
> I suggest that there is not a problem here that needs the investment of precious IETF time.


There are places where RFC 4627 has SHOULDs where some processors do one thing and others do something different. That should be cleaned up in a standards-track RFC, and it should be done with lots of JSON developers and users having a discussion that comes to rough consensus.

The other stuff mentioned so far will probably happen as experimental RFCs even if there is no WG; a WG might help prevent those from being silly, but doing so might take a lot of effort (more than the value).

--Paul Hoffman