IETF Logo Mail Archive

Re: [Json] Working Group Last Call of draft-ietf-jsonbis-rfc7159bis-02

Julian Reschke <julian.reschke@gmx.de> Thu, 28 July 2016 16:13 UTC

Return-Path: <julian.reschke@gmx.de>
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 962DB12D8D5; Thu, 28 Jul 2016 09:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 56diE3RqpadT; Thu, 28 Jul 2016 09:13:22 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41D812D7E4; Thu, 28 Jul 2016 09:13:21 -0700 (PDT)
Received: from [192.168.1.123] ([5.10.171.186]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6P5z-1b4XkE0Ykl-00yQzk; Thu, 28 Jul 2016 18:13:17 +0200
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
References: <CDD4C92E-863F-40FE-8D58-D764C9533FAA@cisco.com> <4c9504d3-c212-0b8c-0016-b31d653f15a6@gmail.com> <9E2C2681-B776-444F-84DC-9A28130DB2C1@cisco.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <77e8ce0f-ceb3-0b69-54eb-635afbdf2a17@gmx.de>
Date: Thu, 28 Jul 2016 18:13:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <9E2C2681-B776-444F-84DC-9A28130DB2C1@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:tPpFHThATzpte/n+bwEKeS6ROUSPl5ICYQA12ype7A01k0Fj6k+ ps89OvBEc9eilBMtMFgEl+UIN2ASW6mXYY4pY9QbfAMrUZ/Q2OYPRy90pCNvFuKs8hLuDOs lnAw4tNCKPzmMVycO98mehrSge06Dkb7kL25K7ZfUZlDtxdYhsSSpf1zSrV0dKKIAP0cHHS l8tHBkTy5bcLSOxeIrKKQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:XO/S3HuFNRw=:bgHIi01rM6otunkNnjR+ii Ed22TAvL4V2dwD8znKv6Z6z65/SSlwHeOLdMxUzTcDtq90ZHveoSTj6qWsJaa7PBuCdb732zM bJcA6X0UovSlki2V2ZkHnWGUfkW3k0TXnvOsItfiX5lfHnKmnSAp0llBIzFnm90GwJQr8C71j rSCxNfv3YgJvLgeeZ0Pgv8hSVzO6cPKZtOIOAwQvClL2Y0u2ozLuAAU2Vk0rP+xaBX0n7mveM rYtOd9aEfynBjEc+B5WFrxpswxN6q2A9PCnKcmuPM3Uwfn+1Lg6eFnH1XRzHzT+uwvlJTVMCq hZCyl9k9I1gt45+qJ8Ki9FwpAGuqGxtTVhqwqDhbAN0uaAfJAtdYCp5kVkd2JxxlQV4+UUdQB 8DZJZY9+8aYLGMicfmaHYW94LR1lxkSWRV62ZmExggDZmVDbSER8Ho9gsanYVOSisyw/0K2Cg 0W+ewW4CM+FfGeL3RTpgaqfwKwbrBrPe9z1N7nzoO0YWZym+L8uNdjA5PQtfOfyijP0xbWDRo Xcfvl08y76kvCBlLjHHfhXBR2nsWKzJHrnhcw9TRnaifGW/kHj738+kqMx/y6RoEuqOima1kG soUfRw7/88xYYmLpK3N7rNgV37hcKaO3OTTAV/kNdNXjNcCPxuj6nJX2eRQJwKJ3PG4+vTCFC RgygMxrbYyANo+ZXLI/G9J94nGIGm9lkwu8M0/RYnFErWGPBLloIXQksRlkIyQAz0BGp4wkCZ m6l7AblzFBfjt28+ZrY83VTy5pTCXWF77x+eFZ8k/+xs0uujprGMLcta6mjbz69vroYNYFqzI HxluhWW
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/xdIhlnuFtqe5PZTG9G7mnO-eEN8>
Cc: "draft-ietf-jsonbis-rfc7159bis.all@ietf.org" <draft-ietf-jsonbis-rfc7159bis.all@ietf.org>, "Matt Miller (mamille2)" <mamille2@cisco.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Working Group Last Call of draft-ietf-jsonbis-rfc7159bis-02
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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 Jul 2016 16:13:23 -0000

On 2016-07-28 18:05, Joe Hildebrand (jhildebr) wrote:
> I agree that the document should not be published as an RFC until we have the equivalent last-call doc from ECMA, and we do a coordinated publish of the two documents.  But having our side ready to go, including finishing AUTH48, will allow us to not be the bottleneck in that process.

Not sure. "approved" means "approved". I believe we need a mechanism 
that makes sure that the update of 404 not only happens, but that it 
also contains the change we expect.

> I believe we have adequate protections in place with Alexey not pushing the button until the right time, and making sure that the RFC Production Center is aware of the dependency to what amounts to a downref.
>
> Would it help if we replaced the ECMA-404 reference with a a ref to ECMA-404bis (with details left out)?  That would make it *very* clear to the RPC what we intend, and would trigger processes they have in place to ensure the reference is resolved before publishing.

I think that helps, but it's not sufficient.

Best regards, Julian

PS: ...and we need a minor revision anyway; see prior feedback.

v2.23.0 | Report a Bug | By Email