Re: [Json] Two Documents

"Matt Miller (mamille2)" <> Tue, 18 June 2013 00:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A78CB21F9E7D for <>; Mon, 17 Jun 2013 17:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N-9anGf4psK1 for <>; Mon, 17 Jun 2013 17:14:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F1EC21F9E81 for <>; Mon, 17 Jun 2013 17:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8647; q=dns/txt; s=iport; t=1371514491; x=1372724091; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rMD77Ni0HKqRkMzWCLMIrJPU/R6I5CeFTYWtcLD3JM8=; b=ACVrScQQYTUFBXU7MzlA54mk+cj3h6pQHd2k491pAKGAMBzL9zzkJYkG mUNogRuT/DqTmqfXWCqIds5VoOO/0fyAGRhVn/wLgRgTmBy0S8HL3z0XC sRuLa3oXph2r70Ey9UDgGqN+NfQ+QXGWuYAG2J4bmDpsL/tDieqDQ21wj 4=;
X-Files: smime.p7s : 4136
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcFAKGlv1GtJXHB/2dsb2JhbABbgwkxSb8DfhZ0giMBAQEDAQEBAWsLBQsCAQgiJAIlCyUCBA4FCAaHegYMukMEjxYxB4J/YQOQAYEsgkKVFYMPgig
X-IronPort-AV: E=Sophos; i="4.87,884,1363132800"; d="p7s'?scan'208"; a="223964484"
Received: from ([]) by with ESMTP; 18 Jun 2013 00:14:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r5I0EXGf019290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 00:14:33 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 19:14:33 -0500
From: "Matt Miller (mamille2)" <>
To: Douglas Crockford <>
Thread-Topic: [Json] Two Documents
Thread-Index: AQHOaE3TrpyS/+r1l0CLz5/49KZnUJk69M0A
Date: Tue, 18 Jun 2013 00:14:32 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_ACF489E3-A365-43DF-A4EB-A648D150E4D5"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Json] Two Documents
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: Tue, 18 Jun 2013 00:15:03 -0000

Hello Douglas,

In order for the WG to fully understand your proposal, we need a more definitive list of what to expect in each document.

As a starting point, can you describe which sections of the current RFC4627 would be in "JSON Data Interchange Format" and which would be in the JSON best practices document?  Clearly the latter will have many additions from the recent discussions, but it is less clear which portions of the current text goes into which document.


- m&m

Matt Miller < >
Cisco Systems, Inc.

On Jun 13, 2013, at 9:50 AM, Douglas Crockford <> wrote:

> The confusion and controversy around this work is due to a mistake that I
> made in RFC 4627. The purpose of the RFC, which is clearly indicated
> in the title, was to establish a MIME type. I also gave a description of
> the JSON Data Interchange Format. My mistake was in conflating the two,
> putting details about the MIME type into the description of the format. My
> intention was to add clarity. That obviously was not the result.
> JSON is just a format. It describes a syntax of brackets and commas that
> is useful in many contexts, profiles, and applications. JSON is agnostic
> about all of that stuff. JSON shouldn't even care about character encoding.
> Its only dependence on Unicode in the hex numbers used in the \u notation.
> JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON can
> be used in contexts where there is no character encoding at all, such as
> paper documents and marble monuments.
> There are uses of JSON however in which such choices matter, and where
> behavior needs to be attached to or derived from the syntax. That is
> important stuff, and it belongs in different documents. Such documents
> will place necessary restrictions on JSON's potential. No such document
> can fit all applications, which causes much of the controversy we've seen
> here. One size cannot fit all. JSON the format is universal. But real
> applications require reasonable restrictions.
> So we should be working on at least two documents, which is something we have
> discussed earlier. The first is The JSON Data Interchange Format, which is
> a simple grammar. The second is a best practices document, which recommends
> specific conventions of usage.
> _______________________________________________
> json mailing list