Re: [Json] Two Documents

Jacob Davies <jacob@well.com> Thu, 13 June 2013 23:16 UTC

Return-Path: <cromis@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747B721F9B2A for <json@ietfa.amsl.com>; Thu, 13 Jun 2013 16:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.145
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUeL2YcpfmI7 for <json@ietfa.amsl.com>; Thu, 13 Jun 2013 16:16:10 -0700 (PDT)
Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBFA21F9B1A for <json@ietf.org>; Thu, 13 Jun 2013 16:16:10 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id n1so2739985qcw.16 for <json@ietf.org>; Thu, 13 Jun 2013 16:16:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.224.205.8 with SMTP id fo8mr5373443qab.62.1371165369844; Thu, 13 Jun 2013 16:16:09 -0700 (PDT)
MIME-Version: 1.0
Sender: cromis@gmail.com
Received: by 10.49.106.228 with HTTP; Thu, 13 Jun 2013 16:15:49 -0700 (PDT)
In-Reply-To: <51B9EA49.2050604@crockford.com>
References: <51B9EA49.2050604@crockford.com>
From: Jacob Davies <jacob@well.com>
Date: Thu, 13 Jun 2013 16:15:49 -0700
X-Google-Sender-Auth: max1SMiVTtTtSMo8PtNrGSj1nGE
Message-ID: <CAO1wJ5SRb+NEP9yXrwzhUPOSJ6mPbkCfG_knnh0PJtZ=yGPC_g@mail.gmail.com>
To: Douglas Crockford <douglas@crockford.com>
Content-Type: multipart/alternative; boundary=20cf3005dc0acc491804df115048
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Two Documents
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=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 <douglas@crockford.com>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
> json@ietf.org
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>