Re: [Json] Two Documents

John Cowan <> Thu, 13 June 2013 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9EDF21F9815 for <>; Thu, 13 Jun 2013 08:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.435
X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S6aOGKMozyjl for <>; Thu, 13 Jun 2013 08:57:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1852421F9967 for <>; Thu, 13 Jun 2013 08:57:20 -0700 (PDT)
Received: from cowan by with local (Exim 4.72) (envelope-from <>) id 1Un9te-0006UK-7v; Thu, 13 Jun 2013 11:57:10 -0400
Date: Thu, 13 Jun 2013 11:57:10 -0400
From: John Cowan <>
To: Douglas Crockford <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <>
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: Thu, 13 Jun 2013 15:57:52 -0000

Douglas Crockford scripsit:

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


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

Fine, but the definition of the application/json media type can't be
exiled to a BCP.  It either has to be in a separate standards-track RFC,
or needs to be in the same RFC as the definition of JSON format but in a
different section of it.  The latter strikes me as more sensible.

John Cowan                         
        "You need a change: try Canada"  "You need a change: try China"
                --fortune cookies opened by a couple that I know