Re: [Json] JSON: encodings

Phillip Hallam-Baker <hallam@gmail.com> Thu, 14 November 2013 01:19 UTC

Return-Path: <hallam@gmail.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 4FAFD21E8098; Wed, 13 Nov 2013 17:19:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.504
X-Spam-Level:
X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY2VOg87Adm9; Wed, 13 Nov 2013 17:19:54 -0800 (PST)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C035011E8102; Wed, 13 Nov 2013 17:19:53 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id z5so1020786lbh.29 for <multiple recipients>; Wed, 13 Nov 2013 17:19:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CrYhdcYbmNFNJvJaV9jvLDcSt9AtvULt1bVVJV5Ov9c=; b=BHsSQ8d0PAmAoyWwVJYTRMsWst3yDaAZI+JKeFbRtuc0LIi0MlAFMd/ZsfRA/dEhaN 4Pp85ApG4VGTWSgtuDnVxpAc/zVCDOmKBKIFH5P9ocCoUVrVxCunXTogn9J7u/38y8jb ImGRYjZjdb16jf6xE6sVVkN7iYu9NnvFjXFzIXiDRIEmj/sdV+Rw6fvRoQW7980xsxU1 pFk/MYx5tHfHA9unabVdqWxRYEPaV2Nz+VzN+2QrsFYNgs+RM38YWcDC5qfxy8Tv27WM rC4JSxeGC2A+zCheS5ZuHIbhZmTVDaH40cj5uvzuiqQ8DRbJAwm1A4gbBVFhsi9G4Q3P Awfw==
MIME-Version: 1.0
X-Received: by 10.112.136.163 with SMTP id qb3mr31849340lbb.14.1384391992555; Wed, 13 Nov 2013 17:19:52 -0800 (PST)
Received: by 10.112.46.98 with HTTP; Wed, 13 Nov 2013 17:19:52 -0800 (PST)
In-Reply-To: <CEA92E3C.2CD06%jhildebr@cisco.com>
References: <99EE3A2D-D1CF-44EF-BA61-156ED8E72F79@vpnc.org> <CEA92E3C.2CD06%jhildebr@cisco.com>
Date: Wed, 13 Nov 2013 20:19:52 -0500
Message-ID: <CAMm+Lwjb9dWzA5Cy0pL1iq7ZfYQMbAcE7gG-6eZib9CJPLqJnA@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
Content-Type: multipart/alternative; boundary="089e0112c73cf23dc604eb18e092"
X-Mailman-Approved-At: Wed, 13 Nov 2013 17:55:04 -0800
Cc: Henri Sivonen <hsivonen@hsivonen.fi>, Anne van Kesteren <annevk@annevk.nl>, JSON WG <json@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, IETF Discussion <ietf@ietf.org>
Subject: Re: [Json] JSON: encodings
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 14 Nov 2013 01:19:55 -0000

On Wed, Nov 13, 2013 at 3:38 PM, Joe Hildebrand (jhildebr) <
jhildebr@cisco.com> wrote:

> On 11/12/13 8:28 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
>
> >[[ Adding the JSON WG to this thread ]]
> >
> >On Nov 11, 2013, at 10:58 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> >
> >> Supporting encodings other than UTF-8 in new formats is not good.
> >>
> >> Supporting UTF-32 is actively harmful as support for it has been
> >> removed or is being removed from clients. You ought to actively
> >> recommend against it.
> >>
> >> In general ASCII incompatible encodings have very bad security
> >> characteristics, the IETF would do well to steer away from them, just
> >> like the W3C has.
>
> Although I hate UTF-32 with the heat of a several moderately-sized stars
> and completely agree that UTF-8 is the one true path, I don't think we can
> completely remove UTF-32 from the bis draft.  There may be existing
> conformant JSON documents stored in UTF-32 that would be made unparseable
> by this change.
>

Nothing the IETF does is going to make documents unparseable. All the IETF
can do is to tell people what the standard form of JSON is.

99.99 % of JSON code out there will reject UTF-32. Much of that code will
reject it in horrible, broken ways. So I don't see any problem at all in
telling people that such encoding is not valid JSON.

All that closing off this option does is to limit the number of test cases
that JSON code has to handle.

-- 
Website: http://hallambaker.com/