Re: [Json] Two Documents

Tim Bray <> Wed, 19 June 2013 14:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D05021F9C35 for <>; Wed, 19 Jun 2013 07:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fNztUPNTl47v for <>; Wed, 19 Jun 2013 07:33:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A65CE21F9C0B for <>; Wed, 19 Jun 2013 07:33:23 -0700 (PDT)
Received: by with SMTP id m17so3887901vca.9 for <>; Wed, 19 Jun 2013 07:33:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=tMuYw/8CrU1NMdJriCWOOm7TktgErzTmRUfTbmrsHWA=; b=V2fFztRWleinOXAC4ZxbfjtHRjs3OSRWZ2kvC7ou5SypVSEvZJ9+8ALie6+av/05Zt mfk5YY9GbPfgZ2Fm4wMzqj3o6DhN2+ej1aLQDGdr8ffprB2nLIvAWSbhzlMDD44vISJq i5+lKpLnM70SSEIU+bE/mTGjbWPcj1ifjK08xdOI5mLWHf6OWQsmkFL2AWMzZVQ0RKAY 6Hl8lJ/HjnsNeGr578A/qVezMshQLGXR0Xnp2DheJpsuEULjIDLT3LjwkAv82mAKENEF haey8mdEewRcIFAi457yHGnRZm/oZP00IkKLiDYVetbaUOxGSbIgabGu7RMm9tRsSdqS znrQ==
MIME-Version: 1.0
X-Received: by with SMTP id q9mr705259vcf.36.1371652402266; Wed, 19 Jun 2013 07:33:22 -0700 (PDT)
Received: by with HTTP; Wed, 19 Jun 2013 07:33:21 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <>
Date: Wed, 19 Jun 2013 07:33:21 -0700
Message-ID: <>
From: Tim Bray <>
To: Douglas Crockford <>
Content-Type: multipart/alternative; boundary=001a11c2e25831561904df82b629
X-Gm-Message-State: ALoCoQnJjOHcF1AGkca+TDOeeUQZX1cG5A27kEbYDhiL2ZCosM45glLRdN2yM2JV5zaONiETOpbf
Cc: "" <>, "Matt Miller \(mamille2\)" <>
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: Wed, 19 Jun 2013 14:33:28 -0000

Let’s take a moment to consider who our audience is.  The RFC will be used
almost exclusively by JSON parser and generator implementors. Out in the
general population of JSON users, the only docs they look at are the docs
for the parser/generator library they’re using.

And if I’m an implementor writing a JSON parser or generator, well, yeah, I
care about the abstract grammar and the security issues, but I also care
about what the incoming sequence of bytes is going to look like, and what
the outgoing sequence of bytes needs to look like.

So I think it would be abusive to our customers to make them read two
documents to get their jobs done.  I’m scratching my head to think of
anyone who would read one of these documents but not the other, and I’m
coming up empty.


On Tue, Jun 18, 2013 at 7:06 PM, Douglas Crockford <>wrote;wrote:

> On 6/17/2013 5:14 PM, Matt Miller (mamille2) wrote:
>> 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.
>>  Please excuse the lateness of this reply. I am traveling.
> I am proposing that The JSON Data Interchange Format document contain only
> the material that is universal to all applications of JSON. So, for
> example, the only dependency on any character encoding is the
> interpretation of the four hex digits in the \u notation, where Unicode
> determines the meaning of the numbers.
> It includes an abstract, an introduction, the detailing of the elements
> (object, array, string, etc), and security considerations. No parsers or
> generators, no octets, no MIME types.
> This provides a standard description of JSON that all other standards and
> practices may refer to. I think this is the standard that ECMA wants to
> publish.
> We can then consider other documents that constrain or interpret JSON for
> specific purposes. The poorly named application/json is one. JSON as a file
> format, JSON as a streaming format, and JSON as an embedded data
> representation are others.
> ______________________________**_________________
> json mailing list