Re: [Json] Two Documents

Jacob Davies <> Thu, 13 June 2013 23:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 747B721F9B2A for <>; Thu, 13 Jun 2013 16:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.145
X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tUeL2YcpfmI7 for <>; Thu, 13 Jun 2013 16:16:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::22b]) by (Postfix) with ESMTP id 8FBFA21F9B1A for <>; Thu, 13 Jun 2013 16:16:10 -0700 (PDT)
Received: by with SMTP id n1so2739985qcw.16 for <>; Thu, 13 Jun 2013 16:16:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=I+IPaPwm62fSm5e3E66GQ6NbZI/FutKnrmJR22+/oOo=; b=GHLz2quwMWfXZIvjUr9HDBlxcm3sEUggoQMiZsRyrXliV4TzlVKcfgV+sWEGIXkmOi r12RxMEaOtwDSIRR+CH9i0E7xntV1rpRlT+jZjpEyMy67mYrmuz5Lnm6A8ierD6gVXRt cycTob4v1tedC8kZya6dbmL1p2zHjANnd6bkGUoW/dkmFaQV5crk8f9l34JDa7H0+lM+ /eNQhpQDIMu9+DbBcxGjpLY6hlazsgX9GRPeihyZ+f8Wuws3hxGGeZD8G+fmasM5KXWj g3I+NOKYYUeJZdvu7Lb8ZLz0BHlMhl+03So/XFgF8RL4yx6kpyhlyGeSnhlOXsU6wsii b/2Q==
X-Received: by with SMTP id fo8mr5373443qab.62.1371165369844; Thu, 13 Jun 2013 16:16:09 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 13 Jun 2013 16:15:49 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Jacob Davies <>
Date: Thu, 13 Jun 2013 16:15:49 -0700
X-Google-Sender-Auth: max1SMiVTtTtSMo8PtNrGSj1nGE
Message-ID: <>
To: Douglas Crockford <>
Content-Type: multipart/alternative; boundary=20cf3005dc0acc491804df115048
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 23:16:11 -0000

I think the current lucid, succinct text that describes a data model, a
language, and a byte serialization is so useful because it comprehensively
describes all three things. So I wouldn't break it up.

The byte serialization description is essential because in order to
actually use JSON for anything you must deal with some byte serialized
form, and in 99% of cases that will be the application/json form.

I advocated dropping the mentions of Unicode except in byte serialization
and character lookup for Unicode escapes. That's as a matter of clarity
since those mentions are extraneous, and also so that applications that
represent models without using Unicode or serialize to non-Unicode
encodings not described as application/json are not needlessly deemed
non-compliant. But I think those changes are relatively unimportant; few
people are going to be confused by the current text, and those who are
doing non-compliant things probably don't know or care.

On Thu, Jun 13, 2013 at 8:50 AM, Douglas Crockford <>wrote;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