Re: [Json] Response to Statement from Ecma International TC39

Nico Williams <nico@cryptonector.com> Thu, 05 December 2013 04:43 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17451AE348 for <json@ietfa.amsl.com>; Wed, 4 Dec 2013 20:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7WCt2qONaIS for <json@ietfa.amsl.com>; Wed, 4 Dec 2013 20:43:01 -0800 (PST)
Received: from homiemail-a89.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 514DF1ADF0E for <json@ietf.org>; Wed, 4 Dec 2013 20:43:01 -0800 (PST)
Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 333CF31805C; Wed, 4 Dec 2013 20:42:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=E1Zu8dYRnYDCxB ywS2TDir7Uq6U=; b=be8uA8q9934ISElw7wCRzzonX89LSTqB6yMs0/VZZAsHZN T1cCgkO+H2vzi9k0bARHU14q5FM2bbeMr30okx1IdRRGE/VIKU5fIyQ532Ou+72L 2an6LEWHt/yF5FNbj6QEmpW9rZOHCpezTbgLGK3F2WEK5GXnox3s/n6rkbUzE=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id DDD44318059; Wed, 4 Dec 2013 20:42:57 -0800 (PST)
Date: Wed, 04 Dec 2013 22:42:56 -0600
From: Nico Williams <nico@cryptonector.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
Message-ID: <20131205044253.GH21240@localhost>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: JSON WG <json@ietf.org>
Subject: Re: [Json] Response to Statement from Ecma International TC39
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
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, 05 Dec 2013 04:43:02 -0000

On Thu, Dec 05, 2013 at 02:57:05AM +0000, Matt Miller (mamille2) wrote:
> [...]

Comments:

 - s/rfc4727/rfc4627/g  (the link to the attachment says 4727)

 - I don't think we ought to demand anything more than stability for
   normatively referencing ECMA-404.  In particular it seems odd to
   demand that the other SDO (ECMA) establish open processes before
   we'll consider referencing their documents -- a demand of that sort
   ought to be backed up by a statement (as a published RFC) from the
   IESG and/or IAB, not from a WG.

   I know, you said "[the IETF] _almost_ exclusively...".

   Are you asking the WG to demand that the ECMA commit to open
   processes in regards to TC39's future updates of ECMA-404?  Is that a
   consensus call?

 - While I think your note says everything that it must (and only a tad
   too much; see above), it reads a bit too plaintive to me.

   We had representation from TC39 members, and we had ECMA-404.  We had
   enormous threads on RFC4627bis.  We knew about the landmines we
   should not step on, and in the end we didn't step on them.  Things
   worked out, even if things could have worked better.

   I'm also not sure that concerns from ECMA TC39 would not have been
   dismissed as easily as similar concerns from individuals were (at
   least for a while).  We probably needed to have those long threads to
   come to our current consensus.

More in-line.

> -----BEGIN RESPONSE-----
> Thank you for your statement of concern about
> draft-ietf-json-rfc4627bis. The chairs of the IETF's JSON Working
> Group were not aware of any serious concerns that TC39 had with the
> update process. Over the past many months, we repeatedly contacted
> ECMA and TC39 members about the JSON WG and
> draft-ietf-json-rfc4627bis, but never received any significant reply.

Is there documentation of "official" attempts to contact ECMA TC39.
(I'm not sure what that would look like.)

> We know that some TC39 members joined the JSON WG mailing list but did
> not voice any process concerns in the WG -- or privately to the WG
> Chairs -- before or during either of the Last Calls on the document.

I've certainly seen complaints about direction or specific consensus
calls.  Were any by TC39 members?  I'd not know.  Were they about
process?  Perhaps if asked for clarification those voicing concerns
might specify the process as a source of concern.

> In the future, it would probably be useful for Ecma and the IETF to
> have a formal liaison relationship. We have heard that there were
> preliminary discussions several months ago, but stopped short of a
> formal relationship before the JSON Working Group was formed.
> Formalizing the liaison relationship will help both SDOs communicate
> with each other and thus avoid late surprises.

I think I'd phrase this more like:

   Given the late stage of RFC4627bis in the RFC publication process we
   came rather close to publishing an RFC of interest to the ECMA
   without formal input from the ECMA.  The ECMA's concerns were
   -accidentally- voiced in time.  The IETF has a formal liason
   relationship process for interaction with other SDOs.  Establishing
   an IETF-ECMA liason will likely make future interactions smoother.

Nico
--