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

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 07 December 2013 16:10 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 70ACF1AE39E for <json@ietfa.amsl.com>; Sat, 7 Dec 2013 08:10:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
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 h0pxHSafXCaQ for <json@ietfa.amsl.com>; Sat, 7 Dec 2013 08:10:18 -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 97B0B1AE399 for <json@ietf.org>; Sat, 7 Dec 2013 08:10:17 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB7GABtO014069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 7 Dec 2013 09:10:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <5D573C1A-BC67-4E00-9EFC-B57172CB0478@mnot.net>
Date: Sat, 07 Dec 2013 08:10:09 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E456E2BC-477A-4306-B676-8BDD52637CFB@vpnc.org>
References: <C7707CE2-C43E-4171-AE96-9FAFDCE53317@cisco.com> <CAHBU6iva2H-ovjmfA7=7j2KxUuXAMjhCb8fcMgKxq6hk+A9BtQ@mail.gmail.com> <5D573C1A-BC67-4E00-9EFC-B57172CB0478@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.1822)
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: Sat, 07 Dec 2013 16:10:19 -0000

<hat on>
<acknowledgement that Matt might disagree with some parts and can speak for himself>

On Dec 6, 2013, at 9:20 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Generally, negotiation-through-liaison-statement is the WORST possible way to communicate.

Fully agree. The response we propose to give is not "negotiation", it's a definitive response.

> Why don’t we suggest a joint meeting, or appoint a temporary representative on both sides to work through the situation and report back, or…?

We've had two face-to-face WG meetings since Ecma, and TC39 in specific, was actively and repeatedly invited to participate. If those weren't convenient, TC39 could have invited us to their face-to-face meetings, or asked for an interim or virtual interim.

>> -----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.
> 
> Yes, the lack of communication has been unfortunate; I’m not sure driving that point too deeply here is really doing any good.

The lack of communication up to this point, despite efforts on the part of the IETF, seems quite relevant in that Ecma is asking for substantial changes to the document at the last minute. If their statement was "we've asked for this repeatedly and you haven't given a good response", or "we didn't know that the IETF was working on this", those would be highly germane, but they are saying neither.

>> 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.
> 
> Why the focus on “process” here? I’d like to believe that we’re engineers focusing on doing the right thing, not just enforcing a process. 

All of the Ecma requests are for process items (title of the RFC and normative referencing). It would be inappropriate for us to ignore their requests because they were on process items.

>> 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.
> 
> Once JSON is done, will there be need for such a liaison in the future?

Absolutely. First, Ecma is much more than TC39. But, even if the liaison relationship was just for TC39, decisions that TC39 makes about the semantics of JSON in ECMAScript have a large affect the interoperability of JSON in other areas. Having a much better form of communication than we have now could certainly lead to better interoperability in the future.

>  . . .
> 
> As others have pointed out, this is misleading about the IETF’s requirements for references, and furthermore has a very patronising tone.

We heard that, and both are being fixed in the final message.

> Why don’t we ask what their intent is for the future of 404, rather than tell them what we deem it might be?

Because their intent might change over time, just as anyone's might. Intention are not promises, nor should they be. If Ecma had looked at our intent for rfc4627bis nine months ago and thought they were promises, they would be really pissed at us. SDOs doing technical work are often surprised by what they find when a lot of different eyes focus on the topic, as you are well aware from your current experience in httpbis. 

>> If the IETF believed that future development of ECMA-404 would involve a similar kind of open participation as seen with the development of draft-ietf-json-rfc4627bis, it could certainly revisit the topic of a normative reference in any subsequent update. Such a belief could be one of the positive products of a formal liaison relationship between the IETF and Ecma.
> 
> Getting into an our-process-is-more-open-than-your process fight is completely inappropriate, and does not represent the IETF well. 

We heard that, and we will are softening this bit as well.

--Paul Hoffman