IETF Logo Mail Archive

Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03

Carsten Bormann <cabo@tzi.org> Sun, 12 March 2017 15:31 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C20126BF6; Sun, 12 Mar 2017 08:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 yKfHguuWtDsQ; Sun, 12 Mar 2017 08:31:50 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 10C3D129509; Sun, 12 Mar 2017 08:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2CFVhYC020320; Sun, 12 Mar 2017 16:31:43 +0100 (CET)
Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vh4jW01q0zDHvr; Sun, 12 Mar 2017 16:31:42 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <cbbd0224-da58-bac5-b751-4195dd7383dc@gmx.de>
Date: Sun, 12 Mar 2017 16:31:42 +0100
X-Mao-Original-Outgoing-Id: 511025502.207779-be1eff5230d4761fb1f26c2a4fa3d8de
Content-Transfer-Encoding: quoted-printable
Message-Id: <38DEEE0A-EE2C-4ADA-9D7A-9DBBAEACB77E@tzi.org>
References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> <CAD2gp_TOxcZJxwPoMhq-xp6M+Yq+tQnMUv81YNFp-ydRMpH=5w@mail.gmail.com> <bed0e331-f5fb-f24d-6207-f5a36ec9e7be@gmx.de> <01QBU8WJOCUO0003XB@mauve.mrochek.com> <6d97dee7-7cf3-9142-aacf-f2ca4909103d@codalogic.com> <cbbd0224-da58-bac5-b751-4195dd7383dc@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/CEEdVXguFbLZkIvNcExN5DkRxbo>
Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan <cowan@ccil.org>, Ned Freed <ned.freed@mrochek.com>, IETF <ietf@ietf.org>, Peter Cordell <petejson@codalogic.com>, secdir@ietf.org, "json@ietf.org" <json@ietf.org>
Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Mar 2017 15:31:52 -0000

On 12 Mar 2017, at 10:14, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> Does anybody recall why we removed <https://tools.ietf.org/html/rfc4627#section-3>:

I seem to remember that the advice simply is no longer working since JSON was extended from 4627 to 7159.  Instead of trying to come up with an updated algorithm, the WG recognized that this is not a real-world problem.

If 7159bis is supposed to be an Internet Standard, it should focus on the variants that actually interoperate.  Re-encoding JSON into UTF-16 (or UTF-32) is not really interoperable with today’s implementations*).

Grüße, Carsten

*) (Given the large number of JSON implementations, I don’t doubt you will find two implementations that do interoperate on this.  It is not the widely interoperable “JSON” thing, though.)

v2.23.0 | Report a Bug | By Email