Re: [Json] Benoit Claise's No Objection on charter-ietf-json-00-01: (with COMMENT)

Benoit Claise <bclaise@cisco.com> Thu, 16 May 2013 17:14 UTC

Return-Path: <bclaise@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 B7BA021F8F6E; Thu, 16 May 2013 10:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.389
X-Spam-Level:
X-Spam-Status: No, score=-10.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 b+Ec-vLPLJws; Thu, 16 May 2013 10:14:02 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6D92711E8129; Thu, 16 May 2013 10:14:02 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4GHDur6017552; Thu, 16 May 2013 19:13:56 +0200 (CEST)
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4GHDTZN013243; Thu, 16 May 2013 19:13:45 +0200 (CEST)
Message-ID: <519513B9.20703@cisco.com>
Date: Thu, 16 May 2013 19:13:29 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <20130516082858.9386.7750.idtracker@ietfa.amsl.com> <CALaySJKi1qKwHQuTxqVbu38=OE_Ebi20tgj3F_bLQGYzB5v2Bg@mail.gmail.com>
In-Reply-To: <CALaySJKi1qKwHQuTxqVbu38=OE_Ebi20tgj3F_bLQGYzB5v2Bg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: The IESG <iesg@ietf.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Benoit Claise's No Objection on charter-ietf-json-00-01: (with COMMENT)
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, 16 May 2013 17:14:07 -0000

Ok, thanks Barry.

Regards, Benoit
>> Probably a detail, but it puzzles me. Maybe I read too much into this...
> I think you are.
>
>> "Any changes that break compatibility with existing implementations of
>> either RFC 4627 or
>> the ECMAScript specification will need to have very strong justification
>> and broad support."
>>
>> Versus
>>
>> "Any changes that break compatibility with the RFC 4627 or
>> the ECMAScript specifications will need to have very strong
>> justification
>> and broad support."
>>
>> Is this intentional that you mention the existing implementations of RFC
>> 4627?
> Yes.
>
> Consider that this is an essentially similar situation to what we had
> in going from PS to DS... except here we're going from Informational
> to PS.  The point, though, is that we have a mature protocol that's
> moving in the Standards Track (here, *into* the Standards Track).  The
> justification required for a change increases with the level of
> disruption it would cause to what's out there.
>
> Errata are easy.
> Useful changes that are fully compatible with current implementations
> are still easy; the conversation should be brief.
> Important changes that break compatibility are still within scope, but
> require a very strong justification, and will probably involve a lot
> more discussion.
>
> Your version (the second above) doesn't make much sense: changes to
> the spec are changes to the spec.  The point is to consider the effect
> those changes will have on implementations.
>
> Barry
>
>