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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 25 November 2013 09:38 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 EEB341AD66E for <json@ietfa.amsl.com>; Mon, 25 Nov 2013 01:38:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.908
X-Spam-Level:
X-Spam-Status: No, score=0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=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 RLEkmU-8AwTh for <json@ietfa.amsl.com>; Mon, 25 Nov 2013 01:38:13 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id ED3221ACCDF for <json@ietf.org>; Mon, 25 Nov 2013 01:38:12 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAP9bssl027834; Mon, 25 Nov 2013 18:37:54 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 74a4_411c_42ccf452_55b5_11e3_85f5_001e6722eec2; Mon, 25 Nov 2013 18:37:54 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 349E0BF521; Mon, 25 Nov 2013 18:37:54 +0900 (JST)
Message-ID: <52931A67.7010309@it.aoyama.ac.jp>
Date: Mon, 25 Nov 2013 18:37:43 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Allen Wirfs-Brock <allen@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> <EF7034DE-EA4D-43E4-9A5A-159E4A9DAB02@wirfs-brock.com>
In-Reply-To: <EF7034DE-EA4D-43E4-9A5A-159E4A9DAB02@wirfs-brock.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 25 Nov 2013 07:21:19 -0800
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>, Tim Bray <tbray@textuality.com>, "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: Mon, 25 Nov 2013 09:38:15 -0000

On 2013/11/23 1:54, Allen Wirfs-Brock wrote:
>
> 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.

That works for ECMA-404. It does not work for the IETF draft, because it 
is extremely relevant for application/json, which is part of that draft.

Regards,    Martin.