Re: [Json] Two Documents

Tim Bray <> Thu, 13 June 2013 16:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88EE921F8CDD for <>; Thu, 13 Jun 2013 09:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.338
X-Spam-Status: No, score=0.338 tagged_above=-999 required=5 tests=[AWL=-1.780, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RKPC0sql0AqM for <>; Thu, 13 Jun 2013 09:55:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c01::22e]) by (Postfix) with ESMTP id 42D3121F8994 for <>; Thu, 13 Jun 2013 09:55:03 -0700 (PDT)
Received: by with SMTP id oz10so7852693veb.5 for <>; Thu, 13 Jun 2013 09:55:02 -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=ocwRCviSsOEPXLRlhbT362UaEYU/w0cpzjEcNuz3Ciw=; b=MKb2oRPK+9jkXg+jeDAV3uDXO7+6fsM50LgWX7M4SbTSLFLBnpArCMsNKnfYbpQjFG G+E/eakVXl0zVylKcFjMhfIF/pm38oR2xtFOKm5vdM2siQwQyCy3iBL3o9Mn1b0+8OQW fONnAvrHY9YcwjGtvxdF5ACh/8R/ilbBHbDqKYfGBtd264X7iB2Lbdek8L95mcQvzNYj SDAHvqw9rYeccpKfrrCg3SG+ydl1qLSlOP9ooTlw7JpAqS30pwl02xX3n0Bwpd3xUrCx MpTGq515+SbaZuz057XTYwO3luSicLzsURMO9BnFuByEXRAaEnCD8OZTqMJuQpu2aI8F 1nzA==
MIME-Version: 1.0
X-Received: by with SMTP id u10mr727091vek.39.1371142502482; Thu, 13 Jun 2013 09:55:02 -0700 (PDT)
Received: by with HTTP; Thu, 13 Jun 2013 09:55:02 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <>
Date: Thu, 13 Jun 2013 09:55:02 -0700
Message-ID: <>
From: Tim Bray <>
To: Douglas Crockford <>
Content-Type: multipart/alternative; boundary=089e0129420ccc18a504df0bfdbe
X-Gm-Message-State: ALoCoQkYs7HgJ99wRqV/Jypx7xNRbVup5C5ECnnpfUwDDGpPmbVmqS1+G3/8brrk8pAQqC3XdXai
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 16:55:07 -0000

I think we have widely-shared agreement on two documents, a JSON spec and a
best-practices doc.  Just a word of caution, though: Our profession has
ample experience with the notion of “abstract syntax” - in ASN.1 and in
SGML.  Neither of which ever exhibited good usability in Internet

One of the central defining virtues of the Internet and the Web is that
there are no object models or APIs, just messages. It is the job of the
IETF to define the message formats and interchange patterns.  Which is to
say, a document that defines a syntax but omits discussion of how that
syntax is expressed in bytes for transmission on the wire is not really
appropriate subject matter for the IETF.

The end-goal is pretty clear, I think: As someone who regularly works on
the design of network protocols based on JSON, I want an RFC to turn to
that will have nice crisp definitions of “JSON text”, “object”, “array”,
“string”, “number” and “boolean” so I can use those confidently in my
protocol design, and also sufficient precision about byte encoding that I
can rely on infrastructure builders to have created interoperable libraries
that work well on a variety of platforms and architectures.

It would also be nice if there were a best-practices document so that
someone could review my design and berate me for something stupid like
allowing the use of duplicate keys, and have something to point to.

So... two documents, yes.  Abstract syntax, no.


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