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

Stefan Hagen <stefan@dilettant.eu> Sat, 30 July 2016 15:40 UTC

Return-Path: <stefan@dilettant.eu>
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 7081112D74F for <json@ietfa.amsl.com>; Sat, 30 Jul 2016 08:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable 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 3rYow1JZ0QU3 for <json@ietfa.amsl.com>; Sat, 30 Jul 2016 08:40:26 -0700 (PDT)
Received: from mailrelay11.public.one.com (mailrelay11.public.one.com [195.47.247.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0E712D685 for <json@ietf.org>; Sat, 30 Jul 2016 08:40:25 -0700 (PDT)
X-HalOne-Cookie: 64e88dc34fb31d99ab3fb268fc150f9b377e0438
X-HalOne-ID: ed233bb0-566b-11e6-9f37-b82a72d06996
Received: from [10.151.207.178] (unknown [80.187.113.75]) by smtpfilter3.public.one.com (Halon Mail Gateway) with ESMTPSA; Sat, 30 Jul 2016 15:40:21 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Stefan Hagen <stefan@dilettant.eu>
X-Mailer: iPhone Mail (13F69)
In-Reply-To: <1F76187B-4470-48B2-BD65-3A7FE1883993@mnot.net>
Date: Sat, 30 Jul 2016 17:40:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4FD98985-C1EF-4693-8B9D-73B6825CF9DD@dilettant.eu>
References: <CDD4C92E-863F-40FE-8D58-D764C9533FAA@cisco.com> <4c9504d3-c212-0b8c-0016-b31d653f15a6@gmail.com> <9E2C2681-B776-444F-84DC-9A28130DB2C1@cisco.com> <77e8ce0f-ceb3-0b69-54eb-635afbdf2a17@gmx.de> <ac67f171-d8b0-f6c6-f7db-d58c01c4505f@it.aoyama.ac.jp> <1F76187B-4470-48B2-BD65-3A7FE1883993@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/TYrrCq6HOl4LmhqcCXnae15ndxQ>
Cc: "draft-ietf-jsonbis-rfc7159bis.all@ietf.org" <draft-ietf-jsonbis-rfc7159bis.all@ietf.org>, "Julian F. Reschke" <julian.reschke@gmx.de>, "json@ietf.org" <json@ietf.org>, Joe Hildebrand <jhildebr@cisco.com>, "Matt Miller (mamille2)" <mamille2@cisco.com>, " Martin J. Dürst " <duerst@it.aoyama.ac.jp>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
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: Sat, 30 Jul 2016 15:40:29 -0000

+1 dito

--
Stefan.

> Am 30.07.2016 um 13:37 schrieb Mark Nottingham <mnot@mnot.net>:
> 
> +1, well said.
> 
>> On 30 Jul 2016, at 12:13 PM, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
>> 
>> I think this is an issue of trust, from both sides. For those not in a mood to trust ECMA, I suggest they trust our WG chairs and ADs.
>> 
>> (If everything goes really wrong, we can always issue a revision with the reference to the ECMA side removed.)
>> 
>> Regards,   Martin.
>> 
>>> On 2016/07/29 01:13, Julian Reschke wrote:
>>>> 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.
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> json mailing list
>>> json@ietf.org
>>> https://www.ietf.org/mailman/listinfo/json
>>> .
>> 
>> _______________________________________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/listinfo/json
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 
> 
> 
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json