[Json] What does "break compatibility" mean?

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 28 February 2013 19:46 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 8F36621F8749 for <json@ietfa.amsl.com>; Thu, 28 Feb 2013 11:46:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.69
X-Spam-Level:
X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 J5rg1C3TmNUb for <json@ietfa.amsl.com>; Thu, 28 Feb 2013 11:46:07 -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 F16B221F8765 for <json@ietf.org>; Thu, 28 Feb 2013 11:46:06 -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 r1SJk2SU028777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Feb 2013 12:46:03 -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: <CAC4RtVDXwPRL-Cz_Xf-kjU3dzzY+JheDGivSE9hF2v1NLkWEgQ@mail.gmail.com>
Date: Thu, 28 Feb 2013 11:46:01 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <63519CDF-144F-4DA4-A9F3-A1AB824861D2@vpnc.org>
References: <CAHBU6ityBeA+M-PEme09gO_jVySr33-X308i1UttxrQwSgYmGQ@mail.gmail.com> <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <CAK3OfOjFCnR8k1csVOkSKTDpA8exDvYdAijn80HKD5zwNzzeSw@mail.gmail.com> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <CAC4RtVDXwPRL-Cz_Xf-kjU3dzzY+JheDGivSE9hF2v1NLkWEgQ@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.1499)
Cc: json@ietf.org
Subject: [Json] What does "break compatibility" mean?
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, 28 Feb 2013 19:46:07 -0000

On Feb 27, 2013, at 10:15 AM, Barry Leiba <barryleiba@computer.org> wrote:

>>> I don't know. I think I'd be fine if we just asked Crockford (perhaps
>>> helped by a willing editor) to do 4627bis and then have the AD sponsor
>>> it on Standards Track.
>> 
>> I did ask him.  I actually asked him about updating it even before I had
>> heard about the JSON BoF.  He indicated that he is willing to work on it "as
>> long as it does not break compatibility with existing implementations."
>> 
>> As editor, I think he would be in a good position to ensure that his
>> requirement is met.
> 
> Indeed; I had talked with him back in August, as well, with the same
> response.  And as the likely responsible AD for any WG that forms, I
> can say that I strongly agree with the "doesn't break compatibility"
> point.  

As we discussed, RFC 4627 says "The names within an object SHOULD be unique." So, what does "break compatibility" mean for this specific issue? If we make the SHOULD a MUST, there are emitters that will become incompatible. If change the sentence to follow the ECMAScript spec ("In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten."), there are parsers that will become incompatible. 

> My view is that the charter has to make it clear that the
> "4627 to Standards Track" work is essentially a re-classification in
> place, rolling in errata and clarifications, but *not* changing the
> language.  

Is the ECMAScript text a clarification or a change?

> Any proposals that actually make changes would have to come
> later, and be considered as separate work proposals.

That certainly sounds reasonable. The question is whether you will allow clarifications that might make something incompatible.

--Paul Hoffman