Re: [Json] Counterproposal #2 on work items

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 21 February 2013 19:14 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 1F79F21F8EF9 for <json@ietfa.amsl.com>; Thu, 21 Feb 2013 11:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level:
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGr9vAfg6dZH for <json@ietfa.amsl.com>; Thu, 21 Feb 2013 11:14:52 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A715D21F8F42 for <json@ietf.org>; Thu, 21 Feb 2013 11:14:52 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1LJEnfr017514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <json@ietf.org>; Thu, 21 Feb 2013 12:14:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <A723FC6ECC552A4D8C8249D9E07425A70F89DCF8@xmb-rcd-x10.cisco.com>
Date: Thu, 21 Feb 2013 11:14:49 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC5143B4-86A8-463C-B45A-3932C9445958@vpnc.org>
References: <A723FC6ECC552A4D8C8249D9E07425A70F89DCF8@xmb-rcd-x10.cisco.com>
To: "json@ietf.org" <json@ietf.org>
X-Mailer: Apple Mail (2.1499)
Subject: Re: [Json] Counterproposal #2 on work items
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <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, 21 Feb 2013 19:14:53 -0000

On Feb 21, 2013, at 11:05 AM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:

> On 2/20/13 10:15 PM, "Robert Sayre" <sayrer@gmail.com> wrote:
> 
>> There is a lack of interoperability, and this issue is one of the smaller
>> points. The larger point is that the JS implementations (and many smaller
>> ones) have no incentive to change their behavior, and what they do is
>> reasonable. Let's just
>> do that.
> 
> How about text like this for section 2.2:

Wrong thread. This thread is for "only product a best practices guide".

I bring this up because there is a huge difference between:
- Changing the requirements in the format specification
- Adding new processing rules, but allowing bad-idea data, in the format document
- Not touching the format specification and creating a best practices guide

Further, as we have discovered in many other areas of the IETF, there is a huge difference between:
- A format specification that is unclear on how to process illegal input
- A format specification that says processors must reject illegal input
- A format specification that says how processors handle legal-but-bad-idea input

--Paul Hoffman