Re: [Json] Two Documents

Eliot Lear <lear@cisco.com> Fri, 14 June 2013 02:49 UTC

Return-Path: <lear@cisco.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 E86A811E80CC for <json@ietfa.amsl.com>; Thu, 13 Jun 2013 19:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 o4R8dkcL86eQ for <json@ietfa.amsl.com>; Thu, 13 Jun 2013 19:49:13 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4ED21E8051 for <json@ietf.org>; Thu, 13 Jun 2013 19:49:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1957; q=dns/txt; s=iport; t=1371178142; x=1372387742; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=p1T/agMAB7LHZPZDFv46v7q2gMlVxBe7RPtM4khz+Yc=; b=OpJDxtOYmMzPGjDw0fPO715VBNqEvIm4SUfuBCGTB9vb94n6GqBnKsB0 TrLARR6/3mwRHhm3RiZ6wABcOJ4ekAQk087WunlOwi7RY55OWUi2+BRgm G0plsJoclBhPk9QkW0rcWHN0RJyuS2d/QuMOrYx2NDvG9CdOFwLGI9T0R c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhkFAMaDulGtJV2Y/2dsb2JhbABagwkwgz27WoEFFnSCIwEBAQQBAQEgSwoBEAsYAgIFFgsCAgkDAgECARUwBg0BBQIBAYgKDKkzkS4EgSaOIQeCTIEUA5dBkUKDKyA
X-IronPort-AV: E=Sophos;i="4.87,863,1363132800"; d="scan'208";a="222650484"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 14 Jun 2013 02:49:02 +0000
Received: from rtp-vpn3-1627.cisco.com (rtp-vpn3-1627.cisco.com [10.82.222.98]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5E2n0Cq001542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Jun 2013 02:49:01 GMT
Message-ID: <51BA849C.4050508@cisco.com>
Date: Thu, 13 Jun 2013 22:49:00 -0400
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Douglas Crockford <douglas@crockford.com>
References: <51B9EA49.2050604@crockford.com> <20130613155710.GB29284@mercury.ccil.org> <51B9EF43.3020700@crockford.com>
In-Reply-To: <51B9EF43.3020700@crockford.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: John Cowan <cowan@mercury.ccil.org>, "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: Fri, 14 Jun 2013 02:49:18 -0000

Hi Douglas,

I think your suggestion of two documents is an interesting one.  One way
to go would be to create the 2nd document and include what needs to be
included there, and then decide LATER whether to merge the two documents
back.  If the best practices document ends up not being excessive in
length, then perhaps there's no harm in adding stuff back to the main
document, so long as it is clear what is normative and what is advice.

Eliot


On 6/13/13 12:11 PM, Douglas Crockford wrote:
>
> On 6/13/2013 8:57 AM, John Cowan wrote:
>> 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.
>> Indeed.
>>
>>> 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.
>>
> I think it will be better for ECMA that application/json be in a
> separate document.
> ECMA does not appear to be concerned with the maintenance of MIME types.
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>
>