IETF Logo Mail Archive

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

Ned Freed <ned.freed@mrochek.com> Sun, 12 March 2017 12:11 UTC

Return-Path: <ned.freed@mrochek.com>
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 2C48B1293EB; Sun, 12 Mar 2017 05:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 H3hYilvbTrdP; Sun, 12 Mar 2017 05:11:44 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 7A8BD128DF6; Sun, 12 Mar 2017 05:11:44 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBVHP8004000PMAR@mauve.mrochek.com>; Sun, 12 Mar 2017 05:06:40 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBQBR8XOKG0003XB@mauve.mrochek.com>; Sun, 12 Mar 2017 05:06:37 -0700 (PDT)
Message-id: <01QBVHP5YAYE0003XB@mauve.mrochek.com>
Date: Sun, 12 Mar 2017 04:56:29 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sun, 12 Mar 2017 10:09:46 +0100" <9F2F2116-4985-4561-BFD3-24B374E4C4ED@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> <9F2F2116-4985-4561-BFD3-24B374E4C4ED@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/GpWPNmv7vsCKt7o_eYbDbIRPzUI>
Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan <cowan@ccil.org>, IETF <ietf@ietf.org>, secdir@ietf.org, ned+ietf@mauve.mrochek.com, "json@ietf.org" <json@ietf.org>, Julian Reschke <julian.reschke@gmx.de>, Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03
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: Sun, 12 Mar 2017 12:11:45 -0000

> On 11 Mar 2017, at 16:41, ned+ietf@mauve.mrochek.com wrote:
> >
> > It would be very helpful to have this text in the RFC.

> That would be a regression.

On the contrary - what you have now is incomplete if not actually broken, and
this completes/fixes it.

You have a specification that says (a) JSON can be encoded in UTF-8, UTF-16, or
UTF-32 and that (b) That no charset parameter is needed to distinguish the
charset and moreover one has "no effect". But you don't explain how why this is
the the case, or what compliant implementation do to determine the charset.

If you believe clarifying this is problemtic in some way, you need to explain
why.

> A better change would be to remove the fiction that JSON exists in UTF-16 or
> UTF-32 forms.

That's of course another way to fix the problem. But it's a far more
significant change, and I have to wonder if there is a consensus to do it.

Personally, I have no preference as to the approach that's used. But moving
forward as-is is really not acceptable.

				Ned

v2.23.0 | Report a Bug | By Email