Re: [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft)

Allen Wirfs-Brock <allen@wirfs-brock.com> Fri, 22 November 2013 16:55 UTC

Return-Path: <allen@wirfs-brock.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626931AE047 for <json@ietfa.amsl.com>; Fri, 22 Nov 2013 08:55:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 rQQ3w-SoTT0c for <json@ietfa.amsl.com>; Fri, 22 Nov 2013 08:55:01 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 129601ADFB6 for <json@ietf.org>; Fri, 22 Nov 2013 08:55:01 -0800 (PST)
Received: from 173-167-127-65-sfba.hfc.comcastbusiness.net ([173.167.127.65] helo=[10.0.0.61]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <allen@wirfs-brock.com>) id 1Vju0J-000C7C-1n; Fri, 22 Nov 2013 16:54:51 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Originating-IP: 173.167.127.65
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+H+D/gUO5JtDwHdd6vU/Wy8ftwxI7NHPU=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="windows-1252"
From: Allen Wirfs-Brock <allen@wirfs-brock.com>
In-Reply-To: <CAHBU6itwNwAy__Yy3n2bGMjuZnXAhK+qNbLq36piFy666m-Cng@mail.gmail.com>
Date: Fri, 22 Nov 2013 08:54:46 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <EF7034DE-EA4D-43E4-9A5A-159E4A9DAB02@wirfs-brock.com>
References: <8413609C8A86497F856897AF2AA24960@codalogic> <CEAA3067.2D132%jhildebr@cisco.com> <CANXqsRJEtBoprQFrftz80ZigmBR_NHoEXK1sR4GyBtz5B2KC8Q@mail.gmail.com> <20131120223305.GB5476@mercury.ccil.org> <CANXqsRJmNmSRXssBnw3tGUt0veViENLoS=dp+gEr2RqvNAf4JQ@mail.gmail.com> <20131121165615.GA12138@mercury.ccil.org> <CANXqsRKrcR54TzSFng0ysyTV60-uZZ7QQ-G4xJOB0gO29C7-Ag@mail.gmail.com> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <CAHBU6itwNwAy__Yy3n2bGMjuZnXAhK+qNbLq36piFy666m-Cng@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1085)
Cc: John Cowan <cowan@mercury.ccil.org>, Pete Cordell <petejson@codalogic.com>, Paul Hoffman <paul.hoffman@vpnc.org>, JSON WG <json@ietf.org>, Henri Sivonen <hsivonen@hsivonen.fi>, "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, "www-tag@w3.org" <www-tag@w3.org>, es-discuss <es-discuss@mozilla.org>
Subject: Re: [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 22 Nov 2013 16:55:02 -0000

On Nov 22, 2013, at 8:39 AM, Tim Bray wrote:

> I’ve been using JSON for quite a few years, but hardly ever in either a to-browser or from-browser role; what I care about is mostly its use in RESTful APIs generally and identity APIs specifically.  In those scenarios, it would be seen as wildly inappropriate to use anything but UTF-8; I’ve never actually seen anything else.  In practice, it would be very unlikely for anyone to deploy UTF-16 or any other non-UTF-8 flavor in a non-browser scenario.
> 
> Having said that, I’m still, hundreds of messages later, not 100% sure what our draft should say about BOMs :(

You should say it that it is not an actual issue of the JSON format whose grammar clearly defines the handling of the 0xfeff code point.  Rather it is an upstream data interchange issue that should be dealt with in exactly the same way as with any other data interchange on a similar channel.  Say whatever you think is appropriate about BOMs in the transmission of data conforming to the "application/json" MIME type.  Just be clear that whatever you decide has nothing to do with the abstract, grammar-based interpretation of the actual JSON payload.

Allen