From presnick@qti.qualcomm.com Fri Nov 1 09:52:26 2013 Return-Path: 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 F3A8F11E831F for ; Fri, 1 Nov 2013 09:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 mJSt+SykbkLT for ; Fri, 1 Nov 2013 09:52:22 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 26A7911E8117 for ; Fri, 1 Nov 2013 09:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1383324742; x=1414860742; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wTGOQH9o6wPuC65NpQBoiVKrr9xPZKeATuI4oq4gAVo=; b=GMB9Bp24djgwzaAGG9WPNFtIE8UbWTKEgOQteQbnZQ+URkSZHskF/FWa RgNYZWm67jpmTanVJWv6vmhmRIcWDguv6Z3vvGsoQ4WDEfBeK/sK6wxrt q64e/UeClLkEoCtemun6A+8pyx2bPFJ06nacCryfY+8s7J7H92yNmRcBV Y=; X-IronPort-AV: E=McAfee;i="5400,1158,7245"; a="54933539" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 01 Nov 2013 09:52:21 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7245"; a="566607221" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Nov 2013 09:52:21 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 09:52:21 -0700 Message-ID: <5273DC44.3000500@qti.qualcomm.com> Date: Fri, 1 Nov 2013 09:52:20 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <52728545.6080009@qti.qualcomm.com> <5272C7C6.40305@qti.qualcomm.com> <527325DE.9030203@it.aoyama.ac.jp> In-Reply-To: <527325DE.9030203@it.aoyama.ac.jp> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] AD Review of draft-ietf-json-rfc4627bis-06 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:52:26 -0000 On 10/31/13 8:54 PM, "Martin J. Dürst" wrote: > Hello Pete, > > On 2013/11/01 6:12, Pete Resnick wrote: >> On 10/31/13 9:59 AM, Tim Bray wrote: > >>> To avoid duplication, I suggest adding this to the abstract: >>> >>> "This document makes no changes to the definition of JSON; it repairs >>> specification errors and offers experience-based interoperability >>> guidance." >> >> Remember that Abstracts get pulled out and put other places where the >> rest of the document does not appear. I think the important thing to >> note is that this is a replacement for 4627. >> >> No need to worry about duplication. It's common, and IMO reasonable, in >> the Abstract. > > In terms of content, some overlap between abstract and intro obviously > is necessary. However, I'd like to remind you of the discussion > starting at > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09936.html. Yes, though do see my contrite followup: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09945.html The point in that message was that the abstract was not explanatory enough. I believe the same is true in this case. Repeating a sentence to accomplish that is not a problem (IMO). Of course, having the Abstract identical to the Introduction is silly and not helpful. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From mamille2@cisco.com Sun Nov 3 11:02:59 2013 Return-Path: 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 C692A21F9FEE for ; Sun, 3 Nov 2013 11:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 WPkEhn3OlaMd for ; Sun, 3 Nov 2013 11:02:54 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5121D21F9DCF for ; Sun, 3 Nov 2013 11:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2296; q=dns/txt; s=iport; t=1383505374; x=1384714974; h=from:to:subject:date:message-id:mime-version; bh=luxlVQpmzj51Sew6af0bLynwiWIBSS2EkUYAyk3B+Zw=; b=m7XKJqzjO0sAN0M0HeUleP12pmwcIiPeZfYl74q/RFsO7x6D/nFwO64g vxOvgMMviuAHTEq3TuFG6KxvNY6iXJ0VqBcJ5A/6TNj5yN9ZY9TW5Nt5t QeM3bsOhJ9vWzLa9eWhcSYZ9MwnxO7FuHbE/1kw8xQMEsblgAweFQc5+5 s=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP+cdlKtJXHA/2dsb2JhbABZgwc4U79OgRsWdIIsZiUBgQAnBBwFh3MNnD+gfo9agyWBDgOQLoEwhiyBL5BagyaCKg X-IronPort-AV: E=Sophos;i="4.93,627,1378857600"; d="asc'?scan'208";a="279905717" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 03 Nov 2013 19:02:53 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA3J2rWM003970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 3 Nov 2013 19:02:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.43]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 13:02:53 -0600 From: "Matt Miller (mamille2)" To: JSON WG Thread-Topic: Agenda for IETF 88 (Now with Slides!) Thread-Index: AQHO2MdM/2njH6kQdEKOYdeTpPKqhQ== Date: Sun, 3 Nov 2013 19:02:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.146.138] Content-Type: multipart/signed; boundary="Apple-Mail=_25E21076-DF1B-490F-893E-FB5AC9B125FA"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Subject: [Json] Agenda for IETF 88 (Now with Slides!) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 19:02:59 -0000 --Apple-Mail=_25E21076-DF1B-490F-893E-FB5AC9B125FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Below is the current agenda for the session on Tuesday (11/05) at 13:00 = PST. Slides for all of the presentations are available in the = proceedings < http://www.ietf.org/proceedings/88/json.html >. -----BEGIN AGENDA----- JSON WG - IETF 88 Agenda =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tuesday, 5 November 2013, 13:00 - 14:00 PST (21:00 - 22:00 UTC) Plaza A - Hyatt Regency Vancouver, Vancouver, BC, Canada 1. Administrivia and Agenda Bashing - 5 min (Chairs) 2. WG Status - 10 min (Chairs) < http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-06 > - Status of Draft - Interactions with other SDOs 3. I-JSON - 10 min (Tim Bray) < http://tools.ietf.org/html/draft-bray-i-json-00 > 4. Documenting JSON in Protocols - 10 min (Barry Leiba) 5. JSON Schema Requirements - 10 min (Paul Hoffman) 6. Wrapping Up - 15 min (Chairs, AD) - Other Requests for Items to Consider - Questions to the Working Group -----END AGENDA----- -- Paul Hoffman and Matt Miller --Apple-Mail=_25E21076-DF1B-490F-893E-FB5AC9B125FA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSdp3dAAoJEDWi+S0W7cO1xWUIALjKNRs/5h3u+tBQPo8EhSja N+YVndiT+UtgVWYUcNHbofSkM4tXZxA8ivkQvBu4WMmq/SRKasQdnjOhYEdzO/G2 h35YtV1a1LDOb6WrkkhpaqufcYMU+5/5XrfFE/r51p9lCZAxPNBVerDrD3bwxYa0 fnkmH3b6mC7jYJ9EnLs43flR9gIY45+QQZbsiK8AVtWGngkg+in1PiWMTb/FrEuZ ZvuexCytdktJixODlRWW9NbcioZeE07cu+FX4R6EHuOZps7Izdwf9vUiU8M0uVnk Ok0GeQz69smndYnzcc2vVFHk/wEG/kimvEmLbeS4RVboWOY5YmuMbFj/dy/QV5g= =ivZ+ -----END PGP SIGNATURE----- --Apple-Mail=_25E21076-DF1B-490F-893E-FB5AC9B125FA-- From cabo@tzi.org Tue Nov 5 13:02:39 2013 Return-Path: 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 4DC0411E820F for ; Tue, 5 Nov 2013 13:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.376 X-Spam-Level: X-Spam-Status: No, score=-106.376 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 xebs6TF0CMo8 for ; Tue, 5 Nov 2013 13:02:33 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E1F5511E8110 for ; Tue, 5 Nov 2013 13:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA5L2PtI024344; Tue, 5 Nov 2013 22:02:25 +0100 (CET) Received: from dhcp-9c96.meeting.ietf.org (dhcp-9c96.meeting.ietf.org [31.133.156.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7DA17575; Tue, 5 Nov 2013 22:02:23 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11535B16508@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 5 Nov 2013 13:02:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <59FB1798-F272-418F-9317-F3AF36CA9125@tzi.org> References: <255B9BB34FB7D647A506DC292726F6E11535B16508@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1816) Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Revised I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 21:02:39 -0000 > "MUST be the first member of the object" >=20 > The spec cannot say a "urn:ietf:i-json" member must be first. Exactly. (And choosing a member name that starts with =93u=94 almost ensures it = will be near the end with some implementations.) > Section 2.2. Encoding and Characters >=20 > "SHOULD NOT include code points which identify > Control characters (Unicode section 2.4)" >=20 > I hope newline U+000A is acceptable in I-JSON, at least as "\n". = Newline is a control character so it clashes with this spec sentence. = Similarly with tab; presumably carriage return; probably form feed. Which newline is the canonical newline? That would need to be decided. Alternatively, we could decide I-JSON strings just don=92t do newlines. But either should be *very* explicit. I agree with I-JSON to rule out tabs and form feeds. Finally, ceterum censeo: 1e60 is not exactly representable in binary64. Neither is 1.1. The problem is not the lack of an exact representation, but reliance on exact representation where that is not possible. Gr=FC=DFe, Carsten From sakimura@gmail.com Tue Nov 5 13:53:14 2013 Return-Path: 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 6237B21F9FCE for ; Tue, 5 Nov 2013 13:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.369, 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 S1DcErZSNdbm for ; Tue, 5 Nov 2013 13:53:13 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5208621F9E26 for ; Tue, 5 Nov 2013 13:53:12 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id ea20so1746048lab.0 for ; Tue, 05 Nov 2013 13:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=s4vp20PRL5dFWasudc2ax+6menMCljqxzHiO32+6HYc=; b=v3Ne8RzxfHvHwvcS0IswhIe88dHbAJ0VYJ3nVJ3DE567hhPu05DSeWxNUGIDRa8w45 +oC15K0dI/6d1nQJS+dj0zIixiTfoMYUb7DgIQmzIN7jAglPSgT+M8JWl1guyJ9yMzxX ZzNWJeSPlOSK1byKZijjoLxUq2Br+C0FHJ7zDjjmxp5F2cdU01EFwc0dw4C9nJO2cSSr 1D+sX6ScPjSv2h7EoZQ1WlmOhe7HXgrizKx0hMLuiLgI0jKu5JLBfjG5zOONcKAwtT0E i7CY4G9M0BJrGgUUic7beQ2PTGaZ7TKtJqCABmoapD0xQL8kHiw5zC1+T8Fi4aW5kwiw HfBA== MIME-Version: 1.0 X-Received: by 10.112.29.147 with SMTP id k19mr262443lbh.9.1383688391187; Tue, 05 Nov 2013 13:53:11 -0800 (PST) Received: by 10.112.134.38 with HTTP; Tue, 5 Nov 2013 13:53:11 -0800 (PST) Date: Tue, 5 Nov 2013 13:53:11 -0800 Message-ID: From: Nat Sakimura To: json@ietf.org Content-Type: multipart/alternative; boundary=001a1133aa860961fb04ea750ffb Subject: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 21:53:14 -0000 --001a1133aa860961fb04ea750ffb Content-Type: text/plain; charset=ISO-8859-1 I have not been following the list very closely but has there been any discussion of defining a standard way of expressing link-relationship in JSON? We have one in HTML and HTTP and I view the lack of standard for this kind of thing for JSON as a shortcoming. In the rechartering, perhaps something like this can be considered? -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1133aa860961fb04ea750ffb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have not been following the list very closely but has th= ere been any discussion of defining a standard way of expressing link-relat= ionship in JSON?=A0

We have one in HTML and HTTP and I v= iew the lack of standard for this kind of thing for JSON as a shortcoming.= =A0

In the rechartering, perhaps something like this can be= considered?=A0

--
Nat Sakimura (=3Dnat= )
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a1133aa860961fb04ea750ffb-- From mnot@mnot.net Tue Nov 5 13:58:32 2013 Return-Path: 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 08C9221E8135 for ; Tue, 5 Nov 2013 13:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=-2.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 y+5zi+k72qTf for ; Tue, 5 Nov 2013 13:58:27 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D80C821E80DE for ; Tue, 5 Nov 2013 13:58:22 -0800 (PST) Received: from dhcp-b641.meeting.ietf.org (unknown [31.133.182.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DD81A22E259; Tue, 5 Nov 2013 16:58:15 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Mark Nottingham In-Reply-To: Date: Tue, 5 Nov 2013 13:58:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> References: To: Nat Sakimura X-Mailer: Apple Mail (2.1816) Cc: JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 21:58:32 -0000 It=92s been discussed from time to time by various people.=20 FWIW I just brought that possibility up obliquely in the discussion of = I-JSON (the WG is meeting right now), and several sour faces were made. Cheers, On 5 Nov 2013, at 1:53 pm, Nat Sakimura wrote: > I have not been following the list very closely but has there been any = discussion of defining a standard way of expressing link-relationship in = JSON?=20 >=20 > We have one in HTML and HTTP and I view the lack of standard for this = kind of thing for JSON as a shortcoming.=20 >=20 > In the rechartering, perhaps something like this can be considered?=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham http://www.mnot.net/ From nico@cryptonector.com Tue Nov 5 14:17:34 2013 Return-Path: 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 A528E11E80E3 for ; Tue, 5 Nov 2013 14:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] 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 fKTSAAMoNSmo for ; Tue, 5 Nov 2013 14:17:28 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id CBD6D11E8125 for ; Tue, 5 Nov 2013 14:17:23 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 2BD20438081; Tue, 5 Nov 2013 14:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=NZzL4GVToDfq8rXMge3pkB3AVNc=; b=ie1Bfrh+CEz q+qHaQiTNj2KnwMSIlbSJJSGkCATOYQ1r7uchGK1MgaksktY7PI86TA+/pWCwBFl rWs0df5vf+2/iJlUiOSIWwR1WWH+A1tqfHGDxUW8VQXBaV463EUrRy16q34GK7nS hbNbsHHCywGv9UPC5mPqGl4e2MUFEzKo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id D64B643807C; Tue, 5 Nov 2013 14:17:20 -0800 (PST) Date: Tue, 5 Nov 2013 16:17:18 -0600 From: Nico Williams To: Tim Bray Message-ID: <20131105221714.GM18713@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" Subject: Re: [Json] Revised I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:17:34 -0000 On Fri, Oct 25, 2013 at 03:20:01PM -0700, Tim Bray wrote: > I revised the I-JSON draft, too late for the Vancouver cutoff. Oh noes! > I tried to make it line up as exactly as possible with the 4627bis draf= t, > and say little more than =E2=80=9Call of those interop problems called = out in 4627 > draft, you MUST NOT do those things.=E2=80=9D - I don't think the self-ID thing is a good idea, and for objects the self-id name can't be required to come first (as others have noted). If this could work for objects surely it could work for arrays too. But I find self-IDs to be intrusive -- I'd have to write code to look for them and remove them if present, and possibly alter parser/app behavior. - "Objects in I-JSON messages MUST NOT have members with duplicate names." Did you mean that encoders must not emit dups? And what should parsers do if faced with dups? If nothing is said about what encoders and parsers must do then it seems like not a change from plain JSON. - re numbers: but should parsers be required to handle the full IEEE754 64-bit double range and precision? I think so, for I-JSON anyways, else this isn't an improvement over plain JSON. - Control characters... me too as to why not... - In general I-JSON should forbid encoders from producing that which you think is bad, and should require some specific parser behavior w.r.t. bad inputs. "MUST NOT trust" is hardly specific enough. - Many use-cases can't have a way to signal complaints to a sender that their JSON isn't I-JSON. Nico --=20 From sakimura@gmail.com Tue Nov 5 14:28:02 2013 Return-Path: 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 372F511E81E1 for ; Tue, 5 Nov 2013 14:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.328, 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 95Ns7r3NNYOL for ; Tue, 5 Nov 2013 14:28:01 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CA6F911E80E3 for ; Tue, 5 Nov 2013 14:28:00 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id c11so7096998lbj.17 for ; Tue, 05 Nov 2013 14:27:59 -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=WAUUMA06SnFBi9unOPOHVtwiKdgrjQZkQ+MBRugUG4g=; b=RzjeQkn6hK9lpjEMafYGIul0fyMAzXjuDWU3VRKUS8vd0X1lHWjhlUra5FiojgcRIA RhYQe9P7iwM8Ah88lKtXwLmgYlE62nuAwVCnSe2j6kD4pqohx8Es/J56g9BzQqHxRxzl UzlBQatPwkw/mrmhTVNScc4UYJBSBuLMeLe5fhUxHuWbdDlATUuNKBbGLADWIpC9qMpq givjAxUYj1F7OoBgd0o2WcjSy0Auw4ey8/nwbaSZElu+paVt0e4tIVV0DqS+KtUTi2cn lk4KXNk592x3zEicbXt3DEZqgsXH3LhKy1jFrywVb/c0nBzrWO/P1QIl+mHPPFQ7cipR tJkw== MIME-Version: 1.0 X-Received: by 10.152.235.8 with SMTP id ui8mr16852lac.55.1383690479763; Tue, 05 Nov 2013 14:27:59 -0800 (PST) Received: by 10.112.134.38 with HTTP; Tue, 5 Nov 2013 14:27:59 -0800 (PST) In-Reply-To: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> Date: Tue, 5 Nov 2013 14:27:59 -0800 Message-ID: From: Nat Sakimura To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a113457c08687f904ea758b16 Cc: JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:28:02 -0000 --001a113457c08687f904ea758b16 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Perhaps it was a bit too oblique that people did not appreciate the value :-) So many specs does the same thing differently. It is a good indication that there is a value in standardizing it. It may be a bit of effort to come to a consensus on a syntax, but it is the whole point of standardization. I strongly support an effort to create such a spec. 2013/11/5 Mark Nottingham > It=92s been discussed from time to time by various people. > > FWIW I just brought that possibility up obliquely in the discussion of > I-JSON (the WG is meeting right now), and several sour faces were made. > > Cheers, > > > On 5 Nov 2013, at 1:53 pm, Nat Sakimura wrote: > > > I have not been following the list very closely but has there been any > discussion of defining a standard way of expressing link-relationship in > JSON? > > > > We have one in HTML and HTTP and I view the lack of standard for this > kind of thing for JSON as a shortcoming. > > > > In the rechartering, perhaps something like this can be considered? > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Mark Nottingham http://www.mnot.net/ > > > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a113457c08687f904ea758b16 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Perhaps it was a bit too oblique that people did not = appreciate the value :-)

So many specs does the same th= ing differently.=A0
It is a good indication that there is a value in st= andardizing it.
It may be a bit of effort to come to a consensus on a syntax, but it i= s the whole point of standardization.=A0

I strongl= y support an effort to create such a spec.=A0


2013/11/5 Mark Nottingham <mnot@mnot.net>
It=92s been discussed from time to time by various people.

FWIW I just brought that possibility up obliquely in the discussion of I-JS= ON (the WG is meeting right now), and several sour faces were made.

Cheers,


On 5 Nov 2013, at 1:53 pm, Nat Sakimura <sakimura@gmail.com> wrote:

> I have not been following the list very closely but has there been any= discussion of defining a standard way of expressing link-relationship in J= SON?
>
> We have one in HTML and HTTP and I view the lack of standard for this = kind of thing for JSON as a shortcoming.
>
> In the rechartering, perhaps something like this can be considered? >
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham =A0 http= ://www.mnot.net/






--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a113457c08687f904ea758b16-- From cowan@ccil.org Tue Nov 5 14:37:59 2013 Return-Path: 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 71A0711E81EB for ; Tue, 5 Nov 2013 14:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.645 X-Spam-Level: X-Spam-Status: No, score=-3.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Yxk4uLQIPUK3 for ; Tue, 5 Nov 2013 14:37:52 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF0411E8160 for ; Tue, 5 Nov 2013 14:37:46 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VdpFl-0003go-I4; Tue, 05 Nov 2013 17:37:41 -0500 Date: Tue, 5 Nov 2013 17:37:41 -0500 From: John Cowan To: Nico Williams Message-ID: <20131105223741.GA11572@mercury.ccil.org> References: <20131105221714.GM18713@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131105221714.GM18713@localhost> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] Revised I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:37:59 -0000 Nico Williams scripsit: > - "Objects in I-JSON messages MUST NOT have members with duplicate > names." > > Did you mean that encoders must not emit dups? And what should > parsers do if faced with dups? If nothing is said about what > encoders and parsers must do then it seems like not a change from > plain JSON. Not at all. Plain JSON just says you may lose if you try this. MUST NOT means that all bets are off as far as conformance is concerned. It licenses the receiver to blow up if it receives such pseudo-I-JSON, or for that matter to blow up *the sender*. See and . -- A rabbi whose congregation doesn't want John Cowan to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan and a rabbi who lets them do it cowan@ccil.org isn't a man. --Jewish saying From tbray@textuality.com Tue Nov 5 14:40:51 2013 Return-Path: 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 15B3921E80D9 for ; Tue, 5 Nov 2013 14:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 EbK3-jiN2n8E for ; Tue, 5 Nov 2013 14:40:44 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 64E1D21E80AA for ; Tue, 5 Nov 2013 14:39:56 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id ia6so6094498vcb.35 for ; Tue, 05 Nov 2013 14:39:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FE2FhkYWB/T4L321JFDBX9wJhtEajtcTR2Bc2ZAGh+o=; b=Bl5wB7qFcSG8SfsMl5TIFBpSqG+9yu5GVNQWBwlgkjozXbY8TyC02f1HfPy0fbBwVl QyWH0ZWZ2kEB6DbMmi1iEAL/KR2nAQEti8dQ2K+7VFeYZ3pLMyYe0uf8SvqFf439FxbD C4Y1sMpf+NhIC8a7nju6ekaryreme0kUHoc9vSsLOYP4Jq4H4zKEI7s2gxsBtGPJpdf4 JnWmrZHT/EJV3XNEDo4WWdMqupD8UsYgcesI4On/V3eZXZnBtttQfRdv/67cq9MUZRky TJu9JlKsUt9tM19OI/YC16Yi/W/TIRIcA7zDntak0QLRwMxr/CAYp06OhHzg5krwo0v1 UtoA== X-Gm-Message-State: ALoCoQmB+FVt92XlwHNi2oiPXvGBhCks3ZEJsG+PBBmkjWBMs1B0w3SD/wrUxq3SIN4JBny349a+ MIME-Version: 1.0 X-Received: by 10.220.76.69 with SMTP id b5mr15628vck.85.1383691193774; Tue, 05 Nov 2013 14:39:53 -0800 (PST) Received: by 10.220.110.134 with HTTP; Tue, 5 Nov 2013 14:39:53 -0800 (PST) X-Originating-IP: [209.121.225.188] Received: by 10.220.110.134 with HTTP; Tue, 5 Nov 2013 14:39:53 -0800 (PST) In-Reply-To: References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> Date: Tue, 5 Nov 2013 14:39:53 -0800 Message-ID: From: Tim Bray To: "Nat Sakimura, (Google Drive)" Content-Type: multipart/alternative; boundary=001a11c200f0158f8f04ea75b650 Cc: Mark Nottingham , json@ietf.org Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:40:51 -0000 --001a11c200f0158f8f04ea75b650 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If I were going to add one thing to JSON, it would be built-in date/time literals. On Nov 5, 2013 2:28 PM, "Nat Sakimura" wrote: > Perhaps it was a bit too oblique that people did not appreciate the value > :-) > > So many specs does the same thing differently. > It is a good indication that there is a value in standardizing it. > It may be a bit of effort to come to a consensus on a syntax, but it is > the whole point of standardization. > > I strongly support an effort to create such a spec. > > > 2013/11/5 Mark Nottingham > >> It=E2=80=99s been discussed from time to time by various people. >> >> FWIW I just brought that possibility up obliquely in the discussion of >> I-JSON (the WG is meeting right now), and several sour faces were made. >> >> Cheers, >> >> >> On 5 Nov 2013, at 1:53 pm, Nat Sakimura wrote: >> >> > I have not been following the list very closely but has there been any >> discussion of defining a standard way of expressing link-relationship in >> JSON? >> > >> > We have one in HTML and HTTP and I view the lack of standard for this >> kind of thing for JSON as a shortcoming. >> > >> > In the rechartering, perhaps something like this can be considered? >> > >> > -- >> > Nat Sakimura (=3Dnat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >> > _______________________________________________ >> > json mailing list >> > json@ietf.org >> > https://www.ietf.org/mailman/listinfo/json >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a11c200f0158f8f04ea75b650 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If I were going to add one thing to JSON, it would be built-= in date/time literals.

On Nov 5, 2013 2:28 PM, "Nat Sakimura"= <sakimura@gmail.com> wrote= :
Perhaps it was a bit too oblique that people did not = appreciate the value :-)

So many specs does the same th= ing differently.=C2=A0
It is a good indication that there is a value in= standardizing it.
It may be a bit of effort to come to a consensus on a syntax, but it i= s the whole point of standardization.=C2=A0

I stro= ngly support an effort to create such a spec.=C2=A0


2013/11/5 Mark Nottingham <mnot@mnot.net>
It=E2=80=99s been discussed from time to time by various people.

FWIW I just brought that possibility up obliquely in the discussion of I-JS= ON (the WG is meeting right now), and several sour faces were made.

Cheers,


On 5 Nov 2013, at 1:53 pm, Nat Sakimura <sakimura@gmail.com> wrote:

> I have not been following the list very closely but has there been any= discussion of defining a standard way of expressing link-relationship in J= SON?
>
> We have one in HTML and HTTP and I view the lack of standard for this = kind of thing for JSON as a shortcoming.
>
> In the rechartering, perhaps something like this can be considered? >
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en
> _______________________________________________
> json mailing list
> json@ietf.org > https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham =C2=A0 h= ttp://www.mnot.net/






--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c200f0158f8f04ea75b650-- From mnot@mnot.net Tue Nov 5 14:47:19 2013 Return-Path: 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 0041C21F9DC9 for ; Tue, 5 Nov 2013 14:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UIGbifF5b04w for ; Tue, 5 Nov 2013 14:47:01 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5488321E808F for ; Tue, 5 Nov 2013 14:43:02 -0800 (PST) Received: from dhcp-9109.meeting.ietf.org (unknown [31.133.145.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1D7FA50A89; Tue, 5 Nov 2013 17:42:54 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Mark Nottingham In-Reply-To: Date: Tue, 5 Nov 2013 14:42:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> To: Nat Sakimura X-Mailer: Apple Mail (2.1816) Cc: JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:47:20 -0000 The problem that I see is that we=92re likely to need more than one = syntax. For example, if you want to serialise simple links, you could just do: =93_links": { =93foo=94: =93http://www.example.com=94 } But what if you need them to contain more information (target = attributes, as per RFC5988)? Then you=92d need: =93_links=94: { =93foo=94: { =93rel=94: =93http://www.example.com=94, =93type=94: =93text/xml=94 } } Or, what if you want to be able to express multiple links of the same = relation? Etc. There are a lot of trade-offs to be made in terms of = flexibility and readability that are fairly case-by-case. Furthermore, I question what utility there is in a standard link format = for JSON. Generic tools (i.e., those that don=92t understand the format = in use) will be able to find and exploit the links, but I wonder how = useful that is for JSON data.=20 I can imaging extending REDbot to do things with = links that follow a certain format in JSON, but that doesn=92t seem like = a tremendously compelling use case. Am I missing something? Cheers, On 5 Nov 2013, at 2:27 pm, Nat Sakimura wrote: > Perhaps it was a bit too oblique that people did not appreciate the = value :-) >=20 > So many specs does the same thing differently.=20 > It is a good indication that there is a value in standardizing it. > It may be a bit of effort to come to a consensus on a syntax, but it = is the whole point of standardization.=20 >=20 > I strongly support an effort to create such a spec.=20 >=20 >=20 > 2013/11/5 Mark Nottingham > It=92s been discussed from time to time by various people. >=20 > FWIW I just brought that possibility up obliquely in the discussion of = I-JSON (the WG is meeting right now), and several sour faces were made. >=20 > Cheers, >=20 >=20 > On 5 Nov 2013, at 1:53 pm, Nat Sakimura wrote: >=20 > > I have not been following the list very closely but has there been = any discussion of defining a standard way of expressing = link-relationship in JSON? > > > > We have one in HTML and HTTP and I view the lack of standard for = this kind of thing for JSON as a shortcoming. > > > > In the rechartering, perhaps something like this can be considered? > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham http://www.mnot.net/ From dret@berkeley.edu Tue Nov 5 15:07:56 2013 Return-Path: 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 F191411E8196 for ; Tue, 5 Nov 2013 15:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Xzhni3Fv9f3H for ; Tue, 5 Nov 2013 15:07:42 -0800 (PST) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id A034011E812A for ; Tue, 5 Nov 2013 15:07:18 -0800 (PST) Received: from [207.194.238.3] (helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VdpiJ-0006y5-7S; Tue, 05 Nov 2013 15:07:17 -0800 Message-ID: <52797A17.7060005@berkeley.edu> Date: Tue, 05 Nov 2013 15:07:03 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Nottingham , JSON WG References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:07:56 -0000 hello. On 2013-11-05, 14:42 , Mark Nottingham wrote: > Furthermore, I question what utility there is in a standard link format for JSON. Generic tools (i.e., those that don’t understand the format in use) will be able to find and exploit the links, but I wonder how useful that is for JSON data. and it may be educational to look in XML's direction. XML itself also does not have links. people usually do not even use the one predefined (but very limited) link framework that is fairly general and stable, which is XInclude. links are usually defined specifically for XML-based media types and described in whatever way that media type deems appropriate (often some mix of schema and documentation, sometimes using RFC5988 linking, sometimes other ways, and often combining both styles in the same media type). it looks like this has worked well so far. over at the w3c, http://www.w3.org/community/xmlhypermedia/ is an attempt to define some general hypermedia framework for XML, but it looks as if it hasn't produced a lot of results so far. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From mca@amundsen.com Tue Nov 5 15:15:19 2013 Return-Path: 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 C2DD021E80D9 for ; Tue, 5 Nov 2013 15:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] 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 jt9o+AaZLIcC for ; Tue, 5 Nov 2013 15:15:16 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id C90C511E812A for ; Tue, 5 Nov 2013 15:15:15 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id w61so4111173wes.38 for ; Tue, 05 Nov 2013 15:15:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=YRV2stUSLs69cDqGpUZaTROBZovs63dDNGnAy5GABII=; b=UIYdZD1vr6wahLiL//FzorGGNsNJoqQryxeGNVugbZ/b9ztkmfgggKe2bJC3E4BZ0Q pNEqez1qURBls2ZIaa8g+4eejmDwiozCkUtw2Xe9KXhgUbPkkJeIOq9T8LPAIvkYBlVh BWhOEvYxZhTDvIWhTbSwMGrMjaAuUcKIzqpp5st8QDAvlJI0N328CLDj8l6yXXuzMwV6 Tj8c0z5mBmDzeTxSIv3NqVdZOquEU4oGgdiP1tLQToXXnMgAwaPkcV2G1WJN0PfDtk2Z StH4Kw7RJtxcPkbjQ1BeW7DHU0m0zsMQU+BK5oTBzXbD6RKsxTa7nHAh4EOjmvn1vIcq FEZw== X-Gm-Message-State: ALoCoQkBP7KSGbjwc7pM3N5iOZZ9RzASK4jDX+dRQ0skuZtO6cXXUmeUgruXFOMp4C85zfcVStdI X-Received: by 10.180.160.240 with SMTP id xn16mr18638102wib.62.1383693314716; Tue, 05 Nov 2013 15:15:14 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.55.195 with HTTP; Tue, 5 Nov 2013 15:14:54 -0800 (PST) In-Reply-To: References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> From: mike amundsen Date: Tue, 5 Nov 2013 18:14:54 -0500 X-Google-Sender-Auth: 5rTJBG4cEXgET-HwR-_Aa2kkzr0 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=047d7b6251b0808e2a04ea763457 Cc: Nat Sakimura , JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:15:19 -0000 --047d7b6251b0808e2a04ea763457 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable IMO, it makes sense to discriminate between expressing links[1] and expressing hypermedia[2]. I'm not making a case for either, but pointing out that it would be wise to not conflate the two when discussing _how_ to express "links" [1] https://gist.github.com/mamund/7328055#file-links-v-hypermedia-js-L1 [2] https://gist.github.com/mamund/7328055#file-links-v-hypermedia-js-L9 mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mamund On Tue, Nov 5, 2013 at 5:42 PM, Mark Nottingham wrote: > The problem that I see is that we=92re likely to need more than one synta= x. > > For example, if you want to serialise simple links, you could just do: > > =93_links": { > =93foo=94: =93http://www.example.com=94 > } > > But what if you need them to contain more information (target attributes, > as per RFC5988)? > > Then you=92d need: > > =93_links=94: { > =93foo=94: { > =93rel=94: =93http://www.example.com=94, > =93type=94: =93text/xml=94 > } > } > > Or, what if you want to be able to express multiple links of the same > relation? Etc. There are a lot of trade-offs to be made in terms of > flexibility and readability that are fairly case-by-case. > > Furthermore, I question what utility there is in a standard link format > for JSON. Generic tools (i.e., those that don=92t understand the format i= n > use) will be able to find and exploit the links, but I wonder how useful > that is for JSON data. > > I can imaging extending REDbot to do things with > links that follow a certain format in JSON, but that doesn=92t seem like = a > tremendously compelling use case. Am I missing something? > > Cheers, > > > On 5 Nov 2013, at 2:27 pm, Nat Sakimura wrote: > > > Perhaps it was a bit too oblique that people did not appreciate the > value :-) > > > > So many specs does the same thing differently. > > It is a good indication that there is a value in standardizing it. > > It may be a bit of effort to come to a consensus on a syntax, but it is > the whole point of standardization. > > > > I strongly support an effort to create such a spec. > > > > > > 2013/11/5 Mark Nottingham > > It=92s been discussed from time to time by various people. > > > > FWIW I just brought that possibility up obliquely in the discussion of > I-JSON (the WG is meeting right now), and several sour faces were made. > > > > Cheers, > > > > > > On 5 Nov 2013, at 1:53 pm, Nat Sakimura wrote: > > > > > I have not been following the list very closely but has there been an= y > discussion of defining a standard way of expressing link-relationship in > JSON? > > > > > > We have one in HTML and HTTP and I view the lack of standard for this > kind of thing for JSON as a shortcoming. > > > > > > In the rechartering, perhaps something like this can be considered? > > > > > > -- > > > Nat Sakimura (=3Dnat) > > > Chairman, OpenID Foundation > > > http://nat.sakimura.org/ > > > @_nat_en > > > _______________________________________________ > > > json mailing list > > > json@ietf.org > > > https://www.ietf.org/mailman/listinfo/json > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b6251b0808e2a04ea763457 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
IMO, it makes sense to discriminate between expressing lin= ks[1] and expressing hypermedia[2].

I'm not making a= case for either, but pointing out that it would be wise to not conflate th= e two when discussing _how_ to express "links"





On Tue, Nov 5, 2013 at 5:42 PM, Mark Not= tingham <mnot@mnot.net> wrote:
The problem that I see is that we=92re likely to need more than one syntax.=

For example, if you want to serialise simple links, you could just do:

=93_links": {
=A0 =A0 =A0 =A0 =93foo=94: =93http://www.example.com=94
}

But what if you need them to contain more information (target attributes, a= s per RFC5988)?

Then you=92d need:

=93_links=94: {
=A0 =A0 =A0 =A0 =93foo=94: {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =93rel=94: =93http://www.example.com=94,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =93type=94: =93text/xml=94<= br> =A0 =A0 =A0 =A0 }
}

Or, what if you want to be able to express multiple links of the same relat= ion? Etc. There are a lot of trade-offs to be made in terms of flexibility = and readability that are fairly case-by-case.

Furthermore, I question what utility there is in a standard link format for= JSON. Generic tools (i.e., those that don=92t understand the format in use= ) will be able to find and exploit the links, but I wonder how useful that = is for JSON data.

I can imaging extending REDbot <http://redbot.org/> to do things with links that follow a c= ertain format in JSON, but that doesn=92t seem like a tremendously compelli= ng use case. Am I missing something?

Cheers,


On 5 Nov 2013, at 2:27 pm, Nat Sakimura <sakimura@gmail.com> wrote:

> Perhaps it was a bit too oblique that people did not appreciate the va= lue :-)
>
> So many specs does the same thing differently.
> It is a good indication that there is a value in standardizing it.
> It may be a bit of effort to come to a consensus on a syntax, but it i= s the whole point of standardization.
>
> I strongly support an effort to create such a spec.
>
>
> 2013/11/5 Mark Nottingham <mnot@mn= ot.net>
> It=92s been discussed from time to time by various people.
>
> FWIW I just brought that possibility up obliquely in the discussion of= I-JSON (the WG is meeting right now), and several sour faces were made. >
> Cheers,
>
>
> On 5 Nov 2013, at 1:53 pm, Nat Sakimura <sakimura@gmail.com> wrote:
>
> > I have not been following the list very closely but has there bee= n any discussion of defining a standard way of expressing link-relationship= in JSON?
> >
> > We have one in HTML and HTTP and I view the lack of standard for = this kind of thing for JSON as a shortcoming.
> >
> > In the rechartering, perhaps something like this can be considere= d?
> >
> > --
> > Nat Sakimura (=3Dnat)
> > Chairman, OpenID Foundation
> > http://nat= .sakimura.org/
> > @_nat_en
> > _______________________________________________
> > json mailing list
> > json@ietf.org
> > https://www.ietf.org/mailman/listinfo/json
>
> --
> Mark Nottingham =A0 http://www.mnot.net/
>
>
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham =A0 http= ://www.mnot.net/



_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7b6251b0808e2a04ea763457-- From nico@cryptonector.com Tue Nov 5 15:15:21 2013 Return-Path: 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 6B86F21E80E5 for ; Tue, 5 Nov 2013 15:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 gTJbxQHRrzGj for ; Tue, 5 Nov 2013 15:15:16 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7997E21E80D8 for ; Tue, 5 Nov 2013 15:15:16 -0800 (PST) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id EFC7D2005D108 for ; Tue, 5 Nov 2013 15:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=r/Rtl5nKoG3q6h8k2jf1 jhPl9so=; b=iGEUzI/BcryTxaNMjGFqxrIgKZzM6nXifvM4O3Dgfrx+j+LQ4MGU kQRiqJr9z2xWoeCVKdIK3Z9hSKSZQzLc2hKQezvjsAWuok+ftbOUwJBad71RLh4p oKQiSR+Tz3CT03aLiKyIk0BhZJvBMGcAdUMy5xRHYR83/hg0bTiIPn4= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 9C11E2005D106 for ; Tue, 5 Nov 2013 15:15:15 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id b13so4204554wgh.27 for ; Tue, 05 Nov 2013 15:15:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jljIJDW7xFLGrnBs7WuFlZO6JLV6aYNXW5tLzcFo8jI=; b=BG6f3JxlTzc6jtWbmDIKPXH2GGnWZkRwxQIPC/5AB1L9SqrP+u3b511Oz8jp8H4Y7k WorKmzGAiMxQtEPdXeTFE4GKFX/x5tRoXW+ievXr+J1+tB8rX2+sQ44V9ZIIfsC0FX9W XCZVKvcnN63iD8HpCeOMOL7pHcUvPDRHA4SfRpLg16Seyxzphgb2bDIEOi93tP2TiuHI GtVyNaScKOl28PE7fj+EepXf/B+FrpVBpBXjDpnxoTDZy4nWSULCnmvYvAuuMNZPjhTg UIG1oQuGtqhCeZHDDKKn3m4RuHjG+/OOx4dzeYpvQq78RjLhoDx1Qzwu2NE5HZ6n/m4b a5MQ== MIME-Version: 1.0 X-Received: by 10.194.171.34 with SMTP id ar2mr119203wjc.81.1383693313866; Tue, 05 Nov 2013 15:15:13 -0800 (PST) Received: by 10.216.151.136 with HTTP; Tue, 5 Nov 2013 15:15:13 -0800 (PST) In-Reply-To: References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> Date: Tue, 5 Nov 2013 17:15:13 -0600 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , "Nat Sakimura, \(Google Drive\)" , "json@ietf.org" Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 23:15:21 -0000 On Tue, Nov 5, 2013 at 4:39 PM, Tim Bray wrote: > If I were going to add one thing to JSON, it would be built-in date/time > literals. I think the idea is to add schema for links, not to extend JSON itself to denote links (or comments, or add new value types, or...). Proponents really ought to be clear on this point... Specifying schemas requires a schema language. Well, it could be done in prose but... Nico -- From mamille2@cisco.com Tue Nov 5 16:22:59 2013 Return-Path: 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 1353221E808F for ; Tue, 5 Nov 2013 16:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.901 X-Spam-Level: X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, WEIRD_QUOTING=1.396] 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 IDTI60V1Xzue for ; Tue, 5 Nov 2013 16:22:54 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 13DA011E8125 for ; Tue, 5 Nov 2013 16:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6403; q=dns/txt; s=iport; t=1383697374; x=1384906974; h=from:to:subject:date:message-id:mime-version; bh=k35QH8wJrcwwS1d9g3vWNK6duJcu25VPtUwHQJIi1e8=; b=I5zdZfQbTot24iiTQbiGcvs31MzNzA95l25eLjV6T5sehb4EyfZVMovr 7zm5vxkcx8YH3xkniEA4qjZiFgk42d8nub8LeoLNeTXtHNhvJrtF/Z2pZ ATaYVcc7df1EpgmHIGwsFWluSuVKlyzVTLxmbncirKKJTKOrSeOocfFq+ E=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAI2KeVKtJV2Z/2dsb2JhbABZgwc4U8BtFnSCLB1RHQEaZhcQBBwFh3MNnR2hRpMAgQ8DkC6BMIYskgmDJoIq X-IronPort-AV: E=Sophos;i="4.93,642,1378857600"; d="asc'?scan'208";a="280976857" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 06 Nov 2013 00:22:53 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA60Mrbj003819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Nov 2013 00:22:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 18:22:52 -0600 From: "Matt Miller (mamille2)" To: JSON WG Thread-Topic: Minutes from IETF 88 Thread-Index: AQHO2oZUzQVsmRyUjkiguVECQrw3Zg== Date: Wed, 6 Nov 2013 00:22:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.115.46] Content-Type: multipart/signed; boundary="Apple-Mail=_3D841176-CA2A-4B45-A0D2-68F39B0645F7"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Subject: [Json] Minutes from IETF 88 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:22:59 -0000 --Apple-Mail=_3D841176-CA2A-4B45-A0D2-68F39B0645F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Below are the minutes from the JSON WG meeting at IETF 88, which have = also been posted to the proceedings page at < = http://www.ietf.org/proceedings/88/minutes/minutes-88-json >. Please = send corrections and updates to the list or the chairs directly. Thanks! - Paul Hoffman and Matt Miller -----BEGIN MINUTES----- JSON WG - IETF 88 Vancouver =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2013-11-05 @ 13:00-14:00 PST [ Thanks to Andrew Biggs for taking minutes, Joe Hildebrand for Jabber monitoring ] 1. WG Draft Status '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Chairs summarized state of working group since IETF 87. Virtual meeting held in late August, where WG decided on an approach to completing 4627bis. For each major issue: * discuss what the most interoperable approach is * note the known common interoperability challenges The current document reflects the consensus of the WG to date. AD completed review just before the meeting, with a couple of nits: * Update the abstract * Update the UNICODE reference Regarding the UNICODE reference, there is a question of which reference the document should use: 1) Use UNICODE preferred "latest version" URL (aka "version-less") 2) Use UNICODE version 4.0 (what RFC 4627 contains today) 3) Use UNICODE version 6.3 (what EMCA-404 contains) The consensus in the room is for #1, but to also include a short rationale for using a version-less reference. The suggestion in the room is for something like: """" We do not expect future changes in the UNICODE specification to impact the grammar """" The next step is for Tim to publish 4627bis-07 with the AD nits addressed, then the Chairs will request Pete Resnick to move forward with IETF Last Call. 2. SDO Interaction Status '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Ecma International recently published ECMA-404: The JSON Data Interchange Format. The document matches the syntax of 4627 (and 4627bis) except for what is allowed at the top-level: 4627bis keeps the limitation from 4627 of only object or array, and EMCA-404 allows for any JSON value. ECMA-404 does not contain any the semantics or interoperability discussions. Ecma International and W3C Technical Architecture Group (TAG) expressed some concern about forking of specifications, but neither group has formally requested a change or discussion. Wendy Seltzer (W3C liaison to IETF) stated that she does not expect a formal statement to come from the W3C. 3. I-JSON '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Tim Bray presented on I-JSON, a profile of 4627bis that enforces certain limits that match the interoperability suggestions from 4627bis. Some discussion on the technical merits and weaknesses of I-JSON, however the Chairs requested the meeting focus on the interest or objection to such work in general. In the room, there appears to be interest in moving forward on a profile of JSON. Mark Nottingham (IETF liaison to W3C) suggested that there would be significant interest in this from the W3C TAG. 4. Documenting JSON in Protocols '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Barry Leiba presented on the need for a standard format that protocol documents follow to describe their JSON data. Included in the presentation was one possible approach. Andy Newton pointed out that he has a (now expired) draft that defines a formal language (draft-newton-json-content-rules). There was general consensus in the room that some type of description format is worthwhile. 5. JSON Schema Requirements '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Paul Hoffman presented on a possible approach for defining schema requirements (but not the schema itself). The proposal does not itself call for an actual document to be ratified, per se, but to be used as input on defining a schema. Some came to the microphone to describe actual harm done by schemas for other formats (most notably XML). The consensus in the room is that working on schema requirements is not a worthwhile activity of the WG, and might be harmfully distracting. 6. Wrapping up - Other Items '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Larry Masinter requested the WG consider a Guidelines document for not only how to use JSON, but also describe when it might be appropriate (or not) to use JSON versus other common data formats. The Chairs agreed to bring this item up to the Working Group. No other requests for Working Group items were made in the room. 7. Wrapping up - Questions to WG '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' Because of the large amount of participation on the mailing list, no questions on specific work items was made in the room. The chairs did ask the following: * Is anyone interested in reviewing documents? (several hands) * Is anyone interested in providing text or authoring documents? (much fewer hands) The Chairs and AD will come up with a list of specific questions, then provide an initial charter proposal to submit to the WG. -----END MINUTES----- --Apple-Mail=_3D841176-CA2A-4B45-A0D2-68F39B0645F7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSeYvbAAoJEDWi+S0W7cO16S0IALs6sJLh31Z3VvNaYJL5Kg/j WWfAYxB5dX1Yd3JS7X2LSTTtwRNGmTD+IxTSLPy/DMr4O5NpPAAfyy4vduPRX5jD oG43x+OboeOw1Ad0eZAAwE4IM7rUCdXnTH08DuB8aHqiflRlalXEvjD+SR8XM0yM VkV4uWn3aRmIDCRG5bsyEyAmPdNDT3BnO6wgv7w5BmfV1OP3fIzzFr2mV01BjF9P /Sy2vpjcy2yJ+B4hPkmWsnthyITMldAuxAqJUGXs+p2TwEfJyXjQdMEhD9hG/Fvc LCjKYUMABNJBTDveMoID3VJndripdG4IyP0fClHKMb3CfT2OrBiPwyZweJnZ9z0= =22/U -----END PGP SIGNATURE----- --Apple-Mail=_3D841176-CA2A-4B45-A0D2-68F39B0645F7-- From sakimura@gmail.com Tue Nov 5 17:09:23 2013 Return-Path: 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 6FBD211E818C for ; Tue, 5 Nov 2013 17:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 sg6WADFhdsf1 for ; Tue, 5 Nov 2013 17:09:22 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2374921E80C4 for ; Tue, 5 Nov 2013 17:09:11 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id x18so7330407lbi.30 for ; Tue, 05 Nov 2013 17:09:11 -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=bXL/6AzUjgt8/BocISnzRN0C4BI+5pyhJ9/OQtNWXU4=; b=t+Lr2CZcsaFL+nzLx+HtykHqIiLurA/3Sfly+npMKw4WWkZNEl0qWemfzj/+/CSBsU AIKvVDGOKaYI4bLy+NfUR8BgEcnoMen9UninvOrKyv/sO64PpXt9Ll2rrpnv9EX0GqlM MJYEPH1h1kE4e/Ck0RS/AKxx4Y34VyOIqGMCff1A+ASQAC6/TrtYmSsEU/XuYTeaHJuT KL6OHWr3QwxH7AYdSmLdEULSVeJ1b3UZLfRI4fQyyFe1woAwVVgtjeqaOmE87v4De06e 7pR4rwSBTnjkEH6liGZ9gtX0HhIzU4riuwkttfMdEyteNfU+WAKPwuCeFGeHeX8lzAat qq5A== MIME-Version: 1.0 X-Received: by 10.112.52.33 with SMTP id q1mr703039lbo.30.1383700150989; Tue, 05 Nov 2013 17:09:10 -0800 (PST) Received: by 10.112.134.38 with HTTP; Tue, 5 Nov 2013 17:09:10 -0800 (PST) In-Reply-To: References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> Date: Tue, 5 Nov 2013 17:09:10 -0800 Message-ID: From: Nat Sakimura To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c3c882f9bb8b04ea77cb7c Cc: Mark Nottingham , Tim Bray , "json@ietf.org" Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:09:23 -0000 --001a11c3c882f9bb8b04ea77cb7c Content-Type: text/plain; charset=ISO-8859-1 Right. I am merely asking for a standard way of writing link-rel in JSON. I am not talking about extending JSON. Schema language is nice, but this is simple enough that we can just write it down in plain English. A straw-man is here: http://tools.ietf.org/id/draft-sakimura-json-meta-01.html 2013/11/5 Nico Williams > On Tue, Nov 5, 2013 at 4:39 PM, Tim Bray wrote: > > If I were going to add one thing to JSON, it would be built-in date/time > > literals. > > I think the idea is to add schema for links, not to extend JSON itself > to denote links (or comments, or add new value types, or...). > Proponents really ought to be clear on this point... > > Specifying schemas requires a schema language. Well, it could be done > in prose but... > > Nico > -- > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c3c882f9bb8b04ea77cb7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Right. I am merely asking for a standard way of writing li= nk-rel in JSON.=A0
I am not talking about extending JSON.=A0
=
Schema language is nice, but this is simple enough that we c= an just write it down in plain English. A straw-man is here:=A0http://tools.ietf= .org/id/draft-sakimura-json-meta-01.html




2013/11/5 Nico Williams <nico@cryptonector.com<= /a>>
On Tue, Nov 5, 2013 at 4:3= 9 PM, Tim Bray <tbray@textuality= .com> wrote:
> If I were going to add one thing to JSON, it would be built-in date/ti= me
> literals.

I think the idea is to add schema for links, not to extend JSON itsel= f
to denote links (or comments, or add new value types, or...).
Proponents really ought to be clear on this point...

Specifying schemas requires a schema language. =A0Well, it could be done in prose but...

Nico
--



--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c3c882f9bb8b04ea77cb7c-- From sakimura@gmail.com Tue Nov 5 17:12:53 2013 Return-Path: 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 4DB4D21E80F1 for ; Tue, 5 Nov 2013 17:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 QwSKf76D9-ng for ; Tue, 5 Nov 2013 17:12:52 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id AA28D21E80CA for ; Tue, 5 Nov 2013 17:12:51 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id eh20so4850727lab.40 for ; Tue, 05 Nov 2013 17:12:50 -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=Uom0aJtpszMaCdDsdnWTAM5PJrjBOF3Emo7dqhDzW8g=; b=K/MIu0LsL1F05AFUy1um3SR6rb6qLoR8pvGmV1l+DDumDk1Q4/PiuD9i0f/0WbzybK sBVXurINYNYkOsc8oO418FkMapxqPRJwgD7hXMOKHvnQgqglovXeMIrXOPvfkpvt5VGl gZaCyqe59gWT+ppColRybp4Nd2q+CSwzEwjvv0Vc1cWDXTWrmO8Heokag4H84cg8XP7r MougxrdTM25I+IMznA4ToOyvxLKPjxkn8PI89wc/7lhCHs2hZI/fzKLyhk04MaSC5HFm QWprFmGpYeywDPrCSV2/8JxZ+84+B/tHzL0q2MxzE/Y3jfpF66cJ7WZuMlihF+nfWC2G sW3Q== MIME-Version: 1.0 X-Received: by 10.112.29.147 with SMTP id k19mr682538lbh.9.1383700370512; Tue, 05 Nov 2013 17:12:50 -0800 (PST) Received: by 10.112.134.38 with HTTP; Tue, 5 Nov 2013 17:12:50 -0800 (PST) In-Reply-To: References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> Date: Tue, 5 Nov 2013 17:12:50 -0800 Message-ID: From: Nat Sakimura To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a1133aa860f620404ea77d930 Cc: JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:12:53 -0000 --001a1133aa860f620404ea77d930 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable For multiple links, would not something like this do? "_links":{ "replies":[ { "href":"http://example.com/message/123", "type":"text/xml" }, { "href":"http://example.com/message/342", "type":"text/xml" } ] } I see something like this is being invented many times for each protocol. e.g., WebFinger, SCIM. I think it would be useful for something like OAuth as well. For example, if we have something like this in the token response, then it will be able to return the resource endpoint on which the access token will be used, and this resource endpoint may change depending on the users etc. dynamically. Currently, it is quite static. Yes, it can be done with RFC5988 in the case of HTTP binding, but if it were bound to other protocols, having such link relationship in the JSON itself would be useful, IMHO. 2013/11/5 Mark Nottingham > The problem that I see is that we=92re likely to need more than one synta= x. > > For example, if you want to serialise simple links, you could just do: > > =93_links": { > =93foo=94: =93http://www.example.com=94 > } > > But what if you need them to contain more information (target attributes, > as per RFC5988)? > > Then you=92d need: > > =93_links=94: { > =93foo=94: { > =93rel=94: =93http://www.example.com=94, > =93type=94: =93text/xml=94 > } > } > > Or, what if you want to be able to express multiple links of the same > relation? Etc. There are a lot of trade-offs to be made in terms of > flexibility and readability that are fairly case-by-case. > > Furthermore, I question what utility there is in a standard link format > for JSON. Generic tools (i.e., those that don=92t understand the format i= n > use) will be able to find and exploit the links, but I wonder how useful > that is for JSON data. > > I can imaging extending REDbot to do things with > links that follow a certain format in JSON, but that doesn=92t seem like = a > tremendously compelling use case. Am I missing something? > > Cheers, > > > On 5 Nov 2013, at 2:27 pm, Nat Sakimura wrote: > > > Perhaps it was a bit too oblique that people did not appreciate the > value :-) > > > > So many specs does the same thing differently. > > It is a good indication that there is a value in standardizing it. > > It may be a bit of effort to come to a consensus on a syntax, but it is > the whole point of standardization. > > > > I strongly support an effort to create such a spec. > > > > > > 2013/11/5 Mark Nottingham > > It=92s been discussed from time to time by various people. > > > > FWIW I just brought that possibility up obliquely in the discussion of > I-JSON (the WG is meeting right now), and several sour faces were made. > > > > Cheers, > > > > > > On 5 Nov 2013, at 1:53 pm, Nat Sakimura wrote: > > > > > I have not been following the list very closely but has there been an= y > discussion of defining a standard way of expressing link-relationship in > JSON? > > > > > > We have one in HTML and HTTP and I view the lack of standard for this > kind of thing for JSON as a shortcoming. > > > > > > In the rechartering, perhaps something like this can be considered? > > > > > > -- > > > Nat Sakimura (=3Dnat) > > > Chairman, OpenID Foundation > > > http://nat.sakimura.org/ > > > @_nat_en > > > _______________________________________________ > > > json mailing list > > > json@ietf.org > > > https://www.ietf.org/mailman/listinfo/json > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Mark Nottingham http://www.mnot.net/ > > > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1133aa860f620404ea77d930 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
For multiple links, would not something like this do?

"_links":{
=A0 =A0 "replies":[
=A0 =A0 =A0 =A0 {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "href":"http://example.c= om/message/123",
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 "type":"text/xml"
=A0 = =A0 =A0 =A0 },=A0
=A0 =A0 =A0 =A0 {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "href":"http://example.c= om/message/342",
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 "type":"text/xml"
=A0 = =A0 =A0 =A0 }
=A0 =A0 ]
}

I see something like this is being invented many times for each protocol.= =A0
e.g., WebFinger, SCIM. I think it would be useful for something lik= e OAuth as well. For example, if we have something like this in the token r= esponse,=A0
t= hen it will be able to return the resource endpoint on which the access tok= en will be used, and this resource endpoint may change depending on the use= rs etc. dynamically.=A0
C= urrently, it is quite static. Yes, it can be done with RFC5988 in the case = of HTTP binding, but if it were bound to other protocols, having such link = relationship in the JSON itself would be useful, IMHO.=A0


2013/11= /5 Mark Nottingham <mnot@mnot.net>
The problem that I see is that we=92re likely to need more than one syntax.=

For example, if you want to serialise simple links, you could just do:

=93_links": {
=A0 =A0 =A0 =A0 =93foo=94: =93http://www.example.com=94
}

But what if you need them to contain more information (target attributes, a= s per RFC5988)?

Then you=92d need:

=93_links=94: {
=A0 =A0 =A0 =A0 =93foo=94: {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =93rel=94: =93http://www.example.com=94,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =93type=94: =93text/xml=94<= br> =A0 =A0 =A0 =A0 }
}

Or, what if you want to be able to express multiple links of the same relat= ion? Etc. There are a lot of trade-offs to be made in terms of flexibility = and readability that are fairly case-by-case.

Furthermore, I question what utility there is in a standard link format for= JSON. Generic tools (i.e., those that don=92t understand the format in use= ) will be able to find and exploit the links, but I wonder how useful that = is for JSON data.

I can imaging extending REDbot <http://redbot.org/> to do things with links that follow a c= ertain format in JSON, but that doesn=92t seem like a tremendously compelli= ng use case. Am I missing something?

Cheers,


On 5 Nov 2013, at 2:27 pm, Nat Sakimura <sakimura@gmail.com> wrote:

> Perhaps it was a bit too oblique that people did not appreciate the va= lue :-)
>
> So many specs does the same thing differently.
> It is a good indication that there is a value in standardizing it.
> It may be a bit of effort to come to a consensus on a syntax, but it i= s the whole point of standardization.
>
> I strongly support an effort to create such a spec.
>
>
> 2013/11/5 Mark Nottingham <mnot@mn= ot.net>
> It=92s been discussed from time to time by various people.
>
> FWIW I just brought that possibility up obliquely in the discussion of= I-JSON (the WG is meeting right now), and several sour faces were made. >
> Cheers,
>
>
> On 5 Nov 2013, at 1:53 pm, Nat Sakimura <sakimura@gmail.com> wrote:
>
> > I have not been following the list very closely but has there bee= n any discussion of defining a standard way of expressing link-relationship= in JSON?
> >
> > We have one in HTML and HTTP and I view the lack of standard for = this kind of thing for JSON as a shortcoming.
> >
> > In the rechartering, perhaps something like this can be considere= d?
> >
> > --
> > Nat Sakimura (=3Dnat)
> > Chairman, OpenID Foundation
> > http://nat= .sakimura.org/
> > @_nat_en
> > _______________________________________________
> > json mailing list
> > json@ietf.org
> > https://www.ietf.org/mailman/listinfo/json
>
> --
> Mark Nottingham =A0 http://www.mnot.net/
>
>
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham =A0 http= ://www.mnot.net/






--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en
--001a1133aa860f620404ea77d930-- From mnot@mnot.net Tue Nov 5 17:15:35 2013 Return-Path: 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 33C9D11E818C for ; Tue, 5 Nov 2013 17:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.316 X-Spam-Level: X-Spam-Status: No, score=-104.316 tagged_above=-999 required=5 tests=[AWL=-1.717, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 wuAPbsUHqHPS for ; Tue, 5 Nov 2013 17:15:30 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0920311E8210 for ; Tue, 5 Nov 2013 17:15:30 -0800 (PST) Received: from dhcp-b641.meeting.ietf.org (unknown [31.133.182.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 03C2A22E256; Tue, 5 Nov 2013 20:15:28 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Mark Nottingham In-Reply-To: Date: Tue, 5 Nov 2013 17:15:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5233254B-21BA-4311-BBC6-B23246727516@mnot.net> References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> To: Nat Sakimura X-Mailer: Apple Mail (2.1816) Cc: JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:15:35 -0000 On 5 Nov 2013, at 5:12 pm, Nat Sakimura wrote: > For multiple links, would not something like this do? >=20 > "_links":{ > "replies":[ > { > "href":"http://example.com/message/123", > "type":"text/xml" > },=20 > { > "href":"http://example.com/message/342", > "type":"text/xml" > } > ] > } In some cases, yes. However, if you don=92t need the ability to have = multiple relations of the same type, it=92s needlessly verbose, and the = API for pulling out values gets more complex. That=92s going to cause = friction. Cheers, -- Mark Nottingham http://www.mnot.net/ From sakimura@gmail.com Tue Nov 5 17:53:34 2013 Return-Path: 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 AB6B811E8205 for ; Tue, 5 Nov 2013 17:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 GSvaGo2Uee14 for ; Tue, 5 Nov 2013 17:53:30 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E4F9F21F9DCF for ; Tue, 5 Nov 2013 17:52:46 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id w7so7147068lbi.4 for ; Tue, 05 Nov 2013 17:52:45 -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=V0Vi10sqhLWzdIcO0wK+/4jX+OwhU/6qdLoNwXwCtIc=; b=Fd/zkBmOUw4ce6iloAFOaWlQnf+bAtagZcGO9wc5IVRjtR7wCZbgQGbM7EukEiDDOn FY/A7lrC485DdWc2Y5RVX/9izUG9VZz4pmeQnr8P4jrlOFVcO1AeoQlHKupw3auUBrMq VoV61iF3nGTiME6smNPZbceDrNv/eWn5MUD5vTD+kCqn4q6TVvGxf4Vj0prcSm48mStw 1aVm+W1eVmz2s2YHc1ABE+SGkyKYuOl2Cg1M/eguYQmnkBEDx9KC6AwoOOdHFJfGLnE3 7PYtJMHVLTe2AvP/Cf6lFmIZXeyyuK1F+8D+PHq4UGyVW7URiko56j40b9pZaUHWyBJX 4zsw== MIME-Version: 1.0 X-Received: by 10.112.169.33 with SMTP id ab1mr26016lbc.43.1383702765824; Tue, 05 Nov 2013 17:52:45 -0800 (PST) Received: by 10.112.134.38 with HTTP; Tue, 5 Nov 2013 17:52:45 -0800 (PST) In-Reply-To: <5233254B-21BA-4311-BBC6-B23246727516@mnot.net> References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> <5233254B-21BA-4311-BBC6-B23246727516@mnot.net> Date: Tue, 5 Nov 2013 17:52:45 -0800 Message-ID: From: Nat Sakimura To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a11c26306d4f25c04ea786742 Cc: JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 01:53:34 -0000 --001a11c26306d4f25c04ea786742 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2013/11/5 Mark Nottingham > > On 5 Nov 2013, at 5:12 pm, Nat Sakimura wrote: > > > For multiple links, would not something like this do? > > > > "_links":{ > > "replies":[ > > { > > "href":"http://example.com/message/123", > > "type":"text/xml" > > }, > > { > > "href":"http://example.com/message/342", > > "type":"text/xml" > > } > > ] > > } > > In some cases, yes. However, if you don=92t need the ability to have > multiple relations of the same type, it=92s needlessly verbose, and the A= PI > for pulling out values gets more complex. That=92s going to cause frictio= n. > Right. I was debating whether it should always be an array, or could it be a single object. Requiring it to be always an array makes the JSON stub a bit verbose like you say. On the other hand, f it is either an array or an object, then the code has to test the type to start with. So there is a trade-off for sure. However, it probably is not much effort after all to write a code to deal with it so either seems to be fine. Best, Nat > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c26306d4f25c04ea786742 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



2013/11/5 Mark Nottingham <mnot@mnot.net>

On 5 Nov 2013, at 5:12 pm, Nat Sakimura <sakimura@gmail.com> wrote:

> For multiple links, would not something like this do?
>
> "_links":{
> =A0 =A0 "replies":[
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "href":"http://example.com/message/123",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "type":"text/xml"
> =A0 =A0 =A0 =A0 },
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "href":"http://example.com/message/342",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "type":"text/xml"
> =A0 =A0 =A0 =A0 }
> =A0 =A0 ]
> }

In some cases, yes. However, if you don=92t need the ability to have = multiple relations of the same type, it=92s needlessly verbose, and the API= for pulling out values gets more complex. That=92s going to cause friction= .

Right. I was debating whether it should al= ways be an array, or could it be a single object. Requiring it to be always= an array makes the JSON stub a bit verbose like you say. On the other hand= , f it is either an array or an object, then the code has to test the type = to start with. So there is a trade-off for sure.=A0

However, it probably is not much effort after all to wr= ite a code to deal with it so either seems to be fine. =A0



--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en
--001a11c26306d4f25c04ea786742-- From duerst@it.aoyama.ac.jp Tue Nov 5 22:08:40 2013 Return-Path: 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 A080B21E80A8 for ; Tue, 5 Nov 2013 22:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=-2.112, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 eokhIAh4TcHp for ; Tue, 5 Nov 2013 22:08:34 -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 EE38011E80F8 for ; Tue, 5 Nov 2013 22:08:33 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rA668Nta007307; Wed, 6 Nov 2013 15:08:23 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 7856_7f1c_d7e9751c_46a9_11e3_a4a6_001e6722eec2; Wed, 06 Nov 2013 15:08:23 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 23F92BF521; Wed, 6 Nov 2013 15:08:23 +0900 (JST) Message-ID: <5279DCC2.3090800@it.aoyama.ac.jp> Date: Wed, 06 Nov 2013 15:08:02 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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: Erik Wilde References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> <52797A17.7060005@berkeley.edu> In-Reply-To: <52797A17.7060005@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Mark Nottingham , JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 06:08:40 -0000 Hello Erik, On 2013/11/06 8:07, Erik Wilde wrote: > hello. > > On 2013-11-05, 14:42 , Mark Nottingham wrote: >> Furthermore, I question what utility there is in a standard link >> format for JSON. Generic tools (i.e., those that don=E2=80=99t underst= and the >> format in use) will be able to find and exploit the links, but I >> wonder how useful that is for JSON data. > > and it may be educational to look in XML's direction. XML itself also > does not have links. people usually do not even use the one predefined > (but very limited) link framework that is fairly general and stable, > which is XInclude. Did you mean XLink? XInclude also uses links, but the general=20 functionality it provides isn't linking, it's inclusion (as the name says= ). Otherwise, I agree with you. The lesson may be that requirements on=20 links vary too much from application to application (see e.g. Mark's=20 examples), compared with the relatively negligible implementation=20 savings from shared syntax. What's expensive when implementing linking=20 is the 'back end', e.g. caching, network access, and so on, and that can=20 still be (and in most cases is) shared inside an implementation. Regards, Martin. > links are usually defined specifically for XML-based > media types and described in whatever way that media type deems > appropriate (often some mix of schema and documentation, sometimes usin= g > RFC5988 linking, sometimes other ways, and often combining both styles > in the same media type). it looks like this has worked well so far. > > over at the w3c, http://www.w3.org/community/xmlhypermedia/ is an > attempt to define some general hypermedia framework for XML, but it > looks as if it hasn't produced a lot of results so far. > > cheers, > > dret. > From markus.lanthaler@gmx.net Wed Nov 6 07:41:16 2013 Return-Path: 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 97C2E21E8082 for ; Wed, 6 Nov 2013 07:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 k6e57M0dGvbh for ; Wed, 6 Nov 2013 07:41:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id D38EC11E81A2 for ; Wed, 6 Nov 2013 07:41:06 -0800 (PST) Received: from Vostro3500 ([178.115.129.229]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MIdYi-1VbtN32N32-002Dly for ; Wed, 06 Nov 2013 16:41:06 +0100 From: "Markus Lanthaler" To: "'Mark Baker'" , "'Erik Wilde'" References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> In-Reply-To: Date: Wed, 6 Nov 2013 16:41:02 +0100 Message-ID: <028d01cedb06$9a063d70$ce12b850$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7a+2/woU6c0blBSeKSJnKpzRFO3QAColqQ Content-Language: de X-Provags-ID: V03:K0:HVEMj8zJC7diQaDD11clVZF9pm+ek0qPDB5sB8r/4hpRhW5ROp+ UjP2/Z7oNt+J3dTnx4ib8sJa06qXH33+SqKpPUSPeVvkW98ZTn59GoobXD+f8bKm3dYNcfr zkrEonYtYsECQKyMheyAYRJluEwlGmvtoYF/EbxI5XMlqDpwB6sGhUU0zMjEHshGT+ysJfh xa4Y6v64aB+CLhB5E5XOg== Cc: apps-discuss@ietf.org, 'JSON WG' Subject: Re: [Json] [apps-discuss] proposal: adding profile support to JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:41:16 -0000 On Wednesday, November 06, 2013 3:21 PM, Mark Baker wrote: > We agree that a document containing some OPDS extensions is still an > Atom document that can be delivered as application/atom+xml, I > believe. You appear to suggest that there's value in exposing the > existence of those OPDS extensions using an additional external > metadata protocol element. I believe that this is at best an > optimization, since the consumer can easily detect the existence of > the extension by inspecting the content (and understanding the > extensibility model of the host format). But at worst, it's a recipe > for interop problems; does the meaning of the document change if the > profile is declared vs not? What if the v2 profile URI is declared and > the document contains a v1 extension? etc.. As you say, in XML you can leverage namespacing to create fully self-descriptive messages without requiring another media type. In this thread, however, we are talking about JSON which doesn't support namespacing. So, how would you (or any of the numerous JSON APIs out there) signal the semantics of such "extensions" in a JSON document without minting a new media type? -- Markus Lanthaler @markuslanthaler From tsaloranta@gmail.com Wed Nov 6 08:24:16 2013 Return-Path: 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 5072321E8134 for ; Wed, 6 Nov 2013 08:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, 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 3Q6Knv4+dgaq for ; Wed, 6 Nov 2013 08:24:15 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 67BCF11E819E for ; Wed, 6 Nov 2013 08:24:11 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id n12so4504083wgh.1 for ; Wed, 06 Nov 2013 08:24:10 -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=+UfYf5XgOKjPWAepb9natFoL5bxR4Op09xu4+CJWmtA=; b=CfQnw+5pfPsoAj5n9O3XpVF69TNictnWL6/5uC3w5d1fPIiIOtCik06Vd7ayt+tGfT KTIhycIIW07ov0ToidNiUJhHXlRLbGO+mKJMO1vWZA/nLU0FpxQCUZlBKjoqWlqpJCdJ VXYEhJlFF00sWWwUyDsCV2HCe/3p+JxJJIRh9pbSxcrlJgNsNNctSj7mOh3F5s1HoUID IaFVA/5HeqbI6KhHRkgZQGONhHU/SQNIfwDCTNuebE4wechdFQ7sHP7FRKvfIMkOUV9h ORMTy4uh9+idqj6IzGQJ0FxHbQSLz6kYnq3bUMKw3aFttbDdaB/sPxkmJcO07BFKluwM o+3A== MIME-Version: 1.0 X-Received: by 10.180.76.244 with SMTP id n20mr3097370wiw.37.1383755050466; Wed, 06 Nov 2013 08:24:10 -0800 (PST) Received: by 10.227.61.195 with HTTP; Wed, 6 Nov 2013 08:24:10 -0800 (PST) In-Reply-To: References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> <5233254B-21BA-4311-BBC6-B23246727516@mnot.net> Date: Wed, 6 Nov 2013 08:24:10 -0800 Message-ID: From: Tatu Saloranta To: Nat Sakimura Content-Type: multipart/alternative; boundary=f46d043c7b0a3d431c04ea8494c4 Cc: Mark Nottingham , JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:24:16 -0000 --f46d043c7b0a3d431c04ea8494c4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 5, 2013 at 5:52 PM, Nat Sakimura wrote: > > > > 2013/11/5 Mark Nottingham > >> >> On 5 Nov 2013, at 5:12 pm, Nat Sakimura wrote: >> >> > For multiple links, would not something like this do? >> > >> > "_links":{ >> > "replies":[ >> > { >> > "href":"http://example.com/message/123", >> > "type":"text/xml" >> > }, >> > { >> > "href":"http://example.com/message/342", >> > "type":"text/xml" >> > } >> > ] >> > } >> >> In some cases, yes. However, if you don=92t need the ability to have >> multiple relations of the same type, it=92s needlessly verbose, and the = API >> for pulling out values gets more complex. That=92s going to cause fricti= on. >> > > Right. I was debating whether it should always be an array, or could it b= e > a single object. Requiring it to be always an array makes the JSON stub a > bit verbose like you say. On the other hand, f it is either an array or a= n > object, then the code has to test the type to start with. So there is a > trade-off for sure. > > However, it probably is not much effort after all to write a code to deal > with it so either seems to be fine. > > You are making an assumption that actual programming is used for extracting data from JSON. This is not necessarily done especially with static typed languages, where use of data-binding that maps JSON structure into existing native Object structure (POJOs in Java, for example) is more prevalent (and would be even more so if XML/DOM had not established an anti-pattern :) ). In this case one takes care that structures of JSON and matching Object hierarchy are compatible enough for fully automated conversion. The problem with using "Array or Object" approach is that this maps poorly to object hierarchies of most programming languages; it usually is a union closely matched by "anything". In practice it may then be unmappable without extra effort. So I would recommend not using such composite types: JSON can easily express it; and schemas that focus on JSON and mostly ignoring mapping aspect (looking at you JSON Schema) can express it. But it adds impedance in place where little should exist, between JSON and the host language. In fact, I would go as far as claim that "developers should not care if it's JSON or something else", and focus more on logical modeling to make sure that data can be easily, reliably and efficiently converted between transfer/serialization format (JSON) and processing format (internal Object representation of the host language). And this is one of class of anti-patterns one hits, if focus is too much on JSON side. -+ Tatu +- > Best, > > Nat > > > >> Cheers, >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --f46d043c7b0a3d431c04ea8494c4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 5, 2013 at 5:52 PM, Nat Sakimura <sakimura@g= mail.com> wrote:



2013/11/5 Mark Not= tingham <mnot@mnot.net>

On 5 Nov 2013, at 5:12 pm, Nat Sakimura <sakimura@gmail.com> wrote:

> For multiple links, would not something like this do?
>
> "_links":{
> =A0 =A0 "replies":[
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "href":"http://example.com/message/123",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "type":"text/xml"
> =A0 =A0 =A0 =A0 },
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "href":"http://example.com/message/342",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "type":"text/xml"
> =A0 =A0 =A0 =A0 }
> =A0 =A0 ]
> }

In some cases, yes. However, if you don=92t need the ability to have = multiple relations of the same type, it=92s needlessly verbose, and the API= for pulling out values gets more complex. That=92s going to cause friction= .


However, it probably is not much effort after all to wr= ite a code to deal with it so either seems to be fine. =A0





-+ Tatu +-
=A0

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--f46d043c7b0a3d431c04ea8494c4-- From masinter@adobe.com Wed Nov 6 08:58:17 2013 Return-Path: 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 96E7B21F9F31 for ; Wed, 6 Nov 2013 08:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Uld8DVafgS0j for ; Wed, 6 Nov 2013 08:58:11 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id C0CA921E8109 for ; Wed, 6 Nov 2013 08:58:10 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUnp1Ii35gwxQEsjy6Yll6spICtb0qKCR@postini.com; Wed, 06 Nov 2013 08:58:10 PST Received: from inner-relay-2.corp.adobe.com (inner-relay-2.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id rA6Gw8WY015745 for ; Wed, 6 Nov 2013 08:58:09 -0800 (PST) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id rA6Gw8OU008290 for ; Wed, 6 Nov 2013 08:58:08 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Wed, 6 Nov 2013 08:58:08 -0800 From: Larry Masinter To: "json@ietf.org" Date: Wed, 6 Nov 2013 08:58:01 -0800 Thread-Topic: FYI: JSON discussion minutes (W3C TAG) Thread-Index: Ac7bEVB+xfuT9wUBQCKYZt7aq7oSLw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Json] FYI: JSON discussion minutes (W3C TAG) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:58:17 -0000 I thought http://lists.w3.org/Archives/Public/www-tag/2013Nov/0030.html made interesting reading. From julian.reschke@gmx.de Wed Nov 6 09:09:18 2013 Return-Path: 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 4FD7411E8222 for ; Wed, 6 Nov 2013 09:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.418 X-Spam-Level: X-Spam-Status: No, score=-104.418 tagged_above=-999 required=5 tests=[AWL=-1.819, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 HcmJrvNSxXkB for ; Wed, 6 Nov 2013 09:09:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 258CE21F9EF0 for ; Wed, 6 Nov 2013 09:09:12 -0800 (PST) Received: from [31.133.162.78] ([31.133.162.78]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M4CB5-1VvUjF2iTT-00rrU2 for ; Wed, 06 Nov 2013 18:09:11 +0100 Message-ID: <527A77B5.6060800@gmx.de> Date: Wed, 06 Nov 2013 18:09:09 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Larry Masinter , "json@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zG93bZ/E4rFpIGaPX44HeyMqnxUAQ63/HPwTXXHDI3oXuq4Gzcn JETcAvIwqq1JWMm9ORnHGwbbIqwWjncdksVjN81103sHmE2gEH79vZJLBqJTEg3Py47yjbQ pxqXryLKpCY+JUy1C7DXb4jBEC8QdrspspMhr6ZhwDQQ5SzR2BkpjEps67o9fmTTjDrC4IV c+TL0tSXmipuBff1vDJ4Q== Cc: Anne van Kesteren Subject: Re: [Json] FYI: JSON discussion minutes (W3C TAG) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:09:18 -0000 On 2013-11-06 17:58, Larry Masinter wrote: > I thought > > http://lists.w3.org/Archives/Public/www-tag/2013Nov/0030.html > > made interesting reading. FWIW, I think Anne misunderstands the ABNF vs "7 bit" issue. We've used ABNF to specify things in terms of code points (instead of octets) lots of times. Best regards, Julian From nico@cryptonector.com Wed Nov 6 09:28:57 2013 Return-Path: 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 5185821E80FE for ; Wed, 6 Nov 2013 09:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 xZFDdx2dfo5D for ; Wed, 6 Nov 2013 09:28:46 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0111E80FB for ; Wed, 6 Nov 2013 09:28:46 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 14CFA2005D909 for ; Wed, 6 Nov 2013 09:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=oz5w/kwYR3ouwc8hKV5u 2wpGkWE=; b=RhSkxkHzbl2MitwRT7kupZY+Yb4oT8Ax37EX5pKmuaoBh2BZAguz Z2PedzPYTvxocj1C/JhICbpxKj2k7y27Ae6SyCo9Xr4V5EB177UywYyUri+TPSIe uEic4MGYNm+IXOjmaUCBU9WtERcwQS5fetYpd5Xb+mq33iKAVoCrTdE= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPSA id AAE322005D907 for ; Wed, 6 Nov 2013 09:28:45 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id x55so5203246wes.36 for ; Wed, 06 Nov 2013 09:28:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8hxwHP6Ke3XJc8eVFe8W372N7TFK6U1quYhFfcSZrXI=; b=kpzqKD7Rq9MQnx/ECh6MibsSVT2XTIa/tYALCMqbeQ2nlYRDyEFa0gyDayJlzjzhJH EiRTXtvoOqplz69mH4P6CpzM16IKgEXcj/SLMsiyexGlhuVlI3GOFeiB6JFttZWmNtyT KK97iv5qONXj217FYag3RQGF0OcoOVEt3bQ5v8fc0e46ONNlWQLO9mKhDmCOK+5xq7Tv 2PW6MSdOJYXsx+P7XygJx17bSf4ghBWiQ1I6/rAaUcXs+mnnrgA1I81KBChbaz720Muc XBF/aOuD9hkk8SL0FIsK+Q3vycTFHh04GZniljVv6s5kcBCIjovGlNj17bDBPgK/rsTC qKZQ== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr22172992wik.13.1383758923674; Wed, 06 Nov 2013 09:28:43 -0800 (PST) Received: by 10.216.151.136 with HTTP; Wed, 6 Nov 2013 09:28:43 -0800 (PST) In-Reply-To: References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> <5233254B-21BA-4311-BBC6-B23246727516@mnot.net> Date: Wed, 6 Nov 2013 11:28:43 -0600 Message-ID: From: Nico Williams To: Tatu Saloranta Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , Nat Sakimura , JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:28:57 -0000 On Wed, Nov 6, 2013 at 10:24 AM, Tatu Saloranta wrote: > You are making an assumption that actual programming is used for extracting > data from JSON. Well, one would think so... Otherwise we could just use prose! :) > This is not necessarily done especially with static typed languages, where > use of data-binding that maps JSON structure into existing native Object > structure (POJOs in Java, for example) is more prevalent (and would be even > more so if XML/DOM had not established an anti-pattern :) ). Compiler-coded destructuring is still code. > In this case one takes care that structures of JSON and matching Object > hierarchy are compatible enough for fully automated conversion. > > The problem with using "Array or Object" approach is that this maps poorly > to object hierarchies of most programming languages; it usually is a union > closely matched by "anything". In practice it may then be unmappable without > extra effort. It's just a matter of how you build your JSON abstractions. The jv C library, for example, make it very easy to reach deep into a JSON array/object by path, and the jq C library allows you to write complex JSON query expressions. C is statically-typed, and yet with jq/jv it's trivial to destructure JSON texts with complex schemas. If you can do that in C you can do it in any language. I'm biased because I've been using jq a fair bit, but still, if it didn't exist, we'd have to build it. Nico -- From tsaloranta@gmail.com Wed Nov 6 09:36:43 2013 Return-Path: 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 DD7FD21E8132 for ; Wed, 6 Nov 2013 09:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 vhvTgzIvebwD for ; Wed, 6 Nov 2013 09:36:41 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0F17B21E811B for ; Wed, 6 Nov 2013 09:36:40 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id q58so5347799wes.0 for ; Wed, 06 Nov 2013 09:36:40 -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=YO7BG2rE4r7jAK/oVyfOxfSCWVzRqUjKCIz2MZ1vFms=; b=tFAXevvXLc8ZttPul5Zf80+cYY0ARdw+Lt7/PdWzKNI2wo/QG0ugycKboNdNVGa0zc Zn+2ajM84EIaYAZUjEHDG37L1ONGd7GNIKta5+TbNu3fu2+GJ7QfBZTU2OakILYrI2q1 tKudEzPIX1A5pAnRUt7e5iZoXnRWLMO5etxTVq+kIevw4QZnx4lVH+0KZ9MaUprSDaRE DhhLI76Jgf0qnodRtIAuVk06J5neJ6wvuwuXz8Er5ToEsxwTdvTDRpdcS+v+8yBmnvPv q2GjUPjgjx0itYA4CJlPnd9ZIgwfH2O5VrvH6R1UTCMAKBIPR3hDUIuN6YYJe8OIN3Bo Ob/w== MIME-Version: 1.0 X-Received: by 10.180.76.244 with SMTP id n20mr3354823wiw.37.1383759399966; Wed, 06 Nov 2013 09:36:39 -0800 (PST) Received: by 10.227.61.195 with HTTP; Wed, 6 Nov 2013 09:36:39 -0800 (PST) In-Reply-To: References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> <5233254B-21BA-4311-BBC6-B23246727516@mnot.net> Date: Wed, 6 Nov 2013 09:36:39 -0800 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=f46d043c7b0a7d5fa804ea85970c Cc: Mark Nottingham , Nat Sakimura , JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:36:43 -0000 --f46d043c7b0a7d5fa804ea85970c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 6, 2013 at 9:28 AM, Nico Williams wrote: > On Wed, Nov 6, 2013 at 10:24 AM, Tatu Saloranta > wrote: > > You are making an assumption that actual programming is used for > extracting > > data from JSON. > > Well, one would think so... Otherwise we could just use prose! :) > Fine. If we want to split hairs, explicit extraction with specific code to traverse JSON. > > > This is not necessarily done especially with static typed languages, > where > > use of data-binding that maps JSON structure into existing native Object > > structure (POJOs in Java, for example) is more prevalent (and would be > even > > more so if XML/DOM had not established an anti-pattern :) ). > > Compiler-coded destructuring is still code. > > I don't follow you here. > > In this case one takes care that structures of JSON and matching Object > > hierarchy are compatible enough for fully automated conversion. > > > > The problem with using "Array or Object" approach is that this maps > poorly > > to object hierarchies of most programming languages; it usually is a > union > > closely matched by "anything". In practice it may then be unmappable > without > > extra effort. > > It's just a matter of how you build your JSON abstractions. The jv C > library, for example, make it very easy to reach deep into a JSON > array/object by path, and the jq C library allows you to write complex > JSON query expressions. C is statically-typed, and yet with jq/jv > it's trivial to destructure JSON texts with complex schemas. If you > can do that in C you can do it in any language. > > Of course, but I think that writing queries, traversing, is the minority case: more often you let computer do the grunt work of mapping. Why would you spend your time writing queries, expressions, when you can design the model that automatically fits? I'm biased because I've been using jq a fair bit, but still, if it > didn't exist, we'd have to build it. > > You did not actually address my concern at all. Point is very simple: there is no satisfactory model for mapping "Array or Object:" into natural and easily usable model in native object model of most programming languages. You can of course go into JSON-centric (aka untyped) view that world consists only of heterogenous arrays and key-value maps; but this is not the model that programmers handle data, given a chance. They operate on native Objects with typing specific to proglang in use. Put another way: you seem to be saying that if one only uses Tree-based representation and expression language(s), it is possible to deal with any valid JSON structure. Of course. And that is beside the point. -+ Tatu +- --f46d043c7b0a7d5fa804ea85970c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 6, 2013 at 9:28 AM, Nico Williams <nico@c= ryptonector.com> wrote:
On Wed, Nov 6, 2013 at 10:= 24 AM, Tatu Saloranta <tsalorant= a@gmail.com> wrote:
> You are making an assumption that actual programming is used for extra= cting
> data from JSON.

Well, one would think so... =A0Otherwise we could just use prose! =A0= :)

Fine. If we want to split hairs, exp= licit extraction with specific code to traverse JSON.
=A0

> This is not necessarily done especially with static typed languages, w= here
> use of data-binding that maps JSON structure into existing native Obje= ct
> structure (POJOs in Java, for example) is more prevalent (and would be= even
> more so if XML/DOM had not established an anti-pattern :) ).

Compiler-coded destructuring is still code.


I don't fo= llow you here.
=A0
=A0
> In this case one takes care that structures of JSON and matching Objec= t
> hierarchy are compatible enough for fully automated conversion.
>
> The problem with using "Array or Object" approach is that th= is maps poorly
> to object hierarchies of most programming languages; it usually is a u= nion
> closely matched by "anything". In practice it may then be un= mappable without
> extra effort.

It's just a matter of how you build your JSON abstractions. =A0Th= e jv C
library, for example, make it very easy to reach deep into a JSON
array/object by path, and the jq C library allows you to write complex
JSON query expressions. =A0C is statically-typed, and yet with jq/jv
it's trivial to destructure JSON texts with complex schemas. =A0If you<= br> can do that in C you can do it in any language.


Of course, but I think that writing qu= eries, traversing, is the minority case: more often you let computer do the= grunt work of mapping. Why would you spend your time writing queries, expr= essions, when you can design the model that automatically fits?

I'm biased because I've been using jq a fair bit, but sti= ll, if it
didn't exist, we'd have to build it.


You did not actually address my concer= n at all.

Point is very simple: there is no satisfactory = model for mapping "Array or Object:" into natural and easily usab= le model in native object model of most programming languages.
You can of course go into JSON-centric (aka untyped) view that world consis= ts only of heterogenous arrays and key-value maps; but this is not the mode= l that programmers handle data, given a chance. They operate on native Obje= cts with typing specific to proglang in use.

Put another way: you seem to be saying that if on= e only uses Tree-based representation and expression language(s), it is pos= sible to deal with any valid JSON structure. Of course. And that is beside = the point.

-+ Tatu +-

=A0
--f46d043c7b0a7d5fa804ea85970c-- From nico@cryptonector.com Wed Nov 6 09:58:17 2013 Return-Path: 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 5509821E808D for ; Wed, 6 Nov 2013 09:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] 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 llP-AtoBgux3 for ; Wed, 6 Nov 2013 09:58:12 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 48BF021E8163 for ; Wed, 6 Nov 2013 09:58:11 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 0466B2005D90E; Wed, 6 Nov 2013 09:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=bKnFI58vDPWva6 KY8xvyg0klg4E=; b=Ik4olfBlrI2XAxAlxgN86knaM83erpBRMUVYOWGa0C2AsF unCACoOxHfjw41d5IUE4UZ9s+uCrZd6ZeVpAqY3jsXlE10dScxsoIXFjINOoD2iR jlFkuM7ZPrpJ8u34STos+C+Mabj0PkYOQOCo+wbFHCKoOR0qeJJZZ1xN03pf0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPA id 804CF2005D90D; Wed, 6 Nov 2013 09:58:10 -0800 (PST) Date: Wed, 6 Nov 2013 11:58:09 -0600 From: Nico Williams To: Tatu Saloranta Message-ID: <20131106175806.GO18713@localhost> References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> <5233254B-21BA-4311-BBC6-B23246727516@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Mark Nottingham , Nat Sakimura , JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:58:17 -0000 On Wed, Nov 06, 2013 at 09:36:39AM -0800, Tatu Saloranta wrote: > On Wed, Nov 6, 2013 at 9:28 AM, Nico Williams wrote: > > [...] > > Put another way: you seem to be saying that if one only uses Tree-based > representation and expression language(s), it is possible to deal with any > valid JSON structure. Of course. And that is beside the point. I'm saying that given *sufficiently* complex metadata (like that discussed in this thread) it might not be possible to simplify it enough (because it'd be unsatisfactory) to avoid the need for advanced destructuring capabilities in your programming language or libraries. I'm not saying that one ought to use Lisp, jq, or whatever. Or that we should carelessly write specs that end up requiring such languages in practice. The questions here seem to be: whether the metadata in this thread could be simplified, and if not whether it's worth specifying a schema. My answer to the second part is "yes" because clearly such complexity can be handled and it's better to have a schema than not if the pattern will repeat often. Nico -- From derhoermi@gmx.net Wed Nov 6 10:48:21 2013 Return-Path: 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 0533721E808D for ; Wed, 6 Nov 2013 10:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.943 X-Spam-Level: X-Spam-Status: No, score=-2.943 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599] 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 HBcq4YiTWLUM for ; Wed, 6 Nov 2013 10:48:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 76B2011E8115 for ; Wed, 6 Nov 2013 10:48:07 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.23.138]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MbKXI-1VNhBt3C8y-00Io5V for ; Wed, 06 Nov 2013 19:48:06 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Wed, 06 Nov 2013 19:48:02 +0100 Message-ID: References: <527A77B5.6060800@gmx.de> In-Reply-To: <527A77B5.6060800@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:rh8kt2xXMFbJn0tKb68XvlCC15UqBsqX5/bOSrUrtLoCdw2utnA Rza39VNy/QNwWL/a6knozQ/MCuwKekZQWLtJxW54Gt2DeS7Ece6BpjCgf8uk22PNB5mlSav lhzWC+nSxSPQZ0rSORsWS4+YAwxitgcApRzJtU2aCPJoc48DSr5/E/yjy0nbu9YXlCpaGex JGPYmIjp/HBsTcIt9YiOQ== Cc: Anne van Kesteren , "json@ietf.org" , Larry Masinter Subject: Re: [Json] FYI: JSON discussion minutes (W3C TAG) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:48:21 -0000 * Julian Reschke wrote: >On 2013-11-06 17:58, Larry Masinter wrote: >> I thought >> >> http://lists.w3.org/Archives/Public/www-tag/2013Nov/0030.html >> >> made interesting reading. > >FWIW, I think Anne misunderstands the ABNF vs "7 bit" issue. We've used >ABNF to specify things in terms of code points (instead of octets) lots >of times. Indeed. Terminals in ABNF grammars are integers, and since ABNF does not support negation, you can infer the alphabet from the production rules. It would not hurt to note that the alphabet is Unicode scalar values and fix `%x5D-10FFFF` to exclude surrogates, of course, but no 7-bit issues here. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From dret@berkeley.edu Wed Nov 6 10:51:32 2013 Return-Path: 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 050C721E8161; Wed, 6 Nov 2013 10:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 foeUdBsoAjmx; Wed, 6 Nov 2013 10:51:22 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF1221E808D; Wed, 6 Nov 2013 10:51:18 -0800 (PST) Received: from dhcp-a20d.meeting.ietf.org ([31.133.162.13]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Ve8CC-0004zB-BV; Wed, 06 Nov 2013 10:51:18 -0800 Message-ID: <527A8FA5.9040405@berkeley.edu> Date: Wed, 06 Nov 2013 10:51:17 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Markus Lanthaler , apps-discuss@ietf.org, 'JSON WG' References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> <527a6316.c214440a.6c31.ffffefe5SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: <527a6316.c214440a.6c31.ffffefe5SMTPIN_ADDED_BROKEN@mx.google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Json] [apps-discuss] proposal: adding profile support to JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:51:35 -0000 hello markus. thanks for the feedback. On 2013-11-06, 07:41 , Markus Lanthaler wrote: > As you say, in XML you can leverage namespacing to create fully > self-descriptive messages without requiring another media type. In this > thread, however, we are talking about JSON which doesn't support > namespacing. So, how would you (or any of the numerous JSON APIs out there) > signal the semantics of such "extensions" in a JSON document without minting > a new media type? i think there are several ways in which you can do this. if your JSON format supports generic linking somehow somewhere in the format, then you can simply add a "profile" link. if it doesn't, you might have a specific profile identifier in the format, similar to HTML's head/@profile. but that's of course assuming you already *have* some processing model in place that's used for the representation, so we might have a chicken-and-egg problem here. maybe that points to the fact that in practice, profiles make more sense on more meaningful media types (such as adding profiles to Atom or HTML that signify certain ways of how these formats are constrained), and less so on very generic ones. on the other hand, I-JSON may be a good example for how even something as generic as plain JSON might benefit from profiles being exposable on the media type level. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From markus.lanthaler@gmx.net Wed Nov 6 11:10:53 2013 Return-Path: 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 D31B821E817B for ; Wed, 6 Nov 2013 11:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 Q-gQxFXVcILc for ; Wed, 6 Nov 2013 11:10:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id A2BA621E8176 for ; Wed, 6 Nov 2013 11:10:47 -0800 (PST) Received: from Vostro3500 ([178.115.129.229]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MaF8e-1VKPnC1g2i-00Juu1 for ; Wed, 06 Nov 2013 20:10:46 +0100 From: "Markus Lanthaler" To: "'Erik Wilde'" , , "'JSON WG'" References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> <527a6316.c214440a.6c31.ffffefe5SMTPIN_ADDED_BROKEN@mx.google.com> <527A8FA5.9040405@berkeley.edu> In-Reply-To: <527A8FA5.9040405@berkeley.edu> Date: Wed, 6 Nov 2013 20:10:40 +0100 Message-ID: <031601cedb23$e4c5f540$ae51dfc0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7bIS5y9tuveYctTk27UMPT3z2mGAAAjvWw Content-Language: de X-Provags-ID: V03:K0:NMgEKfpompBy2OnFzmIN8YMrrjBoRcqvVexE8wTQ6VRHlFXieov fJWpRtEHElj5VczlpHuBwBgXw4ob6if5/SNDekgqEe0MESvZ/hHD/ZJ2ZPRQvtg7I4EURFS pKO/SoXXmf7XlaU0djKarcx2Nn+YPIGgovH8Rdd/BwddiD0EMBXaFv4ncR2CfGhBBBbObTM /LbLW6ry+2ImeMngmNtyw== Subject: Re: [Json] [apps-discuss] proposal: adding profile support to JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:10:54 -0000 On Wednesday, November 06, 2013 7:51 PM, Erik Wilde wrote: > On 2013-11-06, 07:41 , Markus Lanthaler wrote: > > As you say, in XML you can leverage namespacing to create fully > > self-descriptive messages without requiring another media type. In = this > > thread, however, we are talking about JSON which doesn't support > > namespacing. So, how would you (or any of the numerous JSON APIs out = there) > > signal the semantics of such "extensions" in a JSON document without = minting > > a new media type? >=20 > i think there are several ways in which you can do this. if your JSON > format supports generic linking somehow somewhere in the format, then I was specifically talking about application/json. > you can simply add a "profile" link. if it doesn't, you might have a > specific profile identifier in the format, similar to HTML's > head/@profile. but that's of course assuming you already *have* some > processing model in place that's used for the representation, so we > might have a chicken-and-egg problem here. Right, to signal it you could use a HTTP Link header, but that wouldn't = work for conneg. > maybe that points to the fact that in practice, profiles make more = sense > on more meaningful media types (such as adding profiles to Atom or = HTML > that signify certain ways of how these formats are constrained), and > less so on very generic ones. on the other hand, I-JSON may be a good > example for how even something as generic as plain JSON might benefit > from profiles being exposable on the media type level. I think quite the contrary is the case. IMO generic media types such as = JSON or vanilla XML are the ones benefitting most of this. -- Markus Lanthaler @markuslanthaler From dret@berkeley.edu Wed Nov 6 15:11:15 2013 Return-Path: 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 5318021E812A for ; Wed, 6 Nov 2013 15:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 W9fh+Fo21Qup for ; Wed, 6 Nov 2013 15:11:11 -0800 (PST) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id BA09221E8103 for ; Wed, 6 Nov 2013 15:11:08 -0800 (PST) Received: from dhcp-a20d.meeting.ietf.org ([31.133.162.13]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VeCFf-0006UU-DF for json@ietf.org; Wed, 06 Nov 2013 15:11:08 -0800 Message-ID: <527ACC8A.5050002@berkeley.edu> Date: Wed, 06 Nov 2013 15:11:06 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Json] is it possible to re-register application/json with a profile media type parameter? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 23:11:15 -0000 hello. during the JSON WG meeting, there was a brief exchange about the question whether it would be even possible to use 4627bis to introduce a "profile" media type parameter. regardless of whether that's a goal or not, i simply wanted to check if there is a problem with it. http://tools.ietf.org/html/rfc4288#section-4.3 says: "[...] the names, values, and meanings of any parameters MUST be fully specified when a media type is registered in the standards tree, [...]" as well as: "New parameters SHOULD NOT be defined as a way to introduce new functionality in types registered in the standards tree, although new parameters MAY be added to convey additional information that does not otherwise change existing functionality." i believe that this would apply to a "profile" parameter if that parameter was based on the RFC6096 model of a profile, meaning that anything that represents a profiled media type representation, also represents the media type in its unprofiled way. this means that 4627bis could add a profile media type parameter, and the I-JSON draft could use this parameter to expose the I-JSONness of representations on the media type. this indication would be optional, and old implementations not knowing anything about I-JSON or the profile media type parameter would keep working. one possible source of friction is that some implementations might get confused by this parameter showing up, even though the proper behavior would be to ignore unrecognized parameters. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From internet-drafts@ietf.org Wed Nov 6 15:15:56 2013 Return-Path: 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 61E8F21E814C; Wed, 6 Nov 2013 15:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 VZWMp0P6xPdg; Wed, 6 Nov 2013 15:15:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 537E121E8103; Wed, 6 Nov 2013 15:15:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131106231555.20944.99612.idtracker@ietfa.amsl.com> Date: Wed, 06 Nov 2013 15:15:55 -0800 Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-rfc4627bis-07.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 23:15:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the JavaScript Object Notation Working Group = of the IETF. Title : The JSON Data Interchange Format Author(s) : Tim Bray Filename : draft-ietf-json-rfc4627bis-07.txt Pages : 14 Date : 2013-11-06 Abstract: JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document makes no changes to the definition of JSON; it repairs specification errors and offers experience-based interoperability guidance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-rfc4627bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From duerst@it.aoyama.ac.jp Wed Nov 6 17:29:49 2013 Return-Path: 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 066DD21E8198 for ; Wed, 6 Nov 2013 17:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.842 X-Spam-Level: X-Spam-Status: No, score=-103.842 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 hN84ir4shfUL for ; Wed, 6 Nov 2013 17:29:38 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 621F821E80AF for ; Wed, 6 Nov 2013 17:29:38 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rA71TU59028893; Thu, 7 Nov 2013 10:29:32 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 493e_c587_0ca56fb6_474c_11e3_b4b7_001e6722eec2; Thu, 07 Nov 2013 10:29:30 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 3FF33BF545; Thu, 7 Nov 2013 10:29:30 +0900 (JST) Message-ID: <527AECE4.3000002@it.aoyama.ac.jp> Date: Thu, 07 Nov 2013 10:29:08 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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: Erik Wilde References: <527ACC8A.5050002@berkeley.edu> In-Reply-To: <527ACC8A.5050002@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] is it possible to re-register application/json with a profile media type parameter? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 01:29:49 -0000 Hello Erik, I think that in terms of process lawyering, I wouldn't worry too much. What matters is 1) whether this profile parameter really makes sense (see separate discussion), and 2) what happens with actual implementations when they see a profile parameter. Regards, Martin. On 2013/11/07 8:11, Erik Wilde wrote: > hello. > > during the JSON WG meeting, there was a brief exchange about the > question whether it would be even possible to use 4627bis to introduce a > "profile" media type parameter. regardless of whether that's a goal or > not, i simply wanted to check if there is a problem with it. > > http://tools.ietf.org/html/rfc4288#section-4.3 says: > > "[...] the names, values, and meanings of any parameters MUST be fully > specified when a media type is registered in the standards tree, [...]" > > as well as: > > "New parameters SHOULD NOT be defined as a way to introduce new > functionality in types registered in the standards tree, although new > parameters MAY be added to convey additional information that does not > otherwise change existing functionality." > > i believe that this would apply to a "profile" parameter if that > parameter was based on the RFC6096 model of a profile, meaning that > anything that represents a profiled media type representation, also > represents the media type in its unprofiled way. > > this means that 4627bis could add a profile media type parameter, and > the I-JSON draft could use this parameter to expose the I-JSONness of > representations on the media type. this indication would be optional, > and old implementations not knowing anything about I-JSON or the profile > media type parameter would keep working. one possible source of friction > is that some implementations might get confused by this parameter > showing up, even though the proper behavior would be to ignore > unrecognized parameters. > > cheers, > > dret. > From paul.hoffman@vpnc.org Wed Nov 6 18:44:58 2013 Return-Path: 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 9140021E81DA for ; Wed, 6 Nov 2013 18:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UgNsVGO8vzFM for ; Wed, 6 Nov 2013 18:44:51 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BB9B611E81A7 for ; Wed, 6 Nov 2013 18:41:59 -0800 (PST) Received: from dhcp-bd2a.meeting.ietf.org (dhcp-bd2a.meeting.ietf.org [31.133.189.42]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rA72fibn058012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Nov 2013 19:41:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Paul Hoffman In-Reply-To: <52728545.6080009@qti.qualcomm.com> Date: Wed, 6 Nov 2013 18:41:43 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <52728545.6080009@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1816) Cc: "json@ietf.org" Subject: Re: [Json] AD Review of draft-ietf-json-rfc4627bis-06 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 02:44:59 -0000 On Oct 31, 2013, at 9:28 AM, Pete Resnick wrote: > I'll pull the trigger on the Last Call when the chairs say, "Go!" Given Tim's revised version, the chairs say "Go!" --Matt Miller and Paul Hoffman From annevankesteren@gmail.com Thu Nov 7 06:31:23 2013 Return-Path: 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 0B77421E80B9 for ; Thu, 7 Nov 2013 06:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 nJ5oiGca2o-Z for ; Thu, 7 Nov 2013 06:31:22 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id C539121E817F for ; Thu, 7 Nov 2013 06:31:21 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex4so694270wid.15 for ; Thu, 07 Nov 2013 06:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jo2d4wuqLgVgkD//1HIU4yLpAJ2ODWzswIrMEb2pfHM=; b=lPUREUhUrxh4IegDEelT4mEriE+4TRVJcBtZEFOvBT7Wtn2v9EDAHv91gYa7gCcrOk YRzIsMfw7JeR4NGG3185PFTCF6Ly7HbmGp17OQmi0eD7WG1o0Fk2e3LNbl5EHtNWn3XN t/KaeZRM9hJAEQQVkLFddTFh4lT5qW+h8EgXrXkR4uGgyDvYqy5Mz0lWDVXJk6THtDGS BwzZwlINYIHqaY8AHW52LHwBkJZbQwObKayy20LcPwd0aGxud6ZG/pHBwdZSVUVyn/2S S+eOwwJYBbSdAmC63bCyorl4ktbXXXsuNlOAP1FGE4I7fC1zfsk0LX4D6veniL/kxusw kZPg== MIME-Version: 1.0 X-Received: by 10.194.187.101 with SMTP id fr5mr1466794wjc.76.1383834680737; Thu, 07 Nov 2013 06:31:20 -0800 (PST) Sender: annevankesteren@gmail.com Received: by 10.227.19.193 with HTTP; Thu, 7 Nov 2013 06:31:20 -0800 (PST) In-Reply-To: <527A77B5.6060800@gmx.de> References: <527A77B5.6060800@gmx.de> Date: Thu, 7 Nov 2013 14:31:20 +0000 X-Google-Sender-Auth: xHWp7sCLuKPFPbHi7Ftl_HWxb50 Message-ID: From: Anne van Kesteren To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" , Larry Masinter Subject: Re: [Json] FYI: JSON discussion minutes (W3C TAG) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:31:23 -0000 On Wed, Nov 6, 2013 at 5:09 PM, Julian Reschke wrote: > FWIW, I think Anne misunderstands the ABNF vs "7 bit" issue. We've used ABNF > to specify things in terms of code points (instead of octets) lots of times. http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-06#section-1.1 does not define the alphabet used. I assumed ABNF defaulted to ASCII, but it appears I might have skimmed that incorrectly during the teleconference. -- http://annevankesteren.nl/ From tsaloranta@gmail.com Thu Nov 7 10:55:13 2013 Return-Path: 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 AF48E21E8144 for ; Thu, 7 Nov 2013 10:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.417, 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 v2sm9R1P3FOl for ; Thu, 7 Nov 2013 10:55:11 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 262E521E81F9 for ; Thu, 7 Nov 2013 10:55:10 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id c11so946914wgh.21 for ; Thu, 07 Nov 2013 10:55:05 -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=1+tTcdInZa6rvCbxEEJoklkNqeIroGTTyMKOU9zzde8=; b=k02JJg7loLDP3EiMLOvlvzxVJvA1fbEZevCXdqAJsdT+4BBLgUgvQfD7ZgVTsE0A+s u5j2spRA+cUDC85HCk8OoKtLdetzTZlZqWiKKCAqw0WJvmT5FbROxCZRcbRGsVA0mN6I T/FfBx9GDAr/MziNK6sZgQIQrbG4mkrnzL63lY/zKdQ0BETOKkEQ2AB+tZOzr9DEfZd6 pFI0bwR3N5RoCtPL2rpZqeYWcVK1ldB0YshS9o2K23GAkn8UuHhMgT6aXxY5fH4ZhlUa 4X48yBnL3E3vdRLjWaOgXWppvHURjQ36uzSN9aMv+x4AoASjSIvtskl5lOb7M50SW0LV yP6Q== MIME-Version: 1.0 X-Received: by 10.180.221.106 with SMTP id qd10mr3832865wic.57.1383850505691; Thu, 07 Nov 2013 10:55:05 -0800 (PST) Received: by 10.227.61.195 with HTTP; Thu, 7 Nov 2013 10:55:05 -0800 (PST) In-Reply-To: <20131106175806.GO18713@localhost> References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> <5233254B-21BA-4311-BBC6-B23246727516@mnot.net> <20131106175806.GO18713@localhost> Date: Thu, 7 Nov 2013 10:55:05 -0800 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=001a1134ccb2d06d4004ea9acdbd Cc: Mark Nottingham , Nat Sakimura , JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:55:13 -0000 --001a1134ccb2d06d4004ea9acdbd Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 6, 2013 at 9:58 AM, Nico Williams wrote: > On Wed, Nov 06, 2013 at 09:36:39AM -0800, Tatu Saloranta wrote: > > On Wed, Nov 6, 2013 at 9:28 AM, Nico Williams > wrote: > > > [...] > > > > Put another way: you seem to be saying that if one only uses Tree-based > > representation and expression language(s), it is possible to deal with > any > > valid JSON structure. Of course. And that is beside the point. > > I'm saying that given *sufficiently* complex metadata (like that > discussed in this thread) it might not be possible to simplify it enough > (because it'd be unsatisfactory) to avoid the need for advanced > destructuring capabilities in your programming language or libraries. > > I'm not saying that one ought to use Lisp, jq, or whatever. Or that we > should carelessly write specs that end up requiring such languages in > practice. > > The questions here seem to be: whether the metadata in this thread could > be simplified, and if not whether it's worth specifying a schema. My > answer to the second part is "yes" because clearly such complexity can > be handled and it's better to have a schema than not if the pattern will > repeat often. > Fair enough. I agree in that there are complex cases. My point is that complexity of structure is a choice, and should be made explicit. Based on JSON usage I have seen, I think modellers are not always aware of complexities or resulting trade-offs. To reiterate what I was trying to say was just that I think it is necessary to not only consider aesthetics of JSON representation, but also its usage and impedance to usage of data beyond simple transfer or storage. And that certain kind of polymorphism that is easy in JSON (and json-centric schemas) -- such as "Object or Array" -- do not map well to object definitions of programming languages. -+ Tatu +- --001a1134ccb2d06d4004ea9acdbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 6, 2013 at 9:58 AM, Nico Williams <nico@c= ryptonector.com> wrote:
On Wed, Nov 06, 2013 at 09= :36:39AM -0800, Tatu Saloranta wrote:
> On Wed, Nov 6, 2013 at 9:28 AM, Nico Williams <nico@cryptonector.com> wrote:
> > [...]
>
> Put another way: you seem to be saying that if one only uses Tree-base= d
> representation and expression language(s), it is possible to deal with= any
> valid JSON structure. Of course. And that is beside the point.

I'm saying that given *sufficiently* complex metadata (like that<= br> discussed in this thread) it might not be possible to simplify it enough (because it'd be unsatisfactory) to avoid the need for advanced
destructuring capabilities in your programming language or libraries.
<= /blockquote>

I'm not saying that one ought to use Lisp, jq, or whatever. =A0Or that = we
should carelessly write specs that end up requiring such languages in
practice.

The questions here seem to be: whether the metadata in this thread could be simplified, and if not whether it's worth specifying a schema. =A0My=
answer to the second part is "yes" because clearly such complexit= y can
be handled and it's better to have a schema than not if the pattern wil= l
repeat often.

Fair enough.= I agree in that there are complex cases. My point is that complexity of st= ructure is a choice, and should be made explicit. Based on JSON usage I hav= e seen, I think modellers are not always aware of complexities or resulting= trade-offs.

To reiterate what I was trying to say was just that I think = it is necessary to not only consider aesthetics of JSON representation, but= also its usage and impedance to usage of data beyond simple transfer or st= orage.
And that certain kind of polymorphism that is easy in JSON (and = json-centric schemas) -- such as "Object or Array" -- do not map = well to object definitions of programming languages.

-+ Tatu +-


=A0
--001a1134ccb2d06d4004ea9acdbd-- From nico@cryptonector.com Thu Nov 7 11:08:37 2013 Return-Path: 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 7044B11E8222 for ; Thu, 7 Nov 2013 11:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 935IasmP29Dg for ; Thu, 7 Nov 2013 11:08:31 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 37EF211E8118 for ; Thu, 7 Nov 2013 11:08:23 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 7C0452AC078 for ; Thu, 7 Nov 2013 11:08:22 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 2B1002AC099 for ; Thu, 7 Nov 2013 11:08:22 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex4so1126089wid.15 for ; Thu, 07 Nov 2013 11:08:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gLrtlUl9XjDtX0s2yhD5eunzyUmfAX9Y15gg020990I=; b=jnL4EycL4VkIJVZe5KannVyrUEeJ0EBG7Lz972SIFw/yVppb7Mo2vkoTfOMMJsqDPM Z6DI8MuRrpRiFcqy77io3WeeaFHY0gj6kI0phcu/qDmVIODwbLuKb9UPwDYBGYTEcDFK Lo9JQh+Ma3ZbrVNXxvjrOVB8dIzISBNWcnHf6droS0U+jveM7ok+q4f5UgCJVFZFirjq 6WCFiBxywN5cfsKuGwJmBfVxABbtRTEhGSDOr9IrmIRoZHqUsZN58sjw2PHfcHCsy/cU GNtoYNuqp5eP7zX3zg5oktAUGLXj1CEYcAbJsJhyweCNzMLX1gErFISUTGlytdyfxCb2 GYzg== MIME-Version: 1.0 X-Received: by 10.194.94.137 with SMTP id dc9mr7882601wjb.38.1383851300291; Thu, 07 Nov 2013 11:08:20 -0800 (PST) Received: by 10.216.151.136 with HTTP; Thu, 7 Nov 2013 11:08:20 -0800 (PST) In-Reply-To: References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> <5233254B-21BA-4311-BBC6-B23246727516@mnot.net> <20131106175806.GO18713@localhost> Date: Thu, 7 Nov 2013 13:08:20 -0600 Message-ID: From: Nico Williams To: Tatu Saloranta Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , Nat Sakimura , JSON WG Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:08:37 -0000 On Thu, Nov 7, 2013 at 12:55 PM, Tatu Saloranta wrote: > On Wed, Nov 6, 2013 at 9:58 AM, Nico Williams wrote: >> The questions here seem to be: whether the metadata in this thread could >> be simplified, and if not whether it's worth specifying a schema. My >> answer to the second part is "yes" because clearly such complexity can >> be handled and it's better to have a schema than not if the pattern will >> repeat often. > > > Fair enough. I agree in that there are complex cases. My point is that > complexity of structure is a choice, and should be made explicit. Based on > JSON usage I have seen, I think modellers are not always aware of > complexities or resulting trade-offs. That's fair. JSON (and XML) allow for such complex schemas (explicit or otherwise) that we end up needing XSLT- and jq-like query languages. It'd be nice if such complexity could be avoided in many cases, but there's a trade-off: flattening the schema will simply move the complexity into object names (keys) and result in if ladders in actual code. Perhaps this should be noted somewhere, but there's more pressing things to do I think. > To reiterate what I was trying to say was just that I think it is necessary > to not only consider aesthetics of JSON representation, but also its usage > and impedance to usage of data beyond simple transfer or storage. > And that certain kind of polymorphism that is easy in JSON (and json-centric > schemas) -- such as "Object or Array" -- do not map well to object > definitions of programming languages. Right. Having something like XSLT for JSON (jq!) really helps. Nico -- From dret@berkeley.edu Thu Nov 7 11:10:48 2013 Return-Path: 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 7DA5511E80F9 for ; Thu, 7 Nov 2013 11:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hWwyQVztsdEr for ; Thu, 7 Nov 2013 11:10:43 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id EE12311E8118 for ; Thu, 7 Nov 2013 11:10:34 -0800 (PST) Received: from dhcp-a20d.meeting.ietf.org ([31.133.162.13]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VeUyN-0004KG-Ca; Thu, 07 Nov 2013 11:10:33 -0800 Message-ID: <527BE5AA.5040808@berkeley.edu> Date: Thu, 07 Nov 2013 11:10:34 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: JSON WG References: <255AEB83-31FE-47BD-894F-B4270A13B144@mnot.net> <5233254B-21BA-4311-BBC6-B23246727516@mnot.net> <20131106175806.GO18713@localhost> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Tatu Saloranta Subject: Re: [Json] Link-relation expressed in JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:10:48 -0000 hello. On 2013-11-07, 10:55 , Tatu Saloranta wrote: > Fair enough. I agree in that there are complex cases. My point is that > complexity of structure is a choice, and should be made explicit. Based > on JSON usage I have seen, I think modellers are not always aware of > complexities or resulting trade-offs. there is so much existing JSON out there that instead of creating a "standard for hyperJSON", an alternative approach might be to just collect and document (some of the) existing design patterns out there, and compare and highlight their constraints in terms of what they can and cannot represent. that might already be a very useful starting point for JSON designers, and would give them a good starting point for how to design that aspect of their JSON representations. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From duerst@it.aoyama.ac.jp Fri Nov 8 00:03:20 2013 Return-Path: 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 318FF21E8200 for ; Fri, 8 Nov 2013 00:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.688 X-Spam-Level: X-Spam-Status: No, score=-103.688 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 F9hUMqRAZq8B for ; Fri, 8 Nov 2013 00:03:14 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8416021E81A7 for ; Fri, 8 Nov 2013 00:03:13 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rA882trj019700; Fri, 8 Nov 2013 17:02:55 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 493e_b40c_2cd9c786_484c_11e3_b4b7_001e6722eec2; Fri, 08 Nov 2013 17:02:54 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 2DACEBF54D; Fri, 8 Nov 2013 17:02:55 +0900 (JST) Message-ID: <527C9AA5.10503@it.aoyama.ac.jp> Date: Fri, 08 Nov 2013 17:02:45 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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: "json@ietf.org" References: <527A77B5.6060800@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , Anne van Kesteren , Larry Masinter Subject: Re: [Json] FYI: JSON discussion minutes (W3C TAG) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 08:03:20 -0000 On 2013/11/07 23:31, Anne van Kesteren wrote: > On Wed, Nov 6, 2013 at 5:09 PM, Julian Reschke wrote: >> FWIW, I think Anne misunderstands the ABNF vs "7 bit" issue. We've used ABNF >> to specify things in terms of code points (instead of octets) lots of times. > > http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-06#section-1.1 > does not define the alphabet used. I assumed ABNF defaulted to ASCII, > but it appears I might have skimmed that incorrectly during the > teleconference. Good catch! There's no assumption that ABNF defaults to ASCII, but there is also no assumption that ABNF defaults to anything else. See http://tools.ietf.org/html/rfc5234#section-2.4. So this seems to be a hole in the current draft. Although the hole hasn't had lots of consequences so far (there's lots of context to help out), it seems advisable to fix it. I herewith propose the following change to the second paragraph of 1.1: OLD: The grammatical rules in this document are to be interpreted as described in [RFC5234]. NEW: The grammatical rules in this document are to be interpreted as described in [RFC5234]. Character numbers are taken from the Unicode, without implying any actual binary encoding. Terminals in the ABNF are characters, not bytes. (The additional text is based on the last part of the first paragraph of http://tools.ietf.org/html/rfc3987#section-2.2.) For the process-inclined (read chairs and ADs): If this comment comes at a bad moment, please ignore it for the time being and consider it being made as a comment to the upcomming IETF last call. Regards, Martin. From iesg-secretary@ietf.org Mon Nov 11 06:34:21 2013 Return-Path: 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 4561E21E81F3; Mon, 11 Nov 2013 06:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 pnGzKYdZEVTX; Mon, 11 Nov 2013 06:34:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9050021E815D; Mon, 11 Nov 2013 06:34:20 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> Date: Mon, 11 Nov 2013 06:34:20 -0800 Cc: json@ietf.org Subject: [Json] Last Call: (The JSON Data Interchange Format) to Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 14:34:21 -0000 The IESG has received a request from the JavaScript Object Notation WG (json) to consider the following document: - 'The JSON Data Interchange Format' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-11-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document makes no changes to the definition of JSON; it repairs specification errors and offers experience-based interoperability guidance. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis/ballot/ No IPR declarations have been submitted directly on this I-D. From julian.reschke@gmx.de Mon Nov 11 06:53:43 2013 Return-Path: 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 C2ABF21E81E3 for ; Mon, 11 Nov 2013 06:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[AWL=-1.622, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 mYyywtcUgumD for ; Mon, 11 Nov 2013 06:53:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id ACAC621E81D6 for ; Mon, 11 Nov 2013 06:53:37 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MUkxk-1WDsmS2wqC-00YC0n for ; Mon, 11 Nov 2013 15:53:36 +0100 Message-ID: <5280EF6F.6030102@gmx.de> Date: Mon, 11 Nov 2013 15:53:35 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: json@ietf.org References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> In-Reply-To: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:v+x5vBDjKVAWfaYRyztoP1khZImxuYNG/D2cdUiQaf1hp7grQkJ szM4p0o8CdtLj/zJvvmbouzP4TILp/LfQ1UeRHPbu+G2BFTAPX2/GNSEveb8nQ3DquShIuP y+LWDN4UPaWZ7koJSFKOsY+nTH2r9ME5gTMfx7LNR3qIN9MiG+9D7OP9TyY0rXI3t0niAgX qr/R7ZlDKs8S+ijXoFVeg== Subject: Re: [Json] Last Call: (The JSON Data Interchange Format) to Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 14:53:43 -0000 On 2013-11-11 15:34, The IESG wrote: > > The IESG has received a request from the JavaScript Object Notation WG > (json) to consider the following document: > - 'The JSON Data Interchange Format' > as Proposed Standard > ... Why only "proposed"? Best regards, Julian From cowan@ccil.org Mon Nov 11 08:41:49 2013 Return-Path: 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 8F75911E81A9 for ; Mon, 11 Nov 2013 08:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.641 X-Spam-Level: X-Spam-Status: No, score=-3.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Fdl9XAH6+c6T for ; Mon, 11 Nov 2013 08:41:45 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77D11E8163 for ; Mon, 11 Nov 2013 08:41:41 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VfuYU-0005IX-JO; Mon, 11 Nov 2013 11:41:38 -0500 Date: Mon, 11 Nov 2013 11:41:38 -0500 From: John Cowan To: Julian Reschke Message-ID: <20131111164138.GC13063@mercury.ccil.org> References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <5280EF6F.6030102@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5280EF6F.6030102@gmx.de> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: json@ietf.org Subject: Re: [Json] Last Call: (The JSON Data Interchange Format) to Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 16:41:49 -0000 Julian Reschke scripsit: > Why only "proposed"? All IETF Internet Standards start out life as Proposed Standards, and the vast bulk of them remain so. Of the 2378 non-obsolete standards-track RFCs that exist today, only 90 of them have undergone the more rigorous process to become Internet Standards. -- John Cowan http://ccil.org/~cowan cowan@ccil.org 'Tis the Linux rebellion / Let coders take their place, The Linux-nationale / Shall Microsoft outpace, We can write better programs / Our CPUs won't stall, So raise the penguin banner of / The Linux-nationale. --Greg Baker From julian.reschke@gmx.de Mon Nov 11 09:18:56 2013 Return-Path: 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 41D1C21E81DD for ; Mon, 11 Nov 2013 09:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 DXjK0C6lDcUS for ; Mon, 11 Nov 2013 09:18:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9717F11E81B5 for ; Mon, 11 Nov 2013 09:18:37 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LnPnu-1VF6lW0W4c-00hakE for ; Mon, 11 Nov 2013 18:18:36 +0100 Message-ID: <5281116A.6020107@gmx.de> Date: Mon, 11 Nov 2013 18:18:34 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: John Cowan References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> <5280EF6F.6030102@gmx.de> <20131111164138.GC13063@mercury.ccil.org> In-Reply-To: <20131111164138.GC13063@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:k/vkaMeTNy31IEnA+cy2NzRfOzGUjMjg5jlHJCq79xGmOp2lUsp Ktha+/d6T7XjeCRGXnzvmVMZmhYTZlu3pd66kNS2XRaUT84NaGjJTwp8uvBsYXMXul6eOev pRxwo7CWoOhmR/QU9Foarn61lSgvGBV7iqee5iddJqexoBtlC5KMwgMsnKPm80bGTeNPCya dBRBOJE+g/9KV//7XF9Cg== Cc: json@ietf.org Subject: Re: [Json] Last Call: (The JSON Data Interchange Format) to Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 17:18:56 -0000 On 2013-11-11 17:41, John Cowan wrote: > Julian Reschke scripsit: > >> Why only "proposed"? > > All IETF Internet Standards start out life as Proposed Standards, and the > vast bulk of them remain so. Of the 2378 non-obsolete standards-track > RFCs that exist today, only 90 of them have undergone the more rigorous > process to become Internet Standards. I'm aware of that :-) What I forgot (and just remembered) is that RFC 4627 (which is being revised here) wasn't on the standards track. Best regards, Julian From julian.reschke@gmx.de Mon Nov 11 23:19:09 2013 Return-Path: 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 A70CC21E808F for ; Mon, 11 Nov 2013 23:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 4KH9NFSf8xU0 for ; Mon, 11 Nov 2013 23:18:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 63D6121E8097 for ; Mon, 11 Nov 2013 23:18:57 -0800 (PST) Received: from [192.168.2.117] ([93.217.69.91]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M4002-1VOsJR3HEo-00raxl for ; Tue, 12 Nov 2013 08:18:55 +0100 Message-ID: <5281D65E.1080405@gmx.de> Date: Tue, 12 Nov 2013 08:18:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Rfke3Mg3clF1gVqVPT6Q4NMMuO1s09ibJq8LAt5jdK3K3vGDvCm gyiZyx3guVCaYr1kKj0ZGhNMkQBJSqeHanI9Ir1fZRLw3aja14zIMwbhVyQVyQigFFADndZ 7+eAN0ohch1RCaDuFoEbsaQBo1faE8WwDX6z30KFrSZScM0AAX8EO/HNvHidAgWrwC8GL/Q RvdiEibimwKa8fuAMgbcg== Subject: [Json] LC comment on http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07#section-11 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 07:19:09 -0000 : > Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32. > JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON > is written in UTF-8, JSON is 8bit compatible. When JSON is > written in UTF-16 or UTF-32, the binary content-transfer-encoding > must be used. That is a bit misleading, because content-transfer-encoding isn't needed (nor defined) if the transport allows binary anyway (such as HTTP). Related to this: a frequent question on stackoverflow is about the charset parameter on application/json. Maybe it's worth re-stating that it is not only not defined but also really really has no effect. Best regards, Julian From derhoermi@gmx.net Tue Nov 12 04:23:33 2013 Return-Path: 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 030CE21E8117 for ; Tue, 12 Nov 2013 04:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.985 X-Spam-Level: X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599] 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 c+1Hx6igF9ll for ; Tue, 12 Nov 2013 04:23:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9E06221E8113 for ; Tue, 12 Nov 2013 04:23:22 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.38.237]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MVsUW-1WDHfM46hM-00X7xq for ; Tue, 12 Nov 2013 13:23:21 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Tue, 12 Nov 2013 13:23:21 +0100 Message-ID: References: <5281D65E.1080405@gmx.de> In-Reply-To: <5281D65E.1080405@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:uRwTz43+XEdM4j8ewSEXe9E0UVlS0wYvK18BHiEQn1MU7DAtgWx ZDqHq+Qh6uf8PczcKjIVcfTflQLBKzlJwuD26oH0yEBYDDCrCh1bc097XgFJsxU7t0uTaP8 OuTXsNxS3cZTZ5OHaEcXquv8Z56hw3yHE+zXEIeCipTl02O9s0eFEyvNmSmVLabourUVa2A T1vxth+kqqPc4V8SbXsng== Cc: "json@ietf.org" Subject: Re: [Json] LC comment on http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07#section-11 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 12:23:33 -0000 * Julian Reschke wrote: >: > >> Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32. >> JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON >> is written in UTF-8, JSON is 8bit compatible. When JSON is >> written in UTF-16 or UTF-32, the binary content-transfer-encoding >> must be used. > >That is a bit misleading, because content-transfer-encoding isn't needed >(nor defined) if the transport allows binary anyway (such as HTTP). RFC 6838 calls for using one of "binary", "framed", "8bit" and "7bit" for this field, and using anything other than "binary" or "framed" is almost always wrong ("7bit" and "8bit" require CRLF line endings). It is not framed, so Encoding considerations: binary is all that is called for here. >Related to this: a frequent question on stackoverflow is about the >charset parameter on application/json. Maybe it's worth re-stating that >it is not only not defined but also really really has no effect. I agree that this is a common point of confusion, including in running code, that should be explicitly addressed in the specification. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From julian.reschke@gmx.de Tue Nov 12 06:01:20 2013 Return-Path: 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 6CB2011E8143 for ; Tue, 12 Nov 2013 06:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.138 X-Spam-Level: X-Spam-Status: No, score=-104.138 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 uEsbglFYvJaK for ; Tue, 12 Nov 2013 06:01:15 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD3F11E8159 for ; Tue, 12 Nov 2013 06:01:11 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MFcg9-1VukiW2RBl-00Ec5C for ; Tue, 12 Nov 2013 15:01:10 +0100 Message-ID: <528234A4.2040004@gmx.de> Date: Tue, 12 Nov 2013 15:01:08 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> In-Reply-To: <20131111143420.20298.75880.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZHm/kn9oETzJKyoQdQi6i6mj7z8dkMXzkz4vUH20rxV503Uzqsb 0c7MXUOb3S4JdU5llYxuwfW7Quj7RrCwaDStu4KwZpHTxPwhBBp3zgulsqE5N8fkHin+8UR wcUeyzN4zFGvv5jiqr0rf9Islsh5f4B8VkE7/Idls2dDoDnz8SLcT4fVR8EilItoXfy1aIN G4nIrOzYZJxl5nJIeVJWA== Cc: json@ietf.org Subject: Re: [Json] Last Call: (The JSON Data Interchange Format) to Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 14:01:20 -0000 Hi there, below are my editorial comments: Abstract JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document makes no changes to the definition of JSON; it repairs specification errors and offers experience-based interoperability guidance. I believe historical considerations do not belong into the abstract (but into the Introduction) Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 10, 2014. Are we sure that we do not need the "pre-5378 escape clause" here? (Section 4 of ) The grammatical rules in this document are to be interpreted as described in [RFC5234]. Maybe note which productions are imported as well (HEXDIG and DIGIT it seems). This revision does not change any of the rules of the specification; all texts which were legal JSON remain so, and none which were not JSON become JSON. The revision's goal is to fix the errata and highlight practices which can lead to interoperability problems. s/fix errata/apply errata/ ? Insignificant whitespace is allowed before or after any of the six structural characters. ws = *( %x20 / ; Space %x09 / ; Horizontal tab %x0A / ; Line feed or New line %x0D ) ; Carriage return We *could* use SP, HTAB, LF, and CR here. JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. That's a bit misleading. How do I "encode in Unicode"? I think what it tries to say is that one of the Unicode-compatible character encoding schemes needs to be used. Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets. 00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx 00 UTF-16LE xx xx xx xx UTF-8 I'm ok to sticking with this, but I'm also with AvK that it would be good to recommend (not necessarily RECOMMEND) UTF-8. An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range and precision of numbers. An implementation may set limits on the length and character contents of strings. Maybe this should be a bullet list? 10. Generators A JSON generator produces JSON text. The resulting text MUST strictly conform to the JSON grammar. "strictly"? Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32. JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit compatible. When JSON is written in UTF-16 or UTF-32, the binary content-transfer-encoding must be used. As mentioned before, please clarify that there is no such thing as content-transfer-encoding in binary transports such as HTTP. Person & email address to contact for further information: IESG "? Change controller: IESG array = begin-array [ value *( value-separator value ) ] end-array > begin-array = ws "[" ws > begin-object = ws "{" ws > end-array = ws "]" ws > end-object = ws "}" ws > name-separator = ws ":" ws > value-separator = ws "," ws > ws = *( " " / %x09 / %x0A / %x0D ) > value = false / null / true / object / array / number / string > false = %x66.61.6C.73.65 > null = %x6E.75.6C.6C > true = %x74.72.75.65 > object = begin-object [ member *( value-separator member ) ] end-object > member = string name-separator value > number = [ minus ] int [ frac ] [ exp ] > decimal-point = "." > digit1-9 = %x31-39 > e = %x65 / %x45 > ; DIGIT UNDEFINED > exp = e [ minus / plus ] 1*DIGIT > frac = decimal-point 1*DIGIT > int = zero / ( digit1-9 *DIGIT ) > minus = "-" > plus = "+" > zero = "0" > string = quotation-mark *char quotation-mark > ; HEXDIG UNDEFINED > char = unescaped / ( escape ( %x22 / "\" / "/" / %x62 / %x66 / %x6E / %x72 / %x74 / ( %x75 4HEXDIG ) ) ) > escape = "\" > quotation-mark = %x22 > unescaped = %x20-21 / %x23-5B / %x5D-10FFFF Best regards, Julian From paul.hoffman@vpnc.org Tue Nov 12 07:28:50 2013 Return-Path: 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 CAB5E11E8170; Tue, 12 Nov 2013 07:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FbcqqTnoBGvg; Tue, 12 Nov 2013 07:28:50 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1432321E8182; Tue, 12 Nov 2013 07:28:40 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rACFSTbT024846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Nov 2013 08:28:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: Date: Tue, 12 Nov 2013 07:28:29 -0800 Content-Transfer-Encoding: 7bit Message-Id: <99EE3A2D-D1CF-44EF-BA61-156ED8E72F79@vpnc.org> References: To: Anne van Kesteren X-Mailer: Apple Mail (2.1822) Cc: Henri Sivonen , IETF Discussion , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:28:50 -0000 [[ Adding the JSON WG to this thread ]] On Nov 11, 2013, at 10:58 PM, Anne van Kesteren 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. > > > -- > http://annevankesteren.nl/ > From paul.hoffman@vpnc.org Tue Nov 12 07:29:23 2013 Return-Path: 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 47A4B11E8181; Tue, 12 Nov 2013 07:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 fWJm8uxRCGxZ; Tue, 12 Nov 2013 07:29:22 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ABBC621E8182; Tue, 12 Nov 2013 07:29:05 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rACFSTbU024846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Nov 2013 08:29:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: Date: Tue, 12 Nov 2013 07:29:00 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: To: Anne van Kesteren X-Mailer: Apple Mail (2.1822) Cc: JSON WG , IETF Discussion , www-tag@w3.org, es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:29:23 -0000 [[ Adding the JSON WG to this thread ]] On Nov 11, 2013, at 11:01 PM, Anne van Kesteren wrote: > To improve JSON interoperability the IETF should not define a more > restricted version of JSON than defined by Ecma-404. > > Parsers exist that can parse "42" today and parsers that cannot parse > "42" today can be meaningfully upgraded to do so too. This would not > break those parsers, unless they depend on parsing 42 as an error, > which is a far more unlikely scenario than parsing it as 42 given > precedence. > > (Worth pondering about: what to do about a leading BOM, which > XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404 > allow.) > > > -- > http://annevankesteren.nl/ > From jhildebr@cisco.com Wed Nov 13 12:24:27 2013 Return-Path: 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 59AC321F9BC1; Wed, 13 Nov 2013 12:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.729 X-Spam-Level: X-Spam-Status: No, score=-9.729 tagged_above=-999 required=5 tests=[AWL=0.870, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GKZ99WflIOz3; Wed, 13 Nov 2013 12:24:21 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id AA95921F9C00; Wed, 13 Nov 2013 12:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2111; q=dns/txt; s=iport; t=1384374261; x=1385583861; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kzvSVv+Av78rFAUeBAv1hqpb5nYW9L+iYn4KRIw4ktk=; b=jr3KYq+qQIIXucqH1I9nh5MImuG6sXiaROkasAExgdKvmUb13I6nkS3X ba8uNdG7tONqS/FUdMdJoX9reCQSHhiN0TpO/Li3D8+X8ClHU/wdHEFM3 2uLzjd9oBjJ+VQ1XsXADKEM7VLEmtnNQKpcuZeODIqHDussHfDZSGWSP1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAALfg1KtJV2b/2dsb2JhbABZgweBC78sgSgWdIIlAQEBBDo/EgEIGBUJQiUCBAENBYgBwEaOM4EsBwqEJwOULoNikguDKIFqQA X-IronPort-AV: E=Sophos;i="4.93,693,1378857600"; d="scan'208";a="281439135" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 13 Nov 2013 20:24:21 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rADKOKda010881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 20:24:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 14:24:20 -0600 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , Anne van Kesteren Thread-Topic: [Json] JSON: remove gap between Ecma-404 and IETF draft Thread-Index: AQHO37wfJCh2AJRFT02Gmc0EpJu9eJojjGwA Date: Wed, 13 Nov 2013 20:24:20 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.129.24.62] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: es-discuss , IETF Discussion , "www-tag@w3.org" , JSON WG Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:24:27 -0000 >On Nov 11, 2013, at 11:01 PM, Anne van Kesteren wrote: > >> To improve JSON interoperability the IETF should not define a more >> restricted version of JSON than defined by Ecma-404. >>=20 >> Parsers exist that can parse "42" today and parsers that cannot parse >> "42" today can be meaningfully upgraded to do so too. This would not >> break those parsers, unless they depend on parsing 42 as an error, >> which is a far more unlikely scenario than parsing it as 42 given >> precedence. I see Anne's input on the top-level grammar as interesting and useful. I believe that we could choose to be reasonable here by changing the ABNF: JSON-text =3D value and then adding text about interoperability in the same way that we have approached numbers, strings, and duplicate keys. Protocols that come after this draft is published as an RFC can safely decide to allow any top level value. Parsers that claim compatibility with the new doc will allow any value. For widest interoperability, however, you can't assume that an unknown receiver will correctly process anything but an object or an array at the top level. We would also need to change section 8.1 according to the mechanism that was previously proposed: 00 00 00 xx UTF-32BE 00 xx ?? xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx ?? UTF-16LE xx xx ?? ?? UTF-8 in order to account for strings at the top level whose first character has a codepoint greater than 127. It would be awful for there to remain two mutually-incompatible versions of JSON going forward, and I think we should take this opportunity to address the biggest incompatibility. >>(Worth pondering about: what to do about a leading BOM, which >>XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404 >>allow.) If 404 doesn't allow it, I don't see a strong need to add it. Parsers can always be more forgiving of what they will parse than what the spec says, particularly since section 9 says "A JSON parser MAY accept non-JSON forms or extensions". --=20 Joe Hildebrand From cabo@tzi.org Wed Nov 13 12:33:11 2013 Return-Path: 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 13A2911E8107; Wed, 13 Nov 2013 12:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 d6afyGMiXKYm; Wed, 13 Nov 2013 12:33:01 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7D56511E8120; Wed, 13 Nov 2013 12:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rADKWeWq000127; Wed, 13 Nov 2013 21:32:40 +0100 (CET) Received: from [192.168.101.128] (unknown [64.245.0.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8FEF9DD3; Wed, 13 Nov 2013 21:32:35 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Wed, 13 Nov 2013 12:32:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <97CAF0BE-A67D-45AC-9004-D659808889B7@tzi.org> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1822) Cc: IETF Discussion , Paul Hoffman , JSON WG , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:33:11 -0000 On 13 Nov 2013, at 12:24, Joe Hildebrand (jhildebr) = wrote: > changing the ABNF: >=20 > JSON-text =3D value (would need to add the whitespace =97 that is not visible in the ECMA = 404 racetracks because they use an implicit whitespace rule.) There has been a long discussion in the WG about this potential change, = I don=92t want to repeat it here. It may be worthwhile to dig up pointers to how that resulted in not = making the change, for observers outside the WG. Gr=FC=DFe, Carsten From jhildebr@cisco.com Wed Nov 13 12:38:39 2013 Return-Path: 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 2154F21F9FF3; Wed, 13 Nov 2013 12:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.164 X-Spam-Level: X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 FeXqMzQFJv50; Wed, 13 Nov 2013 12:38:33 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CA1C821F85EC; Wed, 13 Nov 2013 12:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1074; q=dns/txt; s=iport; t=1384375112; x=1385584712; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xR2vHpm8s/Z2aDbhG9IefKZ6eBUVgy5PtS2csDHqQUg=; b=JE6dn9AjdhZJtfsxfkL5bnuYWAtE8QGR0RNEWrO2hFWJb+GOgOWThWkY NzX9W0pFsMcf0hrs+aYcI3E4aXTrrIHW+3W2Og4YavDQ+TrNsIgAPeOVb Ao/vX+bpbPOZ36OjCyArmf0WOnoCeyxjugwSSKyL8QzL2Fy1S2EfBeGen w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPzig1KtJXHA/2dsb2JhbABZgweBC78sgSgWdIIlAQEBBDo/EgEIGB5CJQIEAQ0FiAHAMY9fB4QxA4xZizeHOIpTgyiCKg X-IronPort-AV: E=Sophos;i="4.93,695,1378857600"; d="scan'208";a="284451012" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 13 Nov 2013 20:38:10 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rADKc9ec027096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 20:38:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 14:38:09 -0600 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , Anne van Kesteren Thread-Topic: [Json] JSON: encodings Thread-Index: AQHO37v9xjk3Oc0cjEWcneEucZMQiJojkEcA Date: Wed, 13 Nov 2013 20:38:08 +0000 Message-ID: In-Reply-To: <99EE3A2D-D1CF-44EF-BA61-156ED8E72F79@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.129.24.62] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Henri Sivonen , IETF Discussion , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:38:39 -0000 On 11/12/13 8:28 AM, "Paul Hoffman" wrote: >[[ Adding the JSON WG to this thread ]] > >On Nov 11, 2013, at 10:58 PM, Anne van Kesteren wrote: > >> Supporting encodings other than UTF-8 in new formats is not good. >>=20 >> 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. >>=20 >> 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. What I think we *could* do is put a stronger recommendation for UTF-8 in section 8.1, rather than just saying it's the default. --=20 Joe Hildebrand From julian.reschke@gmx.de Wed Nov 13 12:43:00 2013 Return-Path: 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 D48E121F9FAB for ; Wed, 13 Nov 2013 12:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 XeEnvjF0OvlQ for ; Wed, 13 Nov 2013 12:43:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id DEA2321E80F0 for ; Wed, 13 Nov 2013 12:42:51 -0800 (PST) Received: from [192.168.2.117] ([84.187.57.221]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lkzph-1V8BTD3MkX-00annw for ; Wed, 13 Nov 2013 21:42:50 +0100 Message-ID: <5283E447.1070707@gmx.de> Date: Wed, 13 Nov 2013 21:42:47 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , Paul Hoffman , Anne van Kesteren References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:abIoq9anDqY7+WDp1c75QFXiiwcu8D/Snf5XZswC55V4uiheNeQ LyR71AGJR62B6G8pLXkT1XQOcO+JIvhp0/M+nvE6DolYrpWAWKpL1NAz2sPRiL/arbOFYVt F87f9O/8hD9XlFYZWO37scm8+aZo3Lrl9CzYkjXLqDMzWyCGTBH4WScaMjn36s97g9Y4Dt+ dW6aGO2EhuHJp6sYfYyGg== Cc: Henri Sivonen , IETF Discussion , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:43:01 -0000 On 2013-11-13 21:38, Joe Hildebrand (jhildebr) wrote: > On 11/12/13 8:28 AM, "Paul Hoffman" wrote: > >> [[ Adding the JSON WG to this thread ]] >> >> On Nov 11, 2013, at 10:58 PM, Anne van Kesteren 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. +0.5 > What I think we *could* do is put a stronger recommendation for UTF-8 in > section 8.1, rather than just saying it's the default. +10 From jhildebr@cisco.com Wed Nov 13 12:43:22 2013 Return-Path: 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 D433311E81A9; Wed, 13 Nov 2013 12:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.309 X-Spam-Level: X-Spam-Status: No, score=-10.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 N14IdNBaEYch; Wed, 13 Nov 2013 12:43:17 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F16EB21F9FAB; Wed, 13 Nov 2013 12:43:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=967; q=dns/txt; s=iport; t=1384375397; x=1385584997; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=m7RcUrJ3TzyCqU4yMezO7Pin+N9vMDKDrNrS54vfpOk=; b=hO+1mxL0htDPg72g2re5J2UqAExUNSX+DKdRzDVtb+GRmELsjLlXmQVk oOkfTIIZJP/k0AU4A6wEfCA3i2ROGCAqKEETk9Tr1qomu6OceNZs5Ifkh bP9iufCUFjtjTEoYrPWWZw1L1Tpz2ZoOPTGUDONb2k0RZ49sYDfzSKLER E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAO3jg1KtJV2c/2dsb2JhbABZgweBC78sgSgWdIIseRIBCA5qJQIEDgWIAcA2j18HhDEDmBCSC4Mogio X-IronPort-AV: E=Sophos;i="4.93,695,1378857600"; d="scan'208";a="284430418" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 13 Nov 2013 20:43:11 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rADKhBqU016575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 20:43:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 14:43:11 -0600 From: "Joe Hildebrand (jhildebr)" To: Carsten Bormann Thread-Topic: [Json] JSON: remove gap between Ecma-404 and IETF draft Thread-Index: AQHO37wfJCh2AJRFT02Gmc0EpJu9eJojjGwAgAB3owD//42eAA== Date: Wed, 13 Nov 2013 20:43:10 +0000 Message-ID: In-Reply-To: <97CAF0BE-A67D-45AC-9004-D659808889B7@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.129.24.62] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Discussion , Paul Hoffman , JSON WG , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:43:23 -0000 On 11/13/13 1:32 PM, "Carsten Bormann" wrote: >On 13 Nov 2013, at 12:24, Joe Hildebrand (jhildebr) >wrote: > >> changing the ABNF: >>=20 >> JSON-text =3D value > >(would need to add the whitespace =8B that is not visible in the ECMA 404 >racetracks because they use an implicit whitespace rule.) Good catch. >There has been a long discussion in the WG about this potential change, I >don=B9t want to repeat it here. >It may be worthwhile to dig up pointers to how that resulted in not >making the change, for observers outside the WG. I would argue that we didn't have adequate representation from TC39 in that discussion, and that their getting involved is as good a reason as any to double-check that we've still got the same consensus. I know that I for one decided to stop pushing for this when it looked like there were a few more participants that wanted the status quo. --=20 Joe Hildebrand From tony@att.com Wed Nov 13 13:04:51 2013 Return-Path: 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 33B5321E8123; Wed, 13 Nov 2013 13:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 CpQL12AYOIUp; Wed, 13 Nov 2013 13:04:45 -0800 (PST) Received: from tlpi046.enaf.dadc.sbc.com (egssmtp01.att.com [144.160.112.12]) by ietfa.amsl.com (Postfix) with ESMTP id A32B821E80CC; Wed, 13 Nov 2013 13:04:44 -0800 (PST) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp01.att.com (8.14.4/8.14.4) with ESMTP id rADL4g0h026404; Wed, 13 Nov 2013 15:04:43 -0600 Received: from njcdtl02ap0003.itservices.sbc.com ([135.91.110.235]) by maillennium.att.com (mailgw1) with ESMTP id <20131113210442gw100j0c0qe>; Wed, 13 Nov 2013 21:04:42 +0000 X-Originating-IP: [135.91.110.235] Message-ID: <5283E976.2070101@att.com> Date: Wed, 13 Nov 2013 16:04:54 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , IETF Discussion , JSON WG References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:04:51 -0000 On 11/13/13, 3:43 PM, Joe Hildebrand (jhildebr) wrote: > I would argue that we didn't have adequate representation from TC39 in > that discussion, and that their getting involved is as good a reason > as any to double-check that we've still got the same consensus. I know > that I for one decided to stop pushing for this when it looked like > there were a few more participants that wanted the status quo. I personally am on the side of making this change. I think it'd be an extreme shame if this incompatibility remained in the document. Tony Hansen From paul.hoffman@vpnc.org Wed Nov 13 13:28:16 2013 Return-Path: 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 38C5821E8104; Wed, 13 Nov 2013 13:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 r6V7tRiikVGE; Wed, 13 Nov 2013 13:28:15 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4FD21E8121; Wed, 13 Nov 2013 13:28:06 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rADLRxMj088941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Nov 2013 14:28:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: Date: Wed, 13 Nov 2013 13:27:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3389CD77-B1CC-4A76-907A-6D400DA028CC@vpnc.org> References: To: Joe Hildebrand Hildebrand X-Mailer: Apple Mail (2.1822) Cc: Anne van Kesteren , JSON WG , IETF Discussion , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:28:17 -0000 On Nov 13, 2013, at 12:24 PM, Joe Hildebrand (jhildebr) = wrote: > We would also need to change section 8.1 according to the mechanism = that > was previously proposed: >=20 > 00 00 00 xx UTF-32BE > 00 xx ?? xx UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 xx ?? UTF-16LE > xx xx ?? ?? UTF-8 >=20 > in order to account for strings at the top level whose first character = has > a codepoint greater than 127. A string at the top level of a JSON text still needs to start with an = ASCII " character, so the logic is still fine, I believe. Carsten's point about whitespace is more problematic. Does the ECMA-404 = definition of a JSON text allow it to start with one (or more) = whitespace characters? The text in that document says: . . . A JSON text is a sequence of tokens formed from Unicode code points that = conforms to the JSON value grammar. The set of tokens includes six = structural tokens, strings, numbers, and three literal name tokens. . . . Insignificant whitespace is allowed before or after any token. . . . It would be nice if ECMA-404 was clearer on this, given that the = racetrack illustrations show everything other than the whitespace. In = specific, it would be good to know whether or not the racetrack for = "value" in Section 5 is meant to have optional whitespace at the left = and right to match the above text. If TC39 could say for certain on = that, it would be useful to the community. --Paul Hoffman= From allen@wirfs-brock.com Wed Nov 13 13:40:47 2013 Return-Path: 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 D7C9321E8154; Wed, 13 Nov 2013 13:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] 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 uG0Q1oLbQ36P; Wed, 13 Nov 2013 13:40:41 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id ACDE521E8165; Wed, 13 Nov 2013 13:39:26 -0800 (PST) Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.22]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Vgi9k-000MOc-H0; Wed, 13 Nov 2013 21:39:24 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.64.236.244 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18SUWjx8PakZ0HF06+qqSh7q+KKPX8bxDI= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Allen Wirfs-Brock In-Reply-To: <3389CD77-B1CC-4A76-907A-6D400DA028CC@vpnc.org> Date: Wed, 13 Nov 2013 13:39:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <967BEA5F-FA98-4A9E-8311-8295528F30E7@wirfs-brock.com> References: <3389CD77-B1CC-4A76-907A-6D400DA028CC@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1085) Cc: IETF Discussion , JSON WG , Joe Hildebrand Hildebrand , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:40:47 -0000 On Nov 13, 2013, at 1:27 PM, Paul Hoffman wrote: > >=20 > On Nov 13, 2013, at 12:24 PM, Joe Hildebrand (jhildebr) = wrote: >=20 >> We would also need to change section 8.1 according to the mechanism = that >> was previously proposed: >>=20 >> 00 00 00 xx UTF-32BE >> 00 xx ?? xx UTF-16BE >> xx 00 00 00 UTF-32LE >> xx 00 xx ?? UTF-16LE >> xx xx ?? ?? UTF-8 >>=20 >> in order to account for strings at the top level whose first = character has >> a codepoint greater than 127. >=20 > A string at the top level of a JSON text still needs to start with an = ASCII " character, so the logic is still fine, I believe. >=20 > Carsten's point about whitespace is more problematic. Does the = ECMA-404 definition of a JSON text allow it to start with one (or more) = whitespace characters? The text in that document says: > . . . > A JSON text is a sequence of tokens formed from Unicode code points = that conforms to the JSON value grammar. The set of tokens includes six = structural tokens, strings, numbers, and three literal name tokens. > . . . > Insignificant whitespace is allowed before or after any token. > . . . >=20 > It would be nice if ECMA-404 was clearer on this, given that the = racetrack illustrations show everything other than the whitespace. In = specific, it would be good to know whether or not the racetrack for = "value" in Section 5 is meant to have optional whitespace at the left = and right to match the above text. If TC39 could say for certain on = that, it would be useful to the community. Yes, leading white space is allowed: "The set of tokens includes the six structural tokens, *strings*, = *numbers*, ..." (emphasis added) "Insignificant whitespace is allowed before or after any token" The elements matched by the value production are all tokens (or = productions that begin and end with a token) so whitespace can occur to = the left or right of any value Allen From cabo@tzi.org Wed Nov 13 13:41:21 2013 Return-Path: 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 625C721E816D; Wed, 13 Nov 2013 13:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 WTUBB2z5QZda; Wed, 13 Nov 2013 13:41:15 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CFE8D21E8142; Wed, 13 Nov 2013 13:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rADLe85r013006; Wed, 13 Nov 2013 22:40:08 +0100 (CET) Received: from [192.168.101.128] (unknown [64.245.0.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C07E0E18; Wed, 13 Nov 2013 22:40:04 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <3389CD77-B1CC-4A76-907A-6D400DA028CC@vpnc.org> Date: Wed, 13 Nov 2013 13:40:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <017375D1-898E-4012-8328-83A35C9ABFA3@tzi.org> References: <3389CD77-B1CC-4A76-907A-6D400DA028CC@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1822) Cc: es-discuss , IETF Discussion , "www-tag@w3.org" , JSON WG Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:41:21 -0000 On 13 Nov 2013, at 13:27, Paul Hoffman wrote: > It would be nice if ECMA-404 was clearer on this I think the only way to read the English prose in ECMA-404 is to always = allow insignificant whitespace around every token, including the single = token that makes up an out-of-container JSON value. That is also consistent with the most widely deployed extensions of JSON = for out-of-container values, including the one in recent JavaScript. (Yes, it is easier to be unambiguous with ABNF.) Gr=FC=DFe, Carsten From hildjj@cursive.net Wed Nov 13 13:39:42 2013 Return-Path: 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 52EAC21E8091 for ; Wed, 13 Nov 2013 13:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 eF1AqwTD-aKb for ; Wed, 13 Nov 2013 13:39:42 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1D65C11E810F for ; Wed, 13 Nov 2013 13:37:02 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id rd3so1051720pab.14 for ; Wed, 13 Nov 2013 13:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cursive.net; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=wqnklPmZhwGuEDCRhZzgPC+54FgOUAtcJU6PMt85Ve8=; b=JahVoeVYNGWf6zXH6/G/nfh+kNxnLIVfJBZ5OAZV46IkpIGoPjvsZdKvZp4zOHIa0Q ZVMIR3m1FvQHkyemUT85Xc+W542LcBoCHcnCoyG0ZUwWb1+h58ipRKAWr2WycSCAWtkA RS8OK8C2NFqGz3w+GjRevS1qUpUr5X/v0yctg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=wqnklPmZhwGuEDCRhZzgPC+54FgOUAtcJU6PMt85Ve8=; b=gopRQbe4E+KGaYCV955vIrvmFFMrcbyLf6YnREu7zbxnCEw4C3Mtjcny42Z9kmRH3T +iFI0azIqKOTEP6TMT+VKqNVTSfeG1zVRs3aO73b6W8JDHmmL538KiqYEyqWSOitrDjH SDjuvgUAUennWtuXBhHMY1CjhSvfhhssB+9ofeNupcntWKvGftFtpA8EEnt6B+AZr9qj Ck9WsXzWJJ/BBMGUMoKGmkW15qC2nc9StFJ8R2pH1jnWZj29vwLzgbqhcbMzQu9hWI27 lBptfMxH66pZZX8JbUY2Q5y/Ya+f4l3Xv5A6p0snQh/uMbXefTVNwp2Mgz0wULsmiQbp FPGA== X-Gm-Message-State: ALoCoQn5H5NOsgl890VjUvR/y9/4/heJkkAVDt93/UjNtFtU+teLdOdr30CYlSphcW45qa0zNSCN X-Received: by 10.68.182.3 with SMTP id ea3mr43856678pbc.124.1384378610997; Wed, 13 Nov 2013 13:36:50 -0800 (PST) Received: from [10.129.24.62] (128-107-239-234.cisco.com. [128.107.239.234]) by mx.google.com with ESMTPSA id yi10sm54175727pab.8.2013.11.13.13.36.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Nov 2013 13:36:49 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Wed, 13 Nov 2013 14:36:37 -0700 From: Joe Hildebrand To: Paul Hoffman , Joe Hildebrand Hildebrand Message-ID: Thread-Topic: [Json] JSON: remove gap between Ecma-404 and IETF draft In-Reply-To: <3389CD77-B1CC-4A76-907A-6D400DA028CC@vpnc.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Wed, 13 Nov 2013 13:50:25 -0800 Cc: Anne van Kesteren , es-discuss , IETF Discussion , "www-tag@w3.org" , JSON WG Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:39:42 -0000 On 11/13/13 2:27 PM, "Paul Hoffman" wrote: > > >On Nov 13, 2013, at 12:24 PM, Joe Hildebrand (jhildebr) > wrote: > >> We would also need to change section 8.1 according to the mechanism that >> was previously proposed: >> >> 00 00 00 xx UTF-32BE >> 00 xx ?? xx UTF-16BE >> xx 00 00 00 UTF-32LE >> xx 00 xx ?? UTF-16LE >> xx xx ?? ?? UTF-8 >> >> in order to account for strings at the top level whose first character >>has >> a codepoint greater than 127. > >A string at the top level of a JSON text still needs to start with an >ASCII " character, so the logic is still fine, I believe. Without top level strings, the first *two* characters of any JSON text are always ASCII. This: "?" (that's U+0022 U+0100 U+0022) would encode the first two characters in UTF-16BE as: 00 22 01 00 8.1 currently says: 00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx 00 UTF-16LE xx xx xx xx UTF-8 So the JSON text above would not match any of the table entries, causing an error. -- Joe Hildebrand From jhildebr@cisco.com Wed Nov 13 13:54:36 2013 Return-Path: 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 DF18911E810A; Wed, 13 Nov 2013 13:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.381 X-Spam-Level: X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 KtcZpBqYybCM; Wed, 13 Nov 2013 13:54:31 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 47EC121E80DC; Wed, 13 Nov 2013 13:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=882; q=dns/txt; s=iport; t=1384379671; x=1385589271; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eiaT16M54LqUWLs7B6x7UZcQxB/bovnBPJ/An6/1MwU=; b=FoMBvXPvLMZYMkCxUwjAcIqAitLSTCvwz5G2ozYAuSTy2mhahPuKevDz udjFi5OB3ppGQsgJfs1Dfj/rGdw7BFLl7bBR45Tn0dmSsEavqwJAZa4yM 3HTP+0m4gDYGuHc0XIcr7yh4gsONCMRL3Tmw0O4XXJ5vqTO3aBb99Jm0o E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFANzzg1KtJV2a/2dsb2JhbABZgweBC78sgSgWdIIlAQEBBDotEhIBCA4KHkIlAgQBDQWIAcAoj18HhDEDmBCSC4Mogio X-IronPort-AV: E=Sophos;i="4.93,695,1378857600"; d="scan'208";a="284280306" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 13 Nov 2013 21:54:31 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rADLsUvw012706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 21:54:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 15:54:30 -0600 From: "Joe Hildebrand (jhildebr)" To: Carsten Bormann , Paul Hoffman Thread-Topic: [Json] JSON: remove gap between Ecma-404 and IETF draft Thread-Index: AQHO37wfJCh2AJRFT02Gmc0EpJu9eJojjGwAgACHIgCAAANegP//jrEA Date: Wed, 13 Nov 2013 21:54:29 +0000 Message-ID: In-Reply-To: <017375D1-898E-4012-8328-83A35C9ABFA3@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.129.24.62] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: JSON WG , IETF Discussion , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 21:54:37 -0000 On 11/13/13 2:40 PM, "Carsten Bormann" wrote: >On 13 Nov 2013, at 13:27, Paul Hoffman wrote: > >> It would be nice if ECMA-404 was clearer on this > >I think the only way to read the English prose in ECMA-404 is to always >allow insignificant whitespace around every token, including the single >token that makes up an out-of-container JSON value. >That is also consistent with the most widely deployed extensions of JSON >for out-of-container values, including the one in recent JavaScript. > >(Yes, it is easier to be unambiguous with ABNF.) Note further that since ECMA-404 says: "The whitespace characters are: character tabulation (U+0009), line feed (U+000A), carriage return (U+000D), and space (U+0020)" that the encoding detection does not need to be modified again with this change. --=20 Joe Hildebrand From paul.hoffman@vpnc.org Wed Nov 13 14:18:48 2013 Return-Path: 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 C37DE21E8157; Wed, 13 Nov 2013 14:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Q2RAqpDVtK-a; Wed, 13 Nov 2013 14:18:48 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB6D21E808A; Wed, 13 Nov 2013 14:18:48 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rADMIglS090355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Nov 2013 15:18:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: Date: Wed, 13 Nov 2013 14:18:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <953661EF-8ECC-420E-8467-2A19E01DAFDB@vpnc.org> References: To: Joe Hildebrand Hildebrand X-Mailer: Apple Mail (2.1822) Cc: Anne van Kesteren , es-discuss , IETF Discussion , "www-tag@w3.org" , JSON WG Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:18:48 -0000 On Nov 13, 2013, at 1:36 PM, Joe Hildebrand wrote: > Without top level strings, the first *two* characters of any JSON text = are > always ASCII. This: >=20 >=20 > "?" (that's U+0022 U+0100 U+0022) >=20 > would encode the first two characters in UTF-16BE as: >=20 > 00 22 01 00 >=20 > 8.1 currently says: >=20 > 00 00 00 xx UTF-32BE > 00 xx 00 xx UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 xx 00 UTF-16LE > xx xx xx xx UTF-8 >=20 > So the JSON text above would not match any of the table entries, = causing > an error. Yep, you're right, and ignore my previous message. I can't count to two = these days.... --Paul Hoffman= From cowan@ccil.org Wed Nov 13 14:47:56 2013 Return-Path: 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 39D7911E81A3; Wed, 13 Nov 2013 14:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.638 X-Spam-Level: X-Spam-Status: No, score=-3.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 vY5svVwTJxNF; Wed, 13 Nov 2013 14:47:45 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 36D9111E80E6; Wed, 13 Nov 2013 14:47:45 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VgjDm-0007dW-4q; Wed, 13 Nov 2013 17:47:38 -0500 Date: Wed, 13 Nov 2013 17:47:38 -0500 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20131113224737.GI31823@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: IETF Discussion , Paul Hoffman , JSON WG , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:47:56 -0000 Joe Hildebrand (jhildebr) scripsit: > I see Anne's input on the top-level grammar as interesting and useful. > I believe that we could choose to be reasonable here by changing > the ABNF: > > JSON-text = value > > and then adding text about interoperability in the same way that we > have approached numbers, strings, and duplicate keys. +1 for choosing to be reasonable. > If 404 doesn't allow [a BOM], I don't see a strong need to add it. > Parsers can always be more forgiving of what they will parse than what > the spec says, particularly since section 9 says "A JSON parser MAY > accept non-JSON forms or extensions". It's not clear that 404 disallows it, since 404 is defined in terms of characters, and a BOM is not a character but an out-of-band signal. -- John Cowan cowan@ccil.org http://ccil.org/~cowan This great college [Trinity], of this ancient university [Cambridge], has seen some strange sights. It has seen Wordsworth drunk and Porson sober. And here am I, a better poet than Porson, and a better scholar than Wordsworth, somewhere betwixt and between. --A.E. Housman From cowan@ccil.org Wed Nov 13 14:48:46 2013 Return-Path: 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 2A44B11E81A3; Wed, 13 Nov 2013 14:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 rHVh-y5D-TyI; Wed, 13 Nov 2013 14:48:41 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCBF21F9BC1; Wed, 13 Nov 2013 14:48:34 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VgjEe-0007qL-E7; Wed, 13 Nov 2013 17:48:32 -0500 Date: Wed, 13 Nov 2013 17:48:32 -0500 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20131113224832.GJ31823@mercury.ccil.org> References: <99EE3A2D-D1CF-44EF-BA61-156ED8E72F79@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Henri Sivonen , Anne van Kesteren , JSON WG , Paul Hoffman , IETF Discussion 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 22:48:46 -0000 Joe Hildebrand (jhildebr) scripsit: > 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. Well, no, they would just be non-portable but legitimate extensions. -- Using RELAX NG compact syntax to John Cowan develop schemas is one of the simple http://www.ccil.org/~cowan pleasures in life.... --Jeni Tennison From jhildebr@cisco.com Wed Nov 13 15:51:51 2013 Return-Path: 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 DF78921E80FA; Wed, 13 Nov 2013 15:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.201 X-Spam-Level: X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] 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 2WLfPY78NBGM; Wed, 13 Nov 2013 15:51:46 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4366121E8094; Wed, 13 Nov 2013 15:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=961; q=dns/txt; s=iport; t=1384386706; x=1385596306; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1iaQ0BIU+Wt4AjlnfmU/TmQCgMr+4Z3MUWY7OSiWcx8=; b=FPPXoTaJgqyFoE50Lq9lp2FBd34kNBWf0vbW49B1T4EKALeUyC6neqBD hi33yD9DN7uHd5lkDkMfgGRJPotU9agFHVrERXoDWVDyqJj37hdStWbva Z8q1/KlWr+uP2wbaeOB3Z7U5zOJT9MoJM4wcjzAAnweK68GgktAHnUWV3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEcPhFKtJV2a/2dsb2JhbABZgweBC78qgSUWdIIsOj8SAQg2QiUCBA4FiAHAKI9fB4QxA5Qug2KSC4MogWgGPA X-IronPort-AV: E=Sophos;i="4.93,695,1378857600"; d="scan'208";a="284593254" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 13 Nov 2013 23:51:45 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rADNpjeJ017564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 23:51:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 17:51:44 -0600 From: "Joe Hildebrand (jhildebr)" To: John Cowan Thread-Topic: [Json] JSON: remove gap between Ecma-404 and IETF draft Thread-Index: AQHO37wfJCh2AJRFT02Gmc0EpJu9eJojjGwAgACdZQD//5yMgA== Date: Wed, 13 Nov 2013 23:51:44 +0000 Message-ID: In-Reply-To: <20131113224737.GI31823@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.124.251] Content-Type: text/plain; charset="us-ascii" Content-ID: <88A13CDF1F6A284C9F3750B2CFFFFBD8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Discussion , Paul Hoffman , JSON WG , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 23:51:52 -0000 On 11/13/13 3:47 PM, "John Cowan" wrote: >It's not clear that 404 disallows it, since 404 is defined in terms of >characters, and a BOM is not a character but an out-of-band signal. Agree. However, that signal would be a part of the 4627bis octet stream, so a little interop guidance would likely be useful. Something like: "Some producers of JSON produce JSON-text that starts with a redundant U+FEFF (ZERO WIDTH NO-BREAK SPACE, previously known as BYTE ORDER MARK) with the ostensible purpose of signaling the encoding of the text to follow. Since JSON has other mechanisms to determine encoding, this is not required. Receiving applications MAY safely ignore this initial character without generating an error. Implementations that do not send U+FEFF are interoperable in the sense that all software implementations which receive the un-prefixed text will not generate parse errors." --=20 Joe Hildebrand From hallam@gmail.com Wed Nov 13 17:19:55 2013 Return-Path: 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 ; 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: References: <99EE3A2D-D1CF-44EF-BA61-156ED8E72F79@vpnc.org> Date: Wed, 13 Nov 2013 20:19:52 -0500 Message-ID: From: Phillip Hallam-Baker To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=089e0112c73cf23dc604eb18e092 X-Mailman-Approved-At: Wed, 13 Nov 2013 17:55:04 -0800 Cc: Henri Sivonen , Anne van Kesteren , JSON WG , Paul Hoffman , IETF Discussion 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 01:19:55 -0000 --089e0112c73cf23dc604eb18e092 Content-Type: text/plain; charset=ISO-8859-1 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" wrote: > > >[[ Adding the JSON WG to this thread ]] > > > >On Nov 11, 2013, at 10:58 PM, Anne van Kesteren 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/ --089e0112c73cf23dc604eb18e092 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 13, 2013 at 3:38 PM, Joe Hildebrand (jhildebr) <jhild= ebr@cisco.com> wrote:
On 1= 1/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.<= br> >>
>> 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, j= ust
>> like the W3C has.

Although I hate UTF-32 with the heat of a several moderately-si= zed 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. =A0There may be existing
conformant JSON documents stored in UTF-32 that would be made unparseable by this change.

Nothing the IETF does i= s going to make documents unparseable. All the IETF can do is to tell peopl= e what the standard form of JSON is.

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

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

--
Website: http://hallambaker.com/
--089e0112c73cf23dc604eb18e092-- From mark.edward.davis@gmail.com Wed Nov 13 16:50:45 2013 Return-Path: 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 D414221E8095; Wed, 13 Nov 2013 16:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 g2zcwE+EfyOU; Wed, 13 Nov 2013 16:50:45 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4984321E8090; Wed, 13 Nov 2013 16:50:45 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id i7so766371qcq.23 for ; Wed, 13 Nov 2013 16:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ud91NElK6XaQ82AatuXdI1ZKhPnfVMV56RWmaR08Vgc=; b=BIWCt6C0N7oMAYZuqdjzEScfufYoLWHUE8RdlxNi+pY1L+bVZAWHI4pEUxwgfwprHJ mz4spPTLFQwqoJEXaHC6p6op2uH9L6zpWjHxNvyWZGoPUvWHRwfLVBYjKHOOOnyhnkDk lzOmVwByGEZK1t0eIeQN472GHHXMb6q0JaiN2LD6T2nvli5v/6k/7mg4O69e3eqWLXEo FZcsNxETrwCf8nE6tJ+KUBAaOzMFHRDyExVNtuVFAfxvUtjSQe2FngdD0j05Y22vyKiG JvpNFoYzupGCYE1hLR8NP1kONdKq60Yk/q67AlQbPZ5oVWM9U3Zz4RpmqDZWcLaOpZWu /oHg== MIME-Version: 1.0 X-Received: by 10.224.57.68 with SMTP id b4mr72868022qah.63.1384390244778; Wed, 13 Nov 2013 16:50:44 -0800 (PST) Sender: mark.edward.davis@gmail.com Received: by 10.96.214.98 with HTTP; Wed, 13 Nov 2013 16:50:44 -0800 (PST) In-Reply-To: References: <20131113224737.GI31823@mercury.ccil.org> Date: Wed, 13 Nov 2013 16:50:44 -0800 X-Google-Sender-Auth: rmEaYTnzzM9eS8ieVNt_l5-lxb8 Message-ID: From: =?UTF-8?B?TWFyayBEYXZpcyDimJU=?= To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=089e013cba28c56d4104eb187884 X-Mailman-Approved-At: Wed, 13 Nov 2013 17:55:14 -0800 Cc: John Cowan , IETF Discussion , Paul Hoffman , JSON WG , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 00:50:46 -0000 --089e013cba28c56d4104eb187884 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 13, 2013 at 3:51 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > that all software implementations > which receive the un-prefixed text will not generate parse errors." > perhaps: ...=E2=80=8Ball conformant software ...=E2=80=8B Mark *=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94* --089e013cba28c56d4104eb187884 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Nov 13, 2013 at 3:51 PM, Joe Hildebrand (jhildebr) <jhildebr@cisc= o.com> wrote:
th= at all software implementations
which receive the un-prefixed text will not generate parse errors."

perhaps:

...=E2=80=8Ball conformant software ...=E2=80=8B


<= div style=3D"background-color:transparent;margin-top:0px;margin-left:0px;ma= rgin-bottom:0px;margin-right:0px">
=E2=80=94 Il meglio =C3=A8 l=E2=80=99inimico del bene =E2=80=94
--089e013cba28c56d4104eb187884-- From cowan@ccil.org Wed Nov 13 18:12:35 2013 Return-Path: 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 6F8EE21E80D9; Wed, 13 Nov 2013 18:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] 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 hgqHxMdsQG4Z; Wed, 13 Nov 2013 18:12:31 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 37B9C21E80CB; Wed, 13 Nov 2013 18:12:29 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Vgm3p-0001SK-Qd; Wed, 13 Nov 2013 20:49:33 -0500 Date: Wed, 13 Nov 2013 20:49:33 -0500 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20131114014933.GK31823@mercury.ccil.org> References: <20131113224737.GI31823@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: IETF Discussion , Paul Hoffman , JSON WG , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 02:12:35 -0000 Joe Hildebrand (jhildebr) scripsit: > "Some producers of JSON produce JSON-text that starts with a redundant > U+FEFF (ZERO WIDTH NO-BREAK SPACE, previously known as BYTE ORDER MARK) For "previously" read "also". Indeed, the use of U+FEFF as a zero-width no-break space is deprecated in favor of U+2600 WORD JOINER. See . -- John Cowan Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz. --Calvin, giving Newton's First Law "in his own words" From allen@wirfs-brock.com Wed Nov 13 18:35:24 2013 Return-Path: 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 1BE5121E812D; Wed, 13 Nov 2013 18:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_45=0.6] 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 a0XXOYx2HxkW; Wed, 13 Nov 2013 18:35:18 -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 F39DC21E811C; Wed, 13 Nov 2013 18:35:17 -0800 (PST) Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.22]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Vgmm3-000Lab-3q; Thu, 14 Nov 2013 02:35:15 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.64.236.244 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19HjyrCL5dDEOvVnuQBcuUDCOeOOKXxJrA= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Allen Wirfs-Brock In-Reply-To: Date: Wed, 13 Nov 2013 18:35:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2E62DA50-F941-4A0E-A7B3-966A0DDE4C7A@wirfs-brock.com> References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1085) Cc: John Cowan , IETF Discussion , Paul Hoffman , JSON WG , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 02:35:24 -0000 On Nov 13, 2013, at 3:51 PM, Joe Hildebrand (jhildebr) wrote: > On 11/13/13 3:47 PM, "John Cowan" wrote: >=20 >> It's not clear that 404 disallows it, since 404 is defined in terms = of >> characters, and a BOM is not a character but an out-of-band signal. However, for example, a conforming implementation of the ECMAScript = JSON.parse function would reject any string passed to it that starts = with a U+FFEF code point because the unquoted occurrence of that code = point does not conform to the ECMA-252, 5th Edition or Ecma-404 JSON = grammar. In order to be successfully processed, that code point would have to be = stripped from the string prior to calling JSON.parse. Allen >=20 > Agree. However, that signal would be a part of the 4627bis octet = stream, > so a little interop guidance would likely be useful. Something like: >=20 > "Some producers of JSON produce JSON-text that starts with a redundant > U+FEFF (ZERO WIDTH NO-BREAK SPACE, previously known as BYTE ORDER = MARK) > with the ostensible purpose of signaling the encoding of the text to > follow. Since JSON has other mechanisms to determine encoding, this = is > not required. Receiving applications MAY safely ignore this initial > character without generating an error. Implementations that do not = send > U+FEFF are interoperable in the sense that all software = implementations > which receive the un-prefixed text will not generate parse errors." >=20 Isn't it an interooperbility issue that many receiving applications do = not ignore it. Allen From paul.hoffman@vpnc.org Wed Nov 13 19:15:51 2013 Return-Path: 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 4EFF021E812D; Wed, 13 Nov 2013 19:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.993 X-Spam-Level: X-Spam-Status: No, score=-101.993 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100] 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 6q+YsphG5hAi; Wed, 13 Nov 2013 19:15:50 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D5D3C21E8056; Wed, 13 Nov 2013 19:15:50 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rAE3FT5Q000759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Nov 2013 20:15:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <2E62DA50-F941-4A0E-A7B3-966A0DDE4C7A@wirfs-brock.com> Date: Wed, 13 Nov 2013 19:15:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E62DA50-F941-4A0E-A7B3-966A0DDE4C7A@wirfs-brock.com> To: Allen Wirfs-Brock X-Mailer: Apple Mail (2.1822) Cc: John Cowan , IETF Discussion , JSON WG , Joe Hildebrand Hildebrand , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 03:15:51 -0000 On Nov 13, 2013, at 6:35 PM, Allen Wirfs-Brock = wrote: >=20 > On Nov 13, 2013, at 3:51 PM, Joe Hildebrand (jhildebr) wrote: >=20 >> On 11/13/13 3:47 PM, "John Cowan" wrote: >>=20 >>> It's not clear that 404 disallows it, since 404 is defined in terms = of >>> characters, and a BOM is not a character but an out-of-band signal. >=20 > However, for example, a conforming implementation of the ECMAScript = JSON.parse function would reject any string passed to it that starts = with a U+FFEF code point because the unquoted occurrence of that code = point does not conform to the ECMA-252, 5th Edition or Ecma-404 JSON = grammar. >=20 > In order to be successfully processed, that code point would have to = be stripped from the string prior to calling JSON.parse. The question was specifically about ECMA-404, not ECMA-252. It would be = great to hear from TC39 whether or not ECMA-404 allows or disallows it. --Paul Hoffman= From duerst@it.aoyama.ac.jp Wed Nov 13 21:19:45 2013 Return-Path: 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 EAF2C21E81B1; Wed, 13 Nov 2013 21:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.649 X-Spam-Level: X-Spam-Status: No, score=-103.649 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 dG2UZOAotZXm; Wed, 13 Nov 2013 21:19:39 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4BB21E81B0; Wed, 13 Nov 2013 21:19:38 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAE5JHms021064; Thu, 14 Nov 2013 14:19:17 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 1aa6_71f5_4eda3790_4cec_11e3_a617_001e6722eec2; Thu, 14 Nov 2013 14:19:16 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 75CC8BFF5D; Thu, 14 Nov 2013 14:19:16 +0900 (JST) Message-ID: <52845D45.9020604@it.aoyama.ac.jp> Date: Thu, 14 Nov 2013 14:19:01 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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: Julian Reschke References: <5283E447.1070707@gmx.de> In-Reply-To: <5283E447.1070707@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Discussion , Paul Hoffman , JSON WG , Henri Sivonen , "Joe Hildebrand \(jhildebr\)" , Anne van Kesteren 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 05:19:46 -0000 On 2013/11/14 5:42, Julian Reschke wrote: > On 2013-11-13 21:38, Joe Hildebrand (jhildebr) wrote: >> On 11/12/13 8:28 AM, "Paul Hoffman" wrote: >> >>> [[ Adding the JSON WG to this thread ]] >>> >>> On Nov 11, 2013, at 10:58 PM, Anne van Kesteren >>> 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. > > +0.5 > >> What I think we *could* do is put a stronger recommendation for UTF-8 in >> section 8.1, rather than just saying it's the default. > > +10 What about something like: OLD JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. NEW JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. The vast majority of JSON text is encoded in UTF-8, and UTF-8 is the preferred encoding when creating JSON text. UTF-32 is not widely supported, and JSON texts encoded in UTF-32 are very difficult to find if they exist at all. Regards, Martin. From duerst@it.aoyama.ac.jp Thu Nov 14 03:15:05 2013 Return-Path: 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 5B52421E81B0; Thu, 14 Nov 2013 03:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.854 X-Spam-Level: X-Spam-Status: No, score=-101.854 tagged_above=-999 required=5 tests=[AWL=-2.064, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 mw7a4shTe7wB; Thu, 14 Nov 2013 03:14:59 -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 524D921E812F; Thu, 14 Nov 2013 03:14:56 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAEBEjA8022798; Thu, 14 Nov 2013 20:14:45 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 1aaa_3592_f7d2b4a4_4d1d_11e3_a724_001e6722eec2; Thu, 14 Nov 2013 20:14:45 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 0E700BFF5D; Thu, 14 Nov 2013 20:14:45 +0900 (JST) Message-ID: <5284B095.4070004@it.aoyama.ac.jp> Date: Thu, 14 Nov 2013 20:14:29 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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: "Henry S. Thompson" References: <20131113224737.GI31823@mercury.ccil.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: John Cowan , IETF Discussion , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 11:15:05 -0000 Hello Henry, others, On 2013/11/14 18:44, Henry S. Thompson wrote: > John Cowan writes: > >> Joe Hildebrand (jhildebr) scripsit: >> >>> If 404 doesn't allow [a BOM], I don't see a strong need to add it. >>> Parsers can always be more forgiving of what they will parse than what >>> the spec says, particularly since section 9 says "A JSON parser MAY >>> accept non-JSON forms or extensions". >> >> It's not clear that 404 disallows it, since 404 is defined in terms of >> characters, and a BOM is not a character but an out-of-band signal. > > I think this is a crucial observation. Yes, and I think it's based on the experience with XML. But while this experience may be applicable to JSON, Anne's original comment about the BOM and XMLHttpRequest suggests that 404 actually currently does not tolerate a BOM, and that implementations (except for XMLHttpRequest) also don't. To give some historic background, the BOM for UTF-8 wasn't in the first edition of XML (http://www.w3.org/TR/1998/REC-xml-19980210#sec-guessing). It only later came in because Microsoft used it for notepad to be able to quickly distinguish between UTF-8 and the legacy system encoding. Because many people were writing some XML by hand, and some of them were using notepad, the pressure on XML to accept a BOM at the start of an UTF-8 file mounted, and it was included in the second edition of the XML Recommendation (http://www.w3.org/TR/2000/REC-xml-20001006#sec-guessing). Compared to XML, JSON may be much less edited by hand, or much less edited on notepad, or otherwise just have a different history from XML, but we have to make sure. Regards, Martin. > I note that XML approaches > this problem in what might be a useful way. The XML ABNF makes no > mention of BOM, it's not part of any XML document as such. But it > _is_ allowed. The relevant wording [1] is: > > Entities ... may begin with the Byte Order Mark described by Annex H > of [ISO/IEC 10646:2000], section 16.8 of [Unicode] (the ZERO WIDTH > NO-BREAK SPACE character, #xFEFF). _This is an encoding signature,_ > _not part of either the markup or the character data of the XML_ > _document._ XML processors must be able to use this character to > differentiate between UTF-8 and UTF-16 encoded documents. [emphasis > added] > > ht > > [1] http://www.w3.org/TR/REC-xml/#charencoding From petejson@codalogic.com Thu Nov 14 04:04:27 2013 Return-Path: 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 98BFF21E8090 for ; Thu, 14 Nov 2013 04:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.486 X-Spam-Level: X-Spam-Status: No, score=0.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=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 dACha9VIijw3 for ; Thu, 14 Nov 2013 04:04:23 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id E761621E81B2 for ; Thu, 14 Nov 2013 04:04:22 -0800 (PST) Received: (qmail 27915 invoked from network); 14 Nov 2013 12:04:05 +0000 Received: from host81-129-187-193.range81-129.btcentralplus.com (HELO codalogic) (81.129.187.193) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 14 Nov 2013 12:04:05 +0000 Message-ID: <8413609C8A86497F856897AF2AA24960@codalogic> From: "Pete Cordell" To: "Paul Hoffman" , "Joe Hildebrand Hildebrand" References: X-Unsent: 1 Date: Thu, 14 Nov 2013 12:04:16 -0000 x-vipre-scanned: 00AC71FF005B3400AC734C MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: www-tag@w3.org, JSON WG Subject: [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 12:04:27 -0000 Original Message From: "Joe Hildebrand" > On 11/13/13 2:27 PM, "Paul Hoffman" wrote: > >> >> >>On Nov 13, 2013, at 12:24 PM, Joe Hildebrand (jhildebr) >> wrote: >> >>> We would also need to change section 8.1 according to the mechanism that >>> was previously proposed: >>> >>> 00 00 00 xx UTF-32BE >>> 00 xx ?? xx UTF-16BE >>> xx 00 00 00 UTF-32LE >>> xx 00 xx ?? UTF-16LE >>> xx xx ?? ?? UTF-8 >>> >>> >>> in order to account for strings at the top level whose first character >>>has >>> a codepoint greater than 127. >> >>A string at the top level of a JSON text still needs to start with an >>ASCII " character, so the logic is still fine, I believe. > > > Without top level strings, the first *two* characters of any JSON text are > always ASCII. This: > > > "?" (that's U+0022 U+0100 U+0022) > > ... > > So the JSON text above would not match any of the table entries, causing > an error. In http://www.ietf.org/mail-archive/web/json/current/msg00565.html I mentioned that we also need to allow for characters such as U+2c00 to be the first character in a quoted string. This requires a pattern like: xx 00 00 xx UTF-16LE giving: 00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE 00 xx xx xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 00 xx UTF-16LE xx 00 xx 00 UTF-16LE xx 00 xx xx UTF-16LE xx xx xx xx UTF-8 That can be reduced a bit if we use "--" to indicate "not-tested": 00 00 -- -- UTF-32BE 00 xx -- -- UTF-16BE xx 00 00 00 UTF-32LE xx 00 00 xx UTF-16LE xx 00 xx -- UTF-16LE xx xx -- -- UTF-8 Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From jhildebr@cisco.com Thu Nov 14 07:00:16 2013 Return-Path: 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 A1A6621E80E1 for ; Thu, 14 Nov 2013 07:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.442 X-Spam-Level: X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Lrwu9RiYhxE3 for ; Thu, 14 Nov 2013 06:59:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2059A11E80F2 for ; Thu, 14 Nov 2013 06:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=677; q=dns/txt; s=iport; t=1384441199; x=1385650799; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ErPHPmd0u7g6U2jLbtVAMTwcKqH5m0oza0wt+DdZERg=; b=WNJz49EOZdSNXqSSFcVrOAX2UON+ZwZa9zJwAOiEQZbv4x1e9mUIm55L yZnB5B/ns2mgGj2jhbNPPT3b1GgK66WGhgEMEs26EnPrp7IFAdvBmPNxv GLubboU37Zs29hNF3wMce39MzXOEsSBVOFu8XbvBMgVxjdC/v9dfdEc3Z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAFPkhFKtJV2c/2dsb2JhbABagwc4U78hgR8WdIIlAQEBAwE6PwUNAQg2QiUCBAENBQmHcgYNwBSOJoE5AgWEMQOYEJIMgWqBPoFxOQ X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="284584049" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 14 Nov 2013 14:59:58 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAEExwPQ004844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 14:59:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 08:59:58 -0600 From: "Joe Hildebrand (jhildebr)" To: Pete Cordell , Paul Hoffman Thread-Topic: Encoding detection (Was: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft) Thread-Index: AQHO4TGpZY8HSctvG0iE6+OoZ+IYqZokwTMA Date: Thu, 14 Nov 2013 14:59:57 +0000 Message-ID: In-Reply-To: <8413609C8A86497F856897AF2AA24960@codalogic> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.129.24.62] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "www-tag@w3.org" , JSON WG 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.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:00:16 -0000 On 11/14/13 5:04 AM, "Pete Cordell" wrote: > In http://www.ietf.org/mail-archive/web/json/current/msg00565.html I >mentioned that we also need to allow for characters such as U+2c00 to be >the=20 >first character in a quoted string. Ah, yes. Sorry, I quoted from the wrong part of the conversation. I completely agree. >That can be reduced a bit if we use "--" to indicate "not-tested": > > 00 00 -- -- UTF-32BE > 00 xx -- -- UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 00 xx UTF-16LE > xx 00 xx -- UTF-16LE > xx xx -- -- UTF-8 +1 to this table. It's clear, correct, and implementable. --=20 Joe Hildebrand From cowan@ccil.org Thu Nov 14 07:33:55 2013 Return-Path: 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 D57A111E80F2; Thu, 14 Nov 2013 07:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.014 X-Spam-Level: X-Spam-Status: No, score=-3.014 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 anNRR9LnGDMy; Thu, 14 Nov 2013 07:33:50 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id E7ABB11E8158; Thu, 14 Nov 2013 07:33:45 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VgyvN-0006Ug-52; Thu, 14 Nov 2013 10:33:41 -0500 Date: Thu, 14 Nov 2013 10:33:41 -0500 From: John Cowan To: Paul Hoffman Message-ID: <20131114153341.GA2165@mercury.ccil.org> References: <2E62DA50-F941-4A0E-A7B3-966A0DDE4C7A@wirfs-brock.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Allen Wirfs-Brock , IETF Discussion , JSON WG , Joe Hildebrand Hildebrand , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:33:56 -0000 Paul Hoffman scripsit: > The question was specifically about ECMA-404, not ECMA-252. It would be > great to hear from TC39 whether or not ECMA-404 allows or disallows it. The point of issuing standards is so that all may use them, so there is no need to ask anyone. A quick examination of ECMA-404 makes it clear that there are no references to BOMs, whether under that name, or "byte order mark", or "U+FEFF". But that is not determinative for our purposes, because of this statement from the Unicode Standard (I cite section 16.8 of Unicode 6.2, but substantially equivalent statements can be found back to Unicode 3.2): Systems that use the byte order mark must recognize when an initial U+FEFF signals the byte order. In those cases, it is not part of the textual content and should be removed before processing, because otherwise it may be mistaken for a legitimate zero width no-break space. Per contra, ECMA-404 refers only to text(ual content). The BOM is meaningful when transforming byte sequences into code point sequences, but ECMA-404 deals in the latter only. So it is the furthest thing from surprising that it makes no mention of BOMs, and has nothing to say about their use outside text. -- Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, "The Nine Billion Names of God" John Cowan From ht@inf.ed.ac.uk Thu Nov 14 01:44:44 2013 Return-Path: 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 2401421E81DB; Thu, 14 Nov 2013 01:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.004 X-Spam-Level: X-Spam-Status: No, score=-7.004 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Yi19c38zd6zH; Thu, 14 Nov 2013 01:44:39 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id D895521E8174; Thu, 14 Nov 2013 01:44:38 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAE9i3tL009868; Thu, 14 Nov 2013 09:44:03 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAE9i1td016584; Thu, 14 Nov 2013 09:44:01 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAE9i2FI031737; Thu, 14 Nov 2013 09:44:02 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAE9i0V8031733; Thu, 14 Nov 2013 09:44:00 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John Cowan References: <20131113224737.GI31823@mercury.ccil.org> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 14 Nov 2013 09:44:00 +0000 In-Reply-To: <20131113224737.GI31823@mercury.ccil.org> (John Cowan's message of "Wed\, 13 Nov 2013 17\:47\:38 -0500") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 X-Mailman-Approved-At: Thu, 14 Nov 2013 07:37:06 -0800 Cc: IETF Discussion , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 09:44:44 -0000 John Cowan writes: > Joe Hildebrand (jhildebr) scripsit: > >> If 404 doesn't allow [a BOM], I don't see a strong need to add it. >> Parsers can always be more forgiving of what they will parse than what >> the spec says, particularly since section 9 says "A JSON parser MAY >> accept non-JSON forms or extensions". > > It's not clear that 404 disallows it, since 404 is defined in terms of > characters, and a BOM is not a character but an out-of-band signal. I think this is a crucial observation. I note that XML approaches this problem in what might be a useful way. The XML ABNF makes no mention of BOM, it's not part of any XML document as such. But it _is_ allowed. The relevant wording [1] is: Entities ... may begin with the Byte Order Mark described by Annex H of [ISO/IEC 10646:2000], section 16.8 of [Unicode] (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF). _This is an encoding signature,_ _not part of either the markup or the character data of the XML_ _document._ XML processors must be able to use this character to differentiate between UTF-8 and UTF-16 encoded documents. [emphasis added] ht [1] http://www.w3.org/TR/REC-xml/#charencoding -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From allen@wirfs-brock.com Thu Nov 14 07:48:50 2013 Return-Path: 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 6979721F99DC; Thu, 14 Nov 2013 07:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599] 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 TuSYzKxRebu7; Thu, 14 Nov 2013 07:48:44 -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 01E9811E814F; Thu, 14 Nov 2013 07:48:39 -0800 (PST) Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.22]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Vgz9p-000Lci-Ln; Thu, 14 Nov 2013 15:48:37 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.64.236.244 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/Wen/t904BO/53pbD4DpA2mJ6XT0/wYy8= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Allen Wirfs-Brock In-Reply-To: Date: Thu, 14 Nov 2013 07:48:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <82A4E5F4-FF2F-491F-A5BA-96F7CE04D78E@wirfs-brock.com> References: <2E62DA50-F941-4A0E-A7B3-966A0DDE4C7A@wirfs-brock.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1085) Cc: John Cowan , IETF Discussion , JSON WG , Joe Hildebrand Hildebrand , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:48:50 -0000 On Nov 13, 2013, at 7:15 PM, Paul Hoffman wrote: >>=20 >=20 > The question was specifically about ECMA-404, not ECMA-252. It would = be great to hear from TC39 whether or not ECMA-404 allows or disallows = it. ECMA=3Dnnn is the correct designation for Ecma standards. When speaking = about the organization "Ecma" is the usage. Allen From allen@wirfs-brock.com Thu Nov 14 07:55:07 2013 Return-Path: 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 495B621F9B8A; Thu, 14 Nov 2013 07:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] 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 1vRq20Dm0nHG; Thu, 14 Nov 2013 07: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 77F1021F9AE3; Thu, 14 Nov 2013 07:55:01 -0800 (PST) Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.22]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1VgzG0-0001a2-7X; Thu, 14 Nov 2013 15:55:00 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.64.236.244 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18V1XFciZ9rcYm1/PY/XoMWUdAzfx3T6zU= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Allen Wirfs-Brock In-Reply-To: <20131114153341.GA2165@mercury.ccil.org> Date: Thu, 14 Nov 2013 07:54:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6F96C5C0-0531-4C96-8126-EEBB9EE928C0@wirfs-brock.com> References: <2E62DA50-F941-4A0E-A7B3-966A0DDE4C7A@wirfs-brock.com> <20131114153341.GA2165@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1085) Cc: IETF Discussion , Paul Hoffman , JSON WG , Joe Hildebrand Hildebrand , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:55:07 -0000 On Nov 14, 2013, at 7:33 AM, John Cowan wrote: >=20 > Per contra, ECMA-404 refers only to text(ual content). The BOM is > meaningful when transforming byte sequences into code point sequences, > but ECMA-404 deals in the latter only. So it is the furthest thing > from surprising that it makes no mention of BOMs, and has nothing to > say about their use outside text. Exactly ECMA-404 only defines a textual content format. That was = intentional. Allen From ht@inf.ed.ac.uk Thu Nov 14 09:17:50 2013 Return-Path: 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 5D85121E8098 for ; Thu, 14 Nov 2013 09:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.986 X-Spam-Level: X-Spam-Status: No, score=-6.986 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 P8pZpvuwZXGS for ; Thu, 14 Nov 2013 09:17:46 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3F73C21E8056 for ; Thu, 14 Nov 2013 09:17:42 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAEHHPLx000570; Thu, 14 Nov 2013 17:17:25 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAEHHNJc016176; Thu, 14 Nov 2013 17:17:23 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAEHHOLk011035; Thu, 14 Nov 2013 17:17:24 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAEHHNbu011031; Thu, 14 Nov 2013 17:17:23 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "Joe Hildebrand \(jhildebr\)" References: From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 14 Nov 2013 17:17:23 +0000 In-Reply-To: (Joe Hildebrand's message of "Thu\, 14 Nov 2013 14\:59\:57 +0000") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: "www-tag@w3.org" , Paul Hoffman , Pete Cordell , JSON WG Subject: Re: [Json] Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:17:50 -0000 Joe Hildebrand (jhildebr) writes: > On 11/14/13 5:04 AM, "Pete Cordell" wrote: > >> In http://www.ietf.org/mail-archive/web/json/current/msg00565.html I >>mentioned that we also need to allow for characters such as U+2c00 to be >>the=20 >>first character in a quoted string. > > Ah, yes. Sorry, I quoted from the wrong part of the conversation. I > completely agree. > >>That can be reduced a bit if we use "--" to indicate "not-tested": >> >> 00 00 -- -- UTF-32BE >> 00 xx -- -- UTF-16BE >> xx 00 00 00 UTF-32LE >> xx 00 00 xx UTF-16LE >> xx 00 xx -- UTF-16LE >> xx xx -- -- UTF-8 > > +1 to this table. It's clear, correct, and implementable. Doesn't work if you want to allow a pre-document BOM. But I think the following enlarged grid does work, where "--" now means "not any value(s) explicitly tested for with an 'earlier' shared prefix": 00 00 FE FF UTF-32 (BE) w. BOM [00 00 FF FE UCS-4 w. BOM, unusual octet order (2143)] 00 00 -- -- UTF-32BE 00 xx -- -- UTF-16BE FF FE 00 00 UTF-32 (LE) w. BOM [FE FF 00 00 UCS-4 w. BOM, unusual octet order (3412)] FE FF -- -- UTF-16 (BE) w. BOM FF FE -- -- UTF-16 (LE) w. BOM xx 00 00 00 UTF-32LE xx 00 00 xx UTF-16LE [Note that the following algorithm disagrees here] xx 00 xx -- UTF-16LE EF BB BF -- UTF-8 w. BOM xx xx -- -- UTF-8 A possibly simpler algorithm, which has the same outcome I think, minus the unusual octet cases and the exception noted above, is used by the Python requests package [1] for JSON charset detection. Schematically, this works as follows: FF FE 00 00 UTF-32 (LE) w. BOM 00 00 FE FF UTF-32 (BE) w. BOM EF BB BF UTF-8 w. BOM FE FF UTF-16 (BE) w. BOM FF FE UTF-16 (LE) w. BOM Now count 00 bytes in first 4: 0 UTF-8 2 00 -- 00 -- UTF-16 (BE) -- 00 -- 00 UTF-16 (LE) 3 00 00 00 -- UTF-32 (BE) -- 00 00 00 UTF-32 (LE) error I _think_ requests is only correct because it assumes "JSON always starts with two ASCII characters", depending on 4627, i.e. continuing to rule out e.g. "=D0=80=D0=BA=D0=B7=D0=B5=D0=BC=D0=BF=D0=B8=D1=8F=D1=80" To accommodate this case, we would need to add 1 -- 00 -- -- UTF-16 (LE) 2 -- 00 00 -- UTF-16 (LE) to the requests algorithm. (There are, it has to be said, few Unicode characters whose UTF-16-L form is 00xx, i.e. U+xx00, the first code point on a code page -- I had to hunt pretty hard to find the above specimen, which is in fact a slight cheat :-) Many code pages have a gap at the 00 point. Not sure about the status of U+4E00, one variant of the ideograph for the numeral 1). ht [1] http://docs.python-requests.org/en/latest/ --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this mail without it is forged s= pam] From cowan@ccil.org Thu Nov 14 10:30:13 2013 Return-Path: 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 163E411E816B for ; Thu, 14 Nov 2013 10:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 uYMWxuYHOgvk for ; Thu, 14 Nov 2013 10:30:08 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 42FDC11E8143 for ; Thu, 14 Nov 2013 10:30:08 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Vh1fs-0007Z3-TB; Thu, 14 Nov 2013 13:29:52 -0500 Date: Thu, 14 Nov 2013 13:29:52 -0500 From: John Cowan To: "Henry S. Thompson" Message-ID: <20131114182952.GF2165@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Pete Cordell , JSON WG , "www-tag@w3.org" , "Joe Hildebrand \(jhildebr\)" , Paul Hoffman Subject: Re: [Json] Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 18:30:13 -0000 Henry S. Thompson scripsit: > (There are, it has to be said, few Unicode characters whose UTF-16-L > form is 00xx, i.e. U+xx00, the first code point on a code page -- > I had to hunt pretty hard to find the above specimen, which is in > fact a slight cheat :-) Many code pages have a gap at the 00 point. There are 68 of them on the Basic Multilingual Plane. But many characters in other planes involve such 16-bit code units. For example, all of U+10000 to U+103FF are encoded as D800 DC00 through D800 DFFF. Currently there are 622 characters in this range alone, and the number will probably grow. > Not sure about the status of U+4E00, one variant of the ideograph for > the numeral 1). Google reports over 3 gigahits for this character. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --The Hobbit From hallam@gmail.com Thu Nov 14 10:48:34 2013 Return-Path: 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 A8B7021F9FB4; Thu, 14 Nov 2013 10:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 9PHwbDpVMSqm; Thu, 14 Nov 2013 10:48:11 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF1221F9EDA; Thu, 14 Nov 2013 10:48:00 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id eh20so1951681lab.18 for ; Thu, 14 Nov 2013 10:47:59 -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=knME0OmxYO6cfCDRIX/VX+r3AGItsM+eiDfHKkgeouk=; b=SnxzQeclGVqLHpJdwq11FSUA8e9WStmWxk/pzGlFgSIR1wKw6orfEppubFhHDZYslj bs+Pkug7WEX1gUmaowXGrTru1tqhdO6RynHJVMV0Hv3+X01ksIjeWduHfaUyfrwOkftX Qyo7gK9MTaTeYL1slPIbXNeMmf9g70jNjMVjQhzmHWCKhAQBLfxvO1pkfFdNAO8/+54i 8SFoSIbJFWtgD5XFnp3f7DMmDclvRuLn2QdQ+nTr9y8DxwdkZ9Bkkz/nqEWAFNS5gThc UTAAzTsxq1xvecf05W78OLryVSgRywwGu090WZNywOR240bzotkqT/Vu6LSEQJKMf//0 NvSA== MIME-Version: 1.0 X-Received: by 10.152.120.7 with SMTP id ky7mr561770lab.83.1384454879393; Thu, 14 Nov 2013 10:47:59 -0800 (PST) Received: by 10.112.46.98 with HTTP; Thu, 14 Nov 2013 10:47:59 -0800 (PST) In-Reply-To: <20131113224832.GJ31823@mercury.ccil.org> References: <99EE3A2D-D1CF-44EF-BA61-156ED8E72F79@vpnc.org> <20131113224832.GJ31823@mercury.ccil.org> Date: Thu, 14 Nov 2013 13:47:59 -0500 Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: multipart/alternative; boundary=089e0117690d4b3f7d04eb27859f X-Mailman-Approved-At: Thu, 14 Nov 2013 10:57:00 -0800 Cc: IETF Discussion , Paul Hoffman , JSON WG , Henri Sivonen , "Joe Hildebrand \(jhildebr\)" , Anne van Kesteren 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 18:48:35 -0000 --089e0117690d4b3f7d04eb27859f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 13, 2013 at 5:48 PM, John Cowan wrote: > Joe Hildebrand (jhildebr) scripsit: > > > 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. > > Well, no, they would just be non-portable but legitimate extensions. > I like that approach a lot. >From an interop point of view it is FAR more likely that a reader supports BSON than JSON-UTF32 and that is hardly likely to change. Standards are read by people who implement encoders and decoders. What I would like the spec to tell writers of encoders is that they MUST NOT use UTF-32 encoding and call the result JSON. This is so that the spec can then tell decoders that they have absolutely no need to support UTF-32 to comply with the JSON spec. Standards is about making choices that don't matter to the semantics or performance of an operation. Taking an unnecessary option out is an important and useful improvement. This is incidentally why I was so peeved by the CBOR fiasco. First I am told that my requirements don't matter, then the authors are throwing in unnecessary complexity like definite length encodings because they can. Any time a specification changes it is likely to cause some existing code to stop being compliant. That is quite OK. The whole point of going through this process was to reduce the probability that differences in implementations would break interoperability. UTF-32 is a difference in interoperability that adds no expressive value, adds a great deal of complexity and damages performance. It has negligible deployed base. So kill it. -- Website: http://hallambaker.com/ --089e0117690d4b3f7d04eb27859f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Nov 13, 2013 at 5:48 PM, John Cowan <<= a href=3D"mailto:cowan@mercury.ccil.org" target=3D"_blank">cowan@mercury.cc= il.org> wrote:
Joe Hildebrand (jhildebr) scripsit:

> Although I hate UTF-32 with the heat of a several moderately-sized sta= rs
> and completely agree that UTF-8 is the one true path, I don't thin= k we can
> completely remove UTF-32 from the bis draft. =A0There may be existing<= br> > conformant JSON documents stored in UTF-32 that would be made unparsea= ble
> by this change.

Well, no, they would just be non-portable but legitimate extensions.<= br>

I like that approach a lot.
<= br>
From an interop point of view it is FAR more likely that a re= ader supports BSON than JSON-UTF32 and that is hardly likely to change.

Standards are read by people who implement encoders and= decoders. What I would like the spec to tell writers of encoders is that t= hey MUST NOT use UTF-32 encoding and call the result JSON. This is so that = the spec can then tell decoders that they have absolutely no need to suppor= t UTF-32 to comply with the JSON spec.

Standards is about making choices that don't matter= to the semantics or performance of an operation. Taking an unnecessary opt= ion out is an important and useful improvement.


This is incidentally why I was so peeved by the CBOR fiasco.= First I am told that my requirements don't matter, then the authors ar= e throwing in unnecessary complexity like definite length encodings because= they can.

Any time a specification changes it is likely to cause = some existing code to stop being compliant. That is quite OK. The whole poi= nt of going through this process was to reduce the probability that differe= nces in implementations would break interoperability.=A0

UTF-32 is a difference in interoperability that adds no= expressive value, adds a great deal of complexity and damages performance.= It has negligible deployed base.=A0

So kill it.
=A0

--
Website: http://hallambaker.com/
--089e0117690d4b3f7d04eb27859f-- From david@dbooth.org Thu Nov 14 12:24:35 2013 Return-Path: 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 C6EBD21E8117 for ; Thu, 14 Nov 2013 12:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 eHKDIpo3onjE for ; Thu, 14 Nov 2013 12:24:30 -0800 (PST) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by ietfa.amsl.com (Postfix) with SMTP id BA06F11E80FA for ; Thu, 14 Nov 2013 12:24:29 -0800 (PST) Received: (qmail 84658 invoked by uid 0); 14 Nov 2013 20:24:28 -0000 Received: from 209.6.49.245 (HELO ?192.168.10.2?) (209.6.49.245) by relay02.pair.com with SMTP; 14 Nov 2013 20:24:28 -0000 X-pair-Authenticated: 209.197.49.245 Message-ID: <5285317A.1020400@dbooth.org> Date: Thu, 14 Nov 2013 15:24:26 -0500 From: David Booth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: John Cowan , "Henry S. Thompson" References: <20131114182952.GF2165@mercury.ccil.org> In-Reply-To: <20131114182952.GF2165@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 14 Nov 2013 12:56:59 -0800 Cc: Pete Cordell , JSON WG , "www-tag@w3.org" , "Joe Hildebrand \(jhildebr\)" , Paul Hoffman Subject: Re: [Json] Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 20:24:35 -0000 On 11/14/2013 01:29 PM, John Cowan wrote: > Henry S. Thompson scripsit: [ . . . ] >> Not sure about the status of U+4E00, one variant of the ideograph for >> the numeral 1). > > Google reports over 3 gigahits for this character. Curious: How did you do that query? David From cowan@ccil.org Thu Nov 14 14:44:13 2013 Return-Path: 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 5978011E811B for ; Thu, 14 Nov 2013 14:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.281 X-Spam-Level: X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] 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 WzKyxN1eogVu for ; Thu, 14 Nov 2013 14:44:09 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6E33C11E8122 for ; Thu, 14 Nov 2013 14:44:08 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Vh5dj-0008J7-5B; Thu, 14 Nov 2013 17:43:55 -0500 Date: Thu, 14 Nov 2013 17:43:55 -0500 From: John Cowan To: David Booth Message-ID: <20131114224355.GH2165@mercury.ccil.org> References: <20131114182952.GF2165@mercury.ccil.org> <5285317A.1020400@dbooth.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5285317A.1020400@dbooth.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "Henry S. Thompson" , Pete Cordell , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , "www-tag@w3.org" Subject: Re: [Json] Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 22:44:13 -0000 David Booth scripsit: > >Google reports over 3 gigahits for this character. > > Curious: How did you do that query? Using , I put 4E00 into the "Character numbers" box, and pasted the entry in the "Characters" box into a Google window. I could equally well have typed 4300 Alt+X into Microsoft Word, or used . -- On the Semantic Web, it's too hard to prove John Cowan cowan@ccil.org you're not a dog. --Bill de hOra http://www.ccil.org/~cowan From duerst@it.aoyama.ac.jp Thu Nov 14 23:11:19 2013 Return-Path: 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 907F121F9A97 for ; Thu, 14 Nov 2013 23:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.044 X-Spam-Level: X-Spam-Status: No, score=-105.044 tagged_above=-999 required=5 tests=[AWL=-5.255, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 8vsOePD+Xgi0 for ; Thu, 14 Nov 2013 23:11: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 E69CD21F9A59 for ; Thu, 14 Nov 2013 23:11:09 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAF7Asmw032367; Fri, 15 Nov 2013 16:10:54 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 5564_ecff_1121e9e6_4dc5_11e3_bb14_001e6722eec2; Fri, 15 Nov 2013 16:10:54 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 9D502BF4E3; Fri, 15 Nov 2013 16:10:53 +0900 (JST) Message-ID: <5285C8ED.1040701@it.aoyama.ac.jp> Date: Fri, 15 Nov 2013 16:10:37 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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: John Cowan References: <20131114182952.GF2165@mercury.ccil.org> In-Reply-To: <20131114182952.GF2165@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Henry S. Thompson" , Pete Cordell , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , "www-tag@w3.org" Subject: Re: [Json] Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 07:11:19 -0000 On 2013/11/15 3:29, John Cowan wrote: > Henry S. Thompson scripsit: >> Not sure about the status of U+4E00, one variant of the ideograph for >> the numeral 1). > > Google reports over 3 gigahits for this character. Yes indeed. U+4E00 is not just one variant of the ideograph for the numeral 1, except for special occasions such as bank checks, it's the only ideograph used for the numeral 1, as well as the word 'one', and one of the most used ideographs overall. Regards, Martin. From ht@inf.ed.ac.uk Fri Nov 15 00:45:31 2013 Return-Path: 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 CE0E711E8101 for ; Fri, 15 Nov 2013 00:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Nxbary+S9wiF for ; Fri, 15 Nov 2013 00:45:25 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2382211E80F6 for ; Fri, 15 Nov 2013 00:45:21 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAF8j2RQ013803; Fri, 15 Nov 2013 08:45:02 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAF8j0TY017854; Fri, 15 Nov 2013 08:45:00 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAF8j1eI027326; Fri, 15 Nov 2013 08:45:01 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAF8j0tf027322; Fri, 15 Nov 2013 08:45:00 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: John Cowan References: <20131114182952.GF2165@mercury.ccil.org> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 15 Nov 2013 08:45:00 +0000 In-Reply-To: <20131114182952.GF2165@mercury.ccil.org> (John Cowan's message of "Thu\, 14 Nov 2013 13\:29\:52 -0500") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: Pete Cordell , JSON WG , "www-tag@w3.org" , "Joe Hildebrand \(jhildebr\)" , Paul Hoffman Subject: Re: [Json] Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 08:45:31 -0000 John Cowan writes: > There are 68 of them on the Basic Multilingual Plane. But many > characters in other planes involve such 16-bit code units. For example, > all of U+10000 to U+103FF are encoded as D800 DC00 through D800 DFFF. > Currently there are 622 characters in this range alone, and the number > will probably grow. > >> Not sure about the status of U+4E00, one variant of the ideograph for >> the numeral 1). > > Google reports over 3 gigahits for this character. Thanks for the facts, much better than my suppositions. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From petejson@codalogic.com Sun Nov 17 02:04:30 2013 Return-Path: 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 129AC11E8A2C for ; Sun, 17 Nov 2013 02:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.086 X-Spam-Level: *** X-Spam-Status: No, score=3.086 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=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 uHEe7yzHmQti for ; Sun, 17 Nov 2013 02:04:26 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 9704C11E8A08 for ; Sun, 17 Nov 2013 02:04:25 -0800 (PST) Received: (qmail 11232 invoked from network); 17 Nov 2013 10:04:05 +0000 Received: from host81-129-187-193.range81-129.btcentralplus.com (HELO codalogic) (81.129.187.193) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 17 Nov 2013 10:04:05 +0000 Message-ID: <75E35201E30C4EA4B143B520CB6DF273@codalogic> From: "Pete Cordell" To: "Joe Hildebrand \(jhildebr\)" , "Henry S. Thompson" References: Date: Sun, 17 Nov 2013 10:02:34 -0000 X-Unsent: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original x-vipre-scanned: 006BB0D9005B94006BB226 Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: www-tag@w3.org, JSON WG Subject: Re: [Json] Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 10:04:30 -0000 There's some debate about whether BOMs are allowed (at least officially. I think I would accommodate them if I were to implement a JSON parser.) If I did handle BOMs I think I would adopt the "if it starts with a BOM..." approach similar to the Python method, and only resort to deduction based on assumption about ASCII characters if no BOM was found. (I think BOM presence can be surmised by only looking at the first byte. If it's greater than 0x80 - specifically if it's 0xef, 0xfe, 0xff - then it's an error if you don't go on to find a BOM.) While I'm here, Joe mentioned "implementable". From an implementer's perspective the table I presented earlier might be better presented in the following order: 00 00 -- -- UTF-32BE 00 xx -- -- UTF-16BE xx xx -- -- UTF-8 xx 00 xx -- UTF-16LE xx 00 00 xx UTF-16LE xx 00 00 00 UTF-32LE Or is that taking the fun out of it for the implementer?! Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com ----- Original Message ----- From: "Henry S. Thompson" To: "Joe Hildebrand (jhildebr)" Cc: "Pete Cordell" ; "Paul Hoffman" ; ; "JSON WG" Sent: Thursday, November 14, 2013 5:17 PM Subject: Re: Encoding detection Joe Hildebrand (jhildebr) writes: > On 11/14/13 5:04 AM, "Pete Cordell" wrote: > >> In http://www.ietf.org/mail-archive/web/json/current/msg00565.html I >>mentioned that we also need to allow for characters such as U+2c00 to be >>the >>first character in a quoted string. > > Ah, yes. Sorry, I quoted from the wrong part of the conversation. I > completely agree. > >>That can be reduced a bit if we use "--" to indicate "not-tested": >> >> 00 00 -- -- UTF-32BE >> 00 xx -- -- UTF-16BE >> xx 00 00 00 UTF-32LE >> xx 00 00 xx UTF-16LE >> xx 00 xx -- UTF-16LE >> xx xx -- -- UTF-8 > > +1 to this table. It's clear, correct, and implementable. Doesn't work if you want to allow a pre-document BOM. But I think the following enlarged grid does work, where "--" now means "not any value(s) explicitly tested for with an 'earlier' shared prefix": 00 00 FE FF UTF-32 (BE) w. BOM [00 00 FF FE UCS-4 w. BOM, unusual octet order (2143)] 00 00 -- -- UTF-32BE 00 xx -- -- UTF-16BE FF FE 00 00 UTF-32 (LE) w. BOM [FE FF 00 00 UCS-4 w. BOM, unusual octet order (3412)] FE FF -- -- UTF-16 (BE) w. BOM FF FE -- -- UTF-16 (LE) w. BOM xx 00 00 00 UTF-32LE xx 00 00 xx UTF-16LE [Note that the following algorithm disagrees here] xx 00 xx -- UTF-16LE EF BB BF -- UTF-8 w. BOM xx xx -- -- UTF-8 A possibly simpler algorithm, which has the same outcome I think, minus the unusual octet cases and the exception noted above, is used by the Python requests package [1] for JSON charset detection. Schematically, this works as follows: FF FE 00 00 UTF-32 (LE) w. BOM 00 00 FE FF UTF-32 (BE) w. BOM EF BB BF UTF-8 w. BOM FE FF UTF-16 (BE) w. BOM FF FE UTF-16 (LE) w. BOM Now count 00 bytes in first 4: 0 UTF-8 2 00 -- 00 -- UTF-16 (BE) -- 00 -- 00 UTF-16 (LE) 3 00 00 00 -- UTF-32 (BE) -- 00 00 00 UTF-32 (LE) error I _think_ requests is only correct because it assumes "JSON always starts with two ASCII characters", depending on 4627, i.e. continuing to rule out e.g. "Ѐкземпияр" To accommodate this case, we would need to add 1 -- 00 -- -- UTF-16 (LE) 2 -- 00 00 -- UTF-16 (LE) to the requests algorithm. (There are, it has to be said, few Unicode characters whose UTF-16-L form is 00xx, i.e. U+xx00, the first code point on a code page -- I had to hunt pretty hard to find the above specimen, which is in fact a slight cheat :-) Many code pages have a gap at the 00 point. Not sure about the status of U+4E00, one variant of the ideograph for the numeral 1). ht [1] http://docs.python-requests.org/en/latest/ -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this mail without it is forged spam] From paul.hoffman@vpnc.org Sun Nov 17 08:36:30 2013 Return-Path: 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 AD94411E8E73 for ; Sun, 17 Nov 2013 08:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 RLWZPaYeXOmk for ; Sun, 17 Nov 2013 08:36:13 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1CD11E8DD0 for ; Sun, 17 Nov 2013 08:34:30 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rAHGYNhZ071479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Nov 2013 09:34:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman X-Priority: 3 In-Reply-To: <75E35201E30C4EA4B143B520CB6DF273@codalogic> Date: Sun, 17 Nov 2013 08:34:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <13A5A836-A670-4412-82F8-B7BBE84A2FC8@vpnc.org> References: <75E35201E30C4EA4B143B520CB6DF273@codalogic> To: Pete Cordell X-Mailer: Apple Mail (2.1822) Cc: JSON WG Subject: Re: [Json] Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 16:36:32 -0000 On Nov 17, 2013, at 2:02 AM, Pete Cordell = wrote: > While I'm here, Joe mentioned "implementable". =46rom an = implementer's > perspective the table I presented earlier might be better presented in = the > following order: >=20 > 00 00 -- -- UTF-32BE > 00 xx -- -- UTF-16BE > xx xx -- -- UTF-8 > xx 00 xx -- UTF-16LE > xx 00 00 xx UTF-16LE > xx 00 00 00 UTF-32LE >=20 > Or is that taking the fun out of it for the implementer?! I'm not sure that is the right order. Wouldn't that make UTF-16LE be = mistaken for UTF-8? It seems to me that the UTF-8 rule has to be last = because it is more general than any of the ones above it. --Paul Hoffman= From derhoermi@gmx.net Sun Nov 17 12:01:50 2013 Return-Path: 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 6E2D511E91C5 for ; Sun, 17 Nov 2013 12:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] 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 icqpMjNMXFxV for ; Sun, 17 Nov 2013 12:01:32 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6DA11E921A for ; Sun, 17 Nov 2013 12:00:52 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.23.147]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0Ldttv-1VI7Uo3zz1-00j2Zc for ; Sun, 17 Nov 2013 21:00:51 +0100 From: Bjoern Hoehrmann To: Paul Hoffman Date: Sun, 17 Nov 2013 21:00:48 +0100 Message-ID: <3r7i899fler32pdhu1p2nhof0ohl9g8ufp@hive.bjoern.hoehrmann.de> References: <75E35201E30C4EA4B143B520CB6DF273@codalogic> <13A5A836-A670-4412-82F8-B7BBE84A2FC8@vpnc.org> In-Reply-To: <13A5A836-A670-4412-82F8-B7BBE84A2FC8@vpnc.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:CDgxxPZcrb8spSwY/zAxKV4mwmAUADt1BIkaFYBI1D5oCamRO6u U3z/fRW+30a+NiOsPTw723QGcww46AkduFbwTSwGy3VSK0bKleSKlvlFpmLuOS+xGMH/pVU xgRzmvVRWMt6jWc7i7ABa9HE+/6c7rQJrMTs1qmg2Vz6cB57czqJ6w+wQazhjcOpXPohzOR ZZl1HfnaELWvOE0krB7iA== Cc: Pete Cordell , JSON WG Subject: Re: [Json] Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 20:01:51 -0000 * Paul Hoffman wrote: >On Nov 17, 2013, at 2:02 AM, Pete Cordell wrote: > >> While I'm here, Joe mentioned "implementable". From an implementer's >> perspective the table I presented earlier might be better presented in the >> following order: >> >> 00 00 -- -- UTF-32BE >> 00 xx -- -- UTF-16BE >> xx xx -- -- UTF-8 >> xx 00 xx -- UTF-16LE >> xx 00 00 xx UTF-16LE >> xx 00 00 00 UTF-32LE >> >> Or is that taking the fun out of it for the implementer?! > >I'm not sure that is the right order. Wouldn't that make UTF-16LE be >mistaken for UTF-8? It seems to me that the UTF-8 rule has to be last >because it is more general than any of the ones above it. No, `xx` stands for a non-zero byte. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From paul.hoffman@vpnc.org Sun Nov 17 12:19:41 2013 Return-Path: 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 D59F711E81C5 for ; Sun, 17 Nov 2013 12:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 17b3fwXcbkww for ; Sun, 17 Nov 2013 12:19:41 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 53FAD11E81B8 for ; Sun, 17 Nov 2013 12:19:41 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rAHKJVO2076801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Nov 2013 13:19:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <3r7i899fler32pdhu1p2nhof0ohl9g8ufp@hive.bjoern.hoehrmann.de> Date: Sun, 17 Nov 2013 12:19:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4364D345-53AD-457A-8ABC-2A559A2655B7@vpnc.org> References: <75E35201E30C4EA4B143B520CB6DF273@codalogic> <13A5A836-A670-4412-82F8-B7BBE84A2FC8@vpnc.org> <3r7i899fler32pdhu1p2nhof0ohl9g8ufp@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1822) Cc: Pete Cordell , JSON WG Subject: Re: [Json] Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 20:19:41 -0000 On Nov 17, 2013, at 12:00 PM, Bjoern Hoehrmann = wrote: > * Paul Hoffman wrote: >> On Nov 17, 2013, at 2:02 AM, Pete Cordell = wrote: >>=20 >>> While I'm here, Joe mentioned "implementable". =46rom an = implementer's >>> perspective the table I presented earlier might be better presented = in the >>> following order: >>>=20 >>> 00 00 -- -- UTF-32BE >>> 00 xx -- -- UTF-16BE >>> xx xx -- -- UTF-8 >>> xx 00 xx -- UTF-16LE >>> xx 00 00 xx UTF-16LE >>> xx 00 00 00 UTF-32LE >>>=20 >>> Or is that taking the fun out of it for the implementer?! >>=20 >> I'm not sure that is the right order. Wouldn't that make UTF-16LE be=20= >> mistaken for UTF-8? It seems to me that the UTF-8 rule has to be last=20= >> because it is more general than any of the ones above it. >=20 > No, `xx` stands for a non-zero byte. Sorry, I thought "xx" meant "unknown". Then I think Pete's formulation = is correct. --Paul Hoffman From petejson@codalogic.com Mon Nov 18 02:05:54 2013 Return-Path: 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 B5E7011E80F6 for ; Mon, 18 Nov 2013 02:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.236 X-Spam-Level: *** X-Spam-Status: No, score=3.236 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=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 Kjp6Uz6McNwQ for ; Mon, 18 Nov 2013 02:05:53 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 9462411E8132 for ; Mon, 18 Nov 2013 02:05:48 -0800 (PST) Received: (qmail 22840 invoked from network); 18 Nov 2013 10:05:30 +0000 Received: from host81-129-187-193.range81-129.btcentralplus.com (HELO codalogic) (81.129.187.193) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 18 Nov 2013 10:05:30 +0000 Message-ID: From: "Pete Cordell" To: =?iso-8859-1?Q?=22Martin_J._D=FCrst=22?= , "Henry S. Thompson" References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> X-Unsent: 1 Date: Mon, 18 Nov 2013 10:05:07 -0000 MIME-Version: 1.0 x-vipre-scanned: 002D168A005BB6002D17D7 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: John Cowan , IETF Discussion , JSON WG , Anne van Kesteren , www-tag@w3.org, es-discuss Subject: [Json] BOMs (Was: Re: JSON: remove gap between Ecma-404 and IETF draft) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 10:05:54 -0000 Given the history below, would it be sensible to accept BOMs for UTF-8 encoding, but not for UTF-16 and UTF-32? In other words, are BOMs needed and/or used in the wild for UTF-16 and UTF-32? Maybe the text can say something like "SHOULD accept BOMs for UTF-8, and MAY accept BOMs for UTF-16 and / or UTF-32"? Thanks, Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com ----- Original Message ----- From: ""Martin J. Dürst"" To: "Henry S. Thompson" Cc: "John Cowan" ; "IETF Discussion" ; "Paul Hoffman" ; "JSON WG" ; "Joe Hildebrand (jhildebr)" ; "Anne van Kesteren" ; ; "es-discuss" Sent: Thursday, November 14, 2013 11:14 AM Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft > Hello Henry, others, > > On 2013/11/14 18:44, Henry S. Thompson wrote: >> John Cowan writes: >> >>> Joe Hildebrand (jhildebr) scripsit: >>> >>>> If 404 doesn't allow [a BOM], I don't see a strong need to add it. >>>> Parsers can always be more forgiving of what they will parse than what >>>> the spec says, particularly since section 9 says "A JSON parser MAY >>>> accept non-JSON forms or extensions". >>> >>> It's not clear that 404 disallows it, since 404 is defined in terms of >>> characters, and a BOM is not a character but an out-of-band signal. >> >> I think this is a crucial observation. > > Yes, and I think it's based on the experience with XML. But while this > experience may be applicable to JSON, Anne's original comment about the > BOM and XMLHttpRequest suggests that 404 actually currently does not > tolerate a BOM, and that implementations (except for XMLHttpRequest) also > don't. > > To give some historic background, the BOM for UTF-8 wasn't in the first > edition of XML (http://www.w3.org/TR/1998/REC-xml-19980210#sec-guessing). > It only later came in because Microsoft used it for notepad to be able to > quickly distinguish between UTF-8 and the legacy system encoding. Because > many people were writing some XML by hand, and some of them were using > notepad, the pressure on XML to accept a BOM at the start of an UTF-8 file > mounted, and it was included in the second edition of the XML > Recommendation (http://www.w3.org/TR/2000/REC-xml-20001006#sec-guessing). > > Compared to XML, JSON may be much less edited by hand, or much less edited > on notepad, or otherwise just have a different history from XML, but we > have to make sure. > > Regards, Martin. > > >> I note that XML approaches >> this problem in what might be a useful way. The XML ABNF makes no >> mention of BOM, it's not part of any XML document as such. But it >> _is_ allowed. The relevant wording [1] is: >> >> Entities ... may begin with the Byte Order Mark described by Annex H >> of [ISO/IEC 10646:2000], section 16.8 of [Unicode] (the ZERO WIDTH >> NO-BREAK SPACE character, #xFEFF). _This is an encoding signature,_ >> _not part of either the markup or the character data of the XML_ >> _document._ XML processors must be able to use this character to >> differentiate between UTF-8 and UTF-16 encoded documents. [emphasis >> added] >> >> ht >> >> [1] http://www.w3.org/TR/REC-xml/#charencoding > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From petejson@codalogic.com Mon Nov 18 02:05:54 2013 Return-Path: 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 0206711E8152 for ; Mon, 18 Nov 2013 02:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.161 X-Spam-Level: *** X-Spam-Status: No, score=3.161 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=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 sPwp2vUGTZHn for ; Mon, 18 Nov 2013 02:05:49 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 9453911E8106 for ; Mon, 18 Nov 2013 02:05:48 -0800 (PST) Received: (qmail 22826 invoked from network); 18 Nov 2013 10:05:29 +0000 Received: from host81-129-187-193.range81-129.btcentralplus.com (HELO codalogic) (81.129.187.193) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 18 Nov 2013 10:05:29 +0000 Message-ID: <5756A4C4ECFF4C8DA655501B28A1B093@codalogic> From: "Pete Cordell" To: "Paul Hoffman" , "Bjoern Hoehrmann" References: <75E35201E30C4EA4B143B520CB6DF273@codalogic> <13A5A836-A670-4412-82F8-B7BBE84A2FC8@vpnc.org> <3r7i899fler32pdhu1p2nhof0ohl9g8ufp@hive.bjoern.hoehrmann.de> <4364D345-53AD-457A-8ABC-2A559A2655B7@vpnc.org> X-Unsent: 1 Date: Mon, 18 Nov 2013 10:02:15 -0000 MIME-Version: 1.0 x-vipre-scanned: 002A78AE005BB6002A79FB Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: JSON WG Subject: Re: [Json] Encoding detection X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 10:05:54 -0000 ----- Original Message ----- From: "Paul Hoffman" To: "Bjoern Hoehrmann" Cc: "Pete Cordell" ; "JSON WG" Sent: Sunday, November 17, 2013 8:19 PM Subject: Re: [Json] Encoding detection > On Nov 17, 2013, at 12:00 PM, Bjoern Hoehrmann wrote: > >> * Paul Hoffman wrote: >>> On Nov 17, 2013, at 2:02 AM, Pete Cordell >>> wrote: >>> >>>> While I'm here, Joe mentioned "implementable". From an implementer's >>>> perspective the table I presented earlier might be better presented in >>>> the >>>> following order: >>>> >>>> 00 00 -- -- UTF-32BE >>>> 00 xx -- -- UTF-16BE >>>> xx xx -- -- UTF-8 >>>> xx 00 xx -- UTF-16LE >>>> xx 00 00 xx UTF-16LE >>>> xx 00 00 00 UTF-32LE >>>> >>>> Or is that taking the fun out of it for the implementer?! >>> >>> I'm not sure that is the right order. Wouldn't that make UTF-16LE be >>> mistaken for UTF-8? It seems to me that the UTF-8 rule has to be last >>> because it is more general than any of the ones above it. >> >> No, `xx` stands for a non-zero byte. > > Sorry, I thought "xx" meant "unknown". Then I think Pete's formulation is > correct. Although my note about quick detection of BOMs (i.e.: I think BOM presence can be surmised by only looking at the first byte. If it's greater than 0x80 - specifically if it's 0xef, 0xfe, 0xff - then it's an error if you don't go on to find a BOM.) missed the case for 00 00 FE FF UTF-32 (BE) w. BOM. Argh!!! Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From ht@inf.ed.ac.uk Mon Nov 18 03:11:44 2013 Return-Path: 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 5C8F711E813D; Mon, 18 Nov 2013 03:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 2-uFgnvzxc5H; Mon, 18 Nov 2013 03:11:34 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8108011E8128; Mon, 18 Nov 2013 03:11:33 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAIBB5xm015887; Mon, 18 Nov 2013 11:11:10 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAIBB4BS004064; Mon, 18 Nov 2013 11:11:04 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAIBB47g007637; Mon, 18 Nov 2013 11:11:04 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAIBB1xp007633; Mon, 18 Nov 2013 11:11:01 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "Pete Cordell" References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 18 Nov 2013 11:11:01 +0000 In-Reply-To: (Pete Cordell's message of "Mon\, 18 Nov 2013 10\:05\:07 -0000") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: John Cowan , IETF Discussion , JSON WG , Anne van Kesteren , "\"\"Martin J. =?iso-8859-1?Q?D=FCrst=22=22?=" , www-tag@w3.org, es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 11:11:44 -0000 Pete Cordell writes: > Given the history below, would it be sensible to accept BOMs for UTF-8 > encoding, but not for UTF-16 and UTF-32? In other words, are BOMs needed > and/or used in the wild for UTF-16 and UTF-32? > > Maybe the text can say something like "SHOULD accept BOMs for UTF-8, > and MAY accept BOMs for UTF-16 and / or UTF-32"? My sense is that you'll see more UTF-16 BOMs than anything else. UTF-32 support seems to be waning (at least in the browsers), but UTF-16 is in pretty widespread use. John, do you think you can fool google into counting BOMs for us? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From duerst@it.aoyama.ac.jp Mon Nov 18 03:27:17 2013 Return-Path: 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 6A1E111E8107; Mon, 18 Nov 2013 03:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=-2.627, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] 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 c7C6nv+PWAyb; Mon, 18 Nov 2013 03:27:12 -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 ABAFB11E8185; Mon, 18 Nov 2013 03:27:10 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAIBQuto030708; Mon, 18 Nov 2013 20:26:56 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 137b_275b_554186a0_5044_11e3_97b8_001e6722eec2; Mon, 18 Nov 2013 20:26:56 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 2644FBFFFE; Mon, 18 Nov 2013 20:26:56 +0900 (JST) Message-ID: <5289F974.9020709@it.aoyama.ac.jp> Date: Mon, 18 Nov 2013 20:26:44 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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: "Henry S. Thompson" References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: John Cowan , IETF Discussion , Pete Cordell , JSON WG , Anne van Kesteren , www-tag@w3.org, es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 11:27:17 -0000 On 2013/11/18 20:11, Henry S. Thompson wrote: > Pete Cordell writes: > >> Given the history below, would it be sensible to accept BOMs for UTF-8 >> encoding, but not for UTF-16 and UTF-32? In other words, are BOMs needed >> and/or used in the wild for UTF-16 and UTF-32? >> >> Maybe the text can say something like "SHOULD accept BOMs for UTF-8, >> and MAY accept BOMs for UTF-16 and / or UTF-32"? > > My sense is that you'll see more UTF-16 BOMs than anything else. Yes indeed. BOM means Byte Order Mark. It's crucial for over-the-wire UTF-16. (It's irrelevant for in-memory UTF-16, but that's not what we are discussing.) To bring up the XML example again, XML actually strictly requires a BOM for UTF-16. The IETF definition of UTF-16 does not require a BOM for UTF-16. See http://tools.ietf.org/html/rfc2781, in particular http://tools.ietf.org/html/rfc2781#section-3.2, http://tools.ietf.org/html/rfc2781#section-3.3, and http://tools.ietf.org/html/rfc2781#section-4. For UTF-8, the BOM is not a Byte Order Mark, because such a mark isn't necessary at all. It may serve as a signature, but is not necessary, and in some circumstances counterproductive. As for what to say about whether to accept BOMs or not, I'd really want to know what the various existing parsers do. If they accept BOMs, then we can say they should accept BOMs. If they don't accept BOMs, then we should say that they don't. Regards, Martin. > UTF-32 support seems to be waning (at least in the browsers), but > UTF-16 is in pretty widespread use. John, do you think you can fool > google into counting BOMs for us? From derhoermi@gmx.net Mon Nov 18 04:35:27 2013 Return-Path: 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 487B611E810B for ; Mon, 18 Nov 2013 04:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.942 X-Spam-Level: X-Spam-Status: No, score=-4.942 tagged_above=-999 required=5 tests=[AWL=-3.243, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3] 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 2ry3TdDwKAob for ; Mon, 18 Nov 2013 04:35:21 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5110E11E8450 for ; Mon, 18 Nov 2013 04:35:05 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.16.135]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0Lrw2c-1VYAyf01SY-013bc2 for ; Mon, 18 Nov 2013 13:35:04 +0100 From: Bjoern Hoehrmann To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Date: Mon, 18 Nov 2013 13:35:00 +0100 Message-ID: <2tuj89hcus182t4f4rqqgi1dpabt11qak7@hive.bjoern.hoehrmann.de> References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> In-Reply-To: <5289F974.9020709@it.aoyama.ac.jp> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:lPq8YKFZ3C6gZLdtAO5NGqXR/NWeZsxam1Z43WTEbOPX0bG7zJl MUx5/qdNXHpg0taOkq0Zo+Eb3ScCdXkTqCXNNmRm8KVQF/1jQepDaliIkvs79832EYj3uiA OulYqZB998vGKGctX4SnOT/ElpVL/SjEhGwII8d4BcVB5+Atm9gKIdB7HgPuQyhEufYXePa LxZJ2HLSMwOidfwj4JMJg== Cc: Anne van Kesteren , es-discuss , IETF Discussion , www-tag@w3.org, JSON WG Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 12:35:27 -0000 * Martin J. Dürst wrote: >As for what to say about whether to accept BOMs or not, I'd really want >to know what the various existing parsers do. If they accept BOMs, then >we can say they should accept BOMs. If they don't accept BOMs, then we >should say that they don't. Unicode signatures are not useful for application/json resources and are likely to break exisiting and future code, it is not at all uncommon to construct JSON text by concatenating, say, string literals with some web service response without passing the data through a JSON parser. And as RFC 4627 makes no mention of them, there is little reason to think that implementations tolerate them. Perl's JSON module gives me malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "\x{ef}\x{bb}\x{bf}[]") Python's json module gives me ValueError: No JSON object could be decoded Go's "encoding/json" module gives me invalid character 'ď' looking for beginning of value http://shadowregistry.org/js/misc/#t2ea25a961255bb1202da9497a1942e09 is another example of what kinds of bugs await us if we were to specify the use of Unicode signatures for JSON, essentially new DOMParser().parseFromString("\uBBEF\u3CBF\u7979\u3E2F","text/xml") Now U+BBEF U+3CBF U+7979 U+3E2F is not an XML document but Firefox and Internet Explorer treat it as if it were equivalent to "". -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ht@inf.ed.ac.uk Mon Nov 18 05:01:11 2013 Return-Path: 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 E021E11E85BE; Mon, 18 Nov 2013 05:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 7M2Z6RmjKo3u; Mon, 18 Nov 2013 05:01:07 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id E0EEC11E8234; Mon, 18 Nov 2013 04:59:40 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAICxJgv010490; Mon, 18 Nov 2013 12:59:19 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAICxJKB009424; Mon, 18 Nov 2013 12:59:19 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAICxJ1Y012332; Mon, 18 Nov 2013 12:59:19 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAICxIwN012328; Mon, 18 Nov 2013 12:59:18 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Bjoern Hoehrmann References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <2tuj89hcus182t4f4rqqgi1dpabt11qak7@hive.bjoern.hoehrmann.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 18 Nov 2013 12:59:18 +0000 In-Reply-To: <2tuj89hcus182t4f4rqqgi1dpabt11qak7@hive.bjoern.hoehrmann.de> (Bjoern Hoehrmann's message of "Mon\, 18 Nov 2013 13\:35\:00 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: IETF Discussion , JSON WG , Anne van Kesteren , =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= , www-tag@w3.org, es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 13:01:12 -0000 Bjoern Hoehrmann writes: > Perl's JSON module gives me > > malformed JSON string, neither array, object, number, string > or atom, at character offset 0 (before "\x{ef}\x{bb}\x{bf}[]") > > Python's json module gives me > > ValueError: No JSON object could be decoded > > Go's "encoding/json" module gives me > > invalid character '=EF' looking for beginning of value I'm curious to know what level you're invoking the parser at. As implied by my previous post about the Python 'requests' package, it handles application/json resources by stripping any initial BOM it finds -- you can try this with >>> import requests >>> r=3Drequests.get("http://www.ltg.ed.ac.uk/ov-test/b16le.json") >>> r.json() Signatures are not part of the text of a document, as the UNICODE spec makes clear, so asking what happens when you pass a string beginning with a BOM to a parser is not really the right question in this context, is it? As I tried to say in an earlier post, there's a distinction which needs to be carefully insisted on between, on the one hand, languages and their parsers, where I agree signatures/BOMs have no place, and, on the other hand, (media-typed) resources/entities/payloads and _their_ processing, where a discussion of BOMs/signatures _is_ appropriate and, often, necessary. BTW I agree that the status of the UTF-8 BOM as signature is slightly hazy, but again the UNICODE spec itself [1] says "this sequence can serve as signature for UTF-8 encoded text where the character set is unmarked" ht [1] http://www.unicode.org/versions/Unicode6.2.0/ch16.pdf --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] From petejson@codalogic.com Mon Nov 18 05:36:23 2013 Return-Path: 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 C8E2E11E80FC for ; Mon, 18 Nov 2013 05:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.285 X-Spam-Level: *** X-Spam-Status: No, score=3.285 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1, SARE_HEAD_XUNSENT=1.666] 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 w3Jcg6CehV2x for ; Mon, 18 Nov 2013 05:36:19 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id A1D3511E82CD for ; Mon, 18 Nov 2013 05:36:12 -0800 (PST) Received: (qmail 26614 invoked from network); 18 Nov 2013 13:35:41 +0000 Received: from host81-129-187-193.range81-129.btcentralplus.com (HELO codalogic) (81.129.187.193) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 18 Nov 2013 13:35:41 +0000 Message-ID: From: "Pete Cordell" To: =?UTF-8?Q?=22Martin_J._D=C3=BCrst=22?= , "Henry S. Thompson" References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> X-Unsent: 1 x-vipre-scanned: 00EE5E27005BBA00EE5F74 Date: Mon, 18 Nov 2013 13:36:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: John Cowan , IETF Discussion , JSON WG , Anne van Kesteren , www-tag@w3.org, es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 13:36:23 -0000 ----- Original Message ----- From: ""Martin J. DĂĽrst"" > On 2013/11/18 20:11, Henry S. Thompson wrote: >> Pete Cordell writes: >> >>> Given the history below, would it be sensible to accept BOMs for UTF-8 >>> encoding, but not for UTF-16 and UTF-32? In other words, are BOMs >>> needed >>> and/or used in the wild for UTF-16 and UTF-32? >>> >>> Maybe the text can say something like "SHOULD accept BOMs for UTF-8, >>> and MAY accept BOMs for UTF-16 and / or UTF-32"? >> >> My sense is that you'll see more UTF-16 BOMs than anything else. > > Yes indeed. BOM means Byte Order Mark. It's crucial for over-the-wire > UTF-16. (It's irrelevant for in-memory UTF-16, but that's not what we are > discussing.) The in-memory case is not entirely irrelevant because a number of JSON messages will be constructed in memory and then squirted to line. I did a little experiment with Visual Studio. It will allow me to save in UTF-8 with or without a BOM (like thing). Saving in UTF-16 (Or was it UCS2?) is always with a BOM. There didn't seem to be a UTF-32 option. JSON doesn't need BOMs. However, there are cases where people might hand edit messages, and if they choose to save in UTF-16 they will likely have a BOM. Is it acceptable to tell people not to save hand editted files in UTF-16, suggesting UTF-8 (possibly with an encoded BOM) as an alternative? I would imagine that if someone did have a hand editted UTF-8 file on Windows then the allowance of a BOM would help their sanity immeasurably, but it's not something I have firsthand knowledge of. I believe Unix/Linux works with UTF-8 without BOMs. Is this the case? Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From derhoermi@gmx.net Mon Nov 18 05:48:50 2013 Return-Path: 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 E04B611E8121 for ; Mon, 18 Nov 2013 05:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[AWL=-2.387, BAYES_00=-2.599] 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 d4Tbax4OPzon for ; Mon, 18 Nov 2013 05:48:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 03E8311E81A6 for ; Mon, 18 Nov 2013 05:48:24 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.16.135]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0M3zG2-1VQSb12Z18-00rY2p for ; Mon, 18 Nov 2013 14:48:22 +0100 From: Bjoern Hoehrmann To: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 18 Nov 2013 14:48:19 +0100 Message-ID: <626k89plqltbqd5uqgo15krutbn38qa909@hive.bjoern.hoehrmann.de> References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <2tuj89hcus182t4f4rqqgi1dpabt11qak7@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:l9wtXVHB4EitfiRGRQIn0z1WVttROrIvuzM9zDvsUc5f0+BW/bU yQ3aReQbrhGxhrjVaiggxTgAYfutLLwOWnHKMxO5Y2yA2bGIaLwK0HvlwwSaaFH3nuu8SGM dNi2DyOLfJpshHWrkD+PYAh6TCMwZaFqlRZAJYbzBAuptZyqOFf5GHw8HE/f0iluitnG+iT 5ar8VCkasmEAezft4iXSA== Cc: IETF Discussion , JSON WG , Anne van Kesteren , =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , www-tag@w3.org, es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 13:48:51 -0000 * Henry S. Thompson wrote: >I'm curious to know what level you're invoking the parser at. As >implied by my previous post about the Python 'requests' package, it >handles application/json resources by stripping any initial BOM it >finds -- you can try this with > >>>> import requests >>>> r=requests.get("http://www.ltg.ed.ac.uk/ov-test/b16le.json") >>>> r.json() The Perl code was perl -MJSON -MEncode -e "my $s = encode_utf8(chr 0xFEFF) . '[]'; JSON->new->decode($s)" The Python code was import json json.loads(u"\uFEFF[]".encode('utf-8')) The Go code was package main import "encoding/json" import "fmt" func main() { r := "\uFEFF[]" var f interface{} err := json.Unmarshal([]byte(r), &f) fmt.Println(err) } In other words, always passing a UTF-8 encoded byte string to the byte string parsing part of the JSON implementation. RFC 4627 is the only specification for the application/json on-the-wire format and it does not mention anything about Unicode signatures. Looking for certain byte sequences at the beginning and treating them as a Unicode signature is the same as looking for `/* ... */` and treating it as a comment. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From tbray@textuality.com Mon Nov 18 07:58:59 2013 Return-Path: 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 CBEE411E80ED for ; Mon, 18 Nov 2013 07:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.643 X-Spam-Level: X-Spam-Status: No, score=-4.643 tagged_above=-999 required=5 tests=[AWL=-3.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 lunIu4HfgE3K for ; Mon, 18 Nov 2013 07:58:28 -0800 (PST) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6953011E8109 for ; Mon, 18 Nov 2013 07:55:02 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id pa12so5231356veb.13 for ; Mon, 18 Nov 2013 07:54:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1ly1wnTOnxefXI8BFGqM88pymm3Kub9eoGLXhU29Qxs=; b=QbOHB8Gf8oSWG3HrIxmq9P9QDgSl8VyHayppeackIMUWr8/PqlwS7kI4eIld7GynMB jXIN/Regp2LXuBtN4uAF2kFuk/i6EKIiWH1fkGeIOlQNCVQQc5n59AqQqkkJ4fizZpKq gaoMs3+nmeMtNFvEpwCk4bs1PQ1on5BW46X+QObb36sDWtgTEYB1mHdqpQr6j0rBBJxl XQF46lfT+buOU0jkQYWrWkoo+/xQ3U3374NroW7vVWUYDMhg0rL0m7741bZA2nu9T1qe vdea/GPAaGmlXz4Ug6jEKxZPrJ/nKyp8wGCAbpa7nuX9I9WTQtvWgMYON1wzbUGHg7ka Tcbg== X-Gm-Message-State: ALoCoQm0ojkQ/gi4TTtgbNJ/bBKn10OF6GzVMq+bDta2d9vCTFZE2teUQ6TSRSuI5jpFO1M4E6V3 MIME-Version: 1.0 X-Received: by 10.58.208.130 with SMTP id me2mr16190581vec.13.1384790099070; Mon, 18 Nov 2013 07:54:59 -0800 (PST) Received: by 10.220.198.199 with HTTP; Mon, 18 Nov 2013 07:54:58 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> Date: Mon, 18 Nov 2013 07:54:58 -0800 Message-ID: From: Tim Bray To: Pete Cordell Content-Type: multipart/alternative; boundary=047d7bdc192cf1a68704eb7591fb Cc: John Cowan , "Henry S. Thompson" , JSON WG , Anne van Kesteren , es-discuss , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , "www-tag@w3.org" , IETF Discussion Subject: Re: [Json] BOMs (Was: Re: JSON: remove gap between Ecma-404 and IETF draft) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 15:59:00 -0000 --047d7bdc192cf1a68704eb7591fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This feels backward, because BOMs are actually useful for UTF-16 and UTF-32, but essentially useless for UTF-8. On Mon, Nov 18, 2013 at 2:05 AM, Pete Cordell wrote= : > Given the history below, would it be sensible to accept BOMs for UTF-8 > encoding, but not for UTF-16 and UTF-32? In other words, are BOMs needed > and/or used in the wild for UTF-16 and UTF-32? > > Maybe the text can say something like "SHOULD accept BOMs for UTF-8, and > MAY accept BOMs for UTF-16 and / or UTF-32"? > > Thanks, > > Pete Cordell > Codalogic Ltd > C++ tools for C++ programmers, http://codalogic.com > Read & write XML in C++, http://www.xml2cpp.com > ----- Original Message ----- From: ""Martin J. D=C3=BCrst"" < > duerst@it.aoyama.ac.jp> > To: "Henry S. Thompson" > Cc: "John Cowan" ; "IETF Discussion" > ; "Paul Hoffman" ; "JSON WG" > ; "Joe Hildebrand (jhildebr)" ; "Anne > van > Kesteren" ; ; "es-discuss" > > Sent: Thursday, November 14, 2013 11:14 AM > Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft > > > Hello Henry, others, >> >> On 2013/11/14 18:44, Henry S. Thompson wrote: >> >>> John Cowan writes: >>> >>> Joe Hildebrand (jhildebr) scripsit: >>>> >>>> If 404 doesn't allow [a BOM], I don't see a strong need to add it. >>>>> Parsers can always be more forgiving of what they will parse than wha= t >>>>> the spec says, particularly since section 9 says "A JSON parser MAY >>>>> accept non-JSON forms or extensions". >>>>> >>>> >>>> It's not clear that 404 disallows it, since 404 is defined in terms of >>>> characters, and a BOM is not a character but an out-of-band signal. >>>> >>> >>> I think this is a crucial observation. >>> >> >> Yes, and I think it's based on the experience with XML. But while this >> experience may be applicable to JSON, Anne's original comment about the >> BOM and XMLHttpRequest suggests that 404 actually currently does not >> tolerate a BOM, and that implementations (except for XMLHttpRequest) als= o >> don't. >> >> To give some historic background, the BOM for UTF-8 wasn't in the first >> edition of XML (http://www.w3.org/TR/1998/REC-xml-19980210#sec-guessing)= . >> It only later came in because Microsoft used it for notepad to be able t= o >> quickly distinguish between UTF-8 and the legacy system encoding. Becaus= e >> many people were writing some XML by hand, and some of them were using >> notepad, the pressure on XML to accept a BOM at the start of an UTF-8 fi= le >> mounted, and it was included in the second edition of the XML >> Recommendation (http://www.w3.org/TR/2000/REC-xml-20001006#sec-guessing)= . >> >> Compared to XML, JSON may be much less edited by hand, or much less edit= ed >> on notepad, or otherwise just have a different history from XML, but we >> have to make sure. >> >> Regards, Martin. >> >> >> I note that XML approaches >>> this problem in what might be a useful way. The XML ABNF makes no >>> mention of BOM, it's not part of any XML document as such. But it >>> _is_ allowed. The relevant wording [1] is: >>> >>> Entities ... may begin with the Byte Order Mark described by Annex H >>> of [ISO/IEC 10646:2000], section 16.8 of [Unicode] (the ZERO WIDTH >>> NO-BREAK SPACE character, #xFEFF). _This is an encoding signature,_ >>> _not part of either the markup or the character data of the XML_ >>> _document._ XML processors must be able to use this character to >>> differentiate between UTF-8 and UTF-16 encoded documents. [emphasis >>> added] >>> >>> ht >>> >>> [1] http://www.w3.org/TR/REC-xml/#charencoding >>> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7bdc192cf1a68704eb7591fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This feels backward, because BOMs are actually useful for = UTF-16 and UTF-32, but essentially useless for UTF-8.


On Mon, Nov 18, 2013 at 2:05 = AM, Pete Cordell <petejson@codalogic.com> wrote:
Given the history below, would it be sensibl= e to accept BOMs for UTF-8
encoding, but not for UTF-16 and UTF-32? =C2=A0In other words, are BOMs nee= ded
and/or used in the wild for UTF-16 and UTF-32?

Maybe the text can say something like "SHOULD accept BOMs for UTF-8, a= nd MAY accept BOMs for UTF-16 and / or UTF-32"?

Thanks,

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
----- Original Message ----- From: ""Martin J. D=C3=BCrst"&q= uot; <duerst= @it.aoyama.ac.jp>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
Cc: "John Cowan" <cowan@mercury.ccil.org>; "IETF Discussion"=
<ietf@ietf.org>= ;; "Paul Hoffman" <paul.hoffman@vpnc.org>; "JSON WG"
<json@ietf.org>= ;; "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>; "Anne van
Kesteren" <an= nevk@annevk.nl>; <www-tag@w3.org>; "es-discuss"
<es-discuss@= mozilla.org>
Sent: Thursday, November 14, 2013 11:14 AM
Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft


Hello Henry, others,

On 2013/11/14 18:44, Henry S. Thompson wrote:
John Cowan writes:

Joe Hildebrand (jhildebr) scripsit:

If 404 doesn't allow [a BOM], I don't see a strong need to add it.<= br> Parsers can always be more forgiving of what they will parse than what
the spec says, particularly since section 9 says "A JSON parser MAY accept non-JSON forms or extensions".

It's not clear that 404 disallows it, since 404 is defined in terms of<= br> characters, and a BOM is not a character but an out-of-band signal.

I think this is a crucial observation.

Yes, and I think it's based on the experience with XML. But while this<= br> experience may be applicable to JSON, Anne's original comment about the=
BOM and XMLHttpRequest suggests that 404 actually currently does not
tolerate a BOM, and that implementations (except for XMLHttpRequest) also don't.

To give some historic background, the BOM for UTF-8 wasn't in the first=
edition of XML (http://www.w3.org/TR/1998/REC-xml-1998021= 0#sec-guessing).
It only later came in because Microsoft used it for notepad to be able to quickly distinguish between UTF-8 and the legacy system encoding. Because many people were writing some XML by hand, and some of them were using
notepad, the pressure on XML to accept a BOM at the start of an UTF-8 file<= br> mounted, and it was included in the second edition of the XML
Recommendation (http://www.w3.org/TR/2000/REC-xml-2000100= 6#sec-guessing).

Compared to XML, JSON may be much less edited by hand, or much less edited<= br> on notepad, or otherwise just have a different history from XML, but we
have to make sure.

Regards, =C2=A0 Martin.


I note that XML approaches
this problem in what might be a useful way. =C2=A0The XML ABNF makes no
mention of BOM, it's not part of any XML document as such. =C2=A0But it=
_is_ allowed. =C2=A0The relevant wording [1] is:

=C2=A0 =C2=A0Entities ... may begin with the Byte Order Mark described by A= nnex H
=C2=A0 =C2=A0of [ISO/IEC 10646:2000], section 16.8 of [Unicode] (the ZERO W= IDTH
=C2=A0 =C2=A0NO-BREAK SPACE character, #xFEFF). _This is an encoding signat= ure,_
=C2=A0 =C2=A0_not part of either the markup or the character data of the XM= L_
=C2=A0 =C2=A0_document._ XML processors must be able to use this character = to
=C2=A0 =C2=A0differentiate between UTF-8 and UTF-16 encoded documents. [emp= hasis
=C2=A0 =C2=A0added]

ht

[1] http://www.w3.org/TR/REC-xml/#charencoding
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--047d7bdc192cf1a68704eb7591fb-- From petejson@codalogic.com Mon Nov 18 08:12:24 2013 Return-Path: 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 A980311E81CA for ; Mon, 18 Nov 2013 08:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.876 X-Spam-Level: * X-Spam-Status: No, score=1.876 tagged_above=-999 required=5 tests=[AWL=1.390, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1, SARE_HEAD_XUNSENT=1.666, STOX_REPLY_TYPE=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 fyELcoD5U3td for ; Mon, 18 Nov 2013 08:12:24 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id DD61511E81DB for ; Mon, 18 Nov 2013 08:08:31 -0800 (PST) Received: (qmail 29188 invoked from network); 18 Nov 2013 16:08:07 +0000 Received: from host81-129-187-193.range81-129.btcentralplus.com (HELO codalogic) (81.129.187.193) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 18 Nov 2013 16:08:07 +0000 Message-ID: <79BD90E325154FD981F41A6CDF790C45@codalogic> From: "Pete Cordell" To: "Tim Bray" References: <20131113224737.GI31823@mercury.ccil.org><5284B095.4070004@it.aoyama.ac.jp> Date: Mon, 18 Nov 2013 16:08:53 -0000 X-Unsent: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original x-vipre-scanned: 017A21F0005BC0017A233D Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: John Cowan , "Henry S. Thompson" , JSON WG , Anne van Kesteren , es-discuss , "=?UTF-8?Q?Martin_J._D=C3=BCrst?=" , www-tag@w3.org, IETF Discussion Subject: Re: [Json] BOMs (Was: Re: JSON: remove gap between Ecma-404 and IETF draft) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 16:12:25 -0000 ----- Original Message From: "Tim Bray" > This feels backward, because BOMs are actually useful for UTF-16 and > UTF-32, but essentially useless for UTF-8. Not useless if you're trying to tell the difference between a hand editted Windows cp-1252 (or whatever it's called) encoded text file and a UTF-8 encoded text file. I don't think we need them for any other reason, but I think some international Windows users would be thankful if you allowed them for that case. On Mon, Nov 18, 2013 at 2:05 AM, Pete Cordell wrote: > Given the history below, would it be sensible to accept BOMs for UTF-8 > encoding, but not for UTF-16 and UTF-32? In other words, are BOMs needed > and/or used in the wild for UTF-16 and UTF-32? > > Maybe the text can say something like "SHOULD accept BOMs for UTF-8, and > MAY accept BOMs for UTF-16 and / or UTF-32"? > > Thanks, > > Pete Cordell > Codalogic Ltd > C++ tools for C++ programmers, http://codalogic.com > Read & write XML in C++, http://www.xml2cpp.com > ----- Original Message ----- From: ""Martin J. DĂĽrst"" < > duerst@it.aoyama.ac.jp> > To: "Henry S. Thompson" > Cc: "John Cowan" ; "IETF Discussion" > ; "Paul Hoffman" ; "JSON WG" > ; "Joe Hildebrand (jhildebr)" ; "Anne > van > Kesteren" ; ; "es-discuss" > > Sent: Thursday, November 14, 2013 11:14 AM > Subject: Re: [Json] JSON: remove gap between Ecma-404 and IETF draft > > > Hello Henry, others, >> >> On 2013/11/14 18:44, Henry S. Thompson wrote: >> >>> John Cowan writes: >>> >>> Joe Hildebrand (jhildebr) scripsit: >>>> >>>> If 404 doesn't allow [a BOM], I don't see a strong need to add it. >>>>> Parsers can always be more forgiving of what they will parse than what >>>>> the spec says, particularly since section 9 says "A JSON parser MAY >>>>> accept non-JSON forms or extensions". >>>>> >>>> >>>> It's not clear that 404 disallows it, since 404 is defined in terms of >>>> characters, and a BOM is not a character but an out-of-band signal. >>>> >>> >>> I think this is a crucial observation. >>> >> >> Yes, and I think it's based on the experience with XML. But while this >> experience may be applicable to JSON, Anne's original comment about the >> BOM and XMLHttpRequest suggests that 404 actually currently does not >> tolerate a BOM, and that implementations (except for XMLHttpRequest) also >> don't. >> >> To give some historic background, the BOM for UTF-8 wasn't in the first >> edition of XML (http://www.w3.org/TR/1998/REC-xml-19980210#sec-guessing). >> It only later came in because Microsoft used it for notepad to be able to >> quickly distinguish between UTF-8 and the legacy system encoding. Because >> many people were writing some XML by hand, and some of them were using >> notepad, the pressure on XML to accept a BOM at the start of an UTF-8 >> file >> mounted, and it was included in the second edition of the XML >> Recommendation (http://www.w3.org/TR/2000/REC-xml-20001006#sec-guessing). >> >> Compared to XML, JSON may be much less edited by hand, or much less >> edited >> on notepad, or otherwise just have a different history from XML, but we >> have to make sure. >> >> Regards, Martin. >> >> >> I note that XML approaches >>> this problem in what might be a useful way. The XML ABNF makes no >>> mention of BOM, it's not part of any XML document as such. But it >>> _is_ allowed. The relevant wording [1] is: >>> >>> Entities ... may begin with the Byte Order Mark described by Annex H >>> of [ISO/IEC 10646:2000], section 16.8 of [Unicode] (the ZERO WIDTH >>> NO-BREAK SPACE character, #xFEFF). _This is an encoding signature,_ >>> _not part of either the markup or the character data of the XML_ >>> _document._ XML processors must be able to use this character to >>> differentiate between UTF-8 and UTF-16 encoded documents. [emphasis >>> added] >>> >>> ht >>> >>> [1] http://www.w3.org/TR/REC-xml/#charencoding >>> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From cowan@ccil.org Mon Nov 18 08:22:22 2013 Return-Path: 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 7211011E8141; Mon, 18 Nov 2013 08:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 iCcKyOyKYZEb; Mon, 18 Nov 2013 08:22:17 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id D758F11E81E1; Mon, 18 Nov 2013 08:20:09 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1ViRYI-00036h-GB; Mon, 18 Nov 2013 11:19:54 -0500 Date: Mon, 18 Nov 2013 11:19:54 -0500 From: John Cowan To: "Henry S. Thompson" Message-ID: <20131118161954.GB23458@mercury.ccil.org> References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: IETF Discussion , Pete Cordell , JSON WG , Anne van Kesteren , Martin =?iso-8859-1?B?Si4gRPxyc3QiIg==?= , www-tag@w3.org, es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 16:22:22 -0000 Henry S. Thompson scripsit: > My sense is that you'll see more UTF-16 BOMs than anything else. I agree. > UTF-32 support seems to be waning (at least in the browsers), but > UTF-16 is in pretty widespread use. John, do you think you can fool > google into counting BOMs for us? No, because Google transcodes everything into UTF-8 as soon as it starts to process it. What I can say (auct. Mark Davis) is that UTF-16 documents in all formats represent much less than 0.1% of the searchable Web. By contrast, UTF-8 (including ASCII) amounts to 80% of it. This reflects actual rather than declared encodings, and is as of January 2012. -- So they play that [tune] on John Cowan their fascist banjos, eh? cowan@ccil.org --Great-Souled Sam http://www.ccil.org/~cowan From julian.reschke@gmx.de Mon Nov 18 08:24:13 2013 Return-Path: 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 ACE0F11E8135 for ; Mon, 18 Nov 2013 08:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.524 X-Spam-Level: X-Spam-Status: No, score=-105.524 tagged_above=-999 required=5 tests=[AWL=-2.925, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 8cea51nwUEJH for ; Mon, 18 Nov 2013 08:24:13 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 27C2D11E8178 for ; Mon, 18 Nov 2013 08:23:04 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lev1D-1VL8sC0lCR-00qjCE for ; Mon, 18 Nov 2013 17:22:49 +0100 Message-ID: <528A3ED2.30305@gmx.de> Date: Mon, 18 Nov 2013 17:22:42 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Pete Cordell , Tim Bray References: <20131113224737.GI31823@mercury.ccil.org><5284B095.4070004@it.aoyama.ac.jp> <79BD90E325154FD981F41A6CDF790C45@codalogic> In-Reply-To: <79BD90E325154FD981F41A6CDF790C45@codalogic> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Z8Cl9OicyeA4tuoNjL24eAN/tpxXPcMhI0A6NONUg783EsiKcg7 MJS9dQkz7/BSpfLxyh6THCOB1cf/b6Bh87YuJ6x1EZD45Tu/xJOzd9JjHd8l8+P30MOKs+I 4nLOpouLfKDixRW3Wys8q8pNa8GebZfZOJRXep5cZ+Krt/gwQNPzNmqqT8ZsiWxXn5CFQeH 93rr5m2LWxU2X+CVNKABg== X-Mailman-Approved-At: Mon, 18 Nov 2013 08:29:52 -0800 Cc: IETF Discussion , John Cowan , "Henry S. Thompson" , JSON WG , =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Anne van Kesteren , www-tag@w3.org, es-discuss Subject: Re: [Json] BOMs (Was: Re: JSON: remove gap between Ecma-404 and IETF draft) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 16:24:13 -0000 On 2013-11-18 17:08, Pete Cordell wrote: > ----- Original Message From: "Tim Bray" >> This feels backward, because BOMs are actually useful for UTF-16 and >> UTF-32, but essentially useless for UTF-8. > > Not useless if you're trying to tell the difference between a hand > editted Windows cp-1252 (or whatever it's called) encoded text file and > a UTF-8 encoded text file. Ye. > I don't think we need them for any other reason, but I think some > international Windows users would be thankful if you allowed them for > that case. So I gather "non-international Windows" users never need non-ASCII characters? :-) (Yes, that explains lots of I18N brokenness originating from certain countries...) Best regards, Julian From cowan@ccil.org Mon Nov 18 09:07:57 2013 Return-Path: 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 A8AF111E8184; Mon, 18 Nov 2013 09:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 DPIiJqgo18fm; Mon, 18 Nov 2013 09:07:52 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id DC71711E8190; Mon, 18 Nov 2013 09:07:15 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1ViSI1-0007zJ-8Q; Mon, 18 Nov 2013 12:07:09 -0500 Date: Mon, 18 Nov 2013 12:07:09 -0500 From: John Cowan To: Pete Cordell Message-ID: <20131118170708.GE23458@mercury.ccil.org> References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <79BD90E325154FD981F41A6CDF790C45@codalogic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79BD90E325154FD981F41A6CDF790C45@codalogic> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "Henry S. Thompson" , JSON WG , Tim Bray , Anne van Kesteren , es-discuss , Martin =?iso-8859-1?Q?J=2E_D=FCrst?= , www-tag@w3.org, IETF Discussion Subject: Re: [Json] BOMs (Was: Re: JSON: remove gap between Ecma-404 and IETF draft) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 17:07:57 -0000 Pete Cordell scripsit: > Not useless if you're trying to tell the difference between a hand > editted Windows cp-1252 (or whatever it's called) encoded text file > and a UTF-8 encoded text file. In principle you cannot tell, but in practice it's possible to discriminate betwen the two with extremely high reliability. -- "Well, I'm back." --Sam John Cowan From derhoermi@gmx.net Mon Nov 18 09:55:21 2013 Return-Path: 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 4B71411E8219 for ; Mon, 18 Nov 2013 09:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.509 X-Spam-Level: X-Spam-Status: No, score=-4.509 tagged_above=-999 required=5 tests=[AWL=-1.910, BAYES_00=-2.599] 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 4Rwqbi9lVpk8 for ; Mon, 18 Nov 2013 09:55:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1311311E81B5 for ; Mon, 18 Nov 2013 09:50:22 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.16.135]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MYKGj-1WDUDK4BtJ-00V6ZE for ; Mon, 18 Nov 2013 18:50:21 +0100 From: Bjoern Hoehrmann To: mnita@google.com Date: Mon, 18 Nov 2013 18:50:18 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:TnHF/dlHDEki9RPIFthGaWWlfsKyHwEYUtpRseWiLqwUEV2ZzCH qLj2+qIRkLn0IzI4rljCGkxVtW7yuIDqL+syArDIVJHpznRrLM3GeTB7YECOqqUy3PaM5vy F1HYGbV+DqvDXusouhqy5QEhfUbgkw0mAkL31TnjKAh2PcfNRplXHn56KclNw08oM/Cd+WR BNPuyrC+R2mYDsOx7Teng== Cc: es-discuss , IETF Discussion , www-tag@w3.org, JSON WG Subject: Re: [Json] es-discuss Digest, Vol 81, Issue 82 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 17:55:21 -0000 * mnita@google.com wrote: >The first four bytes are: > > 00 00 00 22 UTF-32BE > 00 22 E5 65 UTF-16BE > 22 00 00 00 UTF-32LE > 22 00 65 E5 UTF-16LE > 22 E6 97 A5 UTF-8 > >The UTF-16 bytes don't match the patterns in RFC, so UTF-16 streams would >(wrongly) be detected as UTF-8, if one strictly follows the RFC. RFC 4627 does not allow string literals at the top level. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From petejson@codalogic.com Mon Nov 18 10:32:46 2013 Return-Path: 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 B2D7B1A1F42 for ; Mon, 18 Nov 2013 10:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.679 X-Spam-Level: * X-Spam-Status: No, score=1.679 tagged_above=-999 required=5 tests=[FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.363, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8_PkZNBEMtJ for ; Mon, 18 Nov 2013 10:32:45 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 62DC51A1F4A for ; Mon, 18 Nov 2013 10:32:41 -0800 (PST) Received: (qmail 31104 invoked from network); 18 Nov 2013 18:25:36 +0000 Received: from host81-129-187-193.range81-129.btcentralplus.com (HELO codalogic) (81.129.187.193) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 18 Nov 2013 18:25:36 +0000 Message-ID: <86F95BC45B1F4D85B489091AFF5D675C@codalogic> From: "Pete Cordell" To: "Julian Reschke" References: <20131113224737.GI31823@mercury.ccil.org><5284B095.4070004@it.aoyama.ac.jp> <79BD90E325154FD981F41A6CDF790C45@codalogic> <528A3ED2.30305@gmx.de> X-Unsent: 1 Date: Mon, 18 Nov 2013 18:26:15 -0000 x-vipre-scanned: 01F7E5CD005BC001F7E71A MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: JSON WG Subject: Re: [Json] BOMs (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 18:32:46 -0000 ----- Original Message From: "Julian Reschke" > So I gather "non-international Windows" users never need non-ASCII > characters? :-) (Yes, that explains lots of I18N brokenness originating > from certain countries...) Only as ISO-8859-1 :-) (Quickly hides!!!) Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From petejson@codalogic.com Mon Nov 18 10:32:46 2013 Return-Path: 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 C5AC11A1F45 for ; Mon, 18 Nov 2013 10:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.891 X-Spam-Level: * X-Spam-Status: No, score=1.891 tagged_above=-999 required=5 tests=[FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.363, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.212] autolearn=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQTOOIRiir7L for ; Mon, 18 Nov 2013 10:32:45 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 62C301A1F48 for ; Mon, 18 Nov 2013 10:32:41 -0800 (PST) Received: (qmail 31091 invoked from network); 18 Nov 2013 18:25:36 +0000 Received: from host81-129-187-193.range81-129.btcentralplus.com (HELO codalogic) (81.129.187.193) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 18 Nov 2013 18:25:36 +0000 Message-ID: From: "Pete Cordell" To: "John Cowan" References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <79BD90E325154FD981F41A6CDF790C45@codalogic> <20131118170708.GE23458@mercury.ccil.org> X-Unsent: 1 Date: Mon, 18 Nov 2013 18:19:46 -0000 x-vipre-scanned: 01F1F52C005BC001F1F679 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: "Henry S. Thompson" , JSON WG , Tim Bray , Anne van Kesteren , "=?iso-8859-1?Q?Martin_J._D=FCrst?=" , www-tag@w3.org, IETF Discussion Subject: Re: [Json] BOMs (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 18:32:47 -0000 ----- Original Message From: "John Cowan" > Pete Cordell scripsit: > >> Not useless if you're trying to tell the difference between a hand >> editted Windows cp-1252 (or whatever it's called) encoded text file >> and a UTF-8 encoded text file. > > In principle you cannot tell, but in practice it's possible to > discriminate > betwen the two with extremely high reliability. John, Do you mean that the presence of a UTF-8 BOF sequence doesn't prove that it's not Windows cp-1252 or do you mean you can tell apart a UTF-8 and cp-1252 file without BOMs? If the latter, do the relevant tools take the time to distinguish the 2 without BOMs? Thanks, Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From cowan@ccil.org Mon Nov 18 10:42:06 2013 Return-Path: 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 5BEDC1A1F50; Mon, 18 Nov 2013 10:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525] 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 OJRqCg4iYKT3; Mon, 18 Nov 2013 10:42:03 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id CC9531A1F48; Mon, 18 Nov 2013 10:42:03 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1ViTlh-0000QF-G3; Mon, 18 Nov 2013 13:41:53 -0500 Date: Mon, 18 Nov 2013 13:41:53 -0500 From: John Cowan To: Pete Cordell Message-ID: <20131118184153.GH23458@mercury.ccil.org> References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <79BD90E325154FD981F41A6CDF790C45@codalogic> <20131118170708.GE23458@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "Henry S. Thompson" , JSON WG , Tim Bray , Anne van Kesteren , Martin =?iso-8859-1?Q?J=2E_D=FCrst?= , www-tag@w3.org, IETF Discussion Subject: Re: [Json] BOMs (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 18:42:06 -0000 Pete Cordell scripsit: > Do you mean that the presence of a UTF-8 BOF sequence doesn't prove > that it's not Windows cp-1252 or do you mean you can tell apart a > UTF-8 and cp-1252 file without BOMs? I meant the latter, but the former is true, too. A plain text document beginning "" in Windows-1252 will appear to begin with an 8-BOM in the absence of out of band information. > If the latter, do the relevant tools take the time to distinguish > the 2 without BOMs? Some tools do, some don't. The IRC client I use, XChat, attempts to convert input as UTF-8, and if that fails, converts it as Latin-1. I have not yet seen it produce mojibake. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Most languages are dramatically underdescribed, and at least one is dramatically overdescribed. Still other languages are simultaneously overdescribed and underdescribed. Welsh pertains to the third category. --Alan King From tsaloranta@gmail.com Mon Nov 18 11:01:28 2013 Return-Path: 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 690C31AD62B; Mon, 18 Nov 2013 11:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-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 jg1NjCcWATEu; Mon, 18 Nov 2013 11:01:26 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 594211AE068; Mon, 18 Nov 2013 10:59:54 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hj6so312952wib.4 for ; Mon, 18 Nov 2013 10:59:48 -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=kkmj1TuVT/nthZmqkfzypgax4e5VI6HBW30Zns9mf7w=; b=FuDBDUoNFsRi5k1x+WXDPiZItOgA933e3BoS2U8AP+MVjRGCRkpaYyn7zKEh8pqEeA gQzmqcpWa8UUZRBS+lpV983E9eoLUwdHLuxkxaao+9f2snS4VEVWaNel+7fOJri/qAgd 3+Ezw6El9Jx8+Df9YBYTm9g+iEx5jIknGRppOp1wVaExyKP2vf8fCh+O3ISoNct/GmNy ZFFFpjZRyraFK+NRcACNS1pdRT2Mvgaw9upt4nM0l32bY07Cc0qTB1yjAWOrFQwK6iiY gvsWvEAEGxxgIw7NiBXbMXhyPvhB2Eve+jlyozG2I4p1S9LNQaVoR9V7tNVkX4Nh3Tke 8MDQ== MIME-Version: 1.0 X-Received: by 10.180.187.113 with SMTP id fr17mr17726387wic.35.1384801188109; Mon, 18 Nov 2013 10:59:48 -0800 (PST) Received: by 10.227.61.195 with HTTP; Mon, 18 Nov 2013 10:59:48 -0800 (PST) In-Reply-To: <2tuj89hcus182t4f4rqqgi1dpabt11qak7@hive.bjoern.hoehrmann.de> References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <2tuj89hcus182t4f4rqqgi1dpabt11qak7@hive.bjoern.hoehrmann.de> Date: Mon, 18 Nov 2013 10:59:48 -0800 Message-ID: From: Tatu Saloranta To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=001a11c383b2e6e15404eb7826e9 Cc: IETF Discussion , JSON WG , =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 19:01:28 -0000 --001a11c383b2e6e15404eb7826e9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dominant Java implementations support UTF-16 with BOM; either directly or through Java's Reader implementations that handle BOMs. String concatenation case seems irrelevant, since BOMs are not included in in-memory representation anyway, as opposed to byte stream serialization. -+ Tatu +- On Mon, Nov 18, 2013 at 4:35 AM, Bjoern Hoehrmann wrote= : > * Martin J. D=FCrst wrote: > >As for what to say about whether to accept BOMs or not, I'd really want > >to know what the various existing parsers do. If they accept BOMs, then > >we can say they should accept BOMs. If they don't accept BOMs, then we > >should say that they don't. > > Unicode signatures are not useful for application/json resources and are > likely to break exisiting and future code, it is not at all uncommon to > construct JSON text by concatenating, say, string literals with some web > service response without passing the data through a JSON parser. And as > RFC 4627 makes no mention of them, there is little reason to think that > implementations tolerate them. > > Perl's JSON module gives me > > malformed JSON string, neither array, object, number, string > or atom, at character offset 0 (before "\x{ef}\x{bb}\x{bf}[]") > > Python's json module gives me > > ValueError: No JSON object could be decoded > > Go's "encoding/json" module gives me > > invalid character '=EF' looking for beginning of value > > http://shadowregistry.org/js/misc/#t2ea25a961255bb1202da9497a1942e09 is > another example of what kinds of bugs await us if we were to specify the > use of Unicode signatures for JSON, essentially > > new DOMParser().parseFromString("\uBBEF\u3CBF\u7979\u3E2F","text/xml") > > Now U+BBEF U+3CBF U+7979 U+3E2F is not an XML document but Firefox and > Internet Explorer treat it as if it were equivalent to "". > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c383b2e6e15404eb7826e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dominant Java implementations support UTF-16 with BOM= ; either directly or through Java's Reader implementations that handle = BOMs.
String concatenation case seems irrelevant, since BOMs are not inc= luded in in-memory representation anyway, as opposed to byte stream seriali= zation.

-+ Tatu +-



On Mon, Nov 18, 2013 at 4:35 AM, Bjoern Hoehrmann <de= rhoermi@gmx.net> wrote:
* Martin J. D=FCrst wrote:=
>As for what to say about whether to accept BOMs or not, I'd really = want
>to know what the various existing parsers do. If they accept BOMs, then=
>we can say they should accept BOMs. If they don't accept BOMs, then= we
>should say that they don't.

Unicode signatures are not useful for application/json resources and = are
likely to break exisiting and future code, it is not at all uncommon to
construct JSON text by concatenating, say, string literals with some web service response without passing the data through a JSON parser. And as
RFC 4627 makes no mention of them, there is little reason to think that
implementations tolerate them.

Perl's JSON module gives me

=A0 malformed JSON string, neither array, object, number, string
=A0 or atom, at character offset 0 (before "\x{ef}\x{bb}\x{bf}[]"= )

Python's json module gives me

=A0 ValueError: No JSON object could be decoded

Go's "encoding/json" module gives me

=A0 invalid character '=EF' looking for beginning of value

http://shadowregistry.org/js/misc/#t2ea25a961255bb1= 202da9497a1942e09 is
another example of what kinds of bugs await us if we were to specify the use of Unicode signatures for JSON, essentially

=A0 new DOMParser().parseFromString("\uBBEF\u3CBF\u7979\u3E2F",&q= uot;text/xml")

Now U+BBEF U+3CBF U+7979 U+3E2F is not an XML document but Firefox and
Internet Explorer treat it as if it were equivalent to "<yy/>&qu= ot;.
--
Bj=F6rn H=F6hrmann =B7 mailto:bjoern= @hoehrmann.de =B7 http://bjoern.hoehrmann.de
Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.de
25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c383b2e6e15404eb7826e9-- From hallam@gmail.com Mon Nov 18 12:56:21 2013 Return-Path: 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 652701AE449; Mon, 18 Nov 2013 12:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 lZVb45-eB0bV; Mon, 18 Nov 2013 12:56:18 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3E01AE446; Mon, 18 Nov 2013 12:56:18 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id u14so1936353lbd.27 for ; Mon, 18 Nov 2013 12:56:11 -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=We8IGwKRvXywLkT0upELyAO95ZPXTLtVdjITrkGNSTs=; b=ybazXpho0FG73CyvTx5GTS+3EGGfPVWH2/3pCotEOz6bL3x1FvLLUp4GsYtBffKBRy gAtxwjGT07s7AZH6cKZC7UDw7Z1X5qOdA1/8s3AWBJu6tiVpEJaaPP1/Sb/m97nINecj 2ymtLY9nRiLxZN1C2LaeGVJ6d0cCKlmX3sp7B+cXv41QpuBrUELj06uc5G+Gz/A8YrWc X46k8FhmGwLx34gJZpXIzfC3ErmIuhI9ivHp7APW6kcO2yBQNbBfZ09NGel5ZboMAKES //4jLQyGl4VaLDeeOSy+pb7iEScH0VedvwLPiLrd6q3Zw1yQY2tVKIuNkYBMCDgvpeCd YlRQ== MIME-Version: 1.0 X-Received: by 10.112.146.200 with SMTP id te8mr3011804lbb.32.1384808171846; Mon, 18 Nov 2013 12:56:11 -0800 (PST) Received: by 10.112.46.98 with HTTP; Mon, 18 Nov 2013 12:56:11 -0800 (PST) In-Reply-To: References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> Date: Mon, 18 Nov 2013 15:56:11 -0500 Message-ID: From: Phillip Hallam-Baker To: Pete Cordell Content-Type: multipart/alternative; boundary=047d7b3a83d42a41ff04eb79c74d X-Mailman-Approved-At: Mon, 18 Nov 2013 13:02:16 -0800 Cc: John Cowan , "Henry S. Thompson" , JSON WG , Anne van Kesteren , es-discuss , =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , "www-tag@w3.org" , IETF Discussion Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 20:56:21 -0000 --047d7b3a83d42a41ff04eb79c74d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2013 at 8:36 AM, Pete Cordell wrote= : > ----- Original Message ----- From: ""Martin J. D=FCrst"" < > duerst@it.aoyama.ac.jp> > > On 2013/11/18 20:11, Henry S. Thompson wrote: >> >>> Pete Cordell writes: >>> >>> Given the history below, would it be sensible to accept BOMs for UTF-8 >>>> encoding, but not for UTF-16 and UTF-32? In other words, are BOMs >>>> needed >>>> and/or used in the wild for UTF-16 and UTF-32? >>>> >>>> Maybe the text can say something like "SHOULD accept BOMs for UTF-8, >>>> and MAY accept BOMs for UTF-16 and / or UTF-32"? >>>> >>> >>> My sense is that you'll see more UTF-16 BOMs than anything else. >>> >> >> Yes indeed. BOM means Byte Order Mark. It's crucial for over-the-wire >> UTF-16. (It's irrelevant for in-memory UTF-16, but that's not what we ar= e >> discussing.) >> > > The in-memory case is not entirely irrelevant because a number of JSON > messages will be constructed in memory and then squirted to line. > > I did a little experiment with Visual Studio. It will allow me to save i= n > UTF-8 with or without a BOM (like thing). Saving in UTF-16 (Or was it > UCS2?) is always with a BOM. There didn't seem to be a UTF-32 option. > > JSON doesn't need BOMs. However, there are cases where people might hand > edit messages, and if they choose to save in UTF-16 they will likely have= a > BOM. > > Is it acceptable to tell people not to save hand editted files in UTF-16, > suggesting UTF-8 (possibly with an encoded BOM) as an alternative? > > I would imagine that if someone did have a hand editted UTF-8 file on > Windows then the allowance of a BOM would help their sanity immeasurably, > but it's not something I have firsthand knowledge of. > I believe the opposite is true. The failure of Windows to correctly process documents without BOM markers is a constant pain trying to use .NET to parse XML. The ability to compose a JSON message by wrapping another JSON message is essential. That is, it has to be possible to write something like printf ("{\"Object\", %s}", Text); I use the .NET platform heavily. Please do not let Microsoft off the hook here. The cost of doing so is having to write code to kick out spurious BOM sequences occurring at any random point in the text. Which becomes really painful when having to deal with strings where there might actually be a reason to put the BOM in. The benefit of not doing so is that it might encourage Microsoft to fix their tools so that they don't insert spurious BOM sequences in documents where doing so breaks them. --=20 Website: http://hallambaker.com/ --047d7b3a83d42a41ff04eb79c74d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Nov 18, 2013 at 8:36 AM, Pete Cordell <= ;petejson@codal= ogic.com> wrote:
----- Original Message ----- From: "&qu= ot;Martin J. D=FCrst"" <duerst@it.aoyama.ac.jp>

On 2013/11/18 20:11, Henry S. Thompson wrote:
Pete Cordell writes:

Given the history below, would it be sensible to accept BOMs for UTF-8
encoding, but not for UTF-16 and UTF-32? =A0In other words, are BOMs needed=
and/or used in the wild for UTF-16 and UTF-32?

Maybe the text can say something like "SHOULD accept BOMs for UTF-8, and MAY accept BOMs for UTF-16 and / or UTF-32"?

My sense is that you'll see more UTF-16 BOMs than anything else.

Yes indeed. BOM means Byte Order Mark. It's crucial for over-the-wire U= TF-16. (It's irrelevant for in-memory UTF-16, but that's not what w= e are discussing.)

The in-memory case is not entirely irrelevant because a number of JSON mess= ages will be constructed in memory and then squirted to line.

I did a little experiment with Visual Studio. =A0It will allow me to save i= n UTF-8 with or without a BOM (like thing). =A0Saving in UTF-16 (Or was it = UCS2?) is always with a BOM. =A0There didn't seem to be a UTF-32 option= .

JSON doesn't need BOMs. =A0However, there are cases where people might = hand edit messages, and if they choose to save in UTF-16 they will likely h= ave a BOM.

Is it acceptable to tell people not to save hand editted files in UTF-16, s= uggesting UTF-8 (possibly with an encoded BOM) as an alternative?

I would imagine that if someone did have a hand editted UTF-8 file on Windo= ws then the allowance of a BOM would help their sanity immeasurably, but it= 's not something I have firsthand knowledge of.


I believe the opposite is true.
The failure of Windows to correctly process documents without B= OM markers is a constant pain trying to use .NET to parse XML.

The ability to compose a JSON message by wrapping another JS= ON message is essential. That is, it has to be possible to write something = like

printf ("{\"Object\", %s}"= ;, Text);=A0


I use the .NET platform heavily. Please = do not let Microsoft off the hook here. The cost of doing so is having to w= rite code to kick out spurious BOM sequences occurring at any random point = in the text. Which becomes really painful when having to deal with strings = where there might actually be a reason to put the BOM in.=A0

The benefit of not doing so is that it might encourage = Microsoft to fix their tools so that they don't insert spurious BOM seq= uences in documents where doing so breaks them.

=A0
--
Website: http://h= allambaker.com/
--047d7b3a83d42a41ff04eb79c74d-- From duerst@it.aoyama.ac.jp Mon Nov 18 20:33:15 2013 Return-Path: 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 B94131AE67E; Mon, 18 Nov 2013 20:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 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, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] 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 TtFTkf8h0GvZ; Mon, 18 Nov 2013 20:33:13 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3C88A1AE60F; Mon, 18 Nov 2013 20:33:12 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAJ4WpjF026269; Tue, 19 Nov 2013 13:32:51 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6167_bed3_a65addae_50d3_11e3_9b42_001e6722eec2; Tue, 19 Nov 2013 13:32:50 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 70827BFBBE; Tue, 19 Nov 2013 13:32:50 +0900 (JST) Message-ID: <528AE9E5.3000704@it.aoyama.ac.jp> Date: Tue, 19 Nov 2013 13:32:37 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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: "Henry S. Thompson" References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <2tuj89hcus182t4f4rqqgi1dpabt11qak7@hive.bjoern.hoehrmann.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: IETF Discussion , Bjoern Hoehrmann , JSON WG , Anne van Kesteren , www-tag@w3.org, es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 04:33:15 -0000 Okay, here are some more tests. http://www.sw.it.aoyama.ac.jp/2013/pub/json_tests/test1_utf8_nobom.json http://www.sw.it.aoyama.ac.jp/2013/pub/json_tests/test2_utf8_bom.json They are self-describing JSON files served with application/json, the=20 first without a BOM, and the second with a BOM. They contain some Japanese, and a tiny bit of Spanish. [see more below] On 2013/11/18 21:59, Henry S. Thompson wrote: > Bjoern Hoehrmann writes: > >> Perl's JSON module gives me >> >> malformed JSON string, neither array, object, number, string >> or atom, at character offset 0 (before "\x{ef}\x{bb}\x{bf}[]") >> >> Python's json module gives me >> >> ValueError: No JSON object could be decoded >> >> Go's "encoding/json" module gives me >> >> invalid character '=C3=AF' looking for beginning of value > > I'm curious to know what level you're invoking the parser at. As > implied by my previous post about the Python 'requests' package, it > handles application/json resources by stripping any initial BOM it > finds -- you can try this with > >>>> import requests >>>> r=3Drequests.get("http://www.ltg.ed.ac.uk/ov-test/b16le.json") >>>> r.json() I get a 404 on this example. I can put up UTF-16 examples, too. Regards, Martin. > Signatures are not part of the text of a document, as the UNICODE spec > makes clear, so asking what happens when you pass a string beginning > with a BOM to a parser is not really the right question in this > context, is it? > > As I tried to say in an earlier post, there's a distinction which > needs to be carefully insisted on between, on the one hand, languages > and their parsers, where I agree signatures/BOMs have no place, and, > on the other hand, (media-typed) resources/entities/payloads and _their= _ > processing, where a discussion of BOMs/signatures _is_ appropriate > and, often, necessary. > > BTW I agree that the status of the UTF-8 BOM as signature is slightly > hazy, but again the UNICODE spec itself [1] says > > "this sequence can serve as signature for UTF-8 encoded text where > the character set is unmarked" > > ht > > [1] http://www.unicode.org/versions/Unicode6.2.0/ch16.pdf From duerst@it.aoyama.ac.jp Tue Nov 19 03:10:07 2013 Return-Path: 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 F25451ADE8A; Tue, 19 Nov 2013 03:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 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, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] 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 SQs_R_Z8fxVT; Tue, 19 Nov 2013 03:10:04 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 64C291ADE89; Tue, 19 Nov 2013 03:10:04 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAJB9hOn010714; Tue, 19 Nov 2013 20:09:43 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6163_36c8_17a4d398_510b_11e3_b2e4_001e6722eec2; Tue, 19 Nov 2013 20:09:43 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id A4DF8BFBBE; Tue, 19 Nov 2013 20:09:42 +0900 (JST) Message-ID: <528B46EA.4040503@it.aoyama.ac.jp> Date: Tue, 19 Nov 2013 20:09:30 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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: "t.p." References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> In-Reply-To: <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: John Cowan , IETF Discussion , Pete Cordell , JSON WG , Anne van Kesteren , www-tag@w3.org, es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 11:10:07 -0000 On 2013/11/19 19:10, t.p. wrote: > ----- Original Message ----- > From: "Martin J. D=C3=BCrst" >> For UTF-8, the BOM is not a Byte Order Mark, because such a mark isn't >> necessary at all. It may serve as a signature, but is not necessary, > and >> in some circumstances counterproductive. > > Martin > > We had a similar discussion with syslog back in 2005, the issue being > that UTF-8 was new and different and how to tell whether it was being > used or not, and what made it into RFC5424 was > " If a syslog application encodes MSG in UTF-8, the string MUST start > with the Unicode byte order mask (BOM), which for UTF-8 is ABNF > %xEF.BB.BF. " > which remains a MUST to this day. There are no relevant Errata. > > Tom Petch This is something that seems to have made quite a lot of sense for=20 syslog. I can understand that if before 2005, syslog was used with=20 legacy encodings (iso-8859-1, Shift_JIS and similar), and there was=20 otherwise no easy way to label the UTF-8 strings. But another solution (for syslog, that is) would also have been=20 possible. As John already pointed out, UTF-8 is very easy to detect=20 heuristically: If a byte sequence follows the UTF-8 byte pattern, it's=20 most definitely UTF-8 and not something else. For more background,=20 please see http://www.sw.it.aoyama.ac.jp/2012/pub/IUC11-UTF-8.pdf, where=20 that idea came up first. As for JSON, it doesn't have the problem of legacy encodings. JSON by=20 definition is encoded in an Unicode encoding form, and it's easy to=20 distinguish these because of the restrictions on character sequences in=20 JSON. And this can be done without a BOM (or with a BOM). What's most important now is to know what receivers actually accept. We=20 are not in a design phase, we are just updating the definition of JSON=20 and making sure we fix problems if there are problems, but we have to=20 use the installed base for the main guidance, not other protocols or=20 formats. Regards, Martin. From petejson@codalogic.com Tue Nov 19 03:26:14 2013 Return-Path: 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 1A0D21ADF0E for ; Tue, 19 Nov 2013 03:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.237 X-Spam-Level: ** X-Spam-Status: No, score=2.237 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 tmXBeH-DnoI2 for ; Tue, 19 Nov 2013 03:26:12 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF371ADEDC for ; Tue, 19 Nov 2013 03:26:11 -0800 (PST) Received: (qmail 7542 invoked from network); 19 Nov 2013 11:25:47 +0000 Received: from host81-129-187-193.range81-129.btcentralplus.com (HELO codalogic) (81.129.187.193) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 19 Nov 2013 11:25:47 +0000 Message-ID: <07589B295EAC4DC59FD1FCE17F713C4E@codalogic> From: "Pete Cordell" To: "Phillip Hallam-Baker" References: <20131113224737.GI31823@mercury.ccil.org><5284B095.4070004@it.aoyama.ac.jp><5289F974.9020709@it.aoyama.ac.jp> X-Unsent: 1 Date: Tue, 19 Nov 2013 11:26:26 -0000 x-vipre-scanned: 00C9DABE005BDA00C9DC0B MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: JSON WG Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 11:26:14 -0000 Hi Philip, Could you explain further how these spurious BOMs are getting added in by MS in .Net? If you could come up with a small piece of C# code to demonstrate that would be great to help my understanding. Thanks, Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com ----- Original Message ----- From: "Phillip Hallam-Baker" To: "Pete Cordell" Cc: "Martin J. Dürst" ; "Henry S. Thompson" ; "John Cowan" ; "IETF Discussion" ; "JSON WG" ; "Anne van Kesteren" ; ; "es-discuss" Sent: Monday, November 18, 2013 8:56 PM Subject: Re: BOMs On Mon, Nov 18, 2013 at 8:36 AM, Pete Cordell wrote: > ----- Original Message ----- From: ""Martin J. Dürst"" < > duerst@it.aoyama.ac.jp> > > On 2013/11/18 20:11, Henry S. Thompson wrote: >> >>> Pete Cordell writes: >>> >>> Given the history below, would it be sensible to accept BOMs for UTF-8 >>>> encoding, but not for UTF-16 and UTF-32? In other words, are BOMs >>>> needed >>>> and/or used in the wild for UTF-16 and UTF-32? >>>> >>>> Maybe the text can say something like "SHOULD accept BOMs for UTF-8, >>>> and MAY accept BOMs for UTF-16 and / or UTF-32"? >>>> >>> >>> My sense is that you'll see more UTF-16 BOMs than anything else. >>> >> >> Yes indeed. BOM means Byte Order Mark. It's crucial for over-the-wire >> UTF-16. (It's irrelevant for in-memory UTF-16, but that's not what we are >> discussing.) >> > > The in-memory case is not entirely irrelevant because a number of JSON > messages will be constructed in memory and then squirted to line. > > I did a little experiment with Visual Studio. It will allow me to save in > UTF-8 with or without a BOM (like thing). Saving in UTF-16 (Or was it > UCS2?) is always with a BOM. There didn't seem to be a UTF-32 option. > > JSON doesn't need BOMs. However, there are cases where people might hand > edit messages, and if they choose to save in UTF-16 they will likely have > a > BOM. > > Is it acceptable to tell people not to save hand editted files in UTF-16, > suggesting UTF-8 (possibly with an encoded BOM) as an alternative? > > I would imagine that if someone did have a hand editted UTF-8 file on > Windows then the allowance of a BOM would help their sanity immeasurably, > but it's not something I have firsthand knowledge of. > I believe the opposite is true. The failure of Windows to correctly process documents without BOM markers is a constant pain trying to use .NET to parse XML. The ability to compose a JSON message by wrapping another JSON message is essential. That is, it has to be possible to write something like printf ("{\"Object\", %s}", Text); I use the .NET platform heavily. Please do not let Microsoft off the hook here. The cost of doing so is having to write code to kick out spurious BOM sequences occurring at any random point in the text. Which becomes really painful when having to deal with strings where there might actually be a reason to put the BOM in. The benefit of not doing so is that it might encourage Microsoft to fix their tools so that they don't insert spurious BOM sequences in documents where doing so breaks them. -- Website: http://hallambaker.com/ From derhoermi@gmx.net Tue Nov 19 04:31:13 2013 Return-Path: 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 636491ADF67 for ; Tue, 19 Nov 2013 04:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 LOi4pq6ypf1R for ; Tue, 19 Nov 2013 04:31:12 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2923C1ADF76 for ; Tue, 19 Nov 2013 04:31:11 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.62.159]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0LiTrM-1V8aIF1sa4-00cica for ; Tue, 19 Nov 2013 13:31:04 +0100 From: Bjoern Hoehrmann To: Tatu Saloranta Date: Tue, 19 Nov 2013 13:31:02 +0100 Message-ID: <8ulm89lpscd531fb7rbukksn6lar3jjf3g@hive.bjoern.hoehrmann.de> References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <2tuj89hcus182t4f4rqqgi1dpabt11qak7@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:f99n/X7eT6JNlB4q+kprT0nOSGxs5gfTy7xzHNrPyLD4AjbMbZJ /KoDLq8uRBHaFj84XVfmGKeXT755q5WYUq2mp7pYi8r476GRnqIS3rcAPa45RTb/x9LtLyQ BsXA1Rc6mwQpGmlUh0BDQnGTQlt0tE3zD48+OO4YPkjNRNX8TW5BOwKIgj+QcTBMxr8affV VPQOdKrioSG4ES7XZUaFg== Cc: Anne van Kesteren , es-discuss , IETF Discussion , "www-tag@w3.org" , JSON WG Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 12:31:13 -0000 * Tatu Saloranta wrote: >Dominant Java implementations support UTF-16 with BOM; either directly or >through Java's Reader implementations that handle BOMs. >String concatenation case seems irrelevant, since BOMs are not included in >in-memory representation anyway, as opposed to byte stream serialization. HTTP implementations cannot correctly determine whether an entity body is text in a single character encoding and if so what that encoding is, accordingly the dominant API deals in byte[] arrays, not text Strings; furthermore, many programming languages default to byte[] arrays for string literals. That often combines into forms of byte[] json = sprintf('{"x": %s, "y": %s}', GET(...), GET(...)); which works fine if all three byte[] arrays are UTF-8 encoded and use no Unicode signature, which is the case 99% of the time. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From daedulus@btconnect.com Tue Nov 19 02:13:54 2013 Return-Path: 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 D36081AD8EE; Tue, 19 Nov 2013 02:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 Up3Sv9GJfU3D; Tue, 19 Nov 2013 02:13:53 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8F75E1AD8F1; Tue, 19 Nov 2013 02:13:52 -0800 (PST) Received: from mail121-db9-R.bigfish.com (10.174.16.228) by DB9EHSOBE037.bigfish.com (10.174.14.100) with Microsoft SMTP Server id 14.1.225.22; Tue, 19 Nov 2013 10:13:45 +0000 Received: from mail121-db9 (localhost [127.0.0.1]) by mail121-db9-R.bigfish.com (Postfix) with ESMTP id AE906460572; Tue, 19 Nov 2013 10:13:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(z569dhzbb2dI98dI9371Ic89bh542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh2a8h5a9h839h93fhd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h304l1d11m1155h) Received: from mail121-db9 (localhost.localdomain [127.0.0.1]) by mail121-db9 (MessageSwitch) id 1384856022689400_19253; Tue, 19 Nov 2013 10:13:42 +0000 (UTC) Received: from DB9EHSMHS018.bigfish.com (unknown [10.174.16.253]) by mail121-db9.bigfish.com (Postfix) with ESMTP id 9941842011C; Tue, 19 Nov 2013 10:13:42 +0000 (UTC) Received: from AMSPRD0710HT004.eurprd07.prod.outlook.com (157.56.249.85) by DB9EHSMHS018.bigfish.com (10.174.14.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 19 Nov 2013 10:13:38 +0000 Received: from AMXPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.160.167) with Microsoft SMTP Server (TLS) id 14.16.383.1; Tue, 19 Nov 2013 10:13:37 +0000 Message-ID: <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> From: t.p. To: =?utf-8?Q?Martin_J._D=C3=BCrst?= References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> Date: Tue, 19 Nov 2013 10:10:47 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Tue, 19 Nov 2013 06:22:13 -0800 Cc: John Cowan , IETF Discussion , Pete Cordell , JSON WG , Anne van Kesteren , www-tag@w3.org, es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 10:13:54 -0000 ----- Original Message ----- From: "Martin J. D=C3=BCrst" To: "Henry S. Thompson" Cc: "John Cowan" ; "IETF Discussion" ; "Pete Cordell" ; "JSON WG" ; "Anne van Kesteren" ; ; "es-discuss" Sent: Monday, November 18, 2013 11:26 AM > On 2013/11/18 20:11, Henry S. Thompson wrote: > > Pete Cordell writes: > > > >> Given the history below, would it be sensible to accept BOMs for UTF-8 > >> encoding, but not for UTF-16 and UTF-32? In other words, are BOMs needed > >> and/or used in the wild for UTF-16 and UTF-32? > >> > >> Maybe the text can say something like "SHOULD accept BOMs for UTF-8, > >> and MAY accept BOMs for UTF-16 and / or UTF-32"? > > > > My sense is that you'll see more UTF-16 BOMs than anything else. > > Yes indeed. BOM means Byte Order Mark. It's crucial for over-the-wire > UTF-16. (It's irrelevant for in-memory UTF-16, but that's not what we > are discussing.) To bring up the XML example again, XML actually > strictly requires a BOM for UTF-16. The IETF definition of UTF-16 does > not require a BOM for UTF-16. See http://tools.ietf.org/html/rfc2781, in > particular http://tools.ietf.org/html/rfc2781#section-3.2, > http://tools.ietf.org/html/rfc2781#section-3.3, and > http://tools.ietf.org/html/rfc2781#section-4. > > For UTF-8, the BOM is not a Byte Order Mark, because such a mark isn't > necessary at all. It may serve as a signature, but is not necessary, and > in some circumstances counterproductive. Martin We had a similar discussion with syslog back in 2005, the issue being that UTF-8 was new and different and how to tell whether it was being used or not, and what made it into RFC5424 was " If a syslog application encodes MSG in UTF-8, the string MUST start with the Unicode byte order mask (BOM), which for UTF-8 is ABNF %xEF.BB.BF. " which remains a MUST to this day. There are no relevant Errata. Tom Petch > As for what to say about whether to accept BOMs or not, I'd really want > to know what the various existing parsers do. If they accept BOMs, then > we can say they should accept BOMs. If they don't accept BOMs, then we > should say that they don't. > > Regards, Martin. > > > UTF-32 support seems to be waning (at least in the browsers), but > > UTF-16 is in pretty widespread use. John, do you think you can fool > > google into counting BOMs for us? > > From allen@wirfs-brock.com Tue Nov 19 08:59:53 2013 Return-Path: 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 ECCB41AE0EC; Tue, 19 Nov 2013 08:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 2L4CHNkedwNZ; Tue, 19 Nov 2013 08:59:51 -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 0DD2A1AE0E5; Tue, 19 Nov 2013 08:59:50 -0800 (PST) Received: from [156.39.10.22] (helo=[10.45.151.55]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1VioeL-0008FY-QQ; Tue, 19 Nov 2013 16:59:42 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 156.39.10.22 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX184+q+4QPxmJyIInJxfAfgzeGjv6cdZcN0= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-24-698767587 From: Allen Wirfs-Brock In-Reply-To: <528B46EA.4040503@it.aoyama.ac.jp> Date: Tue, 19 Nov 2013 08:59:36 -0800 Message-Id: <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1085) Cc: John Cowan , IETF Discussion , Pete Cordell , JSON WG , www-tag@w3.org, Anne van Kesteren , "t.p." , es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 16:59:53 -0000 --Apple-Mail-24-698767587 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 19, 2013, at 3:09 AM, Martin J. D=C3=BCrst wrote: > ... > As for JSON, it doesn't have the problem of legacy encodings. JSON by = definition is encoded in an Unicode encoding form, and it's easy to = distinguish these because of the restrictions on character sequences in = JSON. And this can be done without a BOM (or with a BOM). >=20 > What's most important now is to know what receivers actually accept. = We are not in a design phase, we are just updating the definition of = JSON and making sure we fix problems if there are problems, but we have = to use the installed base for the main guidance, not other protocols or = formats. There can be no doubt that the most widely deployed JSON parsers are = those that are built intp the browser javascript implementations. The = ECMAScript 5 specification for JSON.parse that they implement says BOM = is an illegal character. But what do the browser actually implement? = This: //FireFox 25 scratchpad execution: JSON.parse('\ufeff {"abc": 0} ') /* Exception: JSON.parse: unexpected character @Scratchpad/1:1 */ JSON.parse('\ufeff {"abc": 0} ') /* Exception: JSON.parse: unexpected character @Scratchpad/1:1 */ JSON.parse('\ufeff {"abc": 0} ') /* Exception: JSON.parse: unexpected character @Scratchpad/1:1 */ JSON.parse('\ufeff {"abc": 0} ') /* Exception: JSON.parse: unexpected character @Scratchpad/1:1 */ JSON.parse('\ufeff {"abc": 0} ') /* Exception: JSON.parse: unexpected character @Scratchpad/1:1 */ //Safari 5.1.9 JS console JSON.parse('\ufeff {"abc": 0} ') message: "JSON Parse error: Unrecognized token '?'" //Chrome 31 JS console JSON.parse('\ufeff {"abc": 0} ') SyntaxError: Unexpected token =EF=BB=BF message: "Unexpected token =EF=BB=BF" Unfortunately, I don't have access to IE right now, but the trend is = clear Allen --Apple-Mail-24-698767587 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
...
As for JSON, = it doesn't have the problem of legacy encodings. JSON by definition is = encoded in an Unicode encoding form, and it's easy to distinguish these = because of the restrictions on character sequences in JSON. And this can = be done without a BOM (or with a BOM).

What's most important now = is to know what receivers actually accept. We are not in a design phase, = we are just updating the definition of JSON and making sure we fix = problems if there are problems, but we have to use the installed base = for the main guidance, not other protocols or = formats.

There can be no doubt that = the most widely deployed JSON parsers are those that are built intp the = browser javascript implementations.  The ECMAScript 5 specification = for JSON.parse that they implement says BOM is an illegal character. =  But what do the browser actually implement? =  This:

//FireFox 25 scratchpad = execution:
JSON.parse('\ufeff {"abc": 0} ')
/*
Exception: =
JSON.parse: unexpected =
character
@Scratchpad/1:1
*/

JSON.parse('\ufeff {"abc": 0} =
')
/*
Exception: JSON.parse: unexpected =
character
@Scratchpad/1:1
*/

JSON.parse('\ufeff {"abc": 0} =
')
/*
Exception: JSON.parse: unexpected =
character
@Scratchpad/1:1
*/
JSON.parse('\ufeff {"abc": 0} =
')
/*
Exception: JSON.parse: unexpected =
character
@Scratchpad/1:1
*/
JSON.parse('\ufeff = {"abc": 0} ')
/*
Exception: JSON.parse: unexpected = character
@Scratchpad/1:1
*/

//Safari 5.1.9 JS console
    message: "JSON Parse error: Unrecognized = token '?'"

//Chrome 31 JS console
    JSON.parse('\ufeff {"abc": 0} ')
    SyntaxError: Unexpected token =EF=BB=BF
    1. message: "Unexpected token =EF=BB=BF"

    Unfortunately, I don't have access to IE right now, =  but the trend is clear

    Allen
    , JSON WG Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 18:30:56 -0000 --089e0102fb5c0379ef04eb8bdd89 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 19, 2013 at 4:31 AM, Bjoern Hoehrmann wrote: > * Tatu Saloranta wrote: > >Dominant Java implementations support UTF-16 with BOM; either directly or > >through Java's Reader implementations that handle BOMs. > >String concatenation case seems irrelevant, since BOMs are not included in > >in-memory representation anyway, as opposed to byte stream serialization. > > HTTP implementations cannot correctly determine whether an entity body > is text in a single character encoding and if so what that encoding is, > accordingly the dominant API deals in byte[] arrays, not text Strings; > furthermore, many programming languages default to byte[] arrays for > string literals. That often combines into forms of > > byte[] json = sprintf('{"x": %s, "y": %s}', GET(...), GET(...)); > > which works fine if all three byte[] arrays are UTF-8 encoded and use > no Unicode signature, which is the case 99% of the time. > My point was just that although it appears that many scripting languages may not deal with BOM properly, same is not true on all platforms. Proper JSON APIs on JVM do accept both String and byte[] based input; byte[] being preferred since it is more efficient, and reliably with auto-detection, assuming that -- as per JSON specification -- the only single-byte encoding used is UTF-8. -+ Tatu +- --089e0102fb5c0379ef04eb8bdd89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Tue, Nov 19, 2013 at 4:31 AM, Bjoern Hoehrmann <derhoe= rmi@gmx.net> wrote:
    * Tatu Saloranta wrote: >Dominant Java implementations support UTF-16 with BOM; either directly = or
    >through Java's Reader implementations that handle BOMs.
    >String concatenation case seems irrelevant, since BOMs are not included= in
    >in-memory representation anyway, as opposed to byte stream serializatio= n.

    HTTP implementations cannot correctly determine whether an entity bod= y
    is text in a single character encoding and if so what that encoding is,
    accordingly the dominant API deals in byte[] arrays, not text Strings;
    furthermore, many programming languages default to byte[] arrays for
    string literals. That often combines into forms of

    =A0 byte[] json =3D sprintf('{"x": %s, "y": %s}'= ;, GET(...), GET(...));

    which works fine if all three byte[] arrays are UTF-8 encoded and use
    no Unicode signature, which is the case 99% of the time.

    My point was just that although it appears that many scri= pting languages may not deal with BOM properly, same is not true on all pla= tforms. Proper JSON APIs on JVM do accept both String and byte[] based inpu= t; byte[] being preferred since it is more efficient, and reliably with aut= o-detection, assuming that -- as per JSON specification -- the only single-= byte encoding used is UTF-8.

    -+ Tatu +-
    --089e0102fb5c0379ef04eb8bdd89-- From ht@inf.ed.ac.uk Tue Nov 19 10:56:04 2013 Return-Path: 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 06E5E1AE14F; Tue, 19 Nov 2013 10:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 KMDGHsorvewV; Tue, 19 Nov 2013 10:56:01 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5052B1AE14C; Tue, 19 Nov 2013 10:56:00 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAJItYJw003066; Tue, 19 Nov 2013 18:55:35 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAJItVBF026895; Tue, 19 Nov 2013 18:55:32 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAJItWKm016412; Tue, 19 Nov 2013 18:55:32 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAJItT7F016408; Tue, 19 Nov 2013 18:55:29 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Allen Wirfs-Brock References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 19 Nov 2013 18:55:29 +0000 In-Reply-To: <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> (Allen Wirfs-Brock's message of "Tue\, 19 Nov 2013 08\:59\:36 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 X-Mailman-Approved-At: Tue, 19 Nov 2013 11:02:27 -0800 Cc: John Cowan , IETF Discussion , Pete Cordell , JSON WG , www-tag@w3.org, "Martin J. =?iso-8859-1?Q?D=FCrst?=" , Anne van Kesteren , "t.p." , es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 18:56:04 -0000 Allen Wirfs-Brock writes: > There can be no doubt that the most widely deployed JSON parsers are > those that are built intp the browser javascript implementations. > The ECMAScript 5 specification for JSON.parse that they implement > says BOM is an illegal character. But what do the browser actually > implement? This: No, try e.g. jsonviewer.stack.hu [1] (works in Chrome, Safari, Opera, not in IE or Firefox) or feed [2] to www.jsoneditoronline.org (Use Open/Url) (works in Chrome, IE, Firefox, ran out of time to test more). As previously discussed, _no-one_ is arguing that BOMs are in the JSON language as such. JSON parsers shouldn't accept BOMs. BOMs are, to quote the UNICODE spec, "not part of the text". It is appropriate that specs concerned with JSON-on-the-wire, for example the media type registration for 'application/json', _should_ discuss the BOM, and it's open to them, _without changing the language at all_, to say that BOMs are acceptable but, again, are not part of the text which the parser has to accept. ht [1] http://jsonviewer.stack.hu/#http://www.ltg.ed.ac.uk/~ht/ov-test/b16le.json -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nico@cryptonector.com Tue Nov 19 11:04:18 2013 Return-Path: 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 BFC031AE156; Tue, 19 Nov 2013 11:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] 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 23Y6rXRDWyTc; Tue, 19 Nov 2013 11:04:18 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 00A011AE13A; Tue, 19 Nov 2013 11:04:17 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id E9B2B27BC075; Tue, 19 Nov 2013 11:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=1IEY9XO83wQa3M9RmPqtQa3XWaA=; b=hPKqyvk+rsL jo74NZQBWddC8QHPSFa0EF++E8BPz7bC8EanXccofUn4ARLvLQrdkuNHlPKkh68a U7ejYZtQBN9au1DTtZgHDpD61rDzQysmiBkiP/FEvS2PFU3fCwbIjIjwzuXYbbfb TOmQNebH7Jp62iFF8msA0GLOr053RqzQ= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 4AFE327BC06F; Tue, 19 Nov 2013 11:04:10 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id q58so2361328wes.19 for ; Tue, 19 Nov 2013 11:04:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=YVlUAzlZ3vCBcs0ha3P6CWwte5nLfAVFDleWV++LGCY=; b=QoaPkdG0D8yYE+74pFl9MkUfs7JFbQrEYRMTQ2gTumTJ2KpXbJYm/SqpwDvfbvyzt3 OwnzgUiDRTQssZYcreI0BddMedEHQeNxkz3iKHBxZJV4fqhJ789b8dlf3gtEl/zzxeU+ nH3BgREgSp3hIPtjIn5J56BLdea93kHvxNKiuttS0BbEjUqfSIkG7wBsY/lVy+Dj1qFh CSqnSYRt95iQt789F8aHZYrMkJBLVUzTDu+2cbGu4FTPuyyuewSWpheir2AXCyrOnPMf mZ1R00fl+GGX8KVVktUT4mMgg305WTmaBalb4YWc7TD0xg2ZFriuIeHh/MG4gJp2sjIj ja9A== MIME-Version: 1.0 X-Received: by 10.194.20.202 with SMTP id p10mr3234877wje.39.1384887841823; Tue, 19 Nov 2013 11:04:01 -0800 (PST) Received: by 10.216.151.136 with HTTP; Tue, 19 Nov 2013 11:04:01 -0800 (PST) Date: Tue, 19 Nov 2013 13:04:01 -0600 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: Anne van Kesteren , es-discuss , IETF Discussion , www-tag@w3.org, JSON WG Subject: [Json] Consensus re: top-level value restriction (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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 19:04:19 -0000 Wait, so now we have consensus for removing the top-level value restriction in the RFC and instead documenting the interop difference between IETF and ECMAScript JSON? That's what it sounds like to me. If so, thank goodness, we've around to the correct approach. Almost too late (and after earlier rejections that seemed much too out of hand to me, but hey, all's well that ends well), but not quite too late. Or, if the consensus is simply merely no longer clear, shouldn't we have a new consensus call on this? Nico -- From jhildebr@cisco.com Tue Nov 19 12:24:45 2013 Return-Path: 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 4CE181AE1A7; Tue, 19 Nov 2013 12:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.126 X-Spam-Level: X-Spam-Status: No, score=-14.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Jsaz_IsGcshR; Tue, 19 Nov 2013 12:24:43 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A76981AE194; Tue, 19 Nov 2013 12:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2787; q=dns/txt; s=iport; t=1384892678; x=1386102278; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bQfSUHdZT53i6/2USkmtuUORpqsyL8OB25fRlSbB5dg=; b=c8GHdwIIQO8QPvMyfjZS5yBQgjg0BXo+FIPGFZZZdsEWM0puTpSWsA3t KgIXeTniy3sZZ0NlQFV2XL3KICjhdefBKlGB9npOnYnKLqYgpK2CJsY6q 6jVNAzqoePawdDHGXmLL02cm2PpSFFmK0jsYbZSTklwu9oG9bEli/Y19p E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAHPIi1KtJV2c/2dsb2JhbABZDoJ5gQu/QIEhFnSCLHkSAQh4JQIEAQ0FiAG/a48sKweEMgOJCo8Ikg2CaT+CKg X-IronPort-AV: E=Sophos;i="4.93,731,1378857600"; d="scan'208";a="286182639" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 19 Nov 2013 20:24:37 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAJKObbb016841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 20:24:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 14:24:37 -0600 From: "Joe Hildebrand (jhildebr)" To: Allen Wirfs-Brock , =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= Thread-Topic: [Json] BOMs Thread-Index: AQHO5RfnGj7BmRODlUiLjKTcc3gdlpotK9kAgABKCYA= Date: Tue, 19 Nov 2013 20:24:36 +0000 Message-ID: In-Reply-To: <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.121.67] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <854AC8C2FCA3A940AAC7F719D3E3C254@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 19 Nov 2013 12:28:40 -0800 Cc: John Cowan , IETF Discussion , Pete Cordell , JSON WG , "t.p." , Anne van Kesteren , "www-tag@w3.org" , es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 20:24:45 -0000 I've been back and forth on this several times, however I think I've come to a conclusion for myself unless new arguments or data comes in. I don't see any value in a BOM ever being included intentionally. RFC4627 does not specify anything about BOMs. RFC4627 explicitly has a mechanism for determining encoding that does not use BOMs. Although ECMA-262 supports more whitespace than RFC4627, is not one of the supported whitespace characters in my reading. Same with ECMA-404. Many existing implementations do not parse BOM-prepended text in practice (thanks Allen).=20 I understand the use case of manually creating a document in notepad and getting a BOM you didn't expect, but I don't think that's a compelling enough reason to break backward-compatibility by adding effectively-new blessings for BOMs. Section 9 provides complete air-cover for any parser writer that wants to support BOMs anyway: "A JSON parser MAY accept non-JSON forms or extensions." What they do with them, particularly when they don't match the encoding detection of section 8.1 would of course be unspecified, but those documents would have been rejected by a strictly-conforming parser anyway. As such, I think our best course of action is to change nothing with respect to BOMs, leaving them as non-interoperable syntax extensions. On 11/19/13 5:59 PM, "Allen Wirfs-Brock" wrote: >There can be no doubt that the most widely deployed JSON parsers are >those that are built intp the browser javascript implementations. The >ECMAScript 5 specification for JSON.parse that they implement says BOM is >an illegal character. But what do the > browser actually implement? This: > > >//FireFox 25 scratchpad execution: >JSON.parse('\ufeff {"abc": 0} ') >/* >Exception: JSON.parse: unexpected character >@Scratchpad/1:1 >*/ > >JSON.parse('\ufeff {"abc": 0} ') >/* >Exception: JSON.parse: unexpected character >@Scratchpad/1:1 >*/ > >JSON.parse('\ufeff {"abc": 0} ') >/* >Exception: JSON.parse: unexpected character >@Scratchpad/1:1 >*/JSON.parse('\ufeff {"abc": 0} ') >/* >Exception: JSON.parse: unexpected character >@Scratchpad/1:1 >*/JSON.parse('\ufeff {"abc": 0} ') >/* >Exception: JSON.parse: unexpected character >@Scratchpad/1:1 >*/ > > > > > > > >//Safari 5.1.9 JS console >JSON.parse('\ufeff {"abc": 0} ') > >1. message: "JSON > Parse error: Unrecognized token '?'" > > > >//Chrome 31 JS console >JSON.parse('\ufeff > {"abc": 0} ') >1.=20 > > >SyntaxError: Unexpected token > > >1. message: "Unexpected > token " > > > >Unfortunately, > I don't have access to IE right now, but the trend is clear > > >Allen > > > > > > > > --=20 Joe Hildebrand From chris@w3.org Tue Nov 19 13:32:08 2013 Return-Path: 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 A031C1AE201; Tue, 19 Nov 2013 13:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 4sMBATYC1qtV; Tue, 19 Nov 2013 13:32:07 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 027C81AE1FA; Tue, 19 Nov 2013 13:32:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=M6700) by jay.w3.org with esmtpa (Exim 4.72) (envelope-from ) id 1Vistk-0006JQ-2C; Tue, 19 Nov 2013 16:31:52 -0500 Date: Tue, 19 Nov 2013 08:13:37 +0100 From: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <1988085269.20131119081337@w3.org> To: Bjoern Hoehrmann In-Reply-To: <626k89plqltbqd5uqgo15krutbn38qa909@hive.bjoern.hoehrmann.de> References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <2tuj89hcus182t4f4rqqgi1dpabt11qak7@hive.bjoern.hoehrmann.de> <626k89plqltbqd5uqgo15krutbn38qa909@hive.bjoern.hoehrmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Nov 2013 13:37:33 -0800 Cc: "Henry S. Thompson" , JSON WG , Anne van Kesteren , es-discuss , "=?iso-8859-1?Q?Martin_J._D=FCrst?=" , www-tag@w3.org, IETF Discussion Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 21:32:08 -0000 Hello Bjoern, Monday, November 18, 2013, 2:48:19 PM, you wrote: > In other words, always passing a UTF-8 encoded byte string to the byte > string parsing part of the JSON implementation. Yes, a byte stream will contain a BOM if one is present. > RFC 4627 is the only > specification for the application/json on-the-wire format and it does > not mention anything about Unicode signatures. Looking for certain byte > sequences at the beginning and treating them as a Unicode signature is > the same as looking for `/* ... */` and treating it as a comment. No, because /* */ are characters and are found in a character stream. And a character stream does not contain a BOM as a BOM is not character data. RFC 4627 doesn't need to say this, because Unicode says it. If JSON mixes up characters and bytes there will of course be confusion. But hopefully it doesn't, as this is not 1990 anymore. -- Best regards, Chris mailto:chris@w3.org From petejson@codalogic.com Wed Nov 20 03:44:33 2013 Return-Path: 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 8E48D1AD73F for ; Wed, 20 Nov 2013 03:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.837 X-Spam-Level: *** X-Spam-Status: No, score=3.837 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 HKpu0XNFsSxE for ; Wed, 20 Nov 2013 03:44:32 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 796A91ADBFF for ; Wed, 20 Nov 2013 03:44:31 -0800 (PST) Received: (qmail 22106 invoked from network); 20 Nov 2013 11:44:04 +0000 Received: from host81-129-187-193.range81-129.btcentralplus.com (HELO codalogic) (81.129.187.193) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 20 Nov 2013 11:44:04 +0000 Message-ID: <8A41EDC97C8243A39CED3D08964C27FD@codalogic> From: "Pete Cordell" To: =?iso-8859-1?Q?Martin_J._D=FCrst?= , "Henry S. Thompson" References: <20131113224737.GI31823@mercury.ccil.org><5284B095.4070004@it.aoyama.ac.jp><5289F974.9020709@it.aoyama.ac.jp><020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net><528B46EA.4040503@it.aoyama.ac.jp><43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com><528C5445.3050600@it.aoyama.ac.jp> X-Unsent: 1 Date: Wed, 20 Nov 2013 11:45:35 -0000 x-vipre-scanned: 00DDBA92005BF800DDBBDF MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: www-tag@w3.org, JSON WG Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 11:44:33 -0000 ----- Original Message From: "Henry S. Thompson" > I agree that XML is a useful point of comparison, in particular > because it too does not allow a BOM as part of an XML document, but > rather treats it as an aspect of packaging/transport external to the > XML document, which seems to me to be the kind of approach to BOMs the > JSON WG might consider. If I remember rightly, XML demotes notes about encoding detection and BOMs to a rather lowly (informational?) appendix. Maybe that's something JSON should do in the interests of interoperability (AKA avoidance of confusion - which there seems to be a lot of). Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From ht@inf.ed.ac.uk Wed Nov 20 04:04:18 2013 Return-Path: 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 483921ADE88 for ; Wed, 20 Nov 2013 04:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 BeKl6VGfZXZC for ; Wed, 20 Nov 2013 04:04:15 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3171ADE7C for ; Wed, 20 Nov 2013 04:04:14 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAKC3p8t029244; Wed, 20 Nov 2013 12:03:51 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAKC3oTr004114; Wed, 20 Nov 2013 12:03:50 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAKC3pdF001502; Wed, 20 Nov 2013 12:03:51 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAKC3nLd001491; Wed, 20 Nov 2013 12:03:49 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "Pete Cordell" References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> <8A41EDC97C8243A39CED3D08964C27FD@codalogic> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 20 Nov 2013 12:03:49 +0000 In-Reply-To: <8A41EDC97C8243A39CED3D08964C27FD@codalogic> (Pete Cordell's message of "Wed\, 20 Nov 2013 11\:45\:35 -0000") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= , www-tag@w3.org, JSON WG Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:04:18 -0000 Pete Cordell writes: > ----- Original Message From: "Henry S. Thompson" > >> I agree that XML is a useful point of comparison, in particular >> because it too does not allow a BOM as part of an XML document, but >> rather treats it as an aspect of packaging/transport external to the >> XML document, which seems to me to be the kind of approach to BOMs the >> JSON WG might consider. > > > If I remember rightly, XML demotes notes about encoding detection and > BOMs to a rather lowly (informational?) appendix. Maybe that's > something JSON should do in the interests of interoperability (AKA > avoidance of confusion - > which there seems to be a lot of). There is indeed a non-normative appendix [1] which gives implementation advice. But there is also a normative section [2] which, _inter alia_ makes a BOM a requirement in certain circumstances. ht [1] http://www.w3.org/TR/REC-xml/#sec-guessing [2] http://www.w3.org/TR/REC-xml/#charencoding -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From duerst@it.aoyama.ac.jp Tue Nov 19 22:19:29 2013 Return-Path: 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 463061AE338; Tue, 19 Nov 2013 22:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.984 X-Spam-Level: X-Spam-Status: No, score=0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.525] 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 QWQTEHBNYf42; Tue, 19 Nov 2013 22:19:27 -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 F1C4D1AE336; Tue, 19 Nov 2013 22:19:26 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAK6J0Vl017383; Wed, 20 Nov 2013 15:19:00 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 28e9_f0ec_a512753c_51ab_11e3_97e8_001e6722eec2; Wed, 20 Nov 2013 15:18:59 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 90E81BF4CD; Wed, 20 Nov 2013 15:18:59 +0900 (JST) Message-ID: <528C5445.3050600@it.aoyama.ac.jp> Date: Wed, 20 Nov 2013 15:18:45 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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: "Henry S. Thompson" References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 Nov 2013 04:39:38 -0800 Cc: Allen Wirfs-Brock , John Cowan , IETF Discussion , Pete Cordell , JSON WG , www-tag@w3.org, Anne van Kesteren , "t.p." , es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 06:19:29 -0000 Hello Henry, others, On 2013/11/20 3:55, Henry S. Thompson wrote: > Allen Wirfs-Brock writes: > >> There can be no doubt that the most widely deployed JSON parsers are >> those that are built intp the browser javascript implementations. >> The ECMAScript 5 specification for JSON.parse that they implement >> says BOM is an illegal character. But what do the browser actually >> implement? This: > > No, try e.g. jsonviewer.stack.hu [1] (works in Chrome, Safari, Opera, > not in IE or Firefox) In Firefox, I got some garbled characters, in particular some question marks for each of the two bytes of the BOM and one question mark for the e-acute. Because of the type of the errors, I strongly suspect it is related to what we are trying to investigate, and so I don't think this can be taken as evidence one way or another. or feed [2] to www.jsoneditoronline.org (Use > Open/Url) (works in Chrome, IE, Firefox, ran out of time to test more). The fact that some libraries or Web sites accept a BOM for JSON isn't a proof that all (well, let's say the majority) accept a BOM. > As previously discussed, _no-one_ is arguing that BOMs are in the JSON > language as such. JSON parsers shouldn't accept BOMs. > > BOMs are, to quote the UNICODE spec, "not part of the text". It is > appropriate that specs concerned with JSON-on-the-wire, for example > the media type registration for 'application/json', _should_ discuss > the BOM, and it's open to them, _without changing the language at > all_, to say that BOMs are acceptable but, again, are not part of the > text which the parser has to accept. I agree that *from a theoretical viewpoint*, this is correct. But theory isn't everything. As I have written before (and you have cited in another thread, for another spec): What's most important now is to know what receivers actually accept. We are not in a design phase, we are just updating the definition ... and making sure we fix problems if there are problems, but we have to use the installed base for the main guidance For our update from RFC 4627, the null hypothesis is that there are no BOMs (neither for UTF-8 nor for UTF-16). The patterns given in http://tools.ietf.org/html/rfc4627#section-3 cannot apply to characters, they can only apply to bytes. If we want to allow a spec in application/json, then we have to have strong evidence that almost all parsers can deal with BOMs, not just fragmentary evidence that some parsers don't choke on a BOM. Please note that there's some parallel to XML, in that neither Unicode (for the encoding form) nor the IETF (for the 'charset') require a BOM for "UTF-16", but XML nevertheless strictly requires it. Regards, Martin. > ht > > [1] http://jsonviewer.stack.hu/#http://www.ltg.ed.ac.uk/~ht/ov-test/b16le.json From ht@inf.ed.ac.uk Wed Nov 20 02:30:15 2013 Return-Path: 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 7E72F1ADBCA; Wed, 20 Nov 2013 02:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.826 X-Spam-Level: X-Spam-Status: No, score=-3.826 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 0bbwwzAXOPey; Wed, 20 Nov 2013 02:30:12 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id EA5BE1AE3C1; Wed, 20 Nov 2013 02:30:11 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAKATd93012524; Wed, 20 Nov 2013 10:29:43 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAKATas3032549; Wed, 20 Nov 2013 10:29:37 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAKATbjj032038; Wed, 20 Nov 2013 10:29:37 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAKATZ2G032034; Wed, 20 Nov 2013 10:29:35 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 20 Nov 2013 10:29:35 +0000 In-Reply-To: <528C5445.3050600@it.aoyama.ac.jp> ("Martin J. =?iso-8859-1?Q?D=FCrst=22's?= message of "Wed\, 20 Nov 2013 15\:18\:45 +0900") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 X-Mailman-Approved-At: Wed, 20 Nov 2013 04:39:38 -0800 Cc: Allen Wirfs-Brock , John Cowan , IETF Discussion , Pete Cordell , JSON WG , www-tag@w3.org, Anne van Kesteren , "t.p." , es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 10:30:15 -0000 Martin J. D=FCrst writes: > Hello Henry, others, > > The fact that some libraries or Web sites accept a BOM for JSON isn't > a proof that all (well, let's say the majority) accept a BOM. I wasn't suggesting that it did, rather that the kind of testing that needed to be done was testing that included the interface between transport and parser, not parser alone, since, as we are all agreed, the BOM is not allowed by the language itself. >> As previously discussed, _no-one_ is arguing that BOMs are in the JSON >> language as such. JSON parsers shouldn't accept BOMs. >> >> BOMs are, to quote the UNICODE spec, "not part of the text". It is >> appropriate that specs concerned with JSON-on-the-wire, for example >> the media type registration for 'application/json', _should_ discuss >> the BOM, and it's open to them, _without changing the language at >> all_, to say that BOMs are acceptable but, again, are not part of the >> text which the parser has to accept. > > I agree that *from a theoretical viewpoint*, this is correct. But > theory isn't everything. As I have written before (and you have cited > in another thread, for another spec): > > What's most important now is to know what receivers actually > accept. We are not in a design phase, we are just updating the > definition ... and making sure we fix problems if there are > problems, but we have to use the installed base for the main > guidance > > For our update from RFC 4627, the null hypothesis is that there are no > BOMs (neither for UTF-8 nor for UTF-16). The patterns given in > http://tools.ietf.org/html/rfc4627#section-3 cannot apply to > characters, they can only apply to bytes. If we want to allow a spec > in application/json, then we have to have strong evidence that almost > all parsers can deal with BOMs, not just fragmentary evidence that > some parsers don't choke on a BOM. I'm not suggesting parsers should allow BOMs, if by parser you mean what implements the grammar of the language. And I'm certainly not suggesting that two examples pulled at random from a Google search constitute strong evidence about practice at large. All I was trying to suggest was that showing that the language parser as such in Firefox etc.didn't allow BOMs, as the OP had done, was the right kind of evidence _either_. > Please note that there's some parallel to XML, in that neither Unicode > (for the encoding form) nor the IETF (for the 'charset') require a BOM > for "UTF-16", but XML nevertheless strictly requires it. I agree that XML is a useful point of comparison, in particular because it too does not allow a BOM as part of an XML document, but rather treats it as an aspect of packaging/transport external to the XML document, which seems to me to be the kind of approach to BOMs the JSON WG might consider. ht --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] From hallam@gmail.com Wed Nov 20 08:09:42 2013 Return-Path: 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 DD0E71AE022 for ; Wed, 20 Nov 2013 08:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Y4WqXDzYER3V for ; Wed, 20 Nov 2013 08:09:40 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8835D1ADF8E for ; Wed, 20 Nov 2013 08:09:40 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id eo20so1431397lab.0 for ; Wed, 20 Nov 2013 08:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/EqykfKXnH+JFQKVZpsucK1Ygoe/HPEmxiXfRhcpUAI=; b=H5UV+LYb4QgKJbA2T52f5PLva453sHEb5suycpAUG5qVdVM8tjaHWIzHr2OIDZzD9e C/XV7cYYiDRhUJLmESIRazBmZBNdy1lWxn1m9dNr7wRdnSQ05UZCRqFz8PDWFsODwOvG oTQabJGgi8dbZWBoCivpaNJZuuDoZxf5MNQ3/e/ylMr7/Ojki31elLz8oPvgO8Boi2xO dRWFY9bHGSdip6V03TuIrFIjNcwWwariuEPin5DiHm9uVO1RKDnRfyapZGaOq0BCDlXF vHcKqYQLY3g6onLAT9QXKmberplnaZrIloi74OFpZ3BVdbdPpw+tK8N8k+v6lIDKNKqT +gnQ== MIME-Version: 1.0 X-Received: by 10.112.218.39 with SMTP id pd7mr225843lbc.54.1384963773342; Wed, 20 Nov 2013 08:09:33 -0800 (PST) Received: by 10.112.46.98 with HTTP; Wed, 20 Nov 2013 08:09:33 -0800 (PST) Date: Wed, 20 Nov 2013 11:09:33 -0500 Message-ID: From: Phillip Hallam-Baker To: JSON WG Content-Type: multipart/alternative; boundary=001a11c3cdc8bcab6304eb9e0191 X-Mailman-Approved-At: Wed, 20 Nov 2013 08:40:13 -0800 Subject: [Json] Using JSON in log files X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 16:09:43 -0000 --001a11c3cdc8bcab6304eb9e0191 Content-Type: text/plain; charset=ISO-8859-1 The biggest technical blunder in JSON right now is the insistence that there only be one object in a file. XML suffers from the same blunder, here is why. If you have a log file and it is being updated by multiple processes, there is potential for contention between the updates. The simplest mechanism for resolving that contention is to make the log append only and use some operating system primitive that supports an atomic write to the end of the file. I do have code that allows me to append to the end of a JSON log without reading the whole thing into memory (which is important as my logs are expected to grow to several MB.) What I do is to work back from the end of the file until I see "]}" and then I replace that with ", {} ]} But this approach is rather brittle and somewhat risky. It also upsets various schemes designed to avoid wearing out my flash memory that handle atomic append operations in a special way. What I would like is an option for use in log files only that would allow a beginning of array marker to inform the reader that the end of file marker is an implicit close for that structure. So instead of my file starting: { "Keys": [{ "KeyID": "AAAJMA-ECEYAJ-GABJYPA-G6AAVC-GAB4ACI-FAAFGA-BGZ2AL-LAA", "SelfCertificates": [{ It would look something like: [* {"Key": [{ "KeyID": "AAAJMA-ECEYAJ-GABJYPA-G6AAVC-GAB4ACI-FAAFGA-BGZ2AL-LAA", "SelfCertificates": [{ ...} {...} {...} This is not an extension I would want to use in an on-the-wire format. But for log files it is essential. Particularly in my case where the logs are digitally signed notary records. I will be adding a similar feature to JSON-B but I would if possible like to make whatever change I make there be compatible with any solutions that other people have developed independently. I know this is out of scope for the docs, but I think that adding this feature and comments to the text encoding of JSON would be useful recharter items. And yes, I am aware that some people would prefer to keep JSON simple and not meet the requirements of my use cases. My position is that I want to use a single encoding for all the non ASN.1 parts of my system and that be as close to JSON as possible. But I am not going to compromise my system it the specification is not adequate for my needs. Writing a JSON reader is very easy, I am quite OK with a requirement that someone has to write their own reader or put a wrapper around an existing reader to accept my logs. -- Website: http://hallambaker.com/ --001a11c3cdc8bcab6304eb9e0191 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    The biggest technical blunder in JSON right now is the ins= istence that there only be one object in a file. XML suffers from the same = blunder, here is why.

    If you have a log file and it is b= eing updated by multiple processes, there is potential for contention betwe= en the updates. The simplest mechanism for resolving that contention is to = make the log append only and use some operating system primitive that suppo= rts an atomic write to the end of the file.

    I do have code that allows me to append to the end of a= JSON log without reading the whole thing into memory (which is important a= s my logs are expected to grow to several MB.) What I do is to work back fr= om the end of the file until I see "]}" and then I replace that w= ith ", {<New entry>} ]}

    But this approach is rather brittle and somewhat r= isky. It also upsets various schemes designed to avoid wearing out my flash= memory that handle atomic append operations in a special way.


    What I would like is an option for use in log= files only that would allow a beginning of array marker to inform the read= er that the end of file marker is an implicit close for that structure.

    So instead of my file starting:
    {
    <= div>=A0 "Keys": [{
    =A0 =A0 =A0 "KeyID": "= ;AAAJMA-ECEYAJ-GABJYPA-G6AAVC-GAB4ACI-FAAFGA-BGZ2AL-LAA",
    = =A0 =A0 =A0 "SelfCertificates": [{

    It would look something like:

    [*
    =A0 {"Key": [{
    =A0 =A0 =A0 &quo= t;KeyID": "AAAJMA-ECEYAJ-GABJYPA-G6AAVC-GAB4ACI-FAAFGA-BGZ2AL-LAA= ",
    =A0 =A0 =A0 "SelfCertificates": [{
    =A0 =A0..= .}
    =A0 {...}
    =A0 {...}

    This is= not an extension I would want to use in an on-the-wire format. But for log= files it is essential. Particularly in my case where the logs are digitall= y signed notary records.

    I will be adding a similar feature to JSON-B but I woul= d if possible like to make whatever change I make there be compatible with = any solutions that other people have developed independently.


    I know this is out of scope for the docs, but= I think that adding this feature and comments to the text encoding of JSON= would be useful recharter items.

    And yes, I am aw= are that some people would prefer to keep JSON simple and not meet the requ= irements of my use cases. My position is that I want to use a single encodi= ng for all the non ASN.1 parts of my system and that be as close to JSON as= possible. But I am not going to compromise my system it the specification = is not adequate for my needs.

    Writing a JSON reader is very easy, I am quite OK with = a requirement that someone has to write their own reader or put a wrapper a= round an existing reader to accept my logs.

    --
    Website: http://hallambaker.com/
    --001a11c3cdc8bcab6304eb9e0191-- From derhoermi@gmx.net Wed Nov 20 09:02:48 2013 Return-Path: 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 8B2D51AE020 for ; Wed, 20 Nov 2013 09:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 SXtWo1OHv1Sm for ; Wed, 20 Nov 2013 09:02:46 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6436A1AE0B2 for ; Wed, 20 Nov 2013 09:02:46 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.33.37]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MXmpv-1WDcLo0tVP-00Wln5 for ; Wed, 20 Nov 2013 18:02:39 +0100 From: Bjoern Hoehrmann To: Phillip Hallam-Baker Date: Wed, 20 Nov 2013 18:02:40 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:pA5usdbyW/es2DwehQfk+tIGxuGD17LIKu/r8KHCM+PKEYxyXyE dqRpvMDgycrqBhC2cEYNM+DvP9GmPB9NoXMAAY3hnFpbEfpzmIN9JnMKcLaw5yGId9R+oJP 3ShTDA7TZVd7kwTqTA+0LfXTTcWqqI1l+MflQym1yfeM8vD3EBebah0NTpJ3Q9Z/MQZ1n5u oiF+TwSmR84t0FI0AdCEA== Cc: JSON WG Subject: Re: [Json] Using JSON in log files X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:02:48 -0000 * Phillip Hallam-Baker wrote: >This is not an extension I would want to use in an on-the-wire format. But >for log files it is essential. Particularly in my case where the logs are >digitally signed notary records. I use http://yaml.org/ for such purposes. It is a superset of JSON, in a way. Converters to JSON, which you would need one way or another, are readily available. You could also just cheat and say "It's JSON without the encapsulating []". -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From tbray@textuality.com Wed Nov 20 09:16:44 2013 Return-Path: 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 5E2CE1AE106 for ; Wed, 20 Nov 2013 09:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ztOcHWAz9DJL for ; Wed, 20 Nov 2013 09:16:42 -0800 (PST) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id C838F1AE4B7 for ; Wed, 20 Nov 2013 09:16:39 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id x11so2984188vbb.20 for ; Wed, 20 Nov 2013 09:16:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=B7smrp+9/Z0Nwk+02DEzea/QnAMCQ89Yunjfm0Aw9oA=; b=f6LBUck3ZhWhNVQj9fOpqsFmi8XYwMIjm1NVnN97DgtLLbu9T1fpfChvRXeqanmIbX 35mVzkm1s9MG2p+394tT57eOXljsQKsedl44UAvxAKgaagPFt40yuHREVQpggIRe9qO9 FKjNV1PFNanqZcY/uv1O7yS8bOsquOSkpvH2TUwjxbT6QLYg6S2O3ahLoi7gAzVX9MmX E75mUlT+ImcQknarl4JFvAP99kWTt1l7ETGZtmNL8K7ecTCnXJfDUQLYRwInt//49CeT vHpXUHxloFELXIuIECZonmCDtLAttO/R4xP4bSMUEqP4qRspph/Xl9chDSeVr1weK+xD kOmA== X-Gm-Message-State: ALoCoQnRiVqq63t2OLhZtXupWDo3hfZLynuAEdJrzs4TlWO/ZHFEgxXeA7gV26oIusuQ1rPZFAyI MIME-Version: 1.0 X-Received: by 10.58.186.173 with SMTP id fl13mr1269102vec.31.1384967792967; Wed, 20 Nov 2013 09:16:32 -0800 (PST) Received: by 10.220.198.199 with HTTP; Wed, 20 Nov 2013 09:16:32 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Wed, 20 Nov 2013 09:16:32 -0800 Message-ID: From: Tim Bray To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=047d7b6dd1c65381ba04eb9ef121 Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Using JSON in log files X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:16:44 -0000 --047d7b6dd1c65381ba04eb9ef121 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Check how XMPP skates around XML=E2=80=99s single-root-element rule. Me, I= =E2=80=99d just have a log file containing a sequence of JSON texts. On Wed, Nov 20, 2013 at 9:02 AM, Bjoern Hoehrmann wrote= : > * Phillip Hallam-Baker wrote: > >This is not an extension I would want to use in an on-the-wire format. B= ut > >for log files it is essential. Particularly in my case where the logs ar= e > >digitally signed notary records. > > I use http://yaml.org/ for such purposes. It is a superset of JSON, in > a way. Converters to JSON, which you would need one way or another, are > readily available. You could also just cheat and say "It's JSON without > the encapsulating []". > -- > Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://= bjoern.hoehrmann.de > Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoern= sworld.de > 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.w= ebsitedev.de/ > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b6dd1c65381ba04eb9ef121 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Check how XMPP skates around XML=E2=80=99s single-root-ele= ment rule. =C2=A0Me, I=E2=80=99d just have a log file containing a sequence= of JSON texts.


    On Wed, Nov 20, 2013 at 9:02 AM, Bjoern Hoehrmann <derhoermi@gmx.n= et> wrote:
    * Phillip Hallam-Baker wro= te:
    >This is not an extension I would want to use in an on-the-wire format. = But
    >for log files it is essential. Particularly in my case where the logs a= re
    >digitally signed notary records.

    I use http://yaml.org/= for such purposes. It is a superset of JSON, in
    a way. Converters to JSON, which you would need one way or another, are
    readily available. You could also just cheat and say "It's JSON wi= thout
    the encapsulating []".
    --
    Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://bjoern.hoehrmann.de
    Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoernsworld.de
    25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.websitedev.de/
    _______________________________________________
    json mailing list
    json@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/json

    --047d7b6dd1c65381ba04eb9ef121-- From dret@berkeley.edu Wed Nov 20 09:32:05 2013 Return-Path: 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 5A4811AE4A8 for ; Wed, 20 Nov 2013 09:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 N39zXMTKAfqq for ; Wed, 20 Nov 2013 09:32:03 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id A37E41AE4C5 for ; Wed, 20 Nov 2013 09:32:03 -0800 (PST) Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] helo=dretpro.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VjBd4-0004Zj-3w; Wed, 20 Nov 2013 09:31:55 -0800 Message-ID: <528CF208.4050802@berkeley.edu> Date: Wed, 20 Nov 2013 09:31:52 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Bjoern Hoehrmann , Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Using JSON in log files X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:32:05 -0000 or just use http://www.w3.org/TR/xml/#TextEntities and happily and legally append log data to these. good enough for me. cheers, dret. On 2013-11-20, 9:16 , Tim Bray wrote: > Check how XMPP skates around XML’s single-root-element rule. Me, I’d > just have a log file containing a sequence of JSON texts. > > > On Wed, Nov 20, 2013 at 9:02 AM, Bjoern Hoehrmann > wrote: > > * Phillip Hallam-Baker wrote: > >This is not an extension I would want to use in an on-the-wire > format. But > >for log files it is essential. Particularly in my case where the > logs are > >digitally signed notary records. > > I use http://yaml.org/ for such purposes. It is a superset of JSON, in > a way. Converters to JSON, which you would need one way or another, are > readily available. You could also just cheat and say "It's JSON without > the encapsulating []". > -- > Björn Höhrmann · mailto:bjoern@hoehrmann.de > · http://bjoern.hoehrmann.de > Am Badedeich 7 · Telefon: +49(0)160/4415681 > · http://www.bjoernsworld.de > 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From hallam@gmail.com Wed Nov 20 09:43:52 2013 Return-Path: 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 B7CCE1AE060 for ; Wed, 20 Nov 2013 09:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 qeZf_pixBOHm for ; Wed, 20 Nov 2013 09:43:51 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7D51ADFF9 for ; Wed, 20 Nov 2013 09:43:50 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id w6so4002207lbh.25 for ; Wed, 20 Nov 2013 09:43:44 -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=4ySV/+zhXiG3BHlMpxvnLAdXymWEya6L7UhrUtriGMs=; b=M+Z762+wnsW/DrDiBNiTZaCUWvq4pLaZFBg3yxhbG1nHaHbhiqWoJUumlQmA8/OlFV yNOQ5uIa0slw1sHRaPUeKsnk4upiCsPVUb9fe+29QueeQ5q/ehq43B5AZt0g1qq2n+X4 oflOGrMOSdp4lpTjGKr9SpQCQKAdqhvNWMh2JCSPHy011Rfemo35I/QLK6zuLGNrcYCC Rte4PGKucrKkXh4fVUvelMfoqAExYLo+WIcK3QlMmsh6Yggr+xARucK3pHCWhbcpPV9k q0OOCuy6ncCrplCWnhW+nYo3/Ipz+iVlWYT6U18U1vpfs7hjtb6P3VDo2n1/mepiOg0F +xEQ== MIME-Version: 1.0 X-Received: by 10.112.168.170 with SMTP id zx10mr1299446lbb.0.1384969423869; Wed, 20 Nov 2013 09:43:43 -0800 (PST) Received: by 10.112.46.98 with HTTP; Wed, 20 Nov 2013 09:43:43 -0800 (PST) In-Reply-To: <528CF208.4050802@berkeley.edu> References: <528CF208.4050802@berkeley.edu> Date: Wed, 20 Nov 2013 12:43:43 -0500 Message-ID: From: Phillip Hallam-Baker To: Erik Wilde Content-Type: multipart/alternative; boundary=001a11c23c8888dcd704eb9f5269 Cc: Bjoern Hoehrmann , Tim Bray , JSON WG Subject: Re: [Json] Using JSON in log files X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:43:52 -0000 --001a11c23c8888dcd704eb9f5269 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 20, 2013 at 12:31 PM, Erik Wilde wrote: > or just use http://www.w3.org/TR/xml/#TextEntities and happily and > legally append log data to these. good enough for me. cheers, dret. I want to move to a single encoding for the whole system. Moving to XML does not help in that goal. -- Website: http://hallambaker.com/ --001a11c23c8888dcd704eb9f5269 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On W= ed, Nov 20, 2013 at 12:31 PM, Erik Wilde <dret@berkeley.edu>= wrote:
    or just use http://www.w3.org/TR/xml/#TextE= ntities and happily and legally append log data to these. good enough f= or me. cheers, dret.

    I want to move to a single encoding for the whole syste= m.

    Moving to XML does not help in that goal. =A0


    --
    Website: http://hallambaker.com/
    --001a11c23c8888dcd704eb9f5269-- From tsaloranta@gmail.com Wed Nov 20 10:22:33 2013 Return-Path: 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 273551AE505 for ; Wed, 20 Nov 2013 10:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-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 B6NKTX41gNTz for ; Wed, 20 Nov 2013 10:22:31 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1D67E1AE0D8 for ; Wed, 20 Nov 2013 10:22:30 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x12so9353767wgg.1 for ; Wed, 20 Nov 2013 10:22:24 -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=JB4xun/qZJM0mh15zotfcVWCyLCPo3Lx8V8ug8h2AIE=; b=C1zs0ft2AKBYI0J2xLdkl5FbN157kiVJpAA2yUqCF4vqKUiLWfztGBF+QgsuKE/tYj KPdiW75frHecKyf3mo9jiKIyD1z/4muGGozlfhDrujKGDY2SA1M8zgf641GyofPeWr5o kvYjk28MOHvlPJLA5xlaHHtEXD+ebXQ+iYT/EG1JrT13YnAIuGXKSKq7RiOXI+gTdiAt W8sz55ICcHEgeScJzCa3zIzjazQQCew/2MjKKg+iAXSaYtA+5ljEluXJdIV4eUOMxdxT knNynkiZXhkxUFmwZAMYQ7jh2i31tXBVsAIMzjtBYnKT0TFvdFpzmc4KlYLdFSAPMTEU sSRw== MIME-Version: 1.0 X-Received: by 10.180.210.134 with SMTP id mu6mr26559260wic.37.1384971744208; Wed, 20 Nov 2013 10:22:24 -0800 (PST) Received: by 10.227.61.195 with HTTP; Wed, 20 Nov 2013 10:22:24 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Nov 2013 10:22:24 -0800 Message-ID: From: Tatu Saloranta To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a11c37bdcd66c1804eb9fdc54 Cc: JSON WG Subject: Re: [Json] Using JSON in log files X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 18:22:33 -0000 --001a11c37bdcd66c1804eb9fdc54 Content-Type: text/plain; charset=ISO-8859-1 This is one of canonical use-cases for streaming JSON processing: just use linefeed between root-level values. Many/most streaming JSON readers support this, especially Java ones (Jackson definitely does; GSON has streaming mode, Genson as well; org.json's toy lib should not be used for anything). It also makes it easier to read, should you need to check out log files. Or, if you want to be strictly compliant with specs, use a container JSON array. Streaming readers (and generators) should work fine here as well. There is no need to buffer the whole log stream in buffer either when reading or writing. -+ Tatu +- On Wed, Nov 20, 2013 at 8:09 AM, Phillip Hallam-Baker wrote: > The biggest technical blunder in JSON right now is the insistence that > there only be one object in a file. XML suffers from the same blunder, here > is why. > > If you have a log file and it is being updated by multiple processes, > there is potential for contention between the updates. The simplest > mechanism for resolving that contention is to make the log append only and > use some operating system primitive that supports an atomic write to the > end of the file. > > I do have code that allows me to append to the end of a JSON log without > reading the whole thing into memory (which is important as my logs are > expected to grow to several MB.) What I do is to work back from the end of > the file until I see "]}" and then I replace that with ", {} ]} > > But this approach is rather brittle and somewhat risky. It also upsets > various schemes designed to avoid wearing out my flash memory that handle > atomic append operations in a special way. > > > What I would like is an option for use in log files only that would allow > a beginning of array marker to inform the reader that the end of file > marker is an implicit close for that structure. > > So instead of my file starting: > { > "Keys": [{ > "KeyID": "AAAJMA-ECEYAJ-GABJYPA-G6AAVC-GAB4ACI-FAAFGA-BGZ2AL-LAA", > "SelfCertificates": [{ > > It would look something like: > > [* > {"Key": [{ > "KeyID": "AAAJMA-ECEYAJ-GABJYPA-G6AAVC-GAB4ACI-FAAFGA-BGZ2AL-LAA", > "SelfCertificates": [{ > ...} > {...} > {...} > > This is not an extension I would want to use in an on-the-wire format. But > for log files it is essential. Particularly in my case where the logs are > digitally signed notary records. > > I will be adding a similar feature to JSON-B but I would if possible like > to make whatever change I make there be compatible with any solutions that > other people have developed independently. > > > I know this is out of scope for the docs, but I think that adding this > feature and comments to the text encoding of JSON would be useful recharter > items. > > And yes, I am aware that some people would prefer to keep JSON simple and > not meet the requirements of my use cases. My position is that I want to > use a single encoding for all the non ASN.1 parts of my system and that be > as close to JSON as possible. But I am not going to compromise my system it > the specification is not adequate for my needs. > > Writing a JSON reader is very easy, I am quite OK with a requirement that > someone has to write their own reader or put a wrapper around an existing > reader to accept my logs. > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a11c37bdcd66c1804eb9fdc54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    This is one of canonical use-cases for streaming= JSON processing: just use linefeed between root-level values. Many/most st= reaming JSON readers support this, especially Java ones (Jackson definitely= does; GSON has streaming mode, Genson as well; org.json's toy lib shou= ld not be used for anything).
    It also makes it easier to read, should you need to check out log files.
    Or, if you want to be strictly compliant with specs, use a = container JSON array.
    Streaming readers (and generators) shou= ld work fine here as well.
    There is no need to buffer the whole log stream in buffer either= when reading or writing.

    -+ Tatu +-

    <= /div>


    On Wed, = Nov 20, 2013 at 8:09 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
    The biggest technical blund= er in JSON right now is the insistence that there only be one object in a f= ile. XML suffers from the same blunder, here is why.

    If you have a log file and it is being updated by multiple p= rocesses, there is potential for contention between the updates. The simple= st mechanism for resolving that contention is to make the log append only a= nd use some operating system primitive that supports an atomic write to the= end of the file.

    I do have code that allows me to append to the end of a= JSON log without reading the whole thing into memory (which is important a= s my logs are expected to grow to several MB.) What I do is to work back fr= om the end of the file until I see "]}" and then I replace that w= ith ", {<New entry>} ]}

    But this approach is rather brittle and somewhat r= isky. It also upsets various schemes designed to avoid wearing out my flash= memory that handle atomic append operations in a special way.


    What I would like is an option for use in log= files only that would allow a beginning of array marker to inform the read= er that the end of file marker is an implicit close for that structure.

    So instead of my file starting:
    {
    <= div>=A0 "Keys": [{
    =A0 =A0 =A0 "KeyID": "= ;AAAJMA-ECEYAJ-GABJYPA-G6AAVC-GAB4ACI-FAAFGA-BGZ2AL-LAA",
    = =A0 =A0 =A0 "SelfCertificates": [{

    It would look something like:

    [*
    =A0 {"Key": [{
    =A0 =A0 =A0 &quo= t;KeyID": "AAAJMA-ECEYAJ-GABJYPA-G6AAVC-GAB4ACI-FAAFGA-BGZ2AL-LAA= ",
    =A0 =A0 =A0 "SelfCertificates": [{
    =A0 =A0..= .}
    =A0 {...}
    =A0 {...}

    This is= not an extension I would want to use in an on-the-wire format. But for log= files it is essential. Particularly in my case where the logs are digitall= y signed notary records.

    I will be adding a similar feature to JSON-B but I woul= d if possible like to make whatever change I make there be compatible with = any solutions that other people have developed independently.


    I know this is out of scope for the docs, but= I think that adding this feature and comments to the text encoding of JSON= would be useful recharter items.

    And yes, I am aw= are that some people would prefer to keep JSON simple and not meet the requ= irements of my use cases. My position is that I want to use a single encodi= ng for all the non ASN.1 parts of my system and that be as close to JSON as= possible. But I am not going to compromise my system it the specification = is not adequate for my needs.

    Writing a JSON reader is very easy, I am quite OK with = a requirement that someone has to write their own reader or put a wrapper a= round an existing reader to accept my logs.

    --
    Website: http://halla= mbaker.com/

    _______________________________________________
    json mailing list
    json@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/json


    --001a11c37bdcd66c1804eb9fdc54-- From hsivonen@hsivonen.fi Wed Nov 20 05:34:33 2013 Return-Path: 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 1EE2D1ADF6C for ; Wed, 20 Nov 2013 05:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-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 Keox0AZ-e9XH for ; Wed, 20 Nov 2013 05:34:31 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 93B271ADF69 for ; Wed, 20 Nov 2013 05:34:31 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so5576910obc.1 for ; Wed, 20 Nov 2013 05:34:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hsivonen.fi; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tkMHKWgTLDY8iZc0BmNK3SFMsHGKIMIbSp7CrlqvVjE=; b=NtoB1RCnBeeYRWNS7RcpzA85tVc5UPhTeeujQ+jlEpDhEoIKSio9nOtecwAbCY7IzL ndskDNhb045NbzchzJ3hmUwiu3JVdkpjbwjHG51DyKE6nrK9urhEIlCn2utpRZxNESVS n6dRM3xugMowhsEGz+bZKHvv8x3M2LbisMzzE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tkMHKWgTLDY8iZc0BmNK3SFMsHGKIMIbSp7CrlqvVjE=; b=YneE+E6VH01StU3/Ko2ZOlhqfOEGt6zFf+qu2MXvLVXtfaX/6PStdJ+Xem7+Gy0PYZ B3z+MD2xwU1VhZakimC56ihPdi7LT7axnvtEbX4gFqrqukr/ia5zpV++sWQlp/WPr61L dQVFreFw0N17PhsmBYAXgHuaSYMVJzFH+XHBXVKud+3YI38KZ9QMSQw37hxRlt/ENK2s 3/0iTNI7q/K5oIvI7TgWsUssNebrz0PcVrrXvvFxCl1m/pjGSDXO4FVPWGqvBtmDD/VP l3mlh1LGlj0/m42PxfH3CKcyh/3RiQPeAPtoaznF8itljiElroeUIYnBjiLLyl8SBEYn 0H6w== X-Gm-Message-State: ALoCoQmLCSDrjKwJPnpMjH08dHM+1+afUMZ0d4Okdug2+xCm21wYrfvuoETIo216vYs/24VLbwYb MIME-Version: 1.0 X-Received: by 10.182.142.229 with SMTP id rz5mr599860obb.12.1384954464593; Wed, 20 Nov 2013 05:34:24 -0800 (PST) Received: by 10.182.119.130 with HTTP; Wed, 20 Nov 2013 05:34:24 -0800 (PST) In-Reply-To: References: <8413609C8A86497F856897AF2AA24960@codalogic> Date: Wed, 20 Nov 2013 15:34:24 +0200 Message-ID: From: Henri Sivonen To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 20 Nov 2013 10:22:46 -0800 Cc: "www-tag@w3.org" , Paul Hoffman , Pete Cordell , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 18:16:17 -0000 On Thu, Nov 14, 2013 at 4:59 PM, Joe Hildebrand (jhildebr) wrote: >> 00 00 -- -- UTF-32BE >> 00 xx -- -- UTF-16BE >> xx 00 00 00 UTF-32LE >> xx 00 00 xx UTF-16LE >> xx 00 xx -- UTF-16LE >> xx xx -- -- UTF-8 > > +1 to this table. It's clear, correct, and implementable. -1 =E0=B2=A0_=E0=B2=A0 As a person who has actually ended up (re)implementing many of the cases where Firefox sets up the conversion bytes into characters, I find this kind of format-specific making stuff up in order to enable the use of BOMless UTF-16 or any sort of UTF-32 reprehensible. There is no legitimate reason to use UTF-32 for interchange. UTF-32 as an interchange encoding only serves to increase development and QA cost and to potentially add security holes (all multibyte decoders implemented in C or C++ are fine opportunities for security holes). The W3C or the IETF should not act like UTF-32 was a legitimate interchanging coding for any purpose for any format. Producers should be prohibited from emitting UTF-32. Consumers should be prohibited from supporting UTF-32. As for UTF-16, there's no legitimate reason* for any new producer to use it for interchange, but consumers might (depending on format) need to implement it for compatibility with legacy producers, even though in retrospect UTF-16 is a bad idea in general and a terrible idea for interchange. I don't know if JSON is a format where it's necessary to support the consumption of UTF-16 as an interchange encoding, but if it is, the way detection happens for in-band indications should happen in a way consistent with the "decode" algorithm in the Encoding Standard (http://encoding.spec.whatwg.org/#decode) for consistency with how the Web Platform handles text/html, text/plain and text/css (and, shocker, in practice XML). That is, there should be no special rules about looking for patterns of zeros. However, the three BOMs=E2=80=94and only thr= ee (UTF-8, big-endian UTF-16, little-endian UTF-16) BOMs=E2=80=94should take precedence over everything else, including out-of-band metadata. * gzip takes away the advantage UTF-16 might have over UTF-8 for East Asian-heavy text. --=20 Henri Sivonen hsivonen@hsivonen.fi http://hsivonen.fi/ From hallam@gmail.com Wed Nov 20 11:20:12 2013 Return-Path: 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 1D6931AE13E for ; Wed, 20 Nov 2013 11:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-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 FUebWDduh1jL for ; Wed, 20 Nov 2013 11:20:10 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5841AE135 for ; Wed, 20 Nov 2013 11:20:10 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ec20so7718775lab.15 for ; Wed, 20 Nov 2013 11:20:03 -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=WFbEoVsusA2RV1ormFPHnM5c/2eYvkB36Rw/oeJ1A14=; b=wo3zSBcAkomJ+E2PSw27cmCAIIXLcBXzeZn01qHWZIUsY5+StJAbvBsLICfJ7bYWQT qWQVdylWoei+I4vGWBlLNjM+q3QbCYxcMnXHNkEUCD7jCaYyul3Q9bhugEMFqcFPsOgU BfLUMNAE6yKU9JQXnXnIFXnqwaaQ8DKTPDgmt6vst4Cb8rwXDDGD5ui2GXBhT3sCxJm+ eH503w6fN1cH/F3nV604oYSJENMV/NRe0LetskhMDR8a1I9QaZnZjSm7OouwQsEazSys IEpmrpnF79+Y+kkM1pxshk4D6+zWX2N7KFkpoWv+Bu4dTXqWndQXFasj1+f26kGXpZF0 gVQg== MIME-Version: 1.0 X-Received: by 10.112.77.169 with SMTP id t9mr1576478lbw.3.1384975203287; Wed, 20 Nov 2013 11:20:03 -0800 (PST) Received: by 10.112.46.98 with HTTP; Wed, 20 Nov 2013 11:20:03 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Nov 2013 14:20:03 -0500 Message-ID: From: Phillip Hallam-Baker To: Tatu Saloranta Content-Type: multipart/alternative; boundary=001a11c3ecfa03cc2904eba0ab33 Cc: JSON WG Subject: Re: [Json] Using JSON in log files X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:20:12 -0000 --001a11c3ecfa03cc2904eba0ab33 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 20, 2013 at 1:22 PM, Tatu Saloranta wrote: > This is one of canonical use-cases for streaming JSON processing: just use > linefeed between root-level values. Many/most streaming JSON readers > support this, especially Java ones (Jackson definitely does; GSON has > streaming mode, Genson as well; org.json's toy lib should not be used for > anything). > It also makes it easier to read, should you need to check out log files. > > Or, if you want to be strictly compliant with specs, use a container JSON > array. > Streaming readers (and generators) should work fine here as well. > There is no need to buffer the whole log stream in buffer either when > reading or writing. > Thanks, I will do that. Given that this seems to be a common extension, shouldn't we document it as such? What other common extensions are in use? -- Website: http://hallambaker.com/ --001a11c3ecfa03cc2904eba0ab33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On W= ed, Nov 20, 2013 at 1:22 PM, Tatu Saloranta <tsaloranta@gmail.com= > wrote:
    This is one of ca= nonical use-cases for streaming JSON processing: just use linefeed between = root-level values. Many/most streaming JSON readers support this, especiall= y Java ones (Jackson definitely does; GSON has streaming mode, Genson as we= ll; org.json's toy lib should not be used for anything).
    It also makes it easier to read, should you need to check out log files.
    Or, if you want to be strictly compliant with specs, use a = container JSON array.
    Streaming readers (and generators) shou= ld work fine here as well.
    There is no need to buffer the whole log stream in buffer either= when reading or writing.

    Thanks, I will do that.

    Given that this seems to = be a common extension, shouldn't we document it as such?=A0

    What other common extensions are in use?


    --
    Website:= http://hallambaker.com/
    --001a11c3ecfa03cc2904eba0ab33-- From cowan@ccil.org Wed Nov 20 14:33:23 2013 Return-Path: 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 08AC21AE0C1 for ; Wed, 20 Nov 2013 14:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525] 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 HE5xmC8HiEqH for ; Wed, 20 Nov 2013 14:33:21 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6613B1AE078 for ; Wed, 20 Nov 2013 14:33:21 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VjGKX-0003ku-Cf; Wed, 20 Nov 2013 17:33:05 -0500 Date: Wed, 20 Nov 2013 17:33:05 -0500 From: John Cowan To: Henri Sivonen Message-ID: <20131120223305.GB5476@mercury.ccil.org> References: <8413609C8A86497F856897AF2AA24960@codalogic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Pete Cordell , JSON WG , "www-tag@w3.org" , "Joe Hildebrand \(jhildebr\)" , Paul Hoffman 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 22:33:23 -0000 Henri Sivonen scripsit: > There is no legitimate reason to use UTF-32 for interchange. [snip] > As for UTF-16, there's no legitimate reason* for any new producer to > use it for interchange, This is all very well, but we are not at present in the business of banning previously permitted forms of JSON. If you have evidence that the specific use of these encodings harms JSON interchange, bring it forward. -- You are a child of the universe no less John Cowan than the trees and all other acyclic http://www.ccil.org/~cowan graphs; you have a right to be here. cowan@ccil.org --DeXiderata by Sean McGrath From nico@cryptonector.com Wed Nov 20 18:21:57 2013 Return-Path: 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 4AAD31ADF99 for ; Wed, 20 Nov 2013 18:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] 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 tr8GTHlQGkA6 for ; Wed, 20 Nov 2013 18:21:56 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA0A1ADF87 for ; Wed, 20 Nov 2013 18:21:56 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id F0269264059 for ; Wed, 20 Nov 2013 18:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=KTNqbubbSIMeVS9R70NO WyR5Bxo=; b=MorQGvocVfRuABhtVW9fBmxuIACWDk7Dmhw1jtIPMm0Sfjx1cZds iW8n/xG2bJ2G1tiEM6IgJt1XR/oCxlcGFKTSk7reFXrM4/Vk0f/b2++bnLGNd04w gXVIcJQyjs6HRA5vXifuyo+95XYfi8Qq7b20r9ZrN+93uJJK+SkqQ0c= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 99E15264005 for ; Wed, 20 Nov 2013 18:21:49 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id q58so4200290wes.2 for ; Wed, 20 Nov 2013 18:21:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=htag79+zxigDw0ubYZ4qhpXVpF2esXRLUvrIkO1+wtk=; b=DhBEDl5vFr28yMF5Lto9/c9QM5M85mC9K/pN2C7ArCJrmIE14dtPhgT9yGvkjXUneu tJkOBbHrRrKkiViakFKIOkutS1ftHOSVt+CWp358sVPTf2dj1hrtLAaR/hd9vEWIbULO Agb6atOcado1hw1AZMtGRo2vcd9cAOLEmfkVaXRkYD6mtsUOHH3efGnjadjVFNtFsOh6 eOI/N6S93MS8YYtpH2t1H2zLcmIu5k56xp4vWyT2LlrnjzeYC30XP+BqReWgpzpYc2Fg TpMiZSVlpPOHekBhQc7JPNScZxVw8SwYnVdnUJUtk3t9m8mc+YgSIHNApv0SAdoGnS2B v8Mg== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr27954779wik.13.1385000507786; Wed, 20 Nov 2013 18:21:47 -0800 (PST) Received: by 10.216.151.136 with HTTP; Wed, 20 Nov 2013 18:21:47 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Nov 2013 20:21:47 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: JSON WG Subject: Re: [Json] Using JSON in log files X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 02:21:57 -0000 On Wed, Nov 20, 2013 at 10:09 AM, Phillip Hallam-Baker wrote: +1 If you look at tools like jq, you'll see that it's perfectly natural to treat a sequence of JSON texts as an array of values, without any need to first collect them into a larger JSON text consisting of an array of all those values. % echo 1 2 3 4 | jq . 1 2 3 4 % echo 1 2 3 4 | jq -s . [ 1, 2, 3, 4 ] % This approach, combined with an online parser, makes it trivial to deal with log-type structures (append-only with atomic appends) where one appends JSON texts. Sure, one could also pretend that the log starts with '[', make sure every entry is a JSON text followed by a ',', and use an online parser, but this is more fun. The one caveat is that numbers are not self-delimiting, which means that JSON texts consisting of a numeric value must be delimited with whitespace. Nico -- Nico -- From lhotka@nic.cz Thu Nov 21 02:20:38 2013 Return-Path: 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 BA07D1AE12D for ; Thu, 21 Nov 2013 02:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] 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 7SYbCO4F8RtP for ; Thu, 21 Nov 2013 02:20:36 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0EF1AE122 for ; Thu, 21 Nov 2013 02:20:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0D91054039F; Thu, 21 Nov 2013 11:20:29 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjkT5HMKm3sr; Thu, 21 Nov 2013 11:20:21 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id AE21D5401C2; Thu, 21 Nov 2013 11:20:17 +0100 (CET) From: Ladislav Lhotka To: Tim Bray , Bjoern Hoehrmann In-Reply-To: References: User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Date: Thu, 21 Nov 2013 11:20:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] Using JSON in log files X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 10:20:38 -0000 Tim Bray writes: > Check how XMPP skates around XML=E2=80=99s single-root-element rule. Me,= I=E2=80=99d just > have a log file containing a sequence of JSON texts. True. However, compared to XML, JSON has an additional issue of "value-sepa= rator" (comma) that can only appear between members. Perhaps it would be us= eful to allow for a comma right before the closing brace/bracket. Lada > > > On Wed, Nov 20, 2013 at 9:02 AM, Bjoern Hoehrmann wro= te: > >> * Phillip Hallam-Baker wrote: >> >This is not an extension I would want to use in an on-the-wire format. = But >> >for log files it is essential. Particularly in my case where the logs a= re >> >digitally signed notary records. >> >> I use http://yaml.org/ for such purposes. It is a superset of JSON, in >> a way. Converters to JSON, which you would need one way or another, are >> readily available. You could also just cheat and say "It's JSON without >> the encapsulating []". >> -- >> Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http:/= /bjoern.hoehrmann.de >> Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoer= nsworld.de >> 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.= websitedev.de/ >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From allen@wirfs-brock.com Wed Nov 20 21:53:45 2013 Return-Path: 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 AAF491AE03C; Wed, 20 Nov 2013 21:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 NS7-7en84Czm; Wed, 20 Nov 2013 21:53:43 -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 7E0CE1ADFAD; Wed, 20 Nov 2013 21:53:43 -0800 (PST) Received: from [66.201.52.99] (helo=[10.71.1.199]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1VjNCj-0004Wf-IT; Thu, 21 Nov 2013 05:53:30 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 66.201.52.99 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/Y2xxLttZPWlg0ySlnHC1F/FQ4Nf5RkB0= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-37-831593429 From: Allen Wirfs-Brock In-Reply-To: <528C5445.3050600@it.aoyama.ac.jp> Date: Wed, 20 Nov 2013 21:53:22 -0800 Message-Id: References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1085) X-Mailman-Approved-At: Thu, 21 Nov 2013 03:46:38 -0800 Cc: John Cowan , "Henry S. Thompson" , Pete Cordell , JSON WG , www-tag@w3.org, Anne van Kesteren , es-discuss , "t.p." , IETF Discussion Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 05:53:45 -0000 --Apple-Mail-37-831593429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 19, 2013, at 10:18 PM, Martin J. D=FCrst wrote: > Hello Henry, others, >=20 > On 2013/11/20 3:55, Henry S. Thompson wrote: >> Allen Wirfs-Brock writes: >>=20 >>> There can be no doubt that the most widely deployed JSON parsers are >>> those that are built intp the browser javascript implementations. >>> The ECMAScript 5 specification for JSON.parse that they implement >>> says BOM is an illegal character. But what do the browser actually >>> implement? This: >>=20 >> No, try e.g. jsonviewer.stack.hu [1] (works in Chrome, Safari, Opera, >> not in IE or Firefox) >=20 > In Firefox, I got some garbled characters, in particular some question = marks for each of the two bytes of the BOM and one question mark for the = e-acute. Because of the type of the errors, I strongly suspect it is = related to what we are trying to investigate, and so I don't think this = can be taken as evidence one way or another. >=20 > or feed [2] to www.jsoneditoronline.org (Use >> Open/Url) (works in Chrome, IE, Firefox, ran out of time to test = more). >=20 > The fact that some libraries or Web sites accept a BOM for JSON isn't = a proof that all (well, let's say the majority) accept a BOM. Just to be clear about this. My tests directly tested JavaScript = built-in JSON parsers WRT to BOM support in three major browsers. The = tests directly invoked the built-in JSON.parse functions and directly = passed to them a source strings that was explicitly constructed to = contain a BOM code point . This was done to ensure that the all = transport layers (and any transcodings they might perform) were = bypassed and that we were actually testing the real built-in JSON parse = functions. Neither of the sites referenced about perform a comparable test. They = take user inputed text when is then pass through whose knows what layers = of browser and application preprocessing and then they present something = derived from that original user input to a JSON parser. In both bases = the actual parser does not appear to be the the built-in JavaScript = JSON.parse function that I was testing. json.view.stack.hu uses Ext.util.JSON.decode whose document describe it = as "Modified version of Douglas Crockford"s json.js". In other words = not the built-in JSON.parse function www.jsoneditoronlineorg uses a library called JSONLint in preference to = the built-in JSON.parse function. It does not conform to the ECMAScript = 5 JSON.parse specification. So testing using either of these sites say nothing relevant to about my = observation concern BOM handling by the most widely deployed JSON = parsers (the ones that are built into browser JavaScript = implementations)=20 Allen =20= --Apple-Mail-37-831593429 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
    Hello Henry, others,

    On 2013/11/20 3:55, Henry = S. Thompson wrote:
    Allen Wirfs-Brock = writes:

    There can be no doubt that the most widely deployed JSON = parsers are
    those that are built intp the = browser javascript = implementations.
    The ECMAScript 5 specification = for JSON.parse that they = implement
    says BOM is an illegal = character.  But what do the browser = actually
    implement? =  This:

    No, try e.g. jsonviewer.stack.hu [1] (works = in Chrome, Safari, Opera,
    not = in IE or Firefox)

    In Firefox, I got some garbled = characters, in particular some question marks for each of the two bytes = of the BOM and one question mark for the e-acute. Because of the type of = the errors, I strongly suspect it is related to what we are trying to = investigate, and so I don't think this can be taken as evidence one way = or another.

    or feed [2] to www.jsoneditoronline.org = (Use
    Open/Url) (works in Chrome, IE, = Firefox, ran out of time to test more).

    The fact = that some libraries or Web sites accept a BOM for JSON isn't a proof = that all (well, let's say the majority) accept a = BOM.

    Just to be clear about this. =  My tests directly tested JavaScript built-in JSON parsers WRT to = BOM support in three major browsers.  The tests directly invoked = the built-in JSON.parse functions and directly passed to them a source = strings that was explicitly constructed to contain a BOM code point . =  This was done to ensure that the all transport layers  (and = any transcodings they might perform) were bypassed and that we were = actually testing the real built-in JSON parse = functions.

    Neither of the sites referenced = about perform a comparable test.  They take user inputed text when = is then pass through whose knows what layers of browser and application = preprocessing and then they present something derived from that original = user input to a JSON parser.  In both bases the actual parser does = not appear to be the the built-in JavaScript JSON.parse function that I = was testing.

    json.view.stack.hu uses E= xt.util.JSON.decode whose document describe it as "Modified version of = Douglas Crockford"s json.js".   In other words not the built-in = JSON.parse function

    www.jsoneditoronlineorg = uses a library called JSONLint in preference to the built-in JSON.parse = function.  It does not conform to the ECMAScript 5 JSON.parse = specification.

    So testing using either of these = sites say nothing relevant to about my observation concern BOM handling = by the most widely deployed JSON parsers (the ones that are built into = browser JavaScript = implementations) 

    Allen
     = --Apple-Mail-37-831593429-- From hsivonen@hsivonen.fi Thu Nov 21 05:35:51 2013 Return-Path: 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 6F3C01AE158 for ; Thu, 21 Nov 2013 05:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-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 qcS0SNG7TlbR for ; Thu, 21 Nov 2013 05:35:50 -0800 (PST) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 372251AE153 for ; Thu, 21 Nov 2013 05:35:50 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id l6so2267672oag.7 for ; Thu, 21 Nov 2013 05:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hsivonen.fi; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jhsiTOyt8NY5N0uSPLHkd7PRMDYJQfOHx/3VvRRbqJY=; b=QV62IlOyqxte9ZdXfgSE8NZBK03H5bqcyt7+uHQB5rz8z02wwjdsZdTChYfRDp4qNF BSW78hVrYaOarDhk+QCtDEmh0UBDYdUN+jm9fjs3lqQM+tScp0evrIyyGdTugEnf3LoK NuBNJnyJ1ienIoOW5BG9XUQTqjPhv1+iqPlPg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jhsiTOyt8NY5N0uSPLHkd7PRMDYJQfOHx/3VvRRbqJY=; b=aymJkozSF8viywum185DREINDhJw5ta6zFx90UNOEH77KUjoqMISMTlrNf6nhmiJkU isGSn7Hs4wL20utysowyXhAVPW2FTsjHKCBwbVStgwXA83DF3CAaPL6ap5N2nVI3NpPj EN+15xEAhVoZvTmOvetTFmUdgNnutbYOkBGxdMotEszTmjNSW0HWhojsB5CfbLW/J1uY PRU6eU5gAmRe6jj9ybEphdDeE4c4Ri0y/VdXXrc8jgjn8TcR/RNdgCWXvoUWWFuZIzMr dkiJ1RYP7d5MA4sBYnX5fclYNvlJArC1sgUran3Rdl7V9TqAy1uJSTHJ3ZKQt/J3grhF jKQg== X-Gm-Message-State: ALoCoQnqG4lpLoGt3qIkcEaCPJjEMS8fIWCSdqMFMrz5zKGLhKsgUDZ9Ab74m4VW3jOOp46FDXZI MIME-Version: 1.0 X-Received: by 10.60.117.225 with SMTP id kh1mr5553287oeb.15.1385040943340; Thu, 21 Nov 2013 05:35:43 -0800 (PST) Received: by 10.182.119.130 with HTTP; Thu, 21 Nov 2013 05:35:43 -0800 (PST) In-Reply-To: <20131120223305.GB5476@mercury.ccil.org> References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> Date: Thu, 21 Nov 2013 15:35:43 +0200 Message-ID: From: Henri Sivonen To: John Cowan Content-Type: text/plain; charset=UTF-8 Cc: Pete Cordell , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , "www-tag@w3.org" , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 13:35:51 -0000 On Thu, Nov 21, 2013 at 12:33 AM, John Cowan wrote: > This is all very well, but we are not at present in the business of > banning previously permitted forms of JSON. Why not? Surely existing still deployed producers should be what matters when deciding what needs to be ingested--not previous specs. That is, compatibility should be considered in terms of what's out there--not in terms of what unreasonable things were written down in a previous RFC. > If you have evidence > that the specific use of these encodings harms JSON interchange, > bring it forward. UTF-32 harms JSON interchange, because Gecko removed all UTF-32 support throughout the engine (other engines probably did, too, but I'm too busy to check) and, therefore, XHR responseType = "json" doesn't support UTF-32. -- Henri Sivonen hsivonen@hsivonen.fi http://hsivonen.fi/ From annevankesteren@gmail.com Thu Nov 21 05:39:18 2013 Return-Path: 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 272121ADEBA for ; Thu, 21 Nov 2013 05:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-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 egrfXyrl9mgZ for ; Thu, 21 Nov 2013 05:39:17 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D9CCD1ADEA6 for ; Thu, 21 Nov 2013 05:39:16 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hm4so3084215wib.0 for ; Thu, 21 Nov 2013 05:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jkKKqoGF/gVr0EWBirzRBtKNiJa9iZHsglWRl8LleHg=; b=MCxvAbtyzJWK0JT6Dyoqv5ihI1hU3pKqKw7o/tvk3l/bofePDpVOvPYKiN27JLCsFF vg+q7m9UKYO9shcr7fJAycX+TlEVR7U1jA6pOT0RYAvotbc3dqiKCmzfDFA6uhAPgpaJ PtcmDSRtBFjZ4p32GH940Or4Td2QB4SVaHP0ELPVPm+vA0Eb3w6cWGPEMeWq392eX5UM t2ZZu6zJKXnCWaLlm3Nsyf9xbq1KPO7UtkaYcE2ILAxrhL3CUfhUNIrKN/8a662Ur1Od WvGidqctczqC8dtmRQ1oEvJc/J0tCppcPtr0j2nqt2kldeNALCsNL5pMCT2WQPUW2k+s K+LQ== MIME-Version: 1.0 X-Received: by 10.180.37.11 with SMTP id u11mr5018779wij.27.1385041149718; Thu, 21 Nov 2013 05:39:09 -0800 (PST) Sender: annevankesteren@gmail.com Received: by 10.227.19.193 with HTTP; Thu, 21 Nov 2013 05:39:09 -0800 (PST) In-Reply-To: References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> Date: Thu, 21 Nov 2013 13:39:09 +0000 X-Google-Sender-Auth: 457enT4Ntk3Pbe2VRnQaFMyjSLs Message-ID: From: Anne van Kesteren To: Henri Sivonen Content-Type: text/plain; charset=UTF-8 Cc: John Cowan , Pete Cordell , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , "www-tag@w3.org" , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 13:39:18 -0000 On Thu, Nov 21, 2013 at 1:35 PM, Henri Sivonen wrote: > UTF-32 harms JSON interchange, because Gecko removed all UTF-32 > support throughout the engine (other engines probably did, too, but > I'm too busy to check) and, therefore, XHR responseType = "json" > doesn't support UTF-32. XHR's responseType = "json" only supports UTF-8 (optionally with a leading BOM), across the board. -- http://annevankesteren.nl/ From hsivonen@hsivonen.fi Thu Nov 21 05:28:52 2013 Return-Path: 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 07B701AE138 for ; Thu, 21 Nov 2013 05:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, SPF_PASS=-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 yC5L_zhcF9DL for ; Thu, 21 Nov 2013 05:28:50 -0800 (PST) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A41A71AE142 for ; Thu, 21 Nov 2013 05:28:50 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id o6so5707216oag.19 for ; Thu, 21 Nov 2013 05:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hsivonen.fi; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ig2MCEbxmK/rXQSvjwaofDWQh3u3p95ewpuNubPKIG0=; b=i2cRGqdPBbYJivIf1N0yoyVMwuZuSHud7+x9ndaw6XBC0ETTykhalJDkDY6HOnvtjY nJysfLZ92wBgZaUjhgKaawOgp0FPs8lQ6Obm54zRsdK4lSDo3Ko59YtWiRzmqC/m4610 N513Wxd79cB/iXTrnZwYZ8zPz4VyUC6jWx42c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ig2MCEbxmK/rXQSvjwaofDWQh3u3p95ewpuNubPKIG0=; b=de+/vYBRwnH335azxzdKetb592RXIs5CK6fcA2yLDM3YporevrLK7BowtD0WWt51tE kA5x5xVb3nnPZu6FZaM8cn3tp4F1UbDZGMqJLg8FIZ5qe7KoTElcHjNRWOayGABFUHS/ 9MRsqrUyAhCHRk4iC5Qmc44h+VEnlx0QfacSC5zA75WaY5Hklb7tuFdJ4QuHhtWQsYnG buDFJkNbTK2b9BQJQ7EbnAZ2mlq+wtj8a3bR73dRe3k5XLXr3c1XiFfc4JgwqbDpVAPZ nVxkeAFKECGFHFOveeIc9hEGVQFv3UrV0LRiz85okVqqu5tbbqPi0P+I3C9AZNAwfStr 56CA== X-Gm-Message-State: ALoCoQkCp7RZMA79/IVIh2NR6EycscUi32LIXJVdOsA7HgrL5JjC8/LTBYURYz2CWHF6pJchA1s2 MIME-Version: 1.0 X-Received: by 10.182.60.233 with SMTP id k9mr5599104obr.34.1385040523782; Thu, 21 Nov 2013 05:28:43 -0800 (PST) Received: by 10.182.119.130 with HTTP; Thu, 21 Nov 2013 05:28:43 -0800 (PST) In-Reply-To: References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> Date: Thu, 21 Nov 2013 15:28:43 +0200 Message-ID: From: Henri Sivonen To: Allen Wirfs-Brock Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 21 Nov 2013 06:51:49 -0800 Cc: John Cowan , "Henry S. Thompson" , Pete Cordell , JSON WG , www-tag , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , es-discuss , Anne van Kesteren , "t.p." , IETF Discussion Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 13:28:52 -0000 On Thu, Nov 21, 2013 at 7:53 AM, Allen Wirfs-Brock wrote: > Just to be clear about this. My tests directly tested JavaScript built-in > JSON parsers WRT to BOM support in three major browsers. The tests directly > invoked the built-in JSON.parse functions and directly passed to them a > source strings that was explicitly constructed to contain a BOM code point . > This was done to ensure that the all transport layers (and any transcodings > they might perform) were bypassed and that we were actually testing the real > built-in JSON parse functions. It would be surprising if JSON.parse() accepted a BOM, since it doesn't take bytes as input. However, XHR's responseType = "json" exercises browsers in a way where the input is bytes from the network. From the perspective of JSON support in XHR, http://lists.w3.org/Archives/Public/www-tag/2013Nov/0149.html (which didn't reach the es-discuss part of this thread previously) applies. -- Henri Sivonen hsivonen@hsivonen.fi http://hsivonen.fi/ From cowan@ccil.org Thu Nov 21 08:56:35 2013 Return-Path: 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 AA3BE1AE1D9 for ; Thu, 21 Nov 2013 08:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525] 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 YbcNmOqVyYUH for ; Thu, 21 Nov 2013 08:56:32 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B9B371AE1D3 for ; Thu, 21 Nov 2013 08:56:32 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VjXY7-0002Y8-4B; Thu, 21 Nov 2013 11:56:15 -0500 Date: Thu, 21 Nov 2013 11:56:15 -0500 From: John Cowan To: Henri Sivonen Message-ID: <20131121165615.GA12138@mercury.ccil.org> References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Pete Cordell , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , "www-tag@w3.org" , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 16:56:35 -0000 Henri Sivonen scripsit: > Why not? Surely existing still deployed producers should be what > matters when deciding what needs to be ingested--not previous specs. > That is, compatibility should be considered in terms of what's out > there--not in terms of what unreasonable things were written down in a > previous RFC. In principle, maybe. But testing a dozen browsers isn't enough here. We simply don't know how much non-browser traffic involves JSON (though we know there are many such interactions), or what representations they are using. We have therefore decided in the 4627bis effort not to say that anything that was previously valid is now invalid. At least, that is what I understand us to be doing. > UTF-32 harms JSON interchange, because Gecko removed all UTF-32 > support throughout the engine (other engines probably did, too, but > I'm too busy to check) and, therefore, XHR responseType = "json" > doesn't support UTF-32. That has about as much weight as "XYZ implementation only supports ASCII, so the use of non-ASCII characters harms JSON interchange" or "ABC implementation only supports 32-bit integers, so the use of decimal points harms JSON interchange." An implementation's self-imposed limitations don't affect the standard. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org if if = then then then = else else else = if; From jhildebr@cisco.com Thu Nov 21 09:12:05 2013 Return-Path: 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 08AF31AE223 for ; Thu, 21 Nov 2013 09:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.026 X-Spam-Level: X-Spam-Status: No, score=-15.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 PUK3Jcn9BVob for ; Thu, 21 Nov 2013 09:12:03 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 90BA31AE058 for ; Thu, 21 Nov 2013 09:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=541; q=dns/txt; s=iport; t=1385053917; x=1386263517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=asj/qmYjHLgef2CbasiQ4dW92HjdP0gG+jJyyjVbmKA=; b=JHqTaSivZtt2sCI5W+mL9tkOLHSwicmAaryM8ONLug+c23acTER18yJ+ CFLizAvtBiXfOl86gW6qmhlUeCUazPa9g1RKB7U+fu95TDn8Oc0Tjwuu4 in9RcIXButwld5rWdIq6Z2uJf1POSxGv/4HJwh7D7hW2fVPfZqhkyPKQA M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAHo+jlKtJV2Z/2dsb2JhbABZgwc4U7xVgSQWdIImAQEEOj8QAgEINhAyJQIEAQ0FiAENwS+PaweEMgOYEoEwkGCBaoE+gio X-IronPort-AV: E=Sophos;i="4.93,745,1378857600"; d="scan'208";a="286658694" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 21 Nov 2013 17:11:44 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rALHBhEo001765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Nov 2013 17:11:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 11:11:43 -0600 From: "Joe Hildebrand (jhildebr)" To: John Cowan , Henri Sivonen Thread-Topic: [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft) Thread-Index: AQHO5r6VKgdHQsNE0EGiwiUr0CS8opowTEWAgAAVFIA= Date: Thu, 21 Nov 2013 17:11:43 +0000 Message-ID: References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> In-Reply-To: <20131121165615.GA12138@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.147.19.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <4A837F9B48D3894A829956425AF572A9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: es-discuss , JSON WG , Paul Hoffman , "www-tag@w3.org" , Pete Cordell 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 17:12:05 -0000 On 11/21/13 5:56 PM, "John Cowan" wrote: >We have therefore decided in the 4627bis effort not to say >that anything that was previously valid is now invalid. At least, that >is what I understand us to be doing. Specifically, the charter (http://datatracker.ietf.org/wg/json/charter/) says: "Any changes that break compatibility with existing implementations of either RFC 4627 or the ECMAScript specification will need to have very strong justification and broad support." --=20 Joe Hildebrand From allen@wirfs-brock.com Thu Nov 21 09:01:27 2013 Return-Path: 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 DC7361AE03D; Thu, 21 Nov 2013 09:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 gwUtrEDRcrJK; Thu, 21 Nov 2013 09:01:25 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 455861AE009; Thu, 21 Nov 2013 09:01:25 -0800 (PST) Received: from [66.201.52.99] (helo=[10.71.1.199]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1VjXcq-000704-Bb; Thu, 21 Nov 2013 17:01:09 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 66.201.52.99 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19cPuXhUQVsdf+RIThO9TSleB53aSAMUKQ= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Allen Wirfs-Brock In-Reply-To: Date: Thu, 21 Nov 2013 09:01:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <50CFBDEE-53A5-4159-93C4-348CF31EC8EF@wirfs-brock.com> References: <20131113224737.GI31823@mercury.ccil.org> <5284B095.4070004@it.aoyama.ac.jp> <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> To: Henri Sivonen X-Mailer: Apple Mail (2.1085) X-Mailman-Approved-At: Thu, 21 Nov 2013 09:17:41 -0800 Cc: IETF Discussion , John Cowan , "Henry S. Thompson" , Pete Cordell , JSON WG , "t.p." , =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= , Anne van Kesteren , www-tag , es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 17:01:28 -0000 On Nov 21, 2013, at 5:28 AM, Henri Sivonen wrote: > On Thu, Nov 21, 2013 at 7:53 AM, Allen Wirfs-Brock > wrote: >> Just to be clear about this. My tests directly tested JavaScript = built-in >> JSON parsers WRT to BOM support in three major browsers. The tests = directly >> invoked the built-in JSON.parse functions and directly passed to them = a >> source strings that was explicitly constructed to contain a BOM code = point . >> This was done to ensure that the all transport layers (and any = transcodings >> they might perform) were bypassed and that we were actually testing = the real >> built-in JSON parse functions. >=20 > It would be surprising if JSON.parse() accepted a BOM, since it > doesn't take bytes as input. ECMAScript's JSON.parse accepts an ECMAScript string value as its input. = ECMAScript strings are sequences of 16-bit values. JSON.parse (and = most other ECMAScript functions) interpret those values as Unicode code = units. The value U+FEFF can appear at any position within a string. = When defining a string as an ECMAScript literal, a sequence like \ufeff = is an escape sequence that means place the code unit value 0xefff into = the string at this position in the sequence. Also note that the actual = strings passed below to JSON.parse contain the actual code point value = U+FEFF not the escape sequence that was used to express it. To include = the actual escape sequence characters in the string it would have to be = expressed as '\\feff'. JSON.parse('\ufeff ["XYZ"]'); //note outer quotes delimit an ECMAScript = string, the inner quotes are a JSON string. =20 throws a runtime SyntaxError exception because the JSON grammar does not = allow U+FEFF to appear that position JSON.parse('["\ufeffXYZ"]'); operates without error and returns a Array containing a four element = ECMAScript string. This works because the JSON grammar allows any code = unit except for " and \ and the ASCII control characters to appear = literally in a JSON string.=20 >=20 > However, XHR's responseType =3D "json" exercises browsers in a way = where > the input is bytes from the network. =46rom the perspective of JSON > support in XHR, > http://lists.w3.org/Archives/Public/www-tag/2013Nov/0149.html (which > didn't reach the es-discuss part of this thread previously) applies. Right, JSON use via XHR is a different usage scenario and that probably = involves encoding and decoding steps. It has very little to do with the = JSON syntax, as defined in ECMA-404. It's all about how the bits that = represent a string are interchanged, not the eventual semantic = processing of the string (ie, processing by JSON.parse or some other = JSON parser) Allen From derhoermi@gmx.net Thu Nov 21 09:41:23 2013 Return-Path: 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 AC88F1AE19E for ; Thu, 21 Nov 2013 09:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-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 HtcmTl3znbps for ; Thu, 21 Nov 2013 09:41:22 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id E6E791AE061 for ; Thu, 21 Nov 2013 09:41:21 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.32.80]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MP1PX-1VmaeJ22sB-006P9x for ; Thu, 21 Nov 2013 18:41:10 +0100 From: Bjoern Hoehrmann To: Allen Wirfs-Brock Date: Thu, 21 Nov 2013 18:41:08 +0100 Message-ID: References: <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> <50CFBDEE-53A5-4159-93C4-348CF31EC8EF@wirfs-brock.com> In-Reply-To: <50CFBDEE-53A5-4159-93C4-348CF31EC8EF@wirfs-brock.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:/p/FaV+USUSg7/+VFFX7xw+HaehHgtAz+dHPxB41DWwvuQ74Wod R0ES8Iiqrq2dlx5JxIOPyF1zMR/1I2haMfwikbS9lffoxLdr/Yx5RwmDGwvDVQkHgec8bYq FNOpMgulbKyGgp+eb5ltar1DkDfgjTFLSocnGdR3tVehyXtQ8L85oT92dggY5ijs+SaJQ1J df9sGFjQSnbxesvyGOewQ== Cc: Henri Sivonen , es-discuss , IETF Discussion , www-tag , JSON WG Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 17:41:23 -0000 * Allen Wirfs-Brock wrote: >On Nov 21, 2013, at 5:28 AM, Henri Sivonen wrote: >> On Thu, Nov 21, 2013 at 7:53 AM, Allen Wirfs-Brock >> wrote: >>> Just to be clear about this. My tests directly tested JavaScript built-in >>> JSON parsers WRT to BOM support in three major browsers. The tests directly >>> invoked the built-in JSON.parse functions and directly passed to them a >>> source strings that was explicitly constructed to contain a BOM code point . >> It would be surprising if JSON.parse() accepted a BOM, since it >> doesn't take bytes as input. > >ECMAScript's JSON.parse accepts an ECMAScript string value as its input. >ECMAScript strings are sequences of 16-bit values. JSON.parse (and most >other ECMAScript functions) interpret those values as Unicode code >units. The value U+FEFF can appear at any position within a string. >When defining a string as an ECMAScript literal, a sequence like \ufeff >is an escape sequence that means place the code unit value 0xefff into >the string at this position in the sequence. Also note that the actual >strings passed below to JSON.parse contain the actual code point value >U+FEFF not the escape sequence that was used to express it. To include >the actual escape sequence characters in the string it would have to be >expressed as '\\feff'. A byte order mark indicates the order of bytes in a sequence of bytes. An ecmascript string is not a sequence of bytes and therefore it cannot have a byte order mark inside it. Your test is not for BOM support but for an egregious semantic error in the implementation of JSON.parse. http://shadowregistry.org/js/misc/#t2ea25a961255bb1202da9497a1942e09 That is a similar test. It makes Firefox see UTF-8 BOMs in ecmascript strings. Firefox is not supposed to look for UTF-8 BOMs in ecmascript strings because ecmascript strings are not sequences of bytes at that level of reasoning. Is there any chance, by the way, to change `JSON.stringify` so it does not output strings that cannot be encoded using UTF-8? Specifically, JSON.stringify(JSON.parse("\"\uD800\"")) would need to escape the surrogate instead of emitting it literally. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From mathias@qiwi.be Thu Nov 21 10:52:58 2013 Return-Path: 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 B49F31AE249 for ; Thu, 21 Nov 2013 10:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 Or2TfCbW6l0g for ; Thu, 21 Nov 2013 10:52:56 -0800 (PST) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFB21AE0A2 for ; Thu, 21 Nov 2013 10:52:56 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id i13so3411939qae.16 for ; Thu, 21 Nov 2013 10:52:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=w2E57l5Hrc6MErCYcPCi386vI82DodJ72Qxjvluslyc=; b=WObbALpnuWFAAG3Y+e5PstoxqVG8O+lgNIvRSQMiRJlIlgi8gCwLQ8NTEZVRRJGzG+ fjp9Bw9CVFUpXpy0yMKDV4G3btKY0yagsUnuM0SfiJgP7/lsK6lOTLogu/OFG7EZdVsm S12Wszr3ipOJNJBAO7oShvWbzfu2r28Dv2KnmSovzOOInrMfSlkjHsxoG2orPrq77jDI aVbT3DRK5UCsPOKhuBWKFwn4qhFtTTUi8KZJvnXfBI6T/pbRVEa98G/IRNqS9D1sp31k WTaJPjwxWCj6ULc4YJl8iUWoKKcS0VUFf+FTLwaeR0YMnAKWRQk60V4hn57ghnp7vWnT mfdg== X-Gm-Message-State: ALoCoQlWy66PQsHBdrlKn5E49Sf7LQA4PdPj/wKlY3H4JVw9rGQFAakcv5lKXjNLsdCdJLUJ6vEw X-Received: by 10.224.152.14 with SMTP id e14mr14146958qaw.36.1385059969336; Thu, 21 Nov 2013 10:52:49 -0800 (PST) Received: from ?IPv6:2620::1001:fd01:1ddb:9747:171d:d1c1? ([2620:0:1001:fd01:1ddb:9747:171d:d1c1]) by mx.google.com with ESMTPSA id nq5sm18291188qeb.8.2013.11.21.10.52.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 10:52:48 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Mathias Bynens In-Reply-To: Date: Thu, 21 Nov 2013 10:52:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1963DFEA-F4ED-42A8-98D4-4F5A99076136@qiwi.be> References: <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> <50CFBDEE-53A5-4159-93C4-348CF31EC8EF@wirfs-brock.com> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1822) X-Mailman-Approved-At: Thu, 21 Nov 2013 10:54:59 -0800 Cc: Allen Wirfs-Brock , IETF Discussion , JSON WG , Henri Sivonen , www-tag , es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 18:53:52 -0000 On 21 Nov 2013, at 09:41, Bjoern Hoehrmann wrote: > Is there any chance, by the way, to change `JSON.stringify` so it does > not output strings that cannot be encoded using UTF-8? Specifically, >=20 > JSON.stringify(JSON.parse("\"\uD800\"")) >=20 > would need to escape the surrogate instead of emitting it literally. Previous discussion: = http://esdiscuss.org/topic/code-points-vs-unicode-scalar-values#content-14= From cowan@ccil.org Thu Nov 21 11:16:01 2013 Return-Path: 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 14EE41AE064; Thu, 21 Nov 2013 11:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525] 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 7tKue4SM7VLV; Thu, 21 Nov 2013 11:16:00 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id D54751AE048; Thu, 21 Nov 2013 11:15:59 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VjZiv-0008Ok-Fk; Thu, 21 Nov 2013 14:15:33 -0500 Date: Thu, 21 Nov 2013 14:15:33 -0500 From: John Cowan To: Bjoern Hoehrmann Message-ID: <20131121191533.GC12138@mercury.ccil.org> References: <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> <50CFBDEE-53A5-4159-93C4-348CF31EC8EF@wirfs-brock.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Allen Wirfs-Brock , IETF Discussion , JSON WG , Henri Sivonen , www-tag , es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 19:16:01 -0000 Bjoern Hoehrmann scripsit: > Is there any chance, by the way, to change `JSON.stringify` so it does > not output strings that cannot be encoded using UTF-8? Specifically, > > JSON.stringify(JSON.parse("\"\uD800\"")) > > would need to escape the surrogate instead of emitting it literally. No, there isn't. We've been down this road repeatedly. People can and do use JSON strings to encode arbitrary sequences of unsigned 16-bit integers. -- You let them out again, Old Man Willow! John Cowan What you be a-thinking of? You should not be waking! cowan@ccil.org Eat earth! Dig deep! Drink water! Go to sleep! Bombadil is talking. http://ccil.org/~cowan From derhoermi@gmx.net Thu Nov 21 11:38:00 2013 Return-Path: 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 B70B41AE092 for ; Thu, 21 Nov 2013 11:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 jVIb124a1zf4 for ; Thu, 21 Nov 2013 11:37:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3CA1AE14B for ; Thu, 21 Nov 2013 11:37:59 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.61.205]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0M0QLp-1VP2Re2KhZ-00uWP8 for ; Thu, 21 Nov 2013 20:37:52 +0100 From: Bjoern Hoehrmann To: John Cowan Date: Thu, 21 Nov 2013 20:37:49 +0100 Message-ID: <8qns8959uu813f01i1pr5mg2h0676vimg5@hive.bjoern.hoehrmann.de> References: <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> <50CFBDEE-53A5-4159-93C4-348CF31EC8EF@wirfs-brock.com> <20131121191533.GC12138@mercury.ccil.org> In-Reply-To: <20131121191533.GC12138@mercury.ccil.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:BGfIctdeKAg870qblxTS+TRbpCv0opZ5TWGXJaWW6zBOfKOKibe /o5BEDnoWV/5vvk8FJDdnmozkC7sQqFmMsP7nQs1dc2D72RjW69A4IsNQZ5dSO5jy/cObMl 6ysogob80va8vNEVokVfzwZPRuk02DM4ruHZTOnXY4ULC4+05I6441c9mURuIh/LYQRNOBW /2yJr/WyLlImdK80bLISw== Cc: JSON WG , IETF Discussion , www-tag , es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 19:38:00 -0000 * John Cowan wrote: >Bjoern Hoehrmann scripsit: > >> Is there any chance, by the way, to change `JSON.stringify` so it does >> not output strings that cannot be encoded using UTF-8? Specifically, >> >> JSON.stringify(JSON.parse("\"\uD800\"")) >> >> would need to escape the surrogate instead of emitting it literally. > >No, there isn't. We've been down this road repeatedly. People can and >do use JSON strings to encode arbitrary sequences of unsigned 16-bit integers. The output of JSON.stringify("\uD800") contains no backslash character, if you call `utf8_encode(JSON.stringify("\uD800"))` you get an exception because UTF-8 cannot encode the lone surrogate and `utf8_encode` does not know it could encode it as `\uD800` without loss of information. If `JSON.stringify` produced an escape sequence instead, there would be no problem passing the output to `utf8_encode`. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From nico@cryptonector.com Thu Nov 21 11:58:24 2013 Return-Path: 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 D58851AE17E; Thu, 21 Nov 2013 11:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] 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 5VfdNuRbx9DW; Thu, 21 Nov 2013 11:58:24 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 233DF1AE23F; Thu, 21 Nov 2013 11:58:23 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 7AD5F1E064; Thu, 21 Nov 2013 11:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5KDkM/G3D0FHMG3sDNdk WfK68O4=; b=a8Yi/ze54R+d7HC7fow6T/D6SNBdthxCU+ib5IHnNc3dXWpa2JkT vDScwtkM/fG9n180m8l/5/jK8Z2Og5xJQl894KzvjSND8X8XYRZptLxIXKpT7wdO jBIATf9U7cz5CWxdG/paHQmsKUprfg+VasoF7RnHMA2LR2niJCn8/ZQ= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id EADF71E05D; Thu, 21 Nov 2013 11:58:15 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id b13so229280wgh.34 for ; Thu, 21 Nov 2013 11:58:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I5Bk+awGK4RogfmUskT5WO2wCRudinrfhU/JVLN3JG4=; b=C66z3SuSxwU+kqWL6j32/ViKk8cld74TybUWuPU+IvRUwMiOrsa9MlXwSvuvptlLSb arK0M25hA/jL1T2c7g7vofgmV1vB2jSAcSoaeX3Fvgh01p1Ng4wUw2bwvj459GaTWYmB Z3UM6gOFMgJViCWyvrn2XMmaFuM93uPEMsxXkqIl/e3rXyd5CBzL8yZlDtgfSv3AL6zC ic38SK7CNaF4RBwrvdiG+wNZnnj7UvkSjPlD5sVTN1/boLp3461nKk2mmMbpzTuOiHVe z1pa5uqXalyGUBMPHj9blcqj6qjjYGBTNJC43Npmqe41s2cRSPh1n0rnr0FNct92AInr vcbg== MIME-Version: 1.0 X-Received: by 10.194.84.72 with SMTP id w8mr3040716wjy.55.1385063894096; Thu, 21 Nov 2013 11:58:14 -0800 (PST) Received: by 10.216.151.136 with HTTP; Thu, 21 Nov 2013 11:58:13 -0800 (PST) In-Reply-To: <8qns8959uu813f01i1pr5mg2h0676vimg5@hive.bjoern.hoehrmann.de> References: <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> <50CFBDEE-53A5-4159-93C4-348CF31EC8EF@wirfs-brock.com> <20131121191533.GC12138@mercury.ccil.org> <8qns8959uu813f01i1pr5mg2h0676vimg5@hive.bjoern.hoehrmann.de> Date: Thu, 21 Nov 2013 13:58:13 -0600 Message-ID: From: Nico Williams To: Bjoern Hoehrmann Content-Type: text/plain; charset=UTF-8 Cc: es-discuss , John Cowan , IETF Discussion , www-tag , JSON WG Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 19:58:25 -0000 On Thu, Nov 21, 2013 at 1:37 PM, Bjoern Hoehrmann wrote: > * John Cowan wrote: >>Bjoern Hoehrmann scripsit: >> >>> Is there any chance, by the way, to change `JSON.stringify` so it does >>> not output strings that cannot be encoded using UTF-8? Specifically, >>> >>> JSON.stringify(JSON.parse("\"\uD800\"")) >>> >>> would need to escape the surrogate instead of emitting it literally. >> >>No, there isn't. We've been down this road repeatedly. People can and >>do use JSON strings to encode arbitrary sequences of unsigned 16-bit integers. > > The output of JSON.stringify("\uD800") contains no backslash character, > if you call `utf8_encode(JSON.stringify("\uD800"))` you get an exception > because UTF-8 cannot encode the lone surrogate and `utf8_encode` does > not know it could encode it as `\uD800` without loss of information. If > `JSON.stringify` produced an escape sequence instead, there would be no > problem passing the output to `utf8_encode`. That's just one implementation. We had hundreds of e-mails in this list about this. Well over a thousand to cover several issues like this. I think the only area where we have [roughly] consensus to revisit the previous consensus is the top-level value restriction, which has led to the whole UTF and byte-order detection sub-thread (which we had, also, had before). We're on much stronger ground to revisit this one matter than the whole unpaired surrogates matter, and we're much much less likely to change our consensus on that because one proposal is about relaxing JSON to match ECMAScript's definition, while yours is to do the opposite. Nico -- From hsivonen@hsivonen.fi Fri Nov 22 01:22:46 2013 Return-Path: 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 433FE1AE337 for ; Fri, 22 Nov 2013 01:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 wvIjwFv-y30s for ; Fri, 22 Nov 2013 01:22:44 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DE5631AE353 for ; Fri, 22 Nov 2013 01:22:42 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id wp18so1016918obc.16 for ; Fri, 22 Nov 2013 01:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hsivonen.fi; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GbW/kfLHSNDBuI9z/WAXzIXLW0x0/0ijYTmn2locDyk=; b=cgNeGobNA3fjMZF37nyJA3qSGQdI3HjwAMAH9FzxwiRadoX7Tm37twD1Ey+z3t//oL eJOLgmQUOOryASzDwhTIQHa+E0cpHEH1TuwFrYmx31LrR310PstWzICy4jBS0Q/JYllO DQt5wwpqJj+sbNOI1tgqppC0R7SqUeY6MFJhE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GbW/kfLHSNDBuI9z/WAXzIXLW0x0/0ijYTmn2locDyk=; b=QZIxyrnRXiIxsMoOaLmi7rRrvOHj+aodwFYpgcFbsrZtdMiSFwD1NOEW5jgvAhHPrd eFGxYF2V7saxYFtDQTmRFvK014aH/V7cmsosbjojIP6JLFD+SAlxsNPTRLG241y5m81o 4LfNIB4oVZCZjLsdkjAGcT5kkB9IIthG0Fidg97eYhCiX/AO1UMtj79/g0T/H+G11Jr6 RfQpb+K84OrCwfYPn7VqjxCCbpPZ37UHq+Q2YsM8996kg640W9p89jCIBHQnSKG9NLq3 l41udKsEZ3Rb9LY8O+0cOB0jdMWL8SWNGaxOb4nk0Y/ZUkCCLkaJ/pNT8wXA2kfE1Bho PHGQ== X-Gm-Message-State: ALoCoQlGD5DcWGN53qlRdV9THNecn/a6bsHk3UntA3BuwI3WwntqyGqMiuXTjQbgPxc9DLtm1mJV MIME-Version: 1.0 X-Received: by 10.182.28.35 with SMTP id y3mr1192463obg.55.1385112155665; Fri, 22 Nov 2013 01:22:35 -0800 (PST) Received: by 10.182.119.130 with HTTP; Fri, 22 Nov 2013 01:22:35 -0800 (PST) In-Reply-To: <20131121165615.GA12138@mercury.ccil.org> References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> Date: Fri, 22 Nov 2013 11:22:35 +0200 Message-ID: From: Henri Sivonen To: John Cowan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Pete Cordell , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , "www-tag@w3.org" , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 09:22:46 -0000 On Thu, Nov 21, 2013 at 3:39 PM, Anne van Kesteren wrote= : > XHR's responseType =3D "json" only supports UTF-8 (optionally with a > leading BOM), across the board. Good point. I wrote the code that enforces that constraint, but I forgot. Well, there's an interoperability reason against UTF-16, too, then. On Thu, Nov 21, 2013 at 6:56 PM, John Cowan wrote: > Henri Sivonen scripsit: > >> Why not? Surely existing still deployed producers should be what >> matters when deciding what needs to be ingested--not previous specs. >> That is, compatibility should be considered in terms of what's out >> there--not in terms of what unreasonable things were written down in a >> previous RFC. > > In principle, maybe. But testing a dozen browsers isn't enough here. > We simply don't know how much non-browser traffic involves JSON (though > we know there are many such interactions), or what representations they > are using. We have therefore decided in the 4627bis effort not to say > that anything that was previously valid is now invalid. At least, that > is what I understand us to be doing. Even if no one or approximately no one (outside test cases) actually emits JSON in UTF-32? >> UTF-32 harms JSON interchange, because Gecko removed all UTF-32 >> support throughout the engine (other engines probably did, too, but >> I'm too busy to check) and, therefore, XHR responseType =3D "json" >> doesn't support UTF-32. > > That has about as much weight as "XYZ implementation only supports > ASCII, so the use of non-ASCII characters harms JSON interchange" or "ABC > implementation only supports 32-bit integers, so the use of decimal point= s > harms JSON interchange." An implementation's self-imposed limitations > don't affect the standard. Well, what (broadly deployed) running code does affects interoperability regardless of who imposed the behavior. (In this case, the behavior is imposed by a spec: the XHR spec requires that JSON be always treated as UTF-8.) On Thu, Nov 21, 2013 at 7:11 PM, Joe Hildebrand (jhildebr) wrote: > Specifically, the charter (http://datatracker.ietf.org/wg/json/charter/) > says: > > "Any changes that break compatibility with existing implementations of > either RFC 4627 or the ECMAScript specification will need to have very > strong justification and broad support." "existing implementations" =E2=89=A0 "existing specs" I think you should have to show an existing implementation with substantial deployment that in its substantially deployed configuration emits JSON in UTF-32 to have a justification for keeping UTF-32 in the spec. (I have to wonder what kind of theorizing was the cause of putting UTF-32 in the spec in the first place. I also have to wonder if the IETF JSON spec would have supported UTF-64 for completeness if someone had written an April 1st RFC for UTF-64.) --=20 Henri Sivonen hsivonen@hsivonen.fi http://hsivonen.fi/ From petejson@codalogic.com Fri Nov 22 03:32:47 2013 Return-Path: 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 095931AD8F7 for ; Fri, 22 Nov 2013 03:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.736 X-Spam-Level: ** X-Spam-Status: No, score=2.736 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 TwcXaQFTgsUv for ; Fri, 22 Nov 2013 03:32:45 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id BEB151AD7C1 for ; Fri, 22 Nov 2013 03:32:44 -0800 (PST) Received: (qmail 19681 invoked from network); 22 Nov 2013 11:32:16 +0000 Received: from host86-167-12-24.range86-167.btcentralplus.com (HELO codalogic) (86.167.12.24) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 22 Nov 2013 11:32:15 +0000 Message-ID: <54E53D571E5E4589B2E9FA17DC816002@codalogic> From: "Pete Cordell" To: "Henri Sivonen" , "John Cowan" References: <8413609C8A86497F856897AF2AA24960@codalogic><20131120223305.GB5476@mercury.ccil.org><20131121165615.GA12138@mercury.ccil.org> X-Unsent: 1 Date: Fri, 22 Nov 2013 11:33:14 -0000 x-vipre-scanned: 0046AE8B005C3A0046AFD8 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: es-discuss , JSON WG , www-tag@w3.org, "Joe Hildebrand \(jhildebr\)" , Paul Hoffman 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 11:32:47 -0000 ----- Original Message From: "Henri Sivonen" >On Thu, Nov 21, 2013 at 3:39 PM, Anne van Kesteren >wrote: >> XHR's responseType = "json" only supports UTF-8 (optionally with a >> leading BOM), across the board. > > Good point. I wrote the code that enforces that constraint, but I forgot. > > Well, there's an interoperability reason against UTF-16, too, then. Personally I think we have to be careful not to fall into the trap of assuming that the only use-case for JSON will be in "to browser" communications. I'm hoping that for the IETFs purposes we'll be looking at JSONs wider utility into broader areas, which may even include logging to files and interprocess communication where there might be sensible reasons to choose something other than UTF-8. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From julian.reschke@gmx.de Fri Nov 22 04:26:46 2013 Return-Path: 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 288C01AD9B8 for ; Fri, 22 Nov 2013 04:26:46 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 oUJF3UN_WX31 for ; Fri, 22 Nov 2013 04:26:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 688D41AD947 for ; Fri, 22 Nov 2013 04:26:44 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MHal6-1VgWQa1RqG-003Pwi for ; Fri, 22 Nov 2013 13:26:36 +0100 Message-ID: <528F4D74.6030903@gmx.de> Date: Fri, 22 Nov 2013 13:26:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Robin Berjon , Pete Cordell , Henri Sivonen , John Cowan References: <8413609C8A86497F856897AF2AA24960@codalogic><20131120223305.GB5476@mercury.ccil.org><20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <528F445B.2060506@w3.org> In-Reply-To: <528F445B.2060506@w3.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sHV4sseZKorm/zKwQo4VeW3mtpqes8eaBt3rdQFOIu79hxKhFNy qKhlsDs6VzGdB/PNvoIurzr/fo/HLOgJ/6fSGYEGGbYU4GXm6auPhrpAxCRTpUalatniAgm jspMZbBNLNFUY6vTR/lzITusy6obf9D1W4Nv4qwM24ndewwBE4Z4CHQ7fp2z4Cgw6SJhyk5 jnz9BEqBRzsQsgmRRRRKA== Cc: es-discuss , JSON WG , www-tag@w3.org, "Joe Hildebrand \(jhildebr\)" , Paul Hoffman 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 12:26:46 -0000 On 2013-11-22 12:47, Robin Berjon wrote: > On 22/11/2013 12:33 , Pete Cordell wrote: >> ----- Original Message From: "Henri Sivonen" >>> On Thu, Nov 21, 2013 at 3:39 PM, Anne van Kesteren >>> wrote: >>>> XHR's responseType = "json" only supports UTF-8 (optionally with a >>>> leading BOM), across the board. >>> >>> Good point. I wrote the code that enforces that constraint, but I >>> forgot. >>> >>> Well, there's an interoperability reason against UTF-16, too, then. >> >> Personally I think we have to be careful not to fall into the trap of >> assuming that the only use-case for JSON will be in "to browser" >> communications. I'm hoping that for the IETFs purposes we'll be looking >> at JSONs wider utility into broader areas, which may even include >> logging to files and interprocess communication where there might be >> sensible reasons to choose something other than UTF-8. > > Sure, but given the prominence of JSON communicated to the browser, it > would be a pretty bad idea to have JSON variants that don't interoperate > there. For some value of "interoperate". Native JSON support in XHR is a relatively new feature (right?), and JSON has been used long before in the browser. Best regards, Julian From robin@w3.org Fri Nov 22 03:48:09 2013 Return-Path: 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 DA4A91AD738 for ; Fri, 22 Nov 2013 03:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.913 X-Spam-Level: X-Spam-Status: No, score=-5.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 x93OfAk2D5WT for ; Fri, 22 Nov 2013 03:48:06 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id E88C41ACCEA for ; Fri, 22 Nov 2013 03:48:05 -0800 (PST) Received: from [78.109.80.74] (helo=[192.168.10.8]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VjpD9-00087B-Ad; Fri, 22 Nov 2013 06:47:47 -0500 Message-ID: <528F445B.2060506@w3.org> Date: Fri, 22 Nov 2013 12:47:39 +0100 From: Robin Berjon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Pete Cordell , Henri Sivonen , John Cowan References: <8413609C8A86497F856897AF2AA24960@codalogic><20131120223305.GB5476@mercury.ccil.org><20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> In-Reply-To: <54E53D571E5E4589B2E9FA17DC816002@codalogic> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 22 Nov 2013 06:38:46 -0800 Cc: es-discuss , JSON WG , www-tag@w3.org, "Joe Hildebrand \(jhildebr\)" , Paul Hoffman 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 14:10:56 -0000 On 22/11/2013 12:33 , Pete Cordell wrote: > ----- Original Message From: "Henri Sivonen" >> On Thu, Nov 21, 2013 at 3:39 PM, Anne van Kesteren >> wrote: >>> XHR's responseType = "json" only supports UTF-8 (optionally with a >>> leading BOM), across the board. >> >> Good point. I wrote the code that enforces that constraint, but I forgot. >> >> Well, there's an interoperability reason against UTF-16, too, then. > > Personally I think we have to be careful not to fall into the trap of > assuming that the only use-case for JSON will be in "to browser" > communications. I'm hoping that for the IETFs purposes we'll be looking > at JSONs wider utility into broader areas, which may even include > logging to files and interprocess communication where there might be > sensible reasons to choose something other than UTF-8. Sure, but given the prominence of JSON communicated to the browser, it would be a pretty bad idea to have JSON variants that don't interoperate there. -- Robin Berjon - http://berjon.com/ - @robinberjon From cowan@ccil.org Fri Nov 22 08:39:43 2013 Return-Path: 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 D69EE1ADF72 for ; Fri, 22 Nov 2013 08:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525] 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 vLhW5vhP_NbX for ; Fri, 22 Nov 2013 08:39:41 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFCF1ADBE5 for ; Fri, 22 Nov 2013 08:39:41 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VjtlM-0007A9-Bq; Fri, 22 Nov 2013 11:39:24 -0500 Date: Fri, 22 Nov 2013 11:39:24 -0500 From: John Cowan To: Henri Sivonen Message-ID: <20131122163924.GC16749@mercury.ccil.org> References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Pete Cordell , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , "www-tag@w3.org" , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 16:39:44 -0000 Henri Sivonen scripsit: > Even if no one or approximately no one (outside test cases) actually > emits JSON in UTF-32? How on earth would you know that? > I think you should have to show an existing implementation with > substantial deployment that in its substantially deployed > configuration emits JSON in UTF-32 to have a justification for keeping > UTF-32 in the spec. As things now stand, there is zero support for removing anything from 4627bis. If you want to argue for an interoperability warning like the ones we already have, go ahead. Given the evidence you've shown, that's probably a good idea. But the watchword of 4627bis (as opposed to future I-JSON) is "No breaking changes. Anywhere. Ever." > (I have to wonder what kind of theorizing was the cause of putting > UTF-32 in the spec in the first place. I also have to wonder if the > IETF JSON spec would have supported UTF-64 for completeness if someone > had written an April 1st RFC for UTF-64.) You'll have to ask Mr. Crockford. -- Real FORTRAN programmers can program FORTRAN John Cowan in any language. --Ed Post cowan@ccil.org From tbray@textuality.com Fri Nov 22 08:39:59 2013 Return-Path: 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 D608B1ADBE5 for ; Fri, 22 Nov 2013 08:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 BbOh-800qIAL for ; Fri, 22 Nov 2013 08:39:57 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED941ADFD3 for ; Fri, 22 Nov 2013 08:39:57 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id p6so1070268vbe.27 for ; Fri, 22 Nov 2013 08:39:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lD3djPrjT2caQH01Hk0cAVcPkoQqT2VVyIfiwxtlVhs=; b=cD0ziIfXnv7nvBzppjErDZ04FNEmYXwkhNGvYbfDKb9hxMIg48cnURa01P+lt0oMDK QPKprqfGhpSGpmYvZOVRdzoTDr/k7Ffex4FABDXKLtzXzre6IAmzcIfYZDOjtzQ0OB8T 3NuOy1sKUVpy/JGFIE08XOipkzlxnvVXaWxH0BPhZlNReAr6leXA/q8peVRXBSjTPFuD WCpAclgfZ9olQ0mUUtjLdk8+027KIah9sE0pw9je4zsmsH5ExwqOm+q5YQ1UV60t4qzF UB+84oOZWY/BUKXn6TMNg9weTLtCX5CrzC+cBRzi3m1SIN+Lw72/jzOFtPaBEWPzAiL4 CI6Q== X-Gm-Message-State: ALoCoQnJbJj0xHfdeUssbDgp2DhkSIe6bBmAWdFV5aivAYDKyH0ptlLVBJDDeZVym1cmoCR3fVAd MIME-Version: 1.0 X-Received: by 10.52.103.35 with SMTP id ft3mr10325548vdb.5.1385138389649; Fri, 22 Nov 2013 08:39:49 -0800 (PST) Received: by 10.220.198.199 with HTTP; Fri, 22 Nov 2013 08:39:49 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <54E53D571E5E4589B2E9FA17DC816002@codalogic> References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> Date: Fri, 22 Nov 2013 08:39:49 -0800 Message-ID: From: Tim Bray To: Pete Cordell Content-Type: multipart/alternative; boundary=e89a8ff24d9bae24f604ebc6a965 Cc: John Cowan , Paul Hoffman , JSON WG , Henri Sivonen , "Joe Hildebrand \(jhildebr\)" , "www-tag@w3.org" , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 16:40:00 -0000 --e89a8ff24d9bae24f604ebc6a965 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99ve been using JSON for quite a few years, but hardly ever in eith= er 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=E2=80= =99ve 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=E2=80=99m still, hundreds of messages later, not 100% s= ure what our draft should say about BOMs :( On Fri, Nov 22, 2013 at 3:33 AM, Pete Cordell wrote= : > ----- Original Message From: "Henri Sivonen" > > On Thu, Nov 21, 2013 at 3:39 PM, Anne van Kesteren >> wrote: >> >>> XHR's responseType =3D "json" only supports UTF-8 (optionally with a >>> leading BOM), across the board. >>> >> >> Good point. I wrote the code that enforces that constraint, but I forgot= . >> >> Well, there's an interoperability reason against UTF-16, too, then. >> > > Personally I think we have to be careful not to fall into the trap of > assuming that the only use-case for JSON will be in "to browser" > communications. I'm hoping that for the IETFs purposes we'll be looking = at > JSONs wider utility into broader areas, which may even include logging to > files and interprocess communication where there might be sensible reason= s > to choose something other than UTF-8. > > > Pete Cordell > Codalogic Ltd > C++ tools for C++ programmers, http://codalogic.com > Read & write XML in C++, http://www.xml2cpp.com > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --e89a8ff24d9bae24f604ebc6a965 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I=E2=80=99ve been using JSON for quite a few years, but ha= rdly 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. = =C2=A0In those scenarios, it would be seen as wildly inappropriate to use a= nything but UTF-8; I=E2=80=99ve never actually seen anything else. =C2=A0In= practice, it would be very unlikely for anyone to deploy UTF-16 or any oth= er non-UTF-8 flavor in a non-browser scenario.

    Having said that, I=E2=80=99m still, hundreds of messages la= ter, not 100% sure what our draft should say about BOMs :(


    On Fri, Nov 22, 20= 13 at 3:33 AM, Pete Cordell <petejson@codalogic.com> wr= ote:
    ----- Original Message From: "Henri Siv= onen"

    On Thu, Nov 21, 2013 at 3:39 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
    XHR's responseType =3D "json" only supports UTF-8 (optionally= with a
    leading BOM), across the board.

    Good point. I wrote the code that enforces that constraint, but I forgot.
    Well, there's an interoperability reason against UTF-16, too, then.

    Personally I think we have to be careful not to fall into the trap of assum= ing that the only use-case for JSON will be in "to browser" commu= nications. =C2=A0I'm hoping that for the IETFs purposes we'll be lo= oking at JSONs wider utility into broader areas, which may even include log= ging to files and interprocess communication where there might be sensible = reasons to choose something other than UTF-8.


    Pete Cordell
    Codalogic Ltd
    C++ tools for C++ programmers, http://codalogic.com
    Read & write XML in C++, http://www.xml2cpp.com

    _______________________________________________
    json mailing list
    json@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/json

    --e89a8ff24d9bae24f604ebc6a965-- From allen@wirfs-brock.com Fri Nov 22 08:55:02 2013 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 In-Reply-To: Date: Fri, 22 Nov 2013 08:54:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> To: Tim Bray X-Mailer: Apple Mail (2.1085) Cc: John Cowan , Pete Cordell , Paul Hoffman , JSON WG , Henri Sivonen , "Joe Hildebrand \(jhildebr\)" , "www-tag@w3.org" , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=92ve 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=92ve 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. >=20 > Having said that, I=92m 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 From mamille2@cisco.com Fri Nov 22 10:21:31 2013 Return-Path: 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 A650D1AE171; Fri, 22 Nov 2013 10:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.026 X-Spam-Level: X-Spam-Status: No, score=-15.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 6YHUezsVrYyp; Fri, 22 Nov 2013 10:21:30 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 292EA1AE091; Fri, 22 Nov 2013 10:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1303; q=dns/txt; s=iport; t=1385144483; x=1386354083; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ePDgty1UwlI81VTGnLMpeXo6Bjf3ZwVjH5+UOZUUsvw=; b=MU9wCdEM1/hHnbABbkpr6YncHrYSNVBy2qy+VwM8L97X5j5rMtYC3DGy x62WJGP+WiivtFw9Ebup4bsbDiIiamcchsBGvNF+LDCZI5V7VrtEbHKKq YABodYa0tnMPwaAdUSjMAkfZkUfpe6UIvNT2Z72sQL1ICX0M9TQ7wXF2j s=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFACKgj1KtJV2c/2dsb2JhbABZgweBC7wVgSIWdIImAQEEeRACAU4yJQIEAQ0Th3PBJhePBweDIIESA5AxgTGGMpISgyiCKg X-IronPort-AV: E=Sophos;i="4.93,753,1378857600"; d="asc'?scan'208";a="283918230" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 22 Nov 2013 18:21:22 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAMILMsi010369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 18:21:22 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 12:21:21 -0600 From: "Matt Miller (mamille2)" To: JSON WG , IETF Discussion Thread-Topic: Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft) Thread-Index: AQHO56+kCU9hWLBMY0Kn85QC7BaHng== Date: Fri, 22 Nov 2013 18:21:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.44] Content-Type: multipart/signed; boundary="Apple-Mail=_79B7462D-88F1-4E50-8FE4-E1E8BDB2D4AC"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: "www-tag@w3.org" , es-discuss Subject: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:21:31 -0000 --Apple-Mail=_79B7462D-88F1-4E50-8FE4-E1E8BDB2D4AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There appears to be consensus to change JSON-text to allow for any JSON = value -- not just object / array -- while noting that object or array as = the top-level is the most interoperable. We will ask the Document Editor to make this change to = draft-ietf-json-rfc4627bis. - Paul Hoffman and Matt Miller --Apple-Mail=_79B7462D-88F1-4E50-8FE4-E1E8BDB2D4AC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSj6ChAAoJEDWi+S0W7cO1qpwH+wdcC4RcsmgM+YgfQDmbhc+0 QcwNIlTnzfo/TmGOHuHp68BcSCmU37Pbrh9ibFhMUzMqjR9JheHOWTSveXaHPh7L MrzzVtWJJYKsa2W+fyAhkorKJZl414q5wZB/O92pyQq1O5dIEXSv595PnMsKLIkp cMo/KqlR0VsOvPrlsJSiOjExPinuJBHfZLH7FGUM6I53mp4Uex1bmzFkLV8J03q0 h0VRGQ9gGij3HduxqwKroagcwnp2qmpYzVHJYOCo9JYEyJ9SbpyIQ3BQkdokQaUv EF/fMef9MsK4CmwBxliO0gU4GG0SDKM1rb7Zu7Bwi3MgT4v1plvtb0kSjKmK9fM= =K2W5 -----END PGP SIGNATURE----- --Apple-Mail=_79B7462D-88F1-4E50-8FE4-E1E8BDB2D4AC-- From mamille2@cisco.com Fri Nov 22 10:29:26 2013 Return-Path: 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 08D3D1ADF89; Fri, 22 Nov 2013 10:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.026 X-Spam-Level: X-Spam-Status: No, score=-15.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ZUwFh5gHpsTk; Fri, 22 Nov 2013 10:29:25 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CA7F01ADBE5; Fri, 22 Nov 2013 10:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1315; q=dns/txt; s=iport; t=1385144958; x=1386354558; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9zPsJQ9pbdu50TgB6oTA16kE2XNtnFY9iuCr9S46USo=; b=SfpWCZntmlmIo7rh3L2wdZpEISnBdLLn79kUDDc0HJS+XsPqAL0Llj+F YO4XNRFglcB14h6e0/MXBLzMcaxdjtx1a5TqAtSDuEW3x7+AedA+pa271 w9IUUnp+/G3yq4B4vsEpsl2EVOjbYPpVLUpUYvAI1CzVZNDpRQkQEJRuy M=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAD+ij1KtJV2Y/2dsb2JhbABZgweBC7wVgSIWdIImAQEEeRACAQhGMiUCBAENE4dzwScXjwcHgyCBEgOQMYExgk+DY5ISgyiCKg X-IronPort-AV: E=Sophos;i="4.93,753,1378857600"; d="asc'?scan'208";a="286933319" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 22 Nov 2013 18:29:02 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAMIT2dV007955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 18:29:02 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 12:29:02 -0600 From: "Matt Miller (mamille2)" To: IETF Discussion , JSON WG Thread-Topic: [Json] BOMs Thread-Index: AQHO5VjqYoK0+ygbbEegiH/v100NRpouCp6AgAGLPgCAAH85gIAAO1GAgAALNQCAAZ+1AA== Date: Fri, 22 Nov 2013 18:29:01 +0000 Message-ID: <11233CA7-B075-483D-A1C3-3BF6CF91AEE3@cisco.com> References: <5289F974.9020709@it.aoyama.ac.jp> <020401cee50f$a2cdf5c0$4001a8c0@gateway.2wire.net> <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> <50CFBDEE-53A5-4159-93C4-348CF31EC8EF@wirfs-brock.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.44] Content-Type: multipart/signed; boundary="Apple-Mail=_F7B57A2D-EBBE-4841-BC75-843E01A14660"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: www-tag , es-discuss Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:29:26 -0000 --Apple-Mail=_F7B57A2D-EBBE-4841-BC75-843E01A14660 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 There does not appear to be any consensus on explicitly allowing or = disallowing of a Byte Order Mark (BOM). Neither RFC4627 nor the current = draft mention BOM anywhere, and the modus operandi of the JSON Working = Group has been to leave text unchanged unless there was wide support. - Paul Hoffman and Matt Miller --Apple-Mail=_F7B57A2D-EBBE-4841-BC75-843E01A14660 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSj6JsAAoJEDWi+S0W7cO11s4H/08DHyLEVHwLJNV4SfOOe4di 11N6YWISjq3aYZeooAgoPUEajvsnKQSVcFP4Sjk9RutaQYP+QpFWIX7wTviK8NVI LADxZgUT6M0Z9efNf9ImJknoylotKMbL+t7xArxFiFz3zkZ3cFCXiUF0uLn4LMo8 3tSg+AWjjRESjogj5FJMFpZ3VnFZZlBtrbwRToowPXAflS3188FVdYNZb0DZ6UtT YlvL5zvB+FOI1Ex2SCAVofRyyajgYlmLp4d86BcKJUiocuQd1zLDpPLfmSZbk2z2 B7Gqyk/Bu9UefGSNEm0YESjXMLDhpnZN5Ftfa/D4Dp/7vLywdXia8bnuOBdWpbA= =qE3g -----END PGP SIGNATURE----- --Apple-Mail=_F7B57A2D-EBBE-4841-BC75-843E01A14660-- From mamille2@cisco.com Fri Nov 22 10:34:03 2013 Return-Path: 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 1AC291ADF50 for ; Fri, 22 Nov 2013 10:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_QUOTING=0.001] 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 wn2isDY2kK_2 for ; Fri, 22 Nov 2013 10:34:01 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A89BC1ADBE5 for ; Fri, 22 Nov 2013 10:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1522; q=dns/txt; s=iport; t=1385145235; x=1386354835; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WMqZGFmP55G4cr/oWmHqmodiO7XlmDkKlj02qWhJuf8=; b=UbEzbELGHFzMVxoE+RzkVG98/9NfoY1qFKEw6pLgNSuH3Vk8I2NO3TS5 O9ZN4DsghdLF1tBS0GJLTMRtYtWQeoEEjsi2U0LNqYUriV+5/bcgjNPFK c8nSi7i9kQa46imBQwbroj9Q7icHUs+YXWS6m5KV6mVx8S1ppBAMOfwTv w=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAGejj1KtJXG8/2dsb2JhbABZgweBC7wVgSIWdIImAQEEeRACAQhGMiUCBA4Th3PBKRePBweDIIESA5AxgTGGMpISgWqBPoIq X-IronPort-AV: E=Sophos;i="4.93,753,1378857600"; d="asc'?scan'208";a="287001365" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 22 Nov 2013 18:33:29 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAMIXTJ4006894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 18:33:29 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 12:33:28 -0600 From: "Matt Miller (mamille2)" To: JSON WG Thread-Topic: [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft) Thread-Index: AQHO56OXMx7gKyfCUka1bFVpYArVZpox9/mA Date: Fri, 22 Nov 2013 18:33:28 +0000 Message-ID: References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.44] Content-Type: multipart/signed; boundary="Apple-Mail=_2C7E5064-E6DE-4A2C-9A08-ACD983335BD4"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: "www-tag@w3.org" , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:34:03 -0000 --Apple-Mail=_2C7E5064-E6DE-4A2C-9A08-ACD983335BD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 There does seem to be rough consensus that using an encoding other than = UTF-8 can have interoperability issues. The also seems to be rough = consensus that the current text and table in section 8.1 for detecting = the encoding will be inaccurate (and potentially harmful). That appears to mean the approach with the most consensus is to remove = the encoding detection entirely, leaving only: """" JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. """" - Paul Hoffman and Matt Miller --Apple-Mail=_2C7E5064-E6DE-4A2C-9A08-ACD983335BD4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSj6N4AAoJEDWi+S0W7cO1MNoH+wbK2AMru2LYEEBNyh9DO62n 1r+DyO/B+xYgqhFc+cY2fvGqNNdyOFuZFEyxqYiPNcdkLeh8l3E/sWs8aAUDvFK2 7lFbRIiurB4vQHYjR7CYIYqQ9FD9rwcN8QMkejJn4ok21cFus9cmTNf98Srk2Pou 23QsACMrJMYAj8pCqt+i0hE7KYm64Gz6Q6LWQfLzt4W4K8wh4Oq/N1H92AiiLb/k T6lFxhGrqNISsDMAof3DshSr8lITKuaO/3dvNqLK9vX+4m95TBMAQV45d4i3MJSc QdMEoaSszG/r37ek+dOCGAjAWHnhO0OvP8cJsBRCYq9xmWqLD6I8eMvwXUH9WOs= =ukP8 -----END PGP SIGNATURE----- --Apple-Mail=_2C7E5064-E6DE-4A2C-9A08-ACD983335BD4-- From julian.reschke@gmx.de Fri Nov 22 10:41:56 2013 Return-Path: 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 83B6C1AE1F7 for ; Fri, 22 Nov 2013 10:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] 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 Fu31pgX8mTBz for ; Fri, 22 Nov 2013 10:41:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 026451AE20C for ; Fri, 22 Nov 2013 10:41:55 -0800 (PST) Received: from [192.168.2.117] ([93.217.106.3]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MGzwE-1VwYz73Fje-00Drzq for ; Fri, 22 Nov 2013 19:41:47 +0100 Message-ID: <528FA55F.30000@gmx.de> Date: Fri, 22 Nov 2013 19:41:35 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Matt Miller (mamille2)" , JSON WG References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:YaO7E+cCkzqBPESKFtv/QLTBCJRiT23rsJxL+XQxZI0uUQz6zpa QUj0NubhA0nKFe+QWiEtZ+ZTGTwwLdP1tBwGtBSYz0TF9heZHNhOy7BRNtc99p3ybJVEOeg HgDWsNkItwPP1l0WOlk3Tk4+L4uR7ht3OO+irVHjrMv6vcHs3i12m5Kx0/MFSLQ6l37HkRq j+yFUwredhwN/E3xMHQrg== Cc: "www-tag@w3.org" , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:41:56 -0000 On 2013-11-22 19:33, Matt Miller (mamille2) wrote: > There does seem to be rough consensus that using an encoding other than UTF-8 can have interoperability issues. The also seems to be rough consensus that the current text and table in section 8.1 for detecting the encoding will be inaccurate (and potentially harmful). > > That appears to mean the approach with the most consensus is to remove the encoding detection entirely, leaving only: > > """" > JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. > """" > > > - Paul Hoffman and Matt Miller Again: "JSON text SHALL be encoded in Unicode." doesn't make any sense. "Unicode" is not a character encoding. Can we please use proper terminology here? Best regards, Julian From derhoermi@gmx.net Fri Nov 22 10:43:15 2013 Return-Path: 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 986B61AE39B for ; Fri, 22 Nov 2013 10:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 ZTtbkpE6iIae for ; Fri, 22 Nov 2013 10:43:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5261AE393 for ; Fri, 22 Nov 2013 10:43:13 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.1.197]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0M7UUd-1VUkaG15aJ-00xGrG for ; Fri, 22 Nov 2013 19:43:05 +0100 From: Bjoern Hoehrmann To: "Matt Miller (mamille2)" Date: Fri, 22 Nov 2013 19:43:05 +0100 Message-ID: References: <528B46EA.4040503@it.aoyama.ac.jp> <43255615-2FC9-4726-99FD-1B13D6B1F033@wirfs-brock.com> <528C5445.3050600@it.aoyama.ac.jp> <50CFBDEE-53A5-4159-93C4-348CF31EC8EF@wirfs-brock.com> <11233CA7-B075-483D-A1C3-3BF6CF91AEE3@cisco.com> In-Reply-To: <11233CA7-B075-483D-A1C3-3BF6CF91AEE3@cisco.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:jddV6Xq3WdRE1CDI1Bqpoj2KRQg8Kg+tJfbgnvTDgr5KUZW8DZh 7YOIdowqebPufJonXNnUpPiVuuGkk9ytDo+/G2jzIuNZgYnqoNTqAz4aWquLGPGYLXtCz4O SemRwgcHOdy3RmnZcd26qVP23epepZylwMpyv9+aYQ3vi/UgnrOVU5CAYDqReeu+yCaCKPe xwf/L+d6VpFBOZR8T3OTQ== Cc: es-discuss , IETF Discussion , www-tag , JSON WG Subject: Re: [Json] BOMs X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:43:15 -0000 * Matt Miller (mamille2) wrote: >There does not appear to be any consensus on explicitly allowing or >disallowing of a Byte Order Mark (BOM). Neither RFC4627 nor the current >draft mention BOM anywhere, and the modus operandi of the JSON Working >Group has been to leave text unchanged unless there was wide support. To be clear, that means application/json entities that start with a byte sequence that matches U+FEFF encoded in UTF-8/16/32 is malformed because the ABNF does not allow a U+FEFF at that position (and interpreting such a sequence as anything other than ordinary character data requires explicit specification). I do think an informational note saying as much could be useful. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From derhoermi@gmx.net Fri Nov 22 10:52:34 2013 Return-Path: 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 8D4841AE358 for ; Fri, 22 Nov 2013 10:52:34 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] 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 f2KdZCyuNd4Z for ; Fri, 22 Nov 2013 10:52:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id D3A2F1AE25B for ; Fri, 22 Nov 2013 10:52:32 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.1.197]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MDR21-1VtXgD09wD-00GuTz for ; Fri, 22 Nov 2013 19:52:24 +0100 From: Bjoern Hoehrmann To: "Matt Miller (mamille2)" Date: Fri, 22 Nov 2013 19:52:26 +0100 Message-ID: References: <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:UCHivFTyW9MG9lUvWvbuGKfBS8cvrY1d2k3v3idXdrbqn2nebqC 7stb4sXuBQ5m6XVHnAeTey6w2X+78uME19v2ZEGTKniy2Y9fumsZ4h8UTmg2VhgBzMguwOm KHL2MyNqrx4Q28rFg8wI+rusyc+pNl4aJ+XlILrd2AzyFNOmp50Rm7I/w3A+cf9woCVwB1c lfxP+1aTCsn/2ZB21GUyw== Cc: es-discuss , "www-tag@w3.org" , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:52:34 -0000 * Matt Miller (mamille2) wrote: >There does seem to be rough consensus that using an encoding other than >UTF-8 can have interoperability issues. The also seems to be rough >consensus that the current text and table in section 8.1 for detecting >the encoding will be inaccurate (and potentially harmful). > >That appears to mean the approach with the most consensus is to remove >the encoding detection entirely, leaving only: > >"""" > JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. >"""" Neither of the quoted statements mean anything as far as I can tell. The encoding detection rules are a vital part of the specification and cannot be removed without replacement. I am not aware of any argument that the text "will be" inaccurate or harmful. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From cowan@ccil.org Fri Nov 22 10:58:10 2013 Return-Path: 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 B0EA51ADFCE for ; Fri, 22 Nov 2013 10:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525] 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 IjZaC-HmmYCM for ; Fri, 22 Nov 2013 10:58:08 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 124A01ADF7C for ; Fri, 22 Nov 2013 10:58:08 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VjvvT-00041h-FO; Fri, 22 Nov 2013 13:57:59 -0500 Date: Fri, 22 Nov 2013 13:57:59 -0500 From: John Cowan To: "Matt Miller (mamille2)" Message-ID: <20131122185759.GA11066@mercury.ccil.org> References: <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: es-discuss , "www-tag@w3.org" , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:58:10 -0000 Matt Miller (mamille2) scripsit: > There does seem to be rough consensus that using an encoding other > than UTF-8 can have interoperability issues. I agree. > The also seems to be rough consensus that the current text and table > in section 8.1 for detecting the encoding will be inaccurate (and > potentially harmful). If it is inaccurate, it should be fixed, but as it is a statement of fact and not normative, I can see no grounds for removing it altogether. > That appears to mean the approach with the most consensus is to remove > the encoding detection entirely, leaving only: > > JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. I do not believe this is strong enough. I think an interoperability problems warning similar to those we already have would be better. Proposed text: The use of other encodings is known to cause interoperability problems. -- One Word to write them all, John Cowan One Access to find them, http://www.ccil.org/~cowan One Excel to count them all, And thus to Windows bind them. --Mike Champion From cowan@ccil.org Fri Nov 22 10:59:03 2013 Return-Path: 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 A61541ADFD4 for ; Fri, 22 Nov 2013 10:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525] 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 D8v7-ca1r8wO for ; Fri, 22 Nov 2013 10:59:02 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3281ADF7C for ; Fri, 22 Nov 2013 10:59:02 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VjvwK-00046p-PD; Fri, 22 Nov 2013 13:58:52 -0500 Date: Fri, 22 Nov 2013 13:58:52 -0500 From: John Cowan To: Bjoern Hoehrmann Message-ID: <20131122185852.GB11066@mercury.ccil.org> References: <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: JSON WG , es-discuss , "www-tag@w3.org" , "Matt Miller \(mamille2\)" 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:59:03 -0000 Bjoern Hoehrmann scripsit: > Neither of the quoted statements mean anything as far as I can tell. > The encoding detection rules are a vital part of the specification and > cannot be removed without replacement. I am not aware of any argument > that the text "will be" inaccurate or harmful. If we are going to allow interchange of bare strings, the text will be inaccurate. -- And they pack their lyrics till they're so damn dense John Cowan You could put 'em in your yard and you could use 'em for a fence. --Alan Chapman, "Everybody Wants to Be Sondheim" www.ccil.org/~cowan From derhoermi@gmx.net Fri Nov 22 10:59:43 2013 Return-Path: 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 0F5DC1ADFD4 for ; Fri, 22 Nov 2013 10:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 B_SrB_Pp7un9 for ; Fri, 22 Nov 2013 10:59:41 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6621ADFCE for ; Fri, 22 Nov 2013 10:59:41 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.1.197]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MDE6y-1VtoNt1tcq-00GXEp for ; Fri, 22 Nov 2013 19:59:33 +0100 From: Bjoern Hoehrmann To: json@ietf.org Date: Fri, 22 Nov 2013 19:59:36 +0100 Message-ID: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:3vqDSjLh5nijGUr8GZCbm1ppDTBUleuSTQ3KZXDtkLDI+KNe8T+ vWvs+rMw9AgujWdzDNyNopwPZ1yhWiNNcCJtNirFSY3Jm65ko7vVQTjeUjfsVtVkaZZetj9 kjkifoUCpY4PdyAsXynodAmxHp5ipL6lXWOG3jImross/DXaRJlYRMs4t0LG4BQGfX8uwxM bqPoTrxhpmqgVU+JrLsyg== Subject: [Json] First two characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:59:43 -0000 Hi, Now that string literals can occur at the top level, the statement in 8.1 http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07 "the first two characters of a JSON text will always be ASCII characters" is incorrect and needs to be changed alongside changing the JSON-text grammar. regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From mamille2@cisco.com Fri Nov 22 11:06:07 2013 Return-Path: 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 8CF1C1AE230 for ; Fri, 22 Nov 2013 11:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_QUOTING=0.001] 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 lR3DuXgb6GQl for ; Fri, 22 Nov 2013 11:06:05 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A1FD51AE231 for ; Fri, 22 Nov 2013 11:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2089; q=dns/txt; s=iport; t=1385147159; x=1386356759; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PkuhQd8SgVIQfwXh6kLDDG0Od0r6FjgzjBCcubFfDZI=; b=QeKSU/hJa0c4zNGy96yQ5TY1SPbQWVMThcI2uQEj9ZDEnTWRMhL9+dH2 MGHwECEHFJCakC9TvwUztQ/j3hvDxizsvYVzKvkOKU/iGURKHsgIMEMxd BgfqdMgdHjOiE3fUWqm0iT5Tzhq8pA99moR3OPQG9p+xrZ0q04ehC2WLK 8=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAKCqj1KtJXG//2dsb2JhbABZgweBC7wVgSIWdIIlAQEBAwF5BQsCAQgYLjIlAgQOBQ6HYQMJBsEuF4x4gg8HgyCBEgOQMYExhjKSEoFqgT6CKg X-IronPort-AV: E=Sophos;i="4.93,753,1378857600"; d="asc'?scan'208";a="286891641" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 22 Nov 2013 19:05:58 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAMJ5wdx017584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 19:05:58 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 22 Nov 2013 13:05:57 -0600 From: "Matt Miller (mamille2)" To: Julian Reschke Thread-Topic: [Json] Encoding detection (Was: Re: JSON: remove gap between Ecma-404 and IETF draft) Thread-Index: AQHO57KBUSEw68NY50iGvhEm1Fjae5oyAO+A Date: Fri, 22 Nov 2013 19:05:57 +0000 Message-ID: References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <528FA55F.30000@gmx.de> In-Reply-To: <528FA55F.30000@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.44] Content-Type: multipart/signed; boundary="Apple-Mail=_68EFC27F-866D-4995-AA12-DC70BBE2A989"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: es-discuss , "www-tag@w3.org" , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 19:06:07 -0000 --Apple-Mail=_68EFC27F-866D-4995-AA12-DC70BBE2A989 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 22, 2013, at 11:41 AM, Julian Reschke = wrote: > On 2013-11-22 19:33, Matt Miller (mamille2) wrote: >> There does seem to be rough consensus that using an encoding other = than UTF-8 can have interoperability issues. The also seems to be rough = consensus that the current text and table in section 8.1 for detecting = the encoding will be inaccurate (and potentially harmful). >>=20 >> That appears to mean the approach with the most consensus is to = remove the encoding detection entirely, leaving only: >>=20 >> """" >> JSON text SHALL be encoded in Unicode. The default encoding is >> UTF-8. >> """" >>=20 >>=20 >> - Paul Hoffman and Matt Miller >=20 > Again: >=20 > "JSON text SHALL be encoded in Unicode." >=20 > doesn't make any sense. "Unicode" is not a character encoding. >=20 > Can we please use proper terminology here? >=20 > Best regards, Julian This was merely quoting the existing text in section 8.1, minus the = encoding detection text. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_68EFC27F-866D-4995-AA12-DC70BBE2A989 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSj6sVAAoJEDWi+S0W7cO1Wk0H/1AAr3qR6RZ4kpkCWzr5B77S +i8QKm8MfgAKwZgqeiQHNt/wGdNa1JfpVPZTBplg5+2nNIMroBXrJDLtlPzw+FHI erJqP12wwK7UcoGFjhnVZG+JIdHFJXtEXXTTLARQBKL8T4FXzp1R4Hb469Z7WDP4 9KH/ZWVN/lCQ1MIsEEamCcdu+E8+PSurEhpYK2S+mxPAy3ELefCFBGhEJ/tI3eFL l4uXa/ldrNJ3AyznQuAItpkbrGo8+VBT4Mbam+lKz/DhgwF2TrVuEorj5TV/Kw8k rP7eh1Sd/oHwjAzPCjnZJ44XsaVWbqui9+SYKCmbhvSIyZI16WwVhkiscU5Vtrs= =IFmD -----END PGP SIGNATURE----- --Apple-Mail=_68EFC27F-866D-4995-AA12-DC70BBE2A989-- From petejson@codalogic.com Fri Nov 22 11:27:17 2013 Return-Path: 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 3AF7F1AE22D for ; Fri, 22 Nov 2013 11:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.952 X-Spam-Level: *** X-Spam-Status: No, score=3.952 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215, WEIRD_QUOTING=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 3dL2vTNEXIus for ; Fri, 22 Nov 2013 11:27:15 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id E34A41AE1C2 for ; Fri, 22 Nov 2013 11:27:14 -0800 (PST) Received: (qmail 26564 invoked from network); 22 Nov 2013 19:26:48 +0000 Received: from host86-167-12-24.range86-167.btcentralplus.com (HELO codalogic) (86.167.12.24) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 22 Nov 2013 19:26:48 +0000 Message-ID: <06150DAF47D944FD8CDC09D01B6A6459@codalogic> From: "Pete Cordell" To: "Matt Miller \(mamille2\)" , "JSON WG" References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> X-Unsent: 1 x-vipre-scanned: 01F99031005C4A01F9917E Date: Fri, 22 Nov 2013 19:28:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: www-tag@w3.org, es-discuss Subject: Re: [Json] Encoding detection (Was: Re: JSON: remove gapbetween 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 19:27:17 -0000 ----- Original Message From: "Matt Miller (mamille2)" > There does seem to be rough consensus that using an encoding > other than UTF-8 can have interoperability issues. The also > seems to be rough consensus that the current text and table > in section 8.1 for detecting the encoding will be inaccurate > (and potentially harmful). > > That appears to mean the approach with the most consensus is > to remove the encoding detection entirely, leaving only: > > """" > JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. > """" I think we can be a little more helpful here. For example, something along the lines of: JSON text is a sequence of Unicode codepoints. The transfer encoding used to represent those characters on-the-wire is beyond the scope of this document. It is therefore up to the specifications that reference this document to specify whether JSON messages will be transferred using UTF-8 (recommended), UTF-16 and/or UTF-32 (discouraged), and whether preceding BOMs must be present, must not be present or are optional. If multiple encodings are permitted, implementers may choose to auto-detect a message's encoding by exploiting the fact that the first character of a JSON text must be in the ASCII character range and use the following table to deduce the active encoding: 00 00 -- -- UTF-32BE 00 xx -- -- UTF-16BE xx 00 00 00 UTF-32LE xx 00 00 xx UTF-16LE xx 00 xx -- UTF-16LE xx xx -- -- UTF-8 Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From petejson@codalogic.com Fri Nov 22 11:31:44 2013 Return-Path: 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 F09231AE1F7 for ; Fri, 22 Nov 2013 11:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_QUOTING=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 7E_-7qOa_3VZ for ; Fri, 22 Nov 2013 11:31:42 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 0125F1AE042 for ; Fri, 22 Nov 2013 11:31:41 -0800 (PST) Received: (qmail 26630 invoked from network); 22 Nov 2013 19:31:15 +0000 Received: from host86-167-12-24.range86-167.btcentralplus.com (HELO codalogic) (86.167.12.24) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 22 Nov 2013 19:31:14 +0000 Message-ID: <505BA6365AE1490CB577DDB9F4D7FFF5@codalogic> From: "Pete Cordell" To: "Matt Miller \(mamille2\)" , "JSON WG" References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <06150DAF47D944FD8CDC09D01B6A6459@codalogic> X-Unsent: 1 x-vipre-scanned: 01FDB673005C4A01FDB7C0 Date: Fri, 22 Nov 2013 19:32:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: www-tag@w3.org, es-discuss Subject: Re: [Json] Encoding detection (Was: Re: JSON: removegapbetween 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 19:31:44 -0000 Further to my earlier comment, I also wondered about taking a leaf out of cipher suites and allow specifications that use JSON to encode their encoding requirements along the lines of: JSON-8OB-16MB-32NB where OB = Optional BOM, MB = Mandatory BOM and NB = No BOM. So the above would mean UTF-8 is supported with or without BOMs, UTF-16 is supported, but must have a BOM and UTF-32 is supported with NO BOM. Another example would be: JSON-8OB i.e. UTF-16 and UTF-32 are not supported. Maybe that's going too far though! Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com ----- Original Message ----- From: "Pete Cordell" To: "Matt Miller (mamille2)" ; "JSON WG" Cc: ; "es-discuss" Sent: Friday, November 22, 2013 7:28 PM Subject: Re: [Json] Encoding detection (Was: Re: JSON: removegapbetween Ecma-404 and IETF draft) > ----- Original Message From: "Matt Miller (mamille2)" > >> There does seem to be rough consensus that using an encoding >> other than UTF-8 can have interoperability issues. The also >> seems to be rough consensus that the current text and table >> in section 8.1 for detecting the encoding will be inaccurate >> (and potentially harmful). >> >> That appears to mean the approach with the most consensus is >> to remove the encoding detection entirely, leaving only: >> >> """" >> JSON text SHALL be encoded in Unicode. The default encoding is >> UTF-8. >> """" > > I think we can be a little more helpful here. For example, something > along the lines of: > > JSON text is a sequence of Unicode codepoints. The transfer encoding > used to > represent those characters on-the-wire is beyond the scope of this > document. It is therefore up to the specifications that reference this > document to > specify whether JSON messages will be transferred using UTF-8 > (recommended), > UTF-16 and/or UTF-32 (discouraged), and whether preceding BOMs must be > present, must not be present or are optional. > > If multiple encodings are permitted, implementers may choose to > auto-detect a > message's encoding by exploiting the fact that the first character of a > JSON text > must be in the ASCII character range and use the following table to > deduce the > active encoding: > > 00 00 -- -- UTF-32BE > 00 xx -- -- UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 00 xx UTF-16LE > xx 00 xx -- UTF-16LE > xx xx -- -- UTF-8 > > Pete Cordell > Codalogic Ltd > C++ tools for C++ programmers, http://codalogic.com > Read & write XML in C++, http://www.xml2cpp.com > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nico@cryptonector.com Fri Nov 22 14:22:10 2013 Return-Path: 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 C18F11AE366 for ; Fri, 22 Nov 2013 14:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mQoJEh_sbfD1 for ; Fri, 22 Nov 2013 14:22:09 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 31B0C1AE35E for ; Fri, 22 Nov 2013 14:22:09 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 42C053600D5; Fri, 22 Nov 2013 14:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=j+zARBXNgRG3iF U1KoUDsGR6fHQ=; b=mgccfL7n2YdIsEhDdbnk08uPXMHK2hZ450fq2CNWwwWWDC KgdmSLE8GtKHnHywut94pLVeapkFnq4GiRNqEFHeovGYfXg56hMjBotxqtSmMUD1 N/kCZ7aA1tN8Nw4VwSvqU2dI4pNRg0R/SCCP7hqN02M53CbjHe3EQoKKeV+4Q= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 2705A3600DB; Fri, 22 Nov 2013 14:19:43 -0800 (PST) Date: Fri, 22 Nov 2013 16:19:41 -0600 From: Nico Williams To: Bjoern Hoehrmann Message-ID: <20131122221940.GD3655@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: json@ietf.org Subject: Re: [Json] First two characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 22:22:11 -0000 On Fri, Nov 22, 2013 at 07:59:36PM +0100, Bjoern Hoehrmann wrote: > Now that string literals can occur at the top level, the statement in > 8.1 http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07 "the first > two characters of a JSON text will always be ASCII characters" is > incorrect and needs to be changed alongside changing the JSON-text > grammar. Good point. Using 'xx' to mean 0x01..0x7F, XX to mean 0x01..0xFF, YY to mean 0x80..0xFF, ZZ to mean 0x00..0xFF, and 00 to mean 0x00, we have these possible BOM-less patterns: xx 00 00 00 UTF-32LE 00 00 00 xx UTF-32BE xx 00 ZZ ZZ UTF-16LE but ZZ bytes cannot both be 00 00 xx ZZ ZZ UTF-16BE but ZZ bytes cannot both be 00 xx XX UTF-8 Simplified to assume sequential checking: 00 00 00 xx UTF-32BE 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 UTF-16LE xx UTF-8 Optimized for the common cases: xx XX UTF-8 (XX > 0) xx 00 ZZ ZZ UTF-16LE (ZZ can be any value, but both ZZs can't be 0) 00 xx UTF-16BE 00 00 00 xx UTF-32BE xx 00 00 00 UTF-32LE Nico -- From paul.hoffman@vpnc.org Fri Nov 22 14:36:52 2013 Return-Path: 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 466D61AE383 for ; Fri, 22 Nov 2013 14:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 O9nZbXzcGgQC for ; Fri, 22 Nov 2013 14:36:51 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 60D4C1AE380 for ; Fri, 22 Nov 2013 14:36:51 -0800 (PST) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rAMMafne047422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 22 Nov 2013 15:36:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: Date: Fri, 22 Nov 2013 14:36:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: JSON WG X-Mailer: Apple Mail (2.1822) Subject: [Json] Wording on encoding; removing the table X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 22:36:52 -0000 Please note that the chairs tried to find some consensus in the BOM = discussion and found none. Given that, and given that the current table = is now wrong, our proposal is to remove it, not try to doctor it. Current Section 8.1: JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets. 00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx 00 UTF-16LE xx xx xx xx UTF-8 Proposed replacement: The default encoding for JSON transmitted over the Internet is UTF-8. Transmitting JSON using other encodings may not be interoperable unless the receiving system definitively knows the encoding. Does anyone have a technical objection to the proposed replacement? If = so, please state the error and (hopefully) a correction. --Matt Miller and Paul Hoffman From nico@cryptonector.com Fri Nov 22 14:47:33 2013 Return-Path: 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 89E6F1AE393 for ; Fri, 22 Nov 2013 14:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 m-8gRQ_CuVPl for ; Fri, 22 Nov 2013 14:47:32 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6204A1AE2D8 for ; Fri, 22 Nov 2013 14:47:32 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 570B22005D90A; Fri, 22 Nov 2013 14:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=lRFmuDvxVTH+2J uzyciOo5s8iaA=; b=thLazRXDK0BgG0YVY5RpBAZB15NgSlwnVf9bt/lzh8UlHt LjJntwmsPgywGvyEDZqokBEdF77xppn3767et2stFpCpxSi15sHh6nAJUBnJ+28q /9r3vIMJXfyHvaMv3Swxsh3zTfFeGxbCn+cuKCFObncQu77AF7n52o7hWYZp0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 223952005D909; Fri, 22 Nov 2013 14:47:25 -0800 (PST) Date: Fri, 22 Nov 2013 16:47:18 -0600 From: Nico Williams To: Paul Hoffman Message-ID: <20131122224717.GE3655@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: JSON WG Subject: Re: [Json] Wording on encoding; removing the table X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 22:47:34 -0000 On Fri, Nov 22, 2013 at 02:36:41PM -0800, Paul Hoffman wrote: > Please note that the chairs tried to find some consensus in the BOM > discussion and found none. Given that, and given that the current > table is now wrong, our proposal is to remove it, not try to doctor > it. That's fair. > Proposed replacement: > > The default encoding for JSON transmitted over the Internet is UTF-8. > Transmitting JSON using other encodings may not be interoperable > unless the receiving system definitively knows the encoding. > > Does anyone have a technical objection to the proposed replacement? If > so, please state the error and (hopefully) a correction. Might it be worthwhile to note that the previous RFC had implied (but not stated) that UTF-16 and UTF-32 had been intended to be supported? Also, what does this mean for the MIME media type encoding considerations text? Nico -- From paul.hoffman@vpnc.org Fri Nov 22 14:56:43 2013 Return-Path: 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 090B41AE345 for ; Fri, 22 Nov 2013 14:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 tuDvy5B5pmDL for ; Fri, 22 Nov 2013 14:56:42 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ED15B1AE1F8 for ; Fri, 22 Nov 2013 14:56:41 -0800 (PST) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rAMMuVex047998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Nov 2013 15:56:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <20131122224717.GE3655@localhost> Date: Fri, 22 Nov 2013 14:56:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131122224717.GE3655@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1822) Cc: JSON WG Subject: Re: [Json] Wording on encoding; removing the table X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 22:56:43 -0000 On Nov 22, 2013, at 2:47 PM, Nico Williams = wrote: > On Fri, Nov 22, 2013 at 02:36:41PM -0800, Paul Hoffman wrote: >> Please note that the chairs tried to find some consensus in the BOM >> discussion and found none. Given that, and given that the current >> table is now wrong, our proposal is to remove it, not try to doctor >> it. >=20 > That's fair. >=20 >> Proposed replacement: >>=20 >> The default encoding for JSON transmitted over the Internet is = UTF-8. >> Transmitting JSON using other encodings may not be interoperable >> unless the receiving system definitively knows the encoding. >>=20 >> Does anyone have a technical objection to the proposed replacement? = If >> so, please state the error and (hopefully) a correction. >=20 > Might it be worthwhile to note that the previous RFC had implied (but > not stated) that UTF-16 and UTF-32 had been intended to be supported? Sorry, yes, we will need to add some words to that effect to Appendix A = as well. > Also, what does this mean for the MIME media type encoding > considerations text? Nothing. The text above says that UTF-8 is the default, not the only = possible encoding. --Paul Hoffman= From derhoermi@gmx.net Fri Nov 22 15:02:15 2013 Return-Path: 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 C4BAF1AE399 for ; Fri, 22 Nov 2013 15:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 LPYEBOSSn8k0 for ; Fri, 22 Nov 2013 15:02:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id C55521AE345 for ; Fri, 22 Nov 2013 15:02:13 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.33.117]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0LgdBZ-1VMTLk0lOf-00nvoY for ; Sat, 23 Nov 2013 00:02:05 +0100 From: Bjoern Hoehrmann To: Paul Hoffman Date: Sat, 23 Nov 2013 00:02:07 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:vizV0a3fTMa9owrDm7TlRsg9BIOa1dCRMG3OZBzYh1YWcbIYAqI vdTVGhtx8KSecuDwmFCCpX+9oZMBKhA9VGBk/bcp0xuoSAyNSUhzCBNMxWwTLM4J2KH3kQI w0couvF0BGDC1B3kD/T0gQRb5n5SRV9L2n2RznxClRZHq9L4sZfjhIGFdm2ZNxw0YsU5tYd B7fwrzIhjQunNxCCk9VAw== Cc: JSON WG Subject: Re: [Json] Wording on encoding; removing the table X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 23:02:16 -0000 * Paul Hoffman wrote: >Proposed replacement: > > The default encoding for JSON transmitted over the Internet is UTF-8. > Transmitting JSON using other encodings may not be interoperable > unless the receiving system definitively knows the encoding. > >Does anyone have a technical objection to the proposed replacement? If >so, please state the error and (hopefully) a correction. It is necessary for reasons of security and interoperability that all application/json processors agree on how to get from the sequence of bytes that make up the application/json entity to a sequence of integers that are used in the ABNF definition of the JSON syntax. For example, data:application/json,%5B%22Bj+APY-rn%22%5D Under the rules you propose, this can be interpreted as if it were ["Björn"] An implementation that interprets it thus is fully conforming because the bytes look like they are UTF-7 encoded text and the specification does not unambiguously say that, no, the implementation must not take it as UTF-7 encoded document, instead it must use UTF-8 to decode. Under the rules of RFC 4627 there can be no UTF-7 encoded application/ json entities at all and processors are required to decode the example using UTF-8. Some web browsers had exactly this problem for a long time with other formats, it is entirely unacceptable to go back to "just do whatever" specifications for character encoding determination. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From petejson@codalogic.com Sat Nov 23 01:51:47 2013 Return-Path: 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 466101AE274 for ; Sat, 23 Nov 2013 01:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.736 X-Spam-Level: ** X-Spam-Status: No, score=2.736 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 tMOB64Nghqt5 for ; Sat, 23 Nov 2013 01:51:45 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id BF6AC1AE25A for ; Sat, 23 Nov 2013 01:51:44 -0800 (PST) Received: (qmail 31725 invoked from network); 23 Nov 2013 09:51:18 +0000 Received: from host86-167-12-24.range86-167.btcentralplus.com (HELO codalogic) (86.167.12.24) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 23 Nov 2013 09:51:18 +0000 Message-ID: <7404D1DCC5E84DC3B8F8CD300274962D@codalogic> From: "Pete Cordell" To: "Paul Hoffman" , "JSON WG" References: Date: Sat, 23 Nov 2013 09:45:02 -0000 X-Unsent: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original x-vipre-scanned: 003896B1005C56003897FE Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [Json] Wording on encoding; removing the table X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 09:51:47 -0000 I believe we must have consensus that this is a contentious issue, and there is a lot of confusion around it. Therefore, in the interests of interoperability I believe it is inappropriate to decide to be silent on all of these issues. Therefore, I propose text along the following lines: JSON text is a sequence of Unicode codepoints. The transfer encoding used to represent the characters on-the-wire is beyond the scope of this document. It is therefore up to the specifications that reference this document to specify whether JSON messages will be transferred using UTF-8 (recommended), UTF-16 and/or UTF-32 (discouraged), and whether preceding BOMs must be present, must not be present or are optional. If multiple encodings are permitted, implementers may choose to auto-detect a message's encoding by exploiting the fact that the first character of a JSON text must be in the ASCII character range and use the following table to deduce the active encoding: xx xx -- -- UTF-8 xx 00 xx -- UTF-16LE xx 00 00 xx UTF-16LE xx 00 00 00 UTF-32LE 00 xx -- -- UTF-16BE 00 00 -- -- UTF-32BE I don't think that's a lot of text with which to describe the issues here, and I'm sure Tim (or someone else) can make it even snappier and more accurate. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com ----- Original Message ----- From: "Paul Hoffman" To: "JSON WG" Sent: Friday, November 22, 2013 10:36 PM Subject: [Json] Wording on encoding; removing the table > > > Please note that the chairs tried to find some consensus in the BOM > discussion and found none. Given that, and given that the current table is > now wrong, our proposal is to remove it, not try to doctor it. > > Current Section 8.1: > > JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. > > Since the first two characters of a JSON text will always be ASCII > characters [RFC0020], it is possible to determine whether an octet > stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking > at the pattern of nulls in the first four octets. > > 00 00 00 xx UTF-32BE > 00 xx 00 xx UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 xx 00 UTF-16LE > xx xx xx xx UTF-8 > > Proposed replacement: > > The default encoding for JSON transmitted over the Internet is UTF-8. > Transmitting JSON using other encodings may not be interoperable > unless the receiving system definitively knows the encoding. > > Does anyone have a technical objection to the proposed replacement? If so, > please state the error and (hopefully) a correction. > > --Matt Miller and Paul Hoffman > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From petejson@codalogic.com Sat Nov 23 01:51:47 2013 Return-Path: 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 53B0B1AE27B for ; Sat, 23 Nov 2013 01:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 AiJ-Sb1ZgGsg for ; Sat, 23 Nov 2013 01:51:45 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id C08CE1AE26B for ; Sat, 23 Nov 2013 01:51:44 -0800 (PST) Received: (qmail 31717 invoked from network); 23 Nov 2013 09:51:18 +0000 Received: from host86-167-12-24.range86-167.btcentralplus.com (HELO codalogic) (86.167.12.24) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 23 Nov 2013 09:51:18 +0000 Message-ID: <7AE46E6FE04C46B1BB9420C20CDB4EC5@codalogic> From: "Pete Cordell" To: "Nico Williams" , "Bjoern Hoehrmann" References: <20131122221940.GD3655@localhost> Date: Sat, 23 Nov 2013 09:21:18 -0000 X-Unsent: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original x-vipre-scanned: 0022DC51005C560022DD9E Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: json@ietf.org Subject: Re: [Json] First two characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 09:51:47 -0000 ----- Original Message From: "Nico Williams" > On Fri, Nov 22, 2013 at 07:59:36PM +0100, Bjoern Hoehrmann wrote: >> Now that string literals can occur at the top level, the statement in >> 8.1 http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07 "the first >> two characters of a JSON text will always be ASCII characters" is >> incorrect and needs to be changed alongside changing the JSON-text >> grammar. > >... > xx XX UTF-8 (XX > 0) > xx 00 ZZ ZZ UTF-16LE (ZZ can be any value, but both ZZs can't be 0) > 00 xx UTF-16BE > 00 00 00 xx UTF-32BE > xx 00 00 00 UTF-32LE I don't see why that offers any benefit over the following table presented earlier: xx xx -- -- UTF-8 xx 00 xx -- UTF-16LE xx 00 00 xx UTF-16LE xx 00 00 00 UTF-32LE 00 xx -- -- UTF-16BE 00 00 -- -- UTF-32BE What it does demonstrate is that if we are not restricting JSON to UTF-8 and only UTF-8 then a table of some description would be very useful in the interests of interoperability. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From markus.lanthaler@gmx.net Sat Nov 23 05:54:21 2013 Return-Path: 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 41F271ADF57 for ; Sat, 23 Nov 2013 05:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.474 X-Spam-Level: X-Spam-Status: No, score=0.474 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-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 ChEtsaSjg9pq for ; Sat, 23 Nov 2013 05:54:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id EE6C11ADBD4 for ; Sat, 23 Nov 2013 05:54:19 -0800 (PST) Received: from Vostro3500 ([37.116.127.110]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MGAdz-1VqUfU1g6Z-00FCbU for ; Sat, 23 Nov 2013 14:54:11 +0100 From: "Markus Lanthaler" To: References: <20131122221940.GD3655@localhost> In-Reply-To: <20131122221940.GD3655@localhost> Date: Sat, 23 Nov 2013 14:54:01 +0100 Message-ID: <00a401cee853$777307c0$66591740$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: de Thread-Index: Ac7n0Uapqe77X6OEQIeley1/4kQeyAAgg94A X-Provags-ID: V03:K0:YnDRmGiXIpFD/sX7rjBjSCqiG+YsbENhYVhj6gVQ0fw+l7AR1RD 3jub41TW2txIlWUnSpLIXw8+g6iQscouNB4MV3emeNstmPFH0DQexlQZQ3s/CWnp4+FDbCf w+0iDYJCGkgSXsCUsgsjsyA/+cuGQq9FMbpAl9eS3slYA3IYbvwywd87r49U3Wj+ltJu6ho gKMYCRffmOhD2bcULruYA== Subject: Re: [Json] First two characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 13:54:21 -0000 On Fri, Nov 22, 2013 at 07:59:36PM +0100, Bjoern Hoehrmann wrote: > Now that string literals can occur at the top level, ... Can they? When did we decide that? -- Markus Lanthaler @markuslanthaler From derhoermi@gmx.net Sat Nov 23 06:01:04 2013 Return-Path: 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 6236E1AE2F3 for ; Sat, 23 Nov 2013 06:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] 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 69FO0h6bvZv5 for ; Sat, 23 Nov 2013 06:01:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 819F51ADBD4 for ; Sat, 23 Nov 2013 06:01:02 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.63.134]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MWwp6-1W7Kgz3r76-00VzMi for ; Sat, 23 Nov 2013 15:00:54 +0100 From: Bjoern Hoehrmann To: "Markus Lanthaler" Date: Sat, 23 Nov 2013 15:00:56 +0100 Message-ID: References: <20131122221940.GD3655@localhost> <00a401cee853$777307c0$66591740$@lanthaler@gmx.net> In-Reply-To: <00a401cee853$777307c0$66591740$@lanthaler@gmx.net> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:gZ6G0HhgjuAzJoPGl9EprJ56P2UbdttiCB29K9pN1MUQgB0YhCC WrDEJjWetRivgi2ixn1hxwMXoZtyFilAfDfkxSXOdFccHZlB59XMJfBLXuvltBTazrhpHqN 54ShjQ+h22sb4H3UDdm02c9ms3JS62bd56jCPGP/PEfJ/pncnDmss1X2v3JlOwjcAJ8PVj8 vXRsZdON+lhxfNC3gtoIA== Cc: json@ietf.org Subject: Re: [Json] First two characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 14:01:04 -0000 * Markus Lanthaler wrote: >On Fri, Nov 22, 2013 at 07:59:36PM +0100, Bjoern Hoehrmann wrote: >> Now that string literals can occur at the top level, ... > >Can they? When did we decide that? http://www.ietf.org/mail-archive/web/json/current/msg02040.html -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From tbray@textuality.com Sat Nov 23 08:13:38 2013 Return-Path: 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 9766D1AE07C for ; Sat, 23 Nov 2013 08:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 5thpMQ6aUJnB for ; Sat, 23 Nov 2013 08:13:36 -0800 (PST) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 476771ADF46 for ; Sat, 23 Nov 2013 08:13:36 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id lc6so1735550vcb.13 for ; Sat, 23 Nov 2013 08:13:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2Zev/uv5M0XFzx8/rWQv68N9Q3Ri5NBTGdxeGpYEDL4=; b=NKoaaNhM2FBYZG18qcQYSw1oeqNimzbTxx2XyprXcz8KIVzX3DPfVFdBBI+2yucySg gyFXiDmhcrX9t9UGjSeXas/9PX3atUWyUX3Fq1uKDJMsTN2rZ90Ph6F5eBjqWVWkbJEo YOwliHj+R+3n63b8P7LVhXpsuu4B5sgbwnOOO+KxvM0wobnyTsjdXy61PNjasA2qgsLD pXrirTyWrR/qOpIDO77ImedNpmaSlS132GnUHUTenfUh8S6n1i+7wzfCdq9RNflCz6kP OO348pBpqDc4x1XscJlMLU6xaviOxE10Bn1eEI4tYJTmQ2a4U7TxTWQj5aHOvPBkA7QZ O2Wg== X-Gm-Message-State: ALoCoQnN4Tv1qg+oapJTGgfI0KpFmPwQQ0DqQIO+rNiEVsmnrEXxpqV3/rsKFzF0ogL3NRkO2ojZ MIME-Version: 1.0 X-Received: by 10.52.245.9 with SMTP id xk9mr14759725vdc.8.1385223208450; Sat, 23 Nov 2013 08:13:28 -0800 (PST) Received: by 10.220.198.199 with HTTP; Sat, 23 Nov 2013 08:13:28 -0800 (PST) X-Originating-IP: [24.84.235.32] Received: by 10.220.198.199 with HTTP; Sat, 23 Nov 2013 08:13:28 -0800 (PST) In-Reply-To: <5F4F5DE0FE4740D696FBAC03B1F91131@codalogic> References: <5F4F5DE0FE4740D696FBAC03B1F91131@codalogic> Date: Sat, 23 Nov 2013 08:13:28 -0800 Message-ID: From: Tim Bray To: Pete Cordell Content-Type: multipart/alternative; boundary=089e0158b39a46561504ebda698a Cc: json@ietf.org Subject: Re: [Json] ***SPAM*** 5.294 (5) Errata?: 8.3. String Comparison "a\b" and "a\u005Cb" X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 16:13:38 -0000 --089e0158b39a46561504ebda698a Content-Type: text/plain; charset=UTF-8 Yup, thanks On Nov 23, 2013 1:51 AM, "Pete Cordell" wrote: > I'm not sure if this has been reported, but in 8.3. String Comparison it > implies that "a\b" and "a\u005Cb" are equivalent. However, I think the > former should be "a\\b"? > > Pete Cordell > Codalogic Ltd > C++ tools for C++ programmers, http://codalogic.com > Read & write XML in C++, http://www.xml2cpp.com > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0158b39a46561504ebda698a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    Yup, thanks

    On Nov 23, 2013 1:51 AM, "Pete Cordell"= ; <petejson@codalogic.com&= gt; wrote:
    I'm not sure if this has been reported, but in 8.3. =C2=A0String Compar= ison it implies that "a\b" and "a\u005Cb" are equivalen= t. =C2=A0However, I think the former should be "a\\b"?

    Pete Cordell
    Codalogic Ltd
    C++ tools for C++ programmers, http://codalogic.com
    Read & write XML in C++, http://www.xml2cpp.com

    _______________________________________________
    json mailing list
    json@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/json
    --089e0158b39a46561504ebda698a-- From masinter@adobe.com Sun Nov 24 21:59:18 2013 Return-Path: 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 B3C301AC3FA for ; Sun, 24 Nov 2013 21:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 b_ovNkVB04mF for ; Sun, 24 Nov 2013 21:59:16 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0158.outbound.protection.outlook.com [207.46.163.158]) by ietfa.amsl.com (Postfix) with ESMTP id 805ED1ABBB1 for ; Sun, 24 Nov 2013 21:59:16 -0800 (PST) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB274.namprd02.prod.outlook.com (10.141.89.145) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 25 Nov 2013 05:59:15 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0800.005; Mon, 25 Nov 2013 05:59:15 +0000 From: Larry Masinter To: Pete Cordell Thread-Topic: [Json] Wording on encoding; removing the table Thread-Index: AQHO59Nya/85CLOg6UC7m1NK+zF1YZoyk6fhgALbsIA= Date: Mon, 25 Nov 2013 05:59:13 +0000 Message-ID: <7468141ce23a4984a99486c70284ef72@BL2PR02MB307.namprd02.prod.outlook.com> References: <7404D1DCC5E84DC3B8F8CD300274962D@codalogic> In-Reply-To: <7404D1DCC5E84DC3B8F8CD300274962D@codalogic> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.189.131.5] x-forefront-prvs: 0041D46242 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(47976001)(50986001)(47736001)(49866001)(46102001)(76482001)(85306002)(56816003)(54356001)(53806001)(76796001)(76786001)(76576001)(81816001)(15975445006)(80976001)(83322001)(19580395003)(81686001)(51856001)(63696002)(47446002)(79102001)(69226001)(74706001)(80022001)(66066001)(65816001)(74662001)(74502001)(31966008)(81342001)(74876001)(74316001)(15202345003)(56776001)(54316002)(77982001)(59766001)(74366001)(87266001)(83072001)(33646001)(87936001)(81542001)(4396001)(2656002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB274; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:12.189.131.5; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Cc: "json@ietf.org" Subject: Re: [Json] Wording on encoding; removing the table X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 05:59:18 -0000 " The transfer encoding used to represent the characters on-the-wire is beyond the scope of this document." On the contrary, it seems to me that this document is (or should be) MAINLY ABOUT normatively establishing how JSON text is encoded in an application/json message body "on the wire" -- something ECMA 404 doesn't do. JSON in ECMA-404 is a sequence of Unicode codepoints. application/json is a sequence of octets. Those octets are used to represent ECMA 404 JSON text, in the manner prescribed in this document. Insofar as ECMA 404 is updated to include the substance from this draft (guidelines for encoding JSON text and registration of the media type), then anything that remains (implementation advice, non-normative ABNF) could remain in IETF, and obsolete 4627 but normatively point to 404. This might help resolve some of the liaison issues as well as clarifying the relationship of the two documents. >From a "first principles" point of view: * MIME types for a format are best defined in the same document=20 which defines the format. That sometimes means enhancing the format definition to talk about encodings in bytes in a way that it wouldn't otherwise be defined. * Having two overlapping normative documents with different change control is bad for multiple reasons. Even if non-optimal for one side, it's better to avoid overlap; one way to do that is by making one document normatively reference the other, even if it (for information) it restates some of the information. Larry -- http://larry.masinter.net From duerst@it.aoyama.ac.jp Mon Nov 25 01:44:24 2013 Return-Path: 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 9C4051AD2EC for ; Mon, 25 Nov 2013 01:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 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, RCVD_IN_DNSWL_MED=-2.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 ZRLFSD64_9zm for ; Mon, 25 Nov 2013 01:44:23 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 31FB21ACCDF for ; Mon, 25 Nov 2013 01:44:23 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAP9iD6M023067; Mon, 25 Nov 2013 18:44:13 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 74a4_4427_246e8a7e_55b6_11e3_85f5_001e6722eec2; Mon, 25 Nov 2013 18:44:13 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id C00A0BF521; Mon, 25 Nov 2013 18:44:12 +0900 (JST) Message-ID: <52931BE2.90607@it.aoyama.ac.jp> Date: Mon, 25 Nov 2013 18:44:02 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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: Bjoern Hoehrmann References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , JSON WG Subject: Re: [Json] Wording on encoding; removing the table X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 09:44:24 -0000 I agree with Bj=C3=B6rn here. Removing UTF-16 and UTF-32 from the spec=20 completely opens the door for any other odd encoding, which would be a=20 net decrease in interoperability. Regards, Martin. On 2013/11/23 8:02, Bjoern Hoehrmann wrote: > * Paul Hoffman wrote: >> Proposed replacement: >> >> The default encoding for JSON transmitted over the Internet is UTF-= 8. >> Transmitting JSON using other encodings may not be interoperable >> unless the receiving system definitively knows the encoding. >> >> Does anyone have a technical objection to the proposed replacement? If >> so, please state the error and (hopefully) a correction. > > It is necessary for reasons of security and interoperability that all > application/json processors agree on how to get from the sequence of > bytes that make up the application/json entity to a sequence of integer= s > that are used in the ABNF definition of the JSON syntax. For example, > > data:application/json,%5B%22Bj+APY-rn%22%5D > > Under the rules you propose, this can be interpreted as if it were > > ["Bj=C3=B6rn"] > > An implementation that interprets it thus is fully conforming because > the bytes look like they are UTF-7 encoded text and the specification > does not unambiguously say that, no, the implementation must not take > it as UTF-7 encoded document, instead it must use UTF-8 to decode. > > Under the rules of RFC 4627 there can be no UTF-7 encoded application/ > json entities at all and processors are required to decode the example > using UTF-8. > > Some web browsers had exactly this problem for a long time with other > formats, it is entirely unacceptable to go back to "just do whatever" > specifications for character encoding determination. From duerst@it.aoyama.ac.jp Mon Nov 25 01:38:15 2013 Return-Path: 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 ; 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 ; 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 ; 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: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 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 References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> In-Reply-To: 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 , Pete Cordell , Paul Hoffman , JSON WG , Henri Sivonen , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "www-tag@w3.org" , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=E2=80=99ve 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 it= s 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=E2=80=99ve never actually seen anything else. In practice, it w= ould 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=E2=80=99m still, hundreds of messages later, not 1= 00% sure what our draft should say about BOMs :( > > You should say it that it is not an actual issue of the JSON format who= se grammar clearly defines the handling of the 0xfeff code point. Rather= it is an upstream data interchange issue that should be dealt with in ex= actly the same way as with any other data interchange on a similar channe= l. Say whatever you think is appropriate about BOMs in the transmission = of data conforming to the "application/json" MIME type. Just be clear th= at 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=20 is extremely relevant for application/json, which is part of that draft. Regards, Martin. From presnick@qti.qualcomm.com Mon Nov 25 09:13:00 2013 Return-Path: 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 1A7DB1ADF82; Mon, 25 Nov 2013 09:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 No0P3UkjUyqY; Mon, 25 Nov 2013 09:12:57 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id E42CB1ADF62; Mon, 25 Nov 2013 09:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1385399577; x=1416935577; h=message-id:date:from:mime-version:to:cc:subject; bh=1usSNqmYvMk3BIm8zys49F7C0DQKvIAe8tni0Xnxw/o=; b=m0gtDfkGd+sRD1iYtiQmonEMhT7VJiQFHu0Jrfm5MjvNpdhQk1xj/CPr s/ojv6hsZFMGsAPaE4NtWKxDlGbhQ6/NA+qVHF0E7ZKjzsKg3LiOpUK2X w+RHmo1hgwkHhXL8FXniIgYWh700YdvJEYVmBMrqrbPL4UzeBd4fxhPN2 E=; X-IronPort-AV: E=McAfee;i="5400,1158,7269"; a="55757875" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 25 Nov 2013 09:12:56 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7269"; a="552617503" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Nov 2013 09:12:56 -0800 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 09:12:56 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 09:12:54 -0800 Message-ID: <52938515.6070702@qti.qualcomm.com> Date: Mon, 25 Nov 2013 11:12:53 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: multipart/mixed; boundary="------------060209060405000409050707" X-Originating-IP: [172.30.48.1] Cc: "iab@iab.org" , The IESG Subject: [Json] Fwd: Ecma TC39 Comments on RFC 4727bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 17:13:00 -0000 --------------060209060405000409050707 Content-Type: multipart/alternative; boundary="------------080508080707080200040405" --------------080508080707080200040405 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Folks, Barry and I received this liaison statement from the Ecma Secretary General regarding the draft. The chairs and I will chat, we may consult with the IESG and/or IAB, and then propose some text to the WG as a response to the statement. As per RFC 4053, I'll also post this to the Liaison Statements website for reference. I'll also send an acknowledgment to the Secretary General that we have received the message and are working on a response. Please don't respond directly to this, and please let's hold off of discussion of it on the list until the chairs and I get you some proposed text. As the Hitchhiker's Guide says: "Don't Panic". pr -------- Original Message -------- Subject: Ecma TC39 Comments on RFC 4727bis Resent-From: Date: Mon, 25 Nov 2013 12:07:41 +0000 From: Istvan Sebestyen To: 'Barry Leiba' , 'Pete Resnick' CC: TC39 Dear Barry and Tim, Ecma TC39 had last week its 3 days face-to-face meeting at PayPal in San Jose. The attached liaison document has been prepared and approved at the last day's meeting on November 21, 2013. TC39 has requested me to submit this to IETF officially, what I would like to do herewith. AS you may know TC39 is generally very concerned about what is going on with the update of RFC 4627 in the IETF and what is reflected in the currently presented draft. My request would be that on behalf of Ecma TC39 that you look into this matter. My other request would also be that you put this liaison statement (including my email to you) on the json -- JavaScript Object Notation (JSON) WG mailing list. My last request would be that any possible consolidated reply from IETF should be sent to me that I can distribute it accordingly in Ecma (incl. also to TC39). Many thanks in advance. Kind regards, Istvan Dr. Istvan SEBESTYEN Ecma International Secretary General Rue du Rhône 114 CH-1204 Geneva Switzerland Tel: +41 22 849 6011 Fax:+41 22 849 6001 Cell: +41 79 206 3200 E-mail: istvan@ecma-international.org --------------080508080707080200040405 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Folks,

    Barry and I received this liaison statement from the Ecma Secretary General regarding the draft. The chairs and I will chat, we may consult with the IESG and/or IAB, and then propose some text to the WG as a response to the statement. As per RFC 4053, I'll also post this to the Liaison Statements website for reference. I'll also send an acknowledgment to the Secretary General that we have received the message and are working on a response.

    Please don't respond directly to this, and please let's hold off of discussion of it on the list until the chairs and I get you some proposed text.

    As the Hitchhiker's Guide says: "Don't Panic".

    pr

    -------- Original Message --------
    Subject: Ecma TC39 Comments on RFC 4727bis
    Resent-From: <presnick@qti.qualcomm.com>
    Date: Mon, 25 Nov 2013 12:07:41 +0000
    From: Istvan Sebestyen <istvan@ecma-international.org>
    To: 'Barry Leiba' <barryleiba@computer.org>, 'Pete Resnick' <presnick@qti.qualcomm.com>
    CC: TC39 <e-TC39@ecma-international.org> 


    Dear Barry and Tim,

Ecma TC39 had last week its 3 days face-to-face meeting at PayPal in San
Jose. The attached liaison document has been prepared and approved at
the last day's meeting on November 21, 2013. TC39 has requested me to
submit this to IETF officially, what I would like to do herewith.

AS you may know TC39 is generally very concerned about what is going on
with the update of RFC 4627 in the IETF and what is reflected in the
currently presented draft.

My request would be that on behalf of Ecma TC39 that you look into this
matter. My other request would also be that you put this liaison
statement (including my email to you) on the json -- JavaScript Object
Notation (JSON) WG mailing list.

My last request would be that any possible consolidated reply from IETF
should be sent to me that I can distribute it accordingly in Ecma (incl.
also to TC39).

Many thanks in advance.

Kind regards,
Istvan 

Dr. Istvan SEBESTYEN
Ecma International
Secretary General
Rue du Rhône 114
CH-1204 Geneva
Switzerland
Tel: +41 22 849 6011
Fax:+41 22 849 6001
Cell: +41 79 206 3200
E-mail: istvan@ecma-international.org
    --------------080508080707080200040405-- --------------060209060405000409050707 Content-Type: application/pdf; name="Draft TC39 Comment For RFC 4627bis - Google Drive.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Draft TC39 Comment For RFC 4627bis - Google Drive.pdf" JVBERi0xLjQKJeHp69MKNCAwIG9iago8PC9UeXBlIC9DYXRhbG9nCi9QYWdlcyAxIDAgUgo+ PgplbmRvYmoKNSAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMSAwIFIKL1Jlc291cmNl cyA8PC9Qcm9jU2V0cyBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0KL0V4 dEdTdGF0ZSA8PC9HMCA2IDAgUgo+PgovRm9udCA8PC9GMCA3IDAgUgo+Pgo+PgovTWVkaWFC b3ggWzAgMCA2MTIgNzkyXQovQW5ub3RzIFs8PC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGlu awovQm9yZGVyIFswIDAgMF0KL1JlY3QgWzEzOS41IDY0Ny4yNSA0MDIuNzUgNjYwXQovQSA8 PC9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwOi8vd3d3Lmdvb2dsZS5jb20vdXJs P3E9aHR0cCUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtaWV0 Zi1qc29uLXJmYzQ2MjdiaXMlMkYmc2E9RCZzbnR6PTEmdXNnPUFGUWpDTkVDVmlMdzN5ODhK S28tdlhvNWdhZjJDN2paRGcpCj4+Cj4+XQovQ29udGVudHMgOCAwIFIKPj4KZW5kb2JqCjgg MCBvYmoKPDwvRmlsdGVyIC9GbGF0ZURlY29kZQovTGVuZ3RoIDk4NjgKPj4gc3RyZWFtCnic lX3bCmVJbuV7fUX+wLTjfoHB0GW7/TxDgT/AjA0DNozn/2GOdnXX0dLaWlVDviSpDIXuoaNQ aJc/7fmjfP78t/Lr3/ZtP/71P376Pz/ZP566ftQy14//+l8//cuP//yp/rA///Off/z6l//6 95/+7p/Lj3//v/Sf/+23f2m1NvwX/D/F0P36lw+6n3/56e/+Un7U+eOXf/vs9hBWf9zPolp+ /PIfP/33Uvr++x+//O8v8IPOQWcL0NodtPQI3R5zhDYPHSdAO+wbqepXrR1bUTWrp2oG6GoK 8y6eqhWhx0NrgB4v5/EPEQocRcwXZPVPCG1leH7/EqFHSKNVz28L0mgNpDECtIM04lrUYIQO WPsPEao02ECDLfI7lW20tYUWGuh3RJpBvyQN0C9p4RbF0R3CB3vpguZe/L6zBGi9Yt/eutB+ 711osHcljT6W0G+fKm70uRXmNYWX9Q2yipI8Ve17VKzrF6QRMaOH/ozQAVE02uSoSs6jQlQJ kWG0JTga6KF/DtBRFc3jCmkM0FG0urGVtY89hD2PvYWch9TgQA1Gqq6y2FmUxU550k046WL0 nk3Z1UQvC/Y8UUcR81CxbqKOgl1NOOloX9Tgr9Hsn34RKcT8LYwE0d3rgHSSW2ybmVxr2Q4a LbR+qHDQoM/aPGY6q3tV+3bAHNcOwBxzoukxRxusa3jMlF80RdVeSpKnKKrOUZhvU5hBvVEL T/aRcvTkF+m+rS6hwdaGoKq1o6C9KaoGyKpGqMQ8AXPMIOYUWmirq323ssm2JebjMY8boVth vn7fFmTVC0CDL3TQb4/ZB/hgiyc56OjniBl8MPpvHypu9OH5pXxqLmEbHT007gseGn2hH2VX HXyQ8jjQAu0LUTR6ysA4GXLPUYuQ1ahD6Hc0ZXWjgz3H83YsBZ1XSGMsFZHGUpHwyT5S/Y59 FPQsJavrMdcoq+sx15hBFIV5oo5+jlCvhZ/j2laEtc92hX7nUBzNITkCP/o55lMLollcu6Q0 QIO1ROhU0KOsfR51pkz00KiF+xI3ZE600/TDDs2dkVHtJ/tvUEpsKmCOZYbmMccfQNVCbo7Z jOGLOZZGxlSY7Sddzu+qDhpVVpeU1QaOYsp0mpLkWQp6Pb9UkrldyLkVz9H4c4ReB+W0BzDH o7xVoYXWltq3D6HfNpriaCppNNTvP8bEpqp91xVaaLurffdSsjpDcXSb0gJ4aEyZeili3w4e SqUR0C8lJ/Zj8TdoC5LsTWmwg//OSHO/au3w+/aYYEwPpfRjTcXvVpbTQb+Tii5V2MZTkskl eTy/Mar0OyRUeegoXVD1pFtffmPhpE6hhdEk5rYVVV152eiSo+H3jUXTMSXmCf4b0561FUe7 Kqq2lxUlnxC9iSrQLyW9dwvoBO+mJAFOZ0oDqjpDn2QsldVsR+2Lp3Ms2MDpTMWecRR0qpxh rqGoWoA5JnKgX+J3K8uZBywn0nyn4GiBh8ZsZFVldQs99EYo0Bwi/wIP/WsklEng/S3kxoTK wshv0BbIeNK8m7nGc3v2G7RSmjc9NGK2UPCFRqpm9dA/R+h10GiidXmqKKGyY+JmxvDcnn33 Dcfik+bdoNCP2MufyvpsWv7U7bai/Ok8F570j+nl55Mg3szVq4WYL8WUPh4BbcVTHI+9Vovg tlW/b41JTz0K2vy+0TGeO7svlG70JEejqbWzqLUTJBmTWrQqSh/BqoLdPHWxLzTejYLdUB3w FkXVBS+i5PIKW+9F7durklUH7VNiitqPNSbQPqWtXfHbIWrEnxYdo0bEPLawuj6nomp1od++ q9oXtU/pY1f8niOsrkPsjloYRWlwFPDfWPkqynJGVZYzmty3KcsZ7SiqOmjhHyPUS4NSwDGE fscEmwwWO1ZRVK0pNDjgRCF+9xB2NSAyxBN0QGSIJ+iAyB9P0KfSl56gE707rsXoHZOtNoUW Zn/x0M8Z+esZZ174tBX9f/YG2Ynx1xwkll6Kh9It2YfPL5TuwT75i1sbC1GfSPSF8u3c9VTF LONzSrl9Y3nsc0o5KBWxPM1UalqA+SX3Efvuqfj9xClB1QFZUZkKOIr3fh9LzalqqMF47oIG 40+oVrfQkRWx3Np4Z9iu2reDJON5P5RttOExU9Y1ATP1BoGOqPunK2nsJXTU9lUcoX6jrO4U Nmm9QQ5KmUQVsupV2aTd3Ym1TVl7B/+l83504Ud9gMXGss2qiuZ1hR911CCVqbwGqbQGHkpa uFLOoEE6O4vyfSs15fwO0CCdrE3ZhhWTBGaIsXTujqEwzyakMSZ4SjxZl4pmYx1F1VYWa31F Qs5HxatxrtC+lZryfWfxmGO5dxbPUSzKzgpQ6hzysurUOVQUVaBByiRAg9QLNa+wurmUnK1c lFvdhDhJ3U5HYgYfpMzpDoF5FWWxC0/JkM8tzHNmhKqTbmEUDbFugQYJOrvCDHGSqFpL8buL sI21j5DzAj+KtrGO0u8CP/oD96vte61NN6jbQSmRs7CZt3dZ2MzX9uqglNaaW33XUmmtKcwW +mamsro8zZQS28H3vRKPa7eXRo1rz1TQ66URWwDsFjSnqhWQM6WXHjMlRU1ibh4zpXm9q31H FXJuw9sVl7GKomp67XPzF2g/tmitpTBvv2/8IdYOQKMkr+eXWrSKp4patKpfS3dodQmrs5tM B6W7yqbWDiXnDl5WYzIGXkZJ4PQ0UwPXGmpfSz/yRrntoVyKgn1j8nmuohl8kBvHlrA6K0U5 aEwRK2iBoMomrRTl7IpKUVfIefQtOBqgfS42HUUVap/uKouQ8wDtU0q8m5Ik+CClxOcozKhB KidVgXmWK6Qxq7KcCfrlu0rlC3aTmXM0O1h7vH3tV+07trDnOdU5+KSm6bnwpKZfaLxv3HBa RS2crjiS3j2P5Pdu4SkLz9B4C4r6jbeg8gxdTZ3Oq6vTeQ2JeXjMsUC3wH/jT541ARpvX+Ec jJcBaw+1L2RBMXqvA9D1+8nnt7UkVvMs5H6hdK/bPDSmahZU87XmdPnaDlTFG9RR1NoBmOnN pOR3DQXdwC/VRT1mSmuPpzn+dn7qomlDk72ZdNCYjFnY/EJjXbReQVWzHwhpe0jr1UOptukx c21zq32nxxx/ejTQAu0LWqA6MMiZXmMeSdUFquiGVfHbi8fMt6RTrQUtvNYn8/a9PgXNT30y b0kDHRFV02OmVG16L6MUcS0ljT0Uv/sofg9gjqn4LQrz9fvGsDkg1lEDF2gw/vSwt4tuLVUg YS0lgSDnCJ2gwVgnRC3QywOw55herits46lAima3LTzU3i7mHjpuF5bzpIiinW0Ku3pSRNHO VoUkJ2iQkqJ2hZyt2U1QBacV7Qva59qm0tGcKnpP0D7RDDGWm92aogpOOqqpnq6kcdWZMjHG xlpfUXFjlSNktSBXodQUchVKTSFXoX1B+5SMDdiXUkSwjVgXXS/2LBO5b5NdbHaz4yltxXiq iGlbw1NFzNf26te+JXJpY8pTY7yZ09nwiy/0bfiF45cSueKpojccR0H3UvweTzNVTS/IOVbk yhT82ngLhzmmLqAjfodxhZxb81RxjXEq6OhCv/bA1EFjajq9JONFpD0hzeVsT0gdlF5aXCWN 0xVHFyz2Lc1LNdjRj4IGrRnOQWPKVIFfSgKr0GBvnipK5HpX+4IP8hU22HO8/rYaVCrnPiXm Bd4dUzXwQU4Cm+IXPZSerg5hV/1KjjCKxtax4uVMiRzoN/5Ms+enDhqToq68+7nCTtsZB8RJ ThGbsKuBcZKGX3QFPSq225sGQdVV/jtBzpQkVPBfumiWmJvEDGcZv2mYal+MkzFVAx3RvlOd vxPj5Ns1dI4Z4iTX+prw33mLouoe4WXPRXMqyVXV6bzqEZJcTdnz6orm1Y+Q5BrKntdU9rzm VZgXZDK/P4KkfycZvXQqOih1Km4Hjb9Srebm1lKnol9LD1s/eayDUrdh8VBK1Y5auzxHXFXz mHmOyPAcxRrjJw34QuNB//SR5nPZ7hRrWwHMlOZ5fnmOyBIctVbUWtAgv4jwmKlz73OI5Pxa mifWDo+Z0zyvBarILW85VCeU+m2gX34y6zHzpBAp51uEl9mT2dzL7Co59zJ7t5B7We9VeFkH DfJVspcGXUPPptYuJWdL1Zyc43uJPYVtWL3OQWNKfKqEDkXVOcKu+lU2adW83EPt3YKDUjUP 7IqqeUX40ehDyGpAjI0/iAbol3rzQL/0SHRCvHqZQZLLeUAE5l7EqqjaV/jggAjM3YZV7Qv6 pTpSUTHHHra6tXQdrGLshBj79rA1jxsTTkmaUDK9NGLcmOCDMW7M7dfyHBF1wk6IhPF0tn7C fK31E9LpLFOXtI/CBrD2eC/pUhe/No5vsVkgDhofDphS8o6y7jHHaoDVoHp6G241qJ7eLNfp OaK62Sdv7+m9czW3ymnegDlK0pwu7Suwy0SB+VZF1b1i3yftEV1wgDkmRaBfHoFWBM0NtE/J SdtCC1bdEpi75zf2Xtotuts3JmOW1qa9l9YFJ9ZuzxFdgIIGqYp4p8DcQUf0JKEcIQ0bgea8 jLrgvDRiGOnNY45X570r7+7gg9wjd4TlPGmP6IJTGrQalNh3A+aYbu0lfOFJbFIvsxqU4Aii KD+5rGLtgBjLA1iLoNnGs+b2bFecDhoeJ9uTy1yST9qTRmC7ABU0gw/yg0xJs/TBsZWO7FGl gF4Vr6z2lVuOPbnMObInl7k0ZlWnhg1Xy+PkBP1yj9xS0A6yekt78n2HOiWfpOi7Nj4xXZLf BRnFSxdcnm88SdE3V4kJ1fUWG5OxVZSHLtARJVTVnzgxii44y2itPMsWnGVUv4JMhmpuU2Ke EvN6OX9livi9LeUBu18gtUEVgMasp1UHjf10tU2x7VMYS69wawcojdD1VPEtZfdrY9uXnU5f jqgwdtW+x6+lVrVzFFV2/uStW8Vj5hxwOCjngIA55mLNY6byFWiB28284fA9ZFWYQUd/4EfM +P5KixfptTooX6RfByWxt+6gdFX+YV9g7p6q+XKR7qBx7SdFEpg/RujWvlyVOyj9EGmK373U 2uP3pXk1B6QR+b0KsxlwTpUZsFp7BFX2IyaXpP1MEfuCfmMIsl7LkdYVzLydTb78THFrYx10 Kpu0S3i3Nk7v2R5zDMgNNEh9qdfbRrzwtMc6OVX2JYjcB+2q3GkwXju3K7ysd6+jmMZ2kDNV OtHLXq7K3dpI81I2afVXp4WX+qvgCLTA/ZLgv3QZDn5EowM9VX/twk7DpvV7j7+lAfX+TrfS E7G+6Rc9L5wOyhGrO+hbYcVBKWJ5zFw6AcyRKpNlTpXJMi80lCKoemJS+iPWDtV83+bl/lo6 yfm12fI5vza9wu1Ld0J+XxrfOo5aO0FHNL71+rUvM7QclKZXSGnsobSwJc1H2VU7U1ElLadJ y+loOS/jWx1mmrDVFOa6hA9a3/kXGk8VK+g4KBV0/Nr4M6aDd9M9Fng3FaHAu+NEor6v4he9 m541biXnOxXm6/eNU80HeDc9L6yeKnpe2KqwHHuamFNlRZncj+ybOY5fKspcBZ3KB62pKPej Afqlkg3olx8uXqHBAfqlfc8S+rWSTR6RZvF+FH9cWsnG7UtzMYBmaldSVmdTsgRVoF++qfKY qcAxVESyIasOGu+T1hBynhif6R5L+dEE/dL8f4ii1HcOHhot1oas5vxaySanyoas5jHWCjq5 BhdEUWob6io+L4yxwa7WUN698ISNNM+j1i44F2hqxhL+u85Q/J4rLGfdJjS43zIonV/mxSKz 72+5gAZU+LXRn206moPSd4+mh1LRpjvo23S0IYo21XP0MsTfYX55I5jva+MrRl54aVWtbcAv Xc0dRVX3WuBvFw0hjSe//EJjxjw9R/Sr1s6ntMz4ZJD5a8vTlBauh8YvhbTr9Ru/MvL8Is7f rhWwWMrzPM08xH8KLdjrQwd96UgSVA2/b8x7+vD78reLwMvo4q4JL+ugI764G0L71pGUa7+j l1FXURfaH+BH/HUir/141TzAU7jnaAkfHKAFzvOOomp6OceqlHUV5R76ZHI5VTJODoiTdOl3 gCO6mjvCcqxvKJeG9Q3lHFnfkFsbL6NaERzNpuRsfUNOzsF/7duIuYfaK8BcVhP8KPrvRC28 ZWP5+8Lt96WvIh2/7+8V1Z/q0N9aoP9Ydej7WOLlAz1fKFWOV/VQehh2HZSrQx4z17O3X0tf RZ4eStNLJebrMVNtuBQPpX7iImRlD8Pc2lgbNpvNn1GZzaZt+k/9Rzwb85i5dWZ5KLXOeO1T TrG8rKjrd1e1dg+172nCcqxjOLcc++6x2Bf0yzWcKezKno3lOrJP8OQc9aZs0p6NiX1HFfw+ Z3v+XA09lGYHLLUvaP9tcJXYdy+19oAGqY4+hcV28F8ailRAVjRZ4Ap+B2qQ8gIl5yE1OKQG B2iQP7IjaZ7Knm3SeS5nOzMclB6VdcXvlRzdKazO2m7c2ngCF6X9KX1wSg3OJjGDBmM0e2o4 KUcTIzBNTT1q7VSStAdpau0R2rfvIQqqtvJu62MWmM9SsoL4TJghPvPEVZAVDa5aQoM2NTXf 1x6zufM31nDANqjS0gEaK0vD20b/vfzrk1HN9HbSOgRmesNYP97u1lJGNf3a+G7so1EBvVVh vldQZXdmM7/XLkdgtnv8md7k2p2ZW/vyPWaxbwfM1IhSPOZYtRiS5ikxr6KoWkOuPYqq7fel TO4AZsp7qqLqesvhnOkIHVk9xEHphZbi1747k3PU2xJasP6B3Db6ULbRh7I6q4c4KD2mVx7a 1xZeZnmP4OgcJavbhI46aJDeM5Um5GydBQ5KX3ruwq5sYGcu5wH+S/lHu4qqDrGOXmhVtXao eDVAv7QW9RvzrQ2yojszZc927yVkdT1maqEtAKW7Ky8NumFqniN6z9T9WnrPBFGU3jPBWUbv meAso7UQJ/9I1WL+bY73H6pazHQCvn2R5QvlqkVzUKoe7OKhdOdwPOb4hOlUD6U7h+ugXJfo fm08kYrHzF9kUZjtzmHGCenuBFY02zdXZjq3/Tmf09n6z/mcyrmBBrnJVO47m5LVKkJH1oUn ZGXRPZfznkqSR8r5SjlfpUF7aJTza2+kc0la50kuyV79vjwtcQuObB6ioLlfYRs2LTG3Dfvm lMA8p+IXtf/yDMmtpduMpTCDd3P33xX67RfsiqoWYFcvw25yjkZTsrKaRq6Fgd79Mm5b7DuU 9gf6bxyjM7eQ81jKuwfG55eahoDeJTDbfUVO1ZQxdqKOXkZm51HFRmYLzO0omrvEjDH2pS4h 9kUvexmUk/uCDcrJrW5iFKW7jq7Wnq3kfIui6h7BkVUecqqs8pCfKatuIcmFJ2zsD0EPjZWH 3oVN2pCd3NoX6jfSPJX/2jMkIQ15Si7Qb7S6dZra94A9R+gdgqpdmpDVLpvtSueXee+y5R9p l5J1vMy008jegMzYW+Ogfl/KXDfsS+MSi9r3AOZYlboeM1Wl7PTKu4Tt9JqZFdp3hwXUfpvk mC2HyHumQUdvXSti7exCkm15qui+bUmqtrIcu/dy+1IWCLZBGaTniO6fyhIcPVWadF+bo5NL 8qnSpBrsqCOaiu0t523ude4LfV5F1QINvvQuC2lsifkAZvroCkiDJuWAnGlm9hG2MUCD/KC8 Ci08dZi8l7c3IWfreMn5HahfqtIoq3vqMHnP9DyKqqVi3ZMFftfGzHVvhfl4ScZz0SZqC5rP VXLGOBlrOBAnCVq7sA2bqJ1r356M5/HKnoznNBskt+cJOuL+Y+VlE+IkD1PcQs4TdMSfVQGb pCxQnb+rFCENm2wt1tYmZGWTrXMN2mTr3LufPC/V70IvexmXmFv7khpceNLF3HQd1q/OmdLe KXu8PdOOrufeK+25tD4jsXZdte8eaq2dx2mPmn0leaa9cfaV5ByzfSV5pj1q1kk0024w+4by THvUWmsKc/P7UgdTB+jLl0S+0FhltiE8bu3LW7EvNFaZ7UsiDkovurw0YpXZXnSJtddz9Ace nC/54HylxX17cL7S4r49OF/pxY9Nbl/pdYU9OBf7ftxK7PtJc1d6XWE/Rdy+8WfM8pj54+NN Yf6oTNB8juL3drGvlbpzzFbqdlBynC1kZaVut+9Le73DTB/oUfq1R+MC85iKqiE5mp4jbtAD LdDU9yGhR8l5L6FBe6Ap1p6r9Hu3sCtr0MsxW4Oew/wy1z2Xc0f9xrS+HUFzBw99a83/QqkJ fnh+qQke9BsbT+zT5A4aqdoqItnPGMdvfL55VUTqECcpzS0QN+JPEfBBgvaiMHcVN8bogt8x lF1Ze73Yd4Gs6JHlktArLNZ+iuTebT82BEfoR/SMEuRM18keM5VRi7KcCV72VszOPcWK2QIz eBl9uLyriDTHEvq11nzB7zyKo1WFnOdS0WxudeJMiJNxctAE/cZx3BNOyfg4exUV6xZqP/4U Qf3SI0vF0YIYGx+y2yNLFwkjZjglY/K5pl9L87jgpIsP2RecZSQrOMviQ3Z7RumkEdfeJixn XZBz4GiXzvqVqem3o+FloOsXSnVhU2h6K2LjXr9QmuFhDpt3JZjD5ph7VZj7VZgH0EzjXqta O6fad3nMNIR2e8z8ptTTzEnvVtL4/FoUHF2QJH2QSPHbUPvxV1tVknyS3lRW1t+RS8Omkgiq BmCm/g7ATJOSusI8t+JoTbV2XSVn+1GTYz5eg5z0ghbiFJbbhSQ76JdHxS7Bkb04dWtfJjTl Wuig37cJTQoKa2lCk6R5Kl+wL1o6KHVwLMXRBpqjnI/XL88dkTSD/1JvCPjvW+0+33eABrk7 EzDHfsQmMXfATLV7FRkG+C+ltUOdC/bSNfdue+ma68hmlgiOltLvAP/l9y5byfmouPEk22n/ zpNs530HBTii9y6KKhskm3Nk72DzmDPxdKb3LkvY1QT9cjrdFGbQII+KBcyRoy0xH2Ub9g42 j4Q2lSTHbFNJBLRWISubO5Lzu1oXNNtUkjxzs3cngirIkXiQrMpkrIND0LwkzWsLOa/9Egll WpteANtHz1d6cWUfPV/p9ZI1DK/0Ou1JXNNrjydxzRs4TCli7VH7Ds8vp7XALz22ljQvTzPX cq+HUi13Ky0cz+8f+Z2Svxe3TPX7BuvlwxNf6NuHJxz05cMTK3379ZTQ01ehTwk9f00+PWbq 2rZYl75Is5mtDjPdPXUPJbFXD6VucS9J/jXRBUfPr4mUo6eEnr81t5//+Tv1pmh+Sujp276n hJ6/+R4S85iKqnHV2tkVVasK/T6/JlL9Wq+PWHuUxdo3s4Q07lD73iv2tQ+n5vtat3huG9YP 7valXxMeM3UCjSI4sk9LOCi9U6/Cnq0TSHC0lJdZJ5CDUse3lOTx/NJVxZ2Kowv8vrzXytcO iKJv/eC5NAb4L31WFWIsfVa1AzT+xhkQ+emd+lJUYRR9mVOYa39sFRlsuk2uQesHz/3IptsI OcNJR998L0NYu023yTl6svrv2resXrxiV3Ke0gcn+CD3+gC/L5MIxb5LeffcyrvnVtF7ggbf vnGf63eCBqkMDhqkXmPQIH+nvoh9V1Nn98JzMK6Fc5AKzpDJUB/62GrtLELO1kXkoC99Qrn2 11KRcGGO9DLjUEAPUBW1cJWObIohYVZp7U7vj+oH1RdK5fdyPDSmalVibh4zl9+HwvxJiR1m 6irZfi2lxFPt+0modnonYs1aAvPymKMhWVfJTm+mrKvEQWnsE8iZPiO7BEcNNPg2FDzXrw0F z/ltUoMNNEjJNmiQCvujCFlZg7uDUgl9KZrXUDSvo/bdgJk+BSulcYbSAuo3auEqjnpRHHXw UOrQqN5iqUOjAZQGO3lfoA6NsRVVn6TXcRQL+9P7ID9zVJGho5fRkIKpoFdFMyt051RZk3rO 7wA5E+bWhe+PDrKiMvhV+44urG6AjugR5JQ0L4l5Ke1bWivW7qmoOn7ft/Hbecyx8duCKtQ+ FbqrwGxdJTlm6yrJJWkN7nk0m+0qKPggJYFDnTjW3iwwz6MwL6UFG84k+N0qEtpwpjzWzaNO OnsEKXQE+qWECrybUtMKMScOWKoqK1gQRWmUdVd+tLryI0uY82hmaW2uhbWa2nepzG3tovjd ynIW+C8/ggRJxl6XW4U9r/tyasikN70FeJLevOfEjtS8j6J6zJzWesz8ibjuofR1Lg+l+rM5 +3ctvcysiioL9bk07DhO739tUrnAvP2+lMZvj5mnhmwFvUAzze0qQkcNNMh14KWgltb+Bo2t azbrNJfGk/SmOrI6cC5nq/QKfudQ+05lsfYRYYeZJnN1oUFrh3Zr49uH66miCmTx0oi/6K0d OqfZ2qEdv3FtVTZpfSO5tT9Jb+r7HXyQqBrKy2yaqfPfmNbOJWyjL7+WvoSz/Vr6Es4Bi6WX mV4LsYFwgB/FBsKBkZBSYk8VpWr1Ci8bTWnwSYnzjoWuPMW6O3J7tv4NB6XuDnVqWKVX0Lzk vlv5wpMS57I63ia5WVrZ5IAo+jbN1GGm79WAfulV5xAcTfBQauFGH4wpovTBiVE0UgVRlCd/ dEUzaJ/SWtAvV3pBv7HufYqSxjlqX8hkImar9OayskpvLo2F5yBVeqvC3K6Q5IJzkD8iXISX rSE5Qv99aaUW/KIGae1hL5PpZd6/YUrJOxZMKaK7o/i19AXi49fGlKkDVdRmcBVVVivIh2hY ApkP4JhX7bs8v/yhxSKhnl9qfjhSC3cIzK00wZE9cXVrY0NsBVnFhKpNQZW1CuRaeFJEMfjD Y+ZGAtDvWwKZjyNBHdFwOKWjBjriqmlT0rhF0XyngNonDXOrs8FyOUfWKpBbu7UK5FqwT918 oVRx7Z4qqrgOgNJwOC8rqrguZbHWWpxHBmstzqNKPyoiddQRjbQHD6UXc1Vof1QVkZ4UUYz2 qMImR1cafKqmKUdjVkUVxrq3uqgY7aHs2T5XI2g+Q0njgA++fMwmp2rCaUUpUzmC5qfymWNu ysueymc+gKOrU2OCH1GNcQxFFXgZfwhHaXCuKbQ/d1eS3Ft4ygQv42YAde6vos79VUDONP5t C5oXaJAbgMGe476oQaptKn7X8PzGIsyaKhKu6aURJyGs/RKRZJqXf+HPHCefv2Fp3hca5+na hVH6xbtaj8LcPFWxJ/+pIuZrLcHIvw44JFXDU8VVxKYwz6UwW1D9YqZXb1th3lVh3l5H9OWA 4zFTk/b10uCvIXo5c31SyaqhbdC7tuLXvlUgc8xdacFmpIi1w+/79l0BQfOUmFdRVK0hobAv JZ9L6egMJcnbBOYnvcy/HYj6pcnEXez71CdTa7d3bbk0Ong3rQXv5ol1V/E7t9D+U5/MqVpX 2EbfW9F8JOZzlRbuFnK2XtOc34E6ilU10BF/TwmoordpTVGFXhYrruBlPFeuqX3nFHJ+LvRz 6FaWY1/MzrUwjtLvuEq/414hK3tflutowhlKSWBVfjQbnJIxCexV8Du7xDy6sDqbTCw4mlIa cA7Sl4vwHIy1TTgHeTJxU5I8S0njDuEpq6jz6ElcU3t+EtdUGk/immPGGPuWuKaxbskMaskM ag3lg2t2oQXrRM1zlbVfsk2ZuOYPfyxxTZuHn8Q1bR1/6pP5cyRLTtJnFE/ymT84suNJPGXa HkpPmTxmHkw8/dpY29wgK0ogr9rXrmbSRnr7MJWg6k6F+V6BuZUtJNnqFPvaxzxz22hNYu4e M9X6+hWSbKMJ/bZZ1NrZhawa2MbbJLHc2p/0MqcKbIN7PiXmc5SsblOYwX/pCrsUYRtPapo/ /KmKow7eTbVNsA2qbXaAxhojeDfVNudVVC3wslit3d7LKBVH76bPVkEkpH7RLaA2+iDHbKMP cqqejtDfoH/gXer59gbEHptPlnvSO6/6OUNPesdX63BQrjM0vzbWGZrHzJdNsJaeEhe19pNB nXgT5w6C6qF0TFwljQWY6RDZat8t5bz9vrH3w+bnOA1GSV6/liaXVr+WZoR+zMxB6cvM3nJi 70frXvux98PCdc5vG0tI0oK50288vKanma+iJOZdFFUb7Pnly8y5fhvoiGsFR1BlnU45R70q a7daQb6v1QpyP+pNWbvVCnJpWK0gl4aFa0HV3EoaqyppLBU3rL1f7HuKksY5Shq3KZohxtIF SlFxclTlKdYl5fal6fZXYe5ezlSFGFNI0ioJuRas00nQvIqQlXU6OWjcd4Nd0dMAye/ZiqoL mOORihp8ueRy0HgVBRrksZBTWJ1VEnJZzbYFzbOruDGH0oJdcgmahzrL7AtIuZdNOCX5PexW NMMpyVWIo6g6S1F1lQZXUT5odQaHOa6tW0jS3sPmWlgNqKJKgqSqLyHJBfrlOsMRslrg3dRI j/4b+74gPlMV4iiLXVfK6iqLXRcsNmQy+y0Cy4Q5veGtpToo925dD42pmh3WYm5PVfu2pdZa Mia6s5pfS7PQi8Js6Vbeu7U8Zk6JQZKUEg+Feft96bHDASh9gMBrgcb1V88vjeuvfi2N62+e Zkqnu5cGjesfRa0dSs72YU8nyZhsL7AratEHi431DdACj4XcwjZs8KOg+XhJ0q/jAjb5lvTm 3VngR69Jb2qT1sAv9u1d7duX2ncMtXZstXYCVbFGAfrl+sZW/KL2Y7VnX6FfG/Mi9r0g5/gT AHyQ0q2iZDXKFtKw17JibT1CzgOjKE1ZV77wpNOiK0xZ3ZNs5zSD79Na8H2iCi2HRkoqyxlo OfEScwPm+NgBLIf7zfy+saBhL21dBKaxkH4tf/BbRWD74LeDRswdIjCl014LsaBhU9Zzfiec oZTkwxnKXWHqZJ8Qn6nvCzyU37Sq+DzBQ/mDT8rabSyk25egyvcXnKH8YU+wdmrvBzm/9H3l ec6T1ubdaEudOAv8iD4HtVUGtbY62Z+UOPUy++ynoOpIOYOX8Qz2l8xNpsR5h5UF87yzqxwH fXsP69a+jHk56W2pXRee9P7XRlme9P7XnjMIzFZDFl/skhxNzxFPTQRZ0ZT15te+fFpI8Hu6 4vd6afBXTpU0rFctp6pVkHOsi9YrqLLrQoeZLgSrkFUDDdKzgrGFrJ4Kc07zPIrm5fX7By5f 7rew//JdrZv+HLbvat30h7a5xk1/aNuMoxt/8DoDnn4t/R7sHkqNmh4z/x70HNFFxse8BVUf 875picZ+8QlZgZy5nRLk/DL2M5eGvdZx/P7lb+r+Hz/9P/Nt45sKZW5kc3RyZWFtCmVuZG9i ago2IDAgb2JqCjw8L1R5cGUgL0V4dEdTdGF0ZQovQ0EgMQovY2EgMQovTEMgMAovTEogMAov TFcgMAovTUwgNAovU0EgdHJ1ZQovQk0gL05vcm1hbAo+PgplbmRvYmoKNyAwIG9iago8PC9U eXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMAovQmFzZUZvbnQgL0FyaWFsCi9FbmNvZGluZyAv SWRlbnRpdHktSAovRGVzY2VuZGFudEZvbnRzIFs5IDAgUl0KL1RvVW5pY29kZSAxMCAwIFIK Pj4KZW5kb2JqCjkgMCBvYmoKPDwvVHlwZSAvRm9udAovRm9udERlc2NyaXB0b3IgMTEgMCBS Ci9CYXNlRm9udCAvQXJpYWwKL1N1YnR5cGUgL0NJREZvbnRUeXBlMgovQ0lEVG9HSURNYXAg L0lkZW50aXR5Ci9DSURTeXN0ZW1JbmZvIDw8L1JlZ2lzdHJ5IChBZG9iZSkKL09yZGVyaW5n IChJZGVudGl0eSkKL1N1cHBsZW1lbnQgMAo+PgovVyBbMCBbNzUwIDAgMCAyNzcuODMyXSAx MSAxMiAzMzMuMDA3OCAxNSBbMjc3LjgzMiAzMzMuMDA3OCAyNzcuODMyIDI3Ny44MzJdIDE5 IDI4IDU1Ni4xNTIzIDI5IFsyNzcuODMyXSAzNiAzNyA2NjYuOTkyMiAzOCAzOSA3MjIuMTY4 IDQwIFs2NjYuOTkyMiA2MTAuODM5OCA3NzcuODMyIDcyMi4xNjggMjc3LjgzMiA1MDAgNjY2 Ljk5MjIgNTU2LjE1MjMgODMzLjAwNzggNzIyLjE2OCA3NzcuODMyIDY2Ni45OTIyIDAgNzIy LjE2OCA2NjYuOTkyMiA2MTAuODM5OCAwIDAgOTQzLjg0NzcgMCA2NjYuOTkyMl0gNjggNjkg NTU2LjE1MjMgNzAgWzUwMCA1NTYuMTUyMyA1NTYuMTUyMyAyNzcuODMyIDU1Ni4xNTIzIDU1 Ni4xNTIzIDIyMi4xNjggMjIyLjE2OCA1MDAgMjIyLjE2OCA4MzMuMDA3OF0gODEgODQgNTU2 LjE1MjMgODUgWzMzMy4wMDc4IDUwMCAyNzcuODMyIDU1Ni4xNTIzIDUwMCA3MjIuMTY4XSA5 MSAxNzggNTAwIDE3OSAxODAgMzMzLjAwNzggMTgyIFsyMjIuMTY4XSA0MDQgWzYwNC4wMDM5 XV0KPj4KZW5kb2JqCjExIDAgb2JqCjw8L1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250Rmls ZTIgMTIgMCBSCi9Gb250TmFtZSAvQXJpYWwKL0ZsYWdzIDQKL0FzY2VudCA5MDUuMjczNAov RGVzY2VudCAtMjExLjkxNDEKL1N0ZW1WIDg3Ljg5MDYKL0NhcEhlaWdodCA1MDAKL0l0YWxp Y0FuZ2xlIDAKL0ZvbnRCQm94IFstNjY0LjU1MDggLTMyNC43MDcgMjAwMCAxMDA1Ljg1OTRd Cj4+CmVuZG9iagoxMiAwIG9iago8PC9MZW5ndGgxIDU4Njg4Ci9GaWx0ZXIgL0ZsYXRlRGVj b2RlCi9MZW5ndGggMzA1ODIKPj4gc3RyZWFtCnic7L0JfFPV9j+69nBO5uQkndK0TZOmSWnL UFqmQoUABQREZmiRShFQBJGhgKIIRRkLCE4IiExOgCChFCwFL4goiiJeURxAQEXFAUFFHEqT t/ZJUgre+/Pe//A+n/c+NHz32tM5e++111p7rXPSAgQADFAODHImTBo1oV/wwLcA+QUA+tDd w8eN2vfzqHYAh3IAkkzjht87wdDNuAGA2PEq113jRwynMw7uB+hxF4Cj8ehxk+81tyjyY3sb LDcaPXrUcFueLYR9LyLSsTjy3eW+RzG/B9Hqjrum3f6x/8uuACOXA4xadvuEO8a9M614JUDu OwDy3SOmTnYty3p/KkAhzkfOGTFu+IRv/GPa4lxKARLGgJg7A/j6bM13wywFv2qTtCB+1n+Z kSXorg+rLv25te4OBbRGLOqwP1E7YKppH7wZOivw59agT4FIff2PXCFq5ApMOsBU0AAFBZrB IABu0odwTCpHLqH59QjQj+BWXgZxiO6aFLhHGgRFZB4MoZtgugBLAT/fDJOw7yYsd0RaI67F /gMRpxAFiEEIR6SuF2I4or8oY99d4lq8xwRxH5WWwRBtKoyXBoXqcLxl0kG4HbEa8+v5l7BB zodxWH4Wr9vLAVqLPnjNMnkTLMf6Vdg+AutWIy3C8jrMD8XrciJ5nWYxJAqKkLE+E++zMLLe DPYqtOJloc9xLcV4zx6IuThGH6RdET2xTwzSToh55CDMJwdD67EdKTyE488T9YjCCL0R7zMH 2zvgdelYfgjzDpyHjNSCcCMa0c2QT2NhD9JmuP7B4XUjDsJoseb6NeH8I3P6K8Jz7NkQOOYr CA/ND32FVNdgbtfioWvQneVBOdKxiCREX3oYxvGbgCC/VkhfARNAyRR8Oom4gY+Em7FMcJ79 pSpYKcqIXirKQnV8FaxlF6ENtt0nL8N1jER+N0dcgmb0B2gie2Emylch3n8WYjXe86wqDyNh AI7fFGke/0qVobmIRTjW+SifBG+wPAv3tR+OdVloDF7fH9EN96UccZeYD47fTPBc7DsZFMzH vmewz1ABrE9QgWsXMimuEdfjvbwROVx/hcJ67LMY+XoaKUfEiTlEocpZBNj2Bt4nESEjUhBN EV8h1iPGItoiXkY0wrEBx2WqvKLMCNlU5QNlQzqIPMS5qTIbXsNqdT/DOrMuci8xjlveDGMj cIt7Cn0RMotz2Ra9t9ApITNRqsr3WCH35CexTiFT9RR1j38P3cQcVB1E2YpSoXc4Z6EPy+hA mI90JcrxQ0JmxfyiVPBFyJrKE9SJCC1osNYcVUeQovnzRGT9oSiN8qKejoZn8Z6l8m1oU9bC jXwy3Mgegdv4BShkmdBUysE6XA/2DdDvoZ92H+ThXvbG8opr6HIBzYdkjLQP1/ki8vNDeBp5 OpF/SNP4h0SSXgx9KwF5S3qRzlDzf6HXguwLtwkq0LDtv63/XwE9Jr2INvPF0HfSh6EQrudR oROa70kOwhWlWF+JKEdkabPJcu1YUq0ZCIqMZxtiPPdDW8kPrfk+3J84tPOoC1g/UPoc9rLF sIB/GPqElEM5/RDmauJgOF2GNg3HosfgIQFxf6QTGsjRVTJ3rSxFaVRer6XC5kdkKhWpjPr3 bgRnIriE+BXl6BkSHqO1sM/q+YA2GjE3LK+hP+vl8y14DunCqHxeI6djr5FP47VyeS1Vzxa0 71E9xXksiK5f2Edh44SNFHZO2Jlo/2tpg+sr6CaUY2GHD8OQiF6nRdAD5/hFRPfRDuN+Dw6F 5K6hF+Sq0AZmC22QczH/MUIKvYDrvrf+TC0KBSPnaWb0LA3XgyF6jkp5MC5iz55V7c3P8Lh6 jg5S56eTt8JMqRb3HW2gOt+1ER1EfuK8x/JS5PlKWITrSGTzUB+xHjFU8ETdCwC7OBfEmcie QD6Ls2gxPMSOo78grs0Dq3pedIDBOPe31Do8UwUVddJgWC9/D7l8INrafTBS7JVYh5iP2Hvt FDBp49BOfAjN+UbsEwd67LdW5YEfXlDlQlw7FkDwQjMCNCizN2Mfcb916jV+sEX48azKC/V6 9EWEfAle4D3lOOin+hPfwxppIAxGHVqnKYd18kDUuTjYgPd4Dq8bKOaC1znU8/oJuAX1az7a pvloc0CV/yGhWvYirudetOsIVo48ehHsUjnycKy69kIetrHzhP6wTeATMiI/gXZY+BNPQAXP hi7yWFiMdYsltJM47kKsm436m4O6uwCvT43YbcCxF2C9uLaD8GWEjyD0ReOHGLlc9QNAnYPw U3B89i2sYz1gPspxR+0TyIc50ATPC4Ky50Q0D0Mtz4hgURhqnRKmxM0UeECtz4P36SZmQLkV Z+guPgvu5IMglzWHRG6FJvyfqKt/wFPMAsP4IXiKV8MiUeYx0IgFcP1V6FuK+iPQR9TT97G8 HIbwArx+PtzNh0EZ24ay9wHo+e2413id9DDKSTpe/zPeNwLyJQxhg1C35mL+j9Bm0U8doyo0 WIDfCE3U6xpAnWsU18yZ9kS+9cA9xfmK/FXzxbnWzzM6x38xP3Wd4r54nejDnwKMF0InEN4w Dfali+FFxFr6KXRmvWAa2RCqIaugK/kKsSqCLXCjSrch+uIZ35JMRzTlLeFlxCzMN0b6D8TW cBl9t5ZwHDEH7/0q0u0iLhCgnaCVoFi3GrEc8Xa0rSHEWP+qviGkpFDNVeUdeNYgyEVcw8Wr 29QxZ6Ff3hJxQ6hGAGWxh4A8E2I1UyGWZWC9E6+7piwloT7tgPS/m8/fgRyBHJWHYfgbrjG6 H0jj/wOcaEBdgkbOhv+t+f2vAPd3JqJE5e+PEBeWITCTY6ETSAeRY6CwKSiDCCw3wXJMlJ/R fcL6x9T6a/YPZQVDytBv19ZfW752X/+uTLfDsIaIykG9PDwK7QV4B+yPuLasfQvaC8ivY9vr fy3zF/4GQyCLrRRzQhnM+GtZ7g0ZAjQd5+oQ16DOIerLR9BGIERf9XoTdBNQdRdBqzBeQ9S3 t4QuAg342krwla0Mt0f3J7ov1+4Pzs/P34XuSH1I85H2R9ojSuvlO2IvrpL5vmF5ry8LW/LV NX2u6MQV3Tgizpp/fc//PwF15xDiIOKN/9tjEUBZRSgI+QT6IR3Qj/wQ/ZNb4CGAOrQll5sh nkc7NADpR1iHp3cwE2HCvBXr7kD6NEDtr5ifhPUfhhGiPAnWRvzKRKzbGblWG7lf//D1tW8C /HkRsTV8fe0mxBjM/4R4APOfIX0V6XLs/x1eNxvp/nB73TAsT0XswfL3WL4LUYT5pUjjkDZG xCBseP0yAeGP/CUO/T9O/3X88Z9S9FlG4DxTxTMvpNOvjSH+Yxrdz7+h18Ya0f3/O9rgmcE1 NMwHjJm+QL8v0DD2+Z9inCjF/Qw2BB8YqkOf0ij8aOHLCv9Z9R8jVI3fVD8WxwWIjVLhOwv/ VfjOwn9Fuk59ZiCp8xko4nx1XpFzo6FtJRdhNUJBJEXoWOzzB80IvYtnkwVt6q/oaz4roJ5t 4lzbIJ56ho6o7cdCe0UfpIexnIL01+iZFrWtf7Gxf3Om/Z8u/7dn5P/CmZobwbBr8O/qo2gT QXeBa8/i/xZ/d3b/L5/l/+aMbnhO/++Wo+d8FH/nl/7FD/ib8t/d778tX+t3/Nfla/ySaPla /KX9WtmL+jMOcNTjGr37byFiC77jiu8fncO1elyvb9EYYSbGzg2AdqBR5Axdj/YiB5GCwDMq 9CjWzdBehlztFsjF8g4EnpvBc0hHijaka8hi8Xw7VIflB7Gs8MNq36IIRv6dPF8rt8I/V/1D 5JlqB5eK+UMzRDuEDbENMS661yKGxLE/oXjqijiXDwn9yt9FXOMD/i1tCRMRW7BswbIl/IZK RTKor4wMfixhztgVuCEdgCSL11HYOoPMJEvIo2QdCZATJESL6UH6Fv2MEcaYjnnYDFbBFrF1 7F1u5L35UD6MP8af5E/zZ/h2vpt/wr+VXpO+ky7KRjlJTpXbygPlc3LQOcf5h8viinM5XWku n6upK8eV52rrKnC1dxW6xrtmup51veDa7JbcMe54d5rb527qHuC+1f2Ee0MaTZPTLGm2tLg0 R1pqWmZadtqNacPTRnmoR/G4veClXqNX8cZ67d5kb7q3sbeFt8B7l7fcO9s737vI+5h3nXez t9Jb493jPeB923vE+4n3a1+Bz+/r5Cv1jfDd7ht7VjprP9v2Ar3QvJbWumpb1RbUtq/tWFtY u632m9rQ5dvqOtT9HLwcuhwSbxBdsFblzlqylRwmfyJ33kDufMygnjuzkTsPs2c44Wbel9/K l/JlfCVfz1/i1fxjflYKSO9JFyLccct+uVS+4Cx3rnUZXTGuBJcLuZOF3Ml15Ue4Mwa58wxy Z9NV3OnvvsW9tJ47VuROYpozwp3StJEqd1z/hjt96rmz1LvWu6meO4eQOx8jd9rWc2eUb8xZ onKHXOC1pDalNqu2DXLHX9u5tmvt0drLl2+ta4/cKRfcCX2JAvZEKJYeoq+wZqET9B2UZJQ8 5NY9ZCyZdHktlu8UshfMDmYFM4OoqTAd7oOpcBeMhpugPXqT711++/Lpy+9fPhJ9B/plCcAX J8L503MQT3x+y+nZp//4fMPpe7D0MgI90tMVpx/4fMqpMaemna75svHph09tOLXs5LKT608u BDj5vLj2VMLJiSfRpz2Zc9J/Mu9k+omuJ7qcKDiRf6LVibwTOScyT6SdSDoRe4Ic//H498fP Hv/q+BfiquNvHN97/B/HcZTjrx9/7vjW412Odzre8Xj68bTj7uNOxz7Hn47PlX8ASAjN05pV mqc0KzUrIm9vv5XbS4slYCOEnhHH1e926aEwrip/QP+MltmNV/dn/gb5oShh1fx9AP4Djr1K Wiu9hDTQsL+0GVEVxr/7kVYLSGsjpVX/vudfrpwsTa3PT/ofexZdPTNps/ygvOmqLgyegdkw h90Ky+BrmAsPw0J4GjbCs6CAePf9EDwGF+AnWAxPwnzYDyfgPKyGTfAL/AwXYT1shjfhDdgC t8EIWAoj4RCMgoPwFrwLb8M7cBi+gdvhn3AE3oOX4A74ER6BD+B9OIoy9y18DwtgDNwJY2Ec SuHdsBbGw0SYAJOgDKbAZJTNe+As3ItSOg3uhwdQXl+GdTATZkA5zILv4AfYRZaRJwkljHAi QS1cJsvJCrKSPAV1ECQy0RAMAskq8jRZTdag3VhHdERPDMRI1pNn4BL8Rp4lz5HnyQtkA9lI NpEXyWayhbyE9iVAtpFKsh1+hw9JBVlIqsgOspO8TKqJiZjJLlJDLEQhVmKD0/A5iSGxZDfZ Q+JIPFlEXiH/IHvJPvIq2U8SiB22QoAkEgd5jRwgSWjrU4iTvE7egD/gT/gCviSpxEXcJI0c JG+St8gh8jZ5B+3bu8RD0omX+MgR8h75J3mfHCUfYOSUQRqRTJIFZ+Ar8iEcg1PwCXwKx+Ek fASfkfPkAvkJz46fyS/kIrlEfiO/kz/InySb1JLLpI4ESWM8V4ASSimjnEpUphqqpTqqJ02o gRqpiZqphSrUSm00hsaSpjSOxpNmJIcmUDtNpA6aRJNpCnXSVOqii6ibppHmJJd6SB5Np17q oxm0Ec2kWTSbzqcLJEWy0sX0YbqELqWP0EfpY/Rx+gRdhp8n6XK6gq6kT9FV9Gm6mq6h59ks 9hCbw+axBWwxW8IeY0+wFexpPPGeYxvZi2wL28q2sR1sF3uFvcpeZ2+xw/QC+yf7kH3CPmOf s6/Yt+wcO89+oj/Rn+kv9CL9lV6iv9HfpTZSvtSW/kH/pLX0Mq2jQRrCc4MwimcHpz8wSWok NZbaSQVSe8mPfTtJhVJX6Uaph3Sz1E8aJA1hqdKt0m3S7dIY6W5pkjSVZUj3STOkculBabY0 V5ovVUiLpIelpdKj0uPSMmm5tFJaxbKFhkvPShukzXj2VEk7pRppt7QXT+mD0tvSEemfrIl0 VPpIOi6dkr5kzaVvpO+l89Iv0m9SrRSSmayRDbJFtsoxcgL7Xk6UU/DccuHJlSanyz65kZwl N5abyjmspZwrt5Db4InfHk+1TnIh08pd5K5yN/lGubvcQ+4p3yT3km+We8t95L5yP7m/PAB9 g0HyYLlILpaHYMstUd4wPTMwY5g38lA8IUfKo+U7+bP8Of48f4Fv4Bv5Jv4i38y34Km6lQf4 Nl6J3kcV38F38pfxnN3Fa9AX2cNf4f/ge/k+/irfz1/jB/jr/A1+kL/J3+KH+Nv8HX6Yv8uP 8Pf4P/n7/Cj/gH/Ij/GP8JT+hH/Kj/MT/DN+kp/ip/nn/Av+JT/Dv+Jf82/4Wf4t/45/z3/g 5/iP/Dy/wH/iP/Nf+EX+K/mSnOGX+G/8d/4H/5PXwjaopBWkBeyAnfAa+Qq2QxUcgAfhVZjH bma9WT/Wh/VlA9kgNpgVsf5sAPxKvqH7+AzYAyvgHFq75+BR0gGWkI5kKnkEz9LHyD1QTaaT c+RHPpFP4rN4GStmQ9gteCqU8Nl8Cr+Hz+FT+Vw+jc/j8/kCXsEX8kX8Xv44X8wf5kvQI3lE 9Ume4qvQb1uN3ttyvoI/wNfwtXwdeirPyJPlKfI96NmcpKfoafo5/YJ+Sc/Qr+jX9BuUzhtQ GvtLA6SBLJW5mJuloUyOkEZKo1BOe0t9pL4opcOkUmk4Sm5P6SapF8raAel16Q2Ut3ekw9K7 KLtleIJMQSkeL02QJrIM1ohlsiyU5vul6dIDKMkLUJ7noTwvRPmeybJZY5TqR1gT1pQ1Yzms OctleawFSulF6VfpEkrsD9I56UeUUwUl1SbGRDl1ymNQVsfKd7Hv2XeIH1AuO6JkdkZJPy19 Ln2B0puJMpyBMpwtdZVz5OYo016U5yYoxe3kAvkG1pK1Yr+wi+JrMle+nkUoJvSagw4bGZdk jVanNxhNZotitcXExsUn2BMdSckpzlSXO82T7vVlNMrMym7cpGmznOa5eS1atmrdJr9tu4Ib 2nfwd+zUubBL1243du/R86ZeN/fu07df/wEDBw0uKh5yy9CSW4eVDofbRowcdfsdo+8cM/au cXePnzBxUtnkKVPvuXfaffdPf2DGzPJZDz40e87cefMXVCxctPjhJUsfefSxx59Y9uTyFSuf WvX06jVr161/5tnnnn9hw8ZNL7LNW17aGthWub1qx86Xq3fV7N7zyj/27nt1/2sHXn/j4Jtv HXr7ncPvHnkP/vn+0Q8+PPbRx598evzEZydPXY8UrkcK1yOF65HC9UjheqRwPVK4HilcjxSu RwrXI4VrIwV/54EDOvo7tL+hoF3b/DatW7bIy22e06xpk8bZWZmNMnzedE+a25XqTElOciTa E+LjYmNsVsViNhkNep1WI0ucUQKNu3i6lroCvtIA93luvLGJKHuGY8XwBhWlARdWdb26T8BV qnZzXd3Tjz1vv6anP9zTX9+TKK4CKGjS2NXF4wocLvS4qsmQvkWYX1zoKXYFzqn5Xmp+qZo3 Yd7txgtcXeyjC10BUurqEug6dXRFl9JCvN02g76zp/MofZPGsE1vwKwBc4EEz4RtJKE9UTM0 oUvbbRS0JpxUwOEp7BJI9BSKGQSYt8vwkYE+fYu6FCa53cVNGgdI5xGe2wLg6RSwZKtdoLM6 TEDuHNCow7juFKuBha5tjfdVLKpW4LbSbONIz8jhQ4sCbHixGMOajeMWBhLuO2O/UsSb2zoX zWvYmsQqutjvdIliRcU8V2Bt36KGrW6RFhfjPfBa6u1aWtEVh16ETOzZ34Wj0TnFRQEyB4d0 iZWIVYXXN8rTRdSUjnEFdJ5OntEVY0pxaxwVAeg3zV3pcPh3hU6Do4urYkCRxx3okOQpHl6Y vC0WKvpN257odyVe3dKk8TbFGmbsNrMlkjGaGmZG1bepObW7yPXsV89ZImbk6Y4CEXCNcOFM ijy4pjYiGdUGKka0wW74U0zwqsBI3JE7A7rOpRVKW1Evrg9IXowiKn5F36HUc+6Hq2uGR2pk r/IriKyQk3pRw/ZoPpCdHcjKEiKi6Yx7inNsr5ZbNmk8tZp6PBMUFxJkH/RB3g4vbtsM2e92 iw1eWO2H27AQKO9bFC674LakSvA3yy4O0FLRsi/aEjdQtJRHW+ovL/WgJFepUX5cQOur/2dR 4mO6jG4bIPH/Q/OocHvP/p6efYcUubpUlEZ423PAVaVwe5v6tkguENO5iCXRSI4mMbUVhXJo fWdRKDIGuBf/yapQj6zWaFEq1Rri6hpQSm8Mp8V6t/s/vKg6dEFcpZIrl0WmGWibfXW53VXl q6ZnrGA4Ye6jPQcMqajQX9WGohYesHuEoMTDgCK3q3MABqJmevFfdWhfG4HipIAfWdZZdED5 C1dFild1TIrki/FHSGeTxl3R0FVUdPW4ulaUVgyvDpXf5nEpnopddD/dXzGhS2lUcKpDNQuT Al0XFSOvRpO2qBQUOm3zkPl9t/nJ/P5DinYpGL/PH1BUiZ5n59JOxdvSsa1olwuNu1pLRa2o FAWXKEBPgousRN9U9E/a5QcoV1u5WqGWR1QTUOu00ToCI6ppuE6J1lGs4+E6v1onfoSN6Tyg qKH0qCpZ3ARg2wBLxzSWAOcRIQSDVEybIXojhiGWINYgZLBEasYjZiL2Ii6oLX6WUPlonr8a yUKVbB9zV65aHB4uDi1Ri9sHF4dpr75hWtg93K1tuFvzFuHqpp3CNKNxmNq8ueWC6k25+zrG s3h4D0FhAqaEHgALIZAKa1kcBBCUyZEaP7NtT/flrtnLOAj/l2DUlhrax0ilyZrbUU9D9DzY IJX+SM+FW+i57WZr7pqOPegXsBWxF8HQLfkCnZPPYSY9jUxXMO2AWIPYiziCOI+Q0YU5jY7M KXRnToKFfgbNEB0QwxBrEHsR5xEa+hmmCj0hzIGainwHBKUnMFXocVzWcUwt9FPMfUo/xakd rWydn7tLzWQ3i2RSvZFMQlIkY4vPrabvV/6RmVpNv9zuyk5d2zGHfgABBBWRP978A3Ah+iBK ERMQMuaOYe4YlCOWItYiAggZrzmG1xzDaw4h3kEcgxyEH9EHoaXvVeIw1fRIpa9Tasd4+i49 CAnI1MP0TZW+Q99Q6dv0dZW+hdSJ9BB9o9KZCh0N2A54jYJUQdoM2yX66vZ0W2qoo5XuRfak YtoM0QHRGzEMsQQh0700rXJkqg1vshsOaQF7VsK3Kn0e1mvBPybV7+uMMuYSia/tDZjDZI1r jY/6fctWYFEkvocfxZxIfLMXYU4kvvtmYU4kvrumYk4kvpFjMCcS35BhmBOJr/cAzGFSTVe/ nJ6R2rr3WOLqaKH3IJfuQS7dg1y6Bzi9R3zgDy7m9lRlVhZybKU/OzMrtbyGlO8h5f1I+XpS PoqUzyDls0h5ASm/lZRnk/JkUu4k5X5Svpu0QVaUE3/VVcV8v52UHyLlW0h5GSn3kXIvKU8n 5S7S2l9N3ZXd81TSRSXbOwq9QnpD+1wLztGNHHWjWLtR7fdiegQRUkt+7ORKC3dOdAqatj2r Q7jctG3u+I430tfwwtdwG16DUwiOG/QaitFreJPX8AYWTDsghiH2Ic4jQggZe6fhxJeoqQXT ZogOiGGImYjzCFmdznkEhfGRKW5VJ9YsMuneokRfw08aftzU7U9RkpVs5Ua2JJlYnKS3M+Sk rSE+Hg9cm1VrrSamnb+Zfv/NBLqOOhGiQwpuxNIIXVL5R0pqNVle6dud2jGOPAlOjlJH8sFH vEjbQJlabgnJWkFbQDJ9EWluZfIgvMxS6WucWkPM4qqdqX8kn0n9NrmaYvZs8u7Uj1zVnFSm fog1L+5M/SB5Qepbzaq1WLPHV02Q1LjUrruS26RuOaR2nYUNKytTZwiyM/WB5G6pY5PVhlHh hlvLsOS3pPbzDUm9Ee9XmHxbqr8M77kztUPyrakF4V4txTU7U3NwCtnhbBZONjNZHdTjVG84 sHU1Ge1vrFmmKdL01rTS5Goaa9yaVE2KJkkTq7VpFa1Za9TqtVqtrOVaqgVtbHXotD9bvK+I ldVfORdfLCXA1bxCRSpebQi7RrQUekAghvWkPft3Ij0D+0ZAz9tcgUv9PdVEj+e/5OlEArae 0HNAp0Cb7J7VmlC/QOvsngFNn1uKthHycDHWBuh8PPcGFFWTkKiakyQ87V1AiHXO4iRBG81Z XFwM9vipHewdbO2t+V0L/0VSGkmzr/zYr8qnBJb17F8U2JRSHMgVmVBKcc/AY8IV30V+Jhe6 FO4iPwlSXLSLtSc/d+kn6ln7wuLintVkkNoPXOQn7IcS85PaT+sEl+gHLq0z3G9luJ8Xr8d+ 6YJgP50OvGo/r06n9uNE9NtWlt6lcFt6utonwQVlap+yBFfDPoe82MfrVfvEl8Mhtc+h+HLR J9Be7ZKcjF2cyWoX4oBktUsycahdBl3p0izSZUF9lwXqSIxc6ZMc7mM6He1jOo19sv/Tn1Gd srPJ9nbFI4aKMKbU02UUojSwcOpoe6D8Npdr24jiSHzjK71txGhBh48KFHtGFQZGeApd29oN /RfNQ0VzO0/hNhjaZUDRtqH+UYWV7fztuniGFxZv79anReurxlpQP1aLPv/iZn3EzVqIsbq1 /hfNrUVzNzFWazFWazFWN383dSxQZbxP0TYtdCpGr1ml26lBj/JamuQu7hSvTGivCm87t31G Ug06JBvAgEGEEQNSE0I0NenYpKNoQp0STWYRq0aa7DPauZNqyIZIk4LVVk8nyJ48pWwK2Lvc WRj+V4Y/WDV5imB4OM0u+3c/2NYFw87CsskAPQNZ/XsGOqB/uE2jwdpSsaRA22idwdAFveVw ZVOsbCsqGavvKOoKRJ1OF+n41/2fEqGdhRaU093bid9JJkNZMQs4ew6gaAoGRIKCGnSXxPFQ VowLLCPZpCx6D3XaEM6DWG8Uk6dEchE+TI7Q8FV4SVmUHfU/gksg1UAiwiG9AIncB3aA0DeI s4IG7wydFe2C0u/QrFVHALABtpA7YQvshf3kAojn3rugCoTDUwirYDo8DvPwEBuCNQugH34k rH+cJIaqoBmsw2NsHRzGvoNhBtRAPLGHvoWZMIcdxavmgAnSoCP0gfGwmNwUmgJD4RR/CFrD TXA3TCDloaLQw6FHQ8/Cc7CLvRmqAwM4YAR+Dod+lD4OnYAmeMUTsAJOkUd1O8CPo5Rjz6dh EqxkJZyE7gj9iTNwwz04Bw694DDZR7Px7qPgG2In01lnvMszoUDoAPZKhhIYDSuhhrQk3ahb GhrqFToM8TjGvXjXFVAJO/FTDa/Ap8QoXQg9G7oAidAYuuN6quBdso8F62YFO4gXMsilTMjH lvHwDzgI7xEPeZWOl4xSruSX7gt9ALHQHAbibF/AK78mv9EZ+JnJ3uBdQ53AjHx5RHAbXofP iYM0I73JIJpJx9PVbBJoccTm+BkJdyK/l+PdT6LQ7KRGeoQ9w1/ktXJK8HTIjDvig6fgaXiV mHClLlJGHiTHyJe0Mx1Gn6JfsMf5Rv6+Zjiu+lYYB4vhRfiN2Egb0pfcQkaT6WQeeYSsIIfJ e+Qs7UgH0LH0PBvNJrJXeCf89Odl/CFprrRQPhssCh4I/jP4Wyg3NBf6ojzMwtk/AatxZbvg CHyCn1PwBZGIgZjxI96JDCT342cGWUzWq29oqnCU98gX5Fs8gH4ltRTPVSrTJPEOAj8eOgn9 ycfpKnoEP+/RH+gfLIGlsWzWkhWwYjYeZzWPLcXPDvY5d/AjPIR8zpWWSWukDdKL0n7xbljz IJ7o71x+pi6r7mQQgvODy4KVwarQ5xCHe4hnBUZQBTj74fgZg/u9DCVuKxwlRuSdg2SR9uQm 5MwwMoZMJPciJ2eTleQ5de4vkT3IpY/IeZyziSarc25KW9JOtDd+bqWj6ER0vR6lVfQY/ZNp mIFZWBzLYt1YCRvFJrNpbBkLsHfYZ+wLdoldxk+I63kqT+M+ns278WF8Cl/Nv+HfSEOlt6Wv ZL08Tp4rV8s/oQ/TXtNH01dTolmi2an5QFsqnofDDni54YtAcprNYl3YDniY5vFEDFjeRXke BiNZL4qSSjeQ+fQBUkXTpXvldrQduRkucB/y+g26hl6i7Vgv0pP0hzHir5mIHzmWi/eMBfw1 OMf34NrexTvfKxvJDHpeNkIlUf+2Dnmd5fBs9jZ8yk4RDV8Hx7meJJBz9AXWB6XgFd5eKgI3 WwUvsYnkAdhBuwDoa7WLUI5vJpvQLgwgueR3FkKn92aUotbsS3gIxtKP4Rzq8Xx4kozkd8DD kEemwzfwPGpFpnS3nCXHkbfonbyCxpAqoHyj+Js3JJ0wKRZmkxK2Uj5PP4EpcITr4STbjLM/ Ql9ivfgFqR8ZjRrwAMyFiaFZME0q4u+TO4CRQeDlp9G6TWe53I10JlqVoWjTdqJ216Ad6Mh6 YY0dJecmlIuBaCFW4mc52gmOEnQn6vhgtGLvQpU8gFbDHZKZoNUB4G8H+8GQ0POwInQH3B16 FJqgPZgXmo533ABfwRLYQOYE74cJGDh+grp9k9SVHpG6hprQCvoJ7U+XXb2/yG0vscN3+HkJ C+2l3VDBP4L+0CG0KPQhSncjtLAr4DZ0T8/gKn/EEW5k+yAveDPdFurKJuB6T0Hf0AuhVKKH 0aG7oDfsgec0EgzXZEcGyPovgNJB+jTAm7gLZkQPRA2ufSoax34AmukAukG46zsBjBMAzF0R P4dh9SEe/PeIaQwQewAgLgiQgNfZ9Yh9AA4cLwnvmdwWICUNQ88ixBcAHiNAOo7jxVPNdyGM zKEAjTHeb1x1BU1/DiNn+f+MvDEALW8EaHUZoE0AoO3dAO32A9xQCdABx/fjWjveBtD5T4DC SwDdcD03/gDQA/fnpkmg/imh3siTfjin/p8CDLwXYPAyQNECuDUdoBR5c9vI6/i/gREPA4ys CWPUrddxHdfx/zqWXcd1XMd1XMd1XMd1XMd1XMd1XMd1XMd1XMd1XMf/x0CJ+uJbEr97qAFw W91WLyYEOFx2sX2X/eIX+Vx8n/jC1PRgX1oqHQUFbvDrMywEFJtGqyjVJG87rDFrkfqtmjXm W4EpzMUY22x9epE9W7lUUnfpnHLpHHQo6FDQPIeUEB+1tmjdqnWerMFPnELIqSfe7TVkz6xp GTd4skl2sO8e8jsx//hpXe17xRXLdr8STA26rhp/lN/YiDZSqE6vELDpxAz0axhBWgVr2K3m 6tCFKkWhAzHze5XFombOVJlMauYHv0WvpwMt5lQzNW+2ReYovm5xzTxjPGBtkeHDT158Qnyc QutmkezstBsy7pu1Z0ivI8G+5DT5fM+uZRVD3q+t+/TH4M9BLc5yU/AkeQgOgx5u3qFHpr4o V5M+fh9hBZQSPSkAPWVYALmNpm1vGAbjYSasxQ1Ya1i3HGdyseTiGeVcgVIAHUSqnFPqzhGr Lb95Tl7LvLhYWZPRqlXrnYf7DM7Nb8UOH5640NcrcfgtOG5HUk3H0HG4j439iRPoBEZ7kV44 pAeoQ5qAHRL5hMX27JuVMyXK19Cs17nmOTARF9nSHdeRZpLqHTvEHtdgMg9nz8Drt1Mx2YLw FLcCX4vta7k6y0slJcinc+FJ1Rw+fFj9Ql3oG5qP+8Og/y5goZOVsfm0OnTS74rNf5IRytaw rYyyqUBixZ8YINhPz84CPYv7thEH59vvwzsXKBfPKeE9mCc1zS55QDkg9iI7O47kEbJxabAo Ufrhz1jx9wkGhr7hVmkfykMKGbiNii+Q+/UOJ5dinSZTgq46dFbde5HxJ4rN11nBKGog3mjE 1CjqoBlu/GFMDuN6xIqStsl/vdNFvJMs7vQ1SpGa+dGfaDDI4paKqAHFaBSpqKu/5ZV7Vsmu RCUZxbKSugz/CJ2GeIQNYQmd9t/G5Xl0vmG+5S2zpNMY7LRLzE1xPRI7Jw2IGRo3NLFf0ljN WMOImLvixiaWJk2j98hTDfdZ5snLNcuUt+yf0mPyMcNxi6N+umU6v9vTIkdHQKfoqG5pqrUM qkP7/GasdYH4Av5S58GFYaFHeS+ZmH0uMk1SMhFKoI34IYji4hjF1iovNz7ehsIve9IyfDFK fF5uK6vi86Rp5IFjj66dWjm505ij6z6Y9siujdOnb9w4Y3qPEnqUcHLD5mHbg6FPg8Hga1uW v0yeDj55/gIZTcb8eOdcISuncANrce/0sNXvYn6TtcVYPpMuoSu0fDMnOpAlynQSMVJySK/O Xi/WBETYgerQaVW7MfOd36puaLK6oWZ1Q5HL/kSxXdE9UffHYZT8JksLKcqJHIm4JL9EpURD DSkgcyCsGhOzkS+Rb19hoaBXHSpih4R8Ys0X/IGSbLfHKsualqiFebS2quPRAU9+0Wwyv7/9 9NSXuh0aJtZWgLKswbU5ycGILOmsiskeEyMPNAlRslrVzI9+naJgzhkrOYWIJogOTqdodSab scVpFDN3VtPdfiPVJyS4UhUrpa5UtAbNPjgs0sPQ7JyYaQeRHsgVwkvrBzTabFQd0K+zWGl0 nNN+gy2GDnTGijpx70q8tVAVg4EOTBDWUeXivxpNyLMYT4ymDuZv1U5qJ++W9sq7NQe1byVr uhuLjQPMY40jzffZ7otZYNtj+8rxVdIFh3Gv4eUYmqQkKymKU5H/EboAGhR+LVId7pbDqVe0 snwo2RGbnOzQJjvQWmgdyczkVKrps9t7W4m1mth3iBWAyg4LoUZ9WcJR5LaQdbKbzgIXKKSN 32jd0YEOo+PpTMppDU2HVLJkW1jY0a5cyhbmBY1LXUGHc3UlZ6w2sbOYzDM3zTajqQlbWohq QBsoISWTiou9cW5fa9zxVq1atkDRV40w6gWaYzzAZA3XXG5NE7zPrDy/YcX9D64iu2J+/+fR Sze+sH/9UOeWLR0LRuybceCr28c+tqoi5sgn320p2rTn2fnDm6OkDAp9zeNRUrJJcWTjDIl2 v+C/PRmIENVsIxZIpkdvshgtTr0+M86ZzJ2ZyVKmyWMy2hPx+HMpQvhdGp/YRdHd10xYn8PN xAds+R064CFyDvfv3BvKG7Z85UB2roDYv0aSKd7UxTTXxLtYB1unJrF+8XcpY2JHxk8xTYud a6qIXZD0nEkvuZgqN+LPvnANwXGJ2Bbx6z27ifjKnIm0rDIa47i9hj4LiXS0PwNnKeE0Tbay Ya7xLuqyC0l2lWvKfKpt8hHwKT6KM774smjxLW1iryZtKhOPkhrxn5rhwg1XrFXjavLotqjB UndR2KyL2SVhu1V3RggnnpNiP8PbiaqKG4jaSiYWx7SOFzZL3ThN6/psdA/FJmpECp4036Cq 1CfGzty6/oG8m2JthrLquWPuXBRb5f7upXsPjb195INLg2ePvRoiD9lXzAs8OH1d7Gp67wMj Hpw927Xj4B2VI4etaup85eF9wV+/xkk70AYoUg3aNxPx+VvZioyjjSuNG41vGaWb2E2mxzmz oYyDUWYaSW9gGjCish9iPJYxzkxAjSauYbvpbtCii7bWrxf/fYjRCIf0vJre/rIk6f0pqS30 UUuoDx9MauZH9YTSV5PWfpPGn+ZpoSl3t9QstVAhTgZTbAugCnVRRsXF4hrMnNkprqE7zNVk kcrpH9D6qYbwojAvBcrXimoHlYsFlwqs+YLJ+fnzmmZzVBmLxYLsVr8xa8Iz35aPJucDvyEv n6U1yWc8JaVA3KIYNwP7+GONfkO+sbxPvtHvyzemJSNtkq9a22J0O1uSPGtenMfKrIQuq5tN n37sjTeqgi3JsOfYzss9nguuQ6V+om4sCp44+93S82hjB4U1ZxcQXJ9JLIgkm/XOuLhkmzAV BgvnzmSTmYDGjueF6hGoGVXLhE0TWiLkCIWo7gBqhlCMTJtqey1q2tMxLaUiZVnMCzGvGY8Z jydpdTF2c5aD6XKkHEMN2jGG2qHE6ONsMTGHzJZYc0ys2WJCFfHHiIn4zWvR0TRb/HEkMqmX LZwcFeqDVs3vEtOzDlPGKzOVJQpXUEnsqpLYCdgVO7VHlcS+1GXbQ1qChTyBQtWm0rzjXylL 6tXKckVdSoRHiTqiLrTEikCzcGaetmm2hLsIquFTbR6ZiN7WVWqDuhLjjnMz1BeIi9WgJ+Ab +ErcirserNqyaPCiRhsfpp/Uvdx79iP7iHby4otv1pFypWLhgfUrK3t3iKc/bQ5OHRq89M+D j1SeFl5bL9y5OLR5KZBFekesXqqFpJJhhJGkRk6/iZhMeFQlSWnOWJPeScCriENM9eAUZ4Ii djBBtXkJqgeXEHG3Dn9wWHk9upMl55QDJWInm4xNJIUaf1xhYqFriG2AaywbqRmpHWMb6Zqs nZI8Rzs3+Zj2g3irxiVYnBHWCXmgRzV4IudWGzSiIcPlcblFg1XMso+J4jyTyNFhYiPR6Omi c0Z/to3fBju8ZYq6kRijKKiluIoLLwuPRFnaWC92zkny/fEdEoYljE+YmcAT4kVbQrwYLqGa pm/PDjtpqInn6jcxYvFUS4drjOyYUB9h7YqJBqMV4ZrJGmHcbOKA8qSBVWktTB2JbbClrHa7 vXH3sYM6DryNdtxzR1XdPe/N/jx45ukFZ7d8Vte698M3T3p2/f33beL9zWNyeuW0//HEiNLg b+9XnJtBepLpZOOrG/Zf/qxkU3H16uVbtyIDhqO9i5deABNM8JsPmAjHf1TLdWjLhBbmUMJ1 RlMZY1SwpLd6RDPqsGjLdN9Db9z7YZR1QDKezETnMdEckeKbMR6aWNDr4rmblUvCGxORgTi9 86354aMahVVEMDIwWeNpZbO1Hs52LAqe69nKsos9+MsC/ueWRU8EbcHa6uNbyHfk4Kpo3JAo /DOUwJfCHtrLhlRUN68Vle2S6uoLrVMlwS7cyUZia+xW1RpYVa/Sarc2zjY0cooosreZmc2x 0IcQ9cg2KejBEaHVacJhERt2ILskV92wXNVyosAKmVWExH72er3X1mASV+yUP0s1VFajEPh/ M+rVY10zVLOGA/lbtHXcFO/33BI/2HM7uyt+nOMOz32OB5yLHAudK+M3OvY4vov/2nXJFXND /Or4LfGsbeZImWYIG+dBube7XbKrkbO3eZgwaMliSHK0T1j8q8QkUmtIPhhQ+q1Xm7CljYVO VAmVsNaHIla/lVqXZh9seLILIT/X0E5FRRxKMFYtjlil9rRliwwh2UgBBdtmVcMTH1ElOy5W SPmELfHTh/d/oE8r0mr3uJ2XieaNJefuv++n9Zs/pW8/N/neyo3TH1hH+iv33X3TzI8nGO2D xhLtx6eIsjL4Jcbx3wS3v7SXtXhq54FVi1C8UWZ2oas5l/vUpyRt0GZLIGt0VC7grIDIHKNk PEOAiuhknTYSx08Usoqel7oP+K95TgwGywyxCwNmVnz48OUXMHCm4q9xS8XoK2jATO7YScwW RT2Uf66KZH5XBZEKI1gsZE9nFKmkps2UHOUO7WhdqTKfLVXekt6Q9ykXFINWKiaDaB9ltCGg /GL8xfSLWceN3MTNzKDXSZyjJ6eVNRoj5rWyUYOxOw7jt6hRlEtjjMUmypioixN1zMWNsXiV zilJWqfM5Go6wa8DrfFbv/jbRTXEAIQY/DajC0ZpWL8+/Ag/xdlSTng1IX5DH+M+zSkjW2ok RlFWLJojGjpTU66hmscsxz4KcysRgf/syDFHooJSYO9Q4DjX4UyBeBpyTjwLyMZzal5Tu0pV pqInMk85cMB84MA8KUxRWnoGDP17Bpx9hxRVcQvTamowyIDQ70KIismkiSXh2M5D8oiHuVmM m/kyZA2jef+kRZ+9WPfUuk/ITyu6piXnSTV/diV7goV0CFm2657FC8UTsmVo5b7FnbKqp1fM LuC4J91EzM95V88gz+2eMt1snXynY4o0QVdmeEh6yCBnxOuYPSPLGZ+i08XYnFlZmZmQnOJE vqVisAdau082Ch9ORh/OnyfUXrYJlZdlwXlZK+4uq3stxwo5kAd4fcZkcYVRL/oZhVzEiV5G R+MUp0sNkV2R+PiSakfUTCQ2/rNK3eRwRg5Hy3o1Qi7JbjfUXh/9lqCVvVkt9Dp3MRIQRyIn BKpmAbqE+c2s+cLnDrvcIjrOs7ob+NRm6iHu3HDY5POgg5fbWuiuyC+jvg1vl91+x5wlg8tf XRR8jNwwq02Pnl0fXB08Tsbd6us8pO2AJxYFt0g1xbtG3fp8Xsae8ju2lTZn/azxt/fqPj6z dq3G2GZs137TmouI+/bQN9JU6SjuytEdI+iYFErCEa26vrP+YSLnglzTCJgAk1PKYXbKUlgp vcieM+1iVaaDpvfgTMovKVazLcWaksKy5EbWrGRXajfToNjBcYMSR0tjU+63LbStZCvMK5M3 kGfpBuuH5hiIBYcSqzi4eMhV2ShfNf5NGuUrFiA8KcZpZElOrlN8lh7gc6GVdqQm+FxaojWK 2WgTnSOGqudbdkkvcbphGjndrSozcQfE0xg82CeRBJl70tKRcbb0vFyeoPEJM0fjYm3C0PGq /TcEX/vqXPCjp7aSzvtPkMbt9ubtf2zjl0PHfT33mS8obX6+9lVy9/tfkYHbTr/dZO2j64Pn H9kd/LZij7Brq9H2DEGJtiDvvvI3c6WSztqwdFoVpwW0OGUdSVVDUp0qVDq9+kzNrtaooqea JEdqivIfi95vUdH7PSp6zmtFL5IvuSJyzXM6T/O3YkkarayVtFzL5US7w05lgx71QM/kuPjY +Jh4JiexBDexmTGxa5PdJF5vdQNyMTs7C39mkRIhoQnxCfHoHFGUT687NxLXo+fkXk3+eHHI jOLJZTff98jhOcFtJP+R55p36fXkXTdvCb4j1cSl3HRb8MiBF4LBjcNzt7Rq3uXb57/+LcuJ q16PlkH8Jp4BnvDHyZJTq9VogHHBSL3OaQCtRkhHimJroRnAerj0LhPVO0xc97+hrsZ2t4QF KMK0XqrClvS6eCb7Wj1tnoOrjnNHsJ6nX17Nsi9/yGZLNVuCHTYHTVuEFm3ANczBNehgsT9b XcMSDalfBi5hFUbyBkodhv9g3n5D+BlrRAmDf5m+vt3QBtNvMP8zYRdPnP7Xzn0D++zyVzRQ 10fMu+2WuttxDuNQ93eh7ntJjN+RFJsUR0szyK3aGGJj6engtiVQLzipqpwuMQdC5ASnmbmd so4QX4Y33cUYriujVA2Jz6grUU/fSGz8qboD6umbJK6nk8ozSEaKz6UnetUV1Cf6RtxSr8q9 lJJLkfXg5IWbHg1JsgvUcvgZRb5wXlGgC7knKdmRnJjMZKNP8cb5Un1aL/d5vHZTihviLTFu 7Bwb49JgKU3yukmyASU71oqJU+d2QzrDRP1tU5RwpUApqP/dUSHrUEJaeq1XWY/4BE1TiuZD vHmJtXE0IK2t7CY6bknwvbUfB9dUbSd9jq8h5FHfVvdtO8fP2X+Pu808Qh+ZcaE97bCZ1J2e VLaL3PrxMVJWdUf14zkTynv1nd17/poDwd/Lh7cmVtyPZ9GipKma8LF4IrDP74iJa8GZU6df q39PT/USpQYtarBLo5HF0wr1xEN+i3ALc2pgJ4soy66efEQ9+UrKMSqkBlfk+e8+vx5v+h+I nzYifg0sTnxEe1wm4sIgrtQ0wcTbFdsxvqp/8Bu2QOF9zC5QH32gNuWXNFPNEMFDDkUS4cH0 2f30z/3762Sppu55OuTPrnR7XS+c415UqFnIBQbv7BC6Q8WD5+1tblAfQG/PaxGmTXLCtFFm mHq8YZriDFO7I/zAOsuktHBJS6WtEsoqOmtLYC0EgDfDkL8PnIILINlcWLkUmBR+yiO4YI9w 54cod36McueSXwl7eip31vNjxQ2Mb+ehRZXl6M6VFE+cVFBXEmWJePwjVDHPune/cI1wja1D 37Dhqje00a+MonfIk+kUeb5pvlXWqfpWZRDqVk0cfgN3WnQ6n16v9RlEcCNmZog+hDGErYOa CR/aosavhsOGElcMccX4Y/rElMbwGOID9SFn2CR+F93UExGb0tO2M7qSc0rJxPCKhPeIKngu G6cPJZHHGq1a4kLU4NjXbqtmwojuYxrtL371wVcPk7X2DdM7l81gP19OrD405qSwi8vEb78J iSZBv5Oltc7X6tpm6FvKrfTd9IPZXPYR00zVf8I+wUNIWAn1aGwkLeIV0ib+nVbSc9KSH+NU J4RaZ3O3YC6RoNOw3ZhvE7XbsayNUC5oikr3bbfFi/qT/hsScUyv9watLjHxBlRdnV6n1UuM c5ekj5UkLKE6yei1y3o9SJQTqjFoQatn1ECAV9O2fkuORNZKAWmfdFriUg+tqDPkaIgLvfCA hmmq6Vy/0eD6bw+jn68cRhuEGx+RIYzfJp4TEZCwSAVCfQoKBNAKCkdePGlHalefH2q0SoG2 AN12O7rtSei2C6/64zbF4cBcFC5sN1oFvy74EzAjK2ZrC61iVlroRE6voG5Eft2+WPWbor/B 77fq0pBvjRPzuUBaUj4qx8md8ZiNz5cFWw22fG1abD73x+YLNu/wYjYuv8Hv3xeLG5OJk0qy QQQOQvqJm+A/jXXZfvox0dStoA+GoO7SBVT/TPpR3UuXl9OvvwvysNTwLJQaCcb5jYSiBZRA 6xIhEX3Bb9FQ9h8f/Zf+4i7Jf3GXvi4Jn/lhFXXH4fTeRzX9ZQsOsRxAtuBMFHom+qxUizZA tZBas8mqnm5oHDAjiddSjUTOaBPNksXIdECoVmcwg1ZH9QZZ1V0lorh/7lQVVwHxADqykt+j K7lcddULVvE2tMO+fcp77+0Tz+izs8O7BdEXrqka1R7JasrUlKuppKZaIW0ekaOqU4EHpjiN zVciYr2aaqIBs1YwLFV9vSARo0tva2FRE8nIgJjRJdOibyYWLu6mZtSb7KaDwIa8GuQ3RbwX Ocp+9bZAxFouNkNZV4+FgvBiSq7IXuSvPyT5ZwK1aGNpkpZPNc41vomsNHY3drewTO41NTYX sVv4VNO95nkmrYFK2nxTK3Nv2pMVavzaXqZOZv1yuoIt0yzTbmAvaGQbtZjNORJFbadao8mU I2kxqzX2s/QjfgzBteLP8qPdN5sVsU+ltnIbtdXQDWAizSsll7aaNPfrjTq9y2+caSCGGlyk mRiwhVZj4K6zoCBaJihEqaaDXnZJpVK5hEcJ3bDdKo7GRPGthJICO8qZGptj3lFfOFOCkTqy QWnwcWD8LhR93gNqwI4Ebe+VwPwVMIZqUQaPAQ0dU+PyngEjtjVStd8U+n2bWS9qIy8VPtjp zjc3dqsvFna2zjfntlazO5pgbeTlQXYxRvaoo+IZEYo/iU9o1Zq48YAmHmJdTtLJLTnxiS3J MCLtDg7aGiySamp/fuTGPk+xy3925W/XtuSna4UyrkJLnyo8YPLANpsh6mdo7cZ4OpCJSNIt clqKp7BGi+ZWSzWMaXWcUp1Gy5lLlqXoeSvVuzRSWJPQCfE7VHEucRmIy9DHUGqYYCg3SAYt etOqU2PCwf4zt5r/1a+pd6sbHObZJdmqJzPx4lWejE28wcnPn8fVHYoaWhY6/TLaV60LE1CN qXAqcQ+qtP6u+bj8fTu75mv9ueFsbr4GrasIfXcmYjY3nBW1nvC3PgyefI05FhEjyhd3xmA2 JZxNwWycyP6+rd7ckgaqg1uYR4R/RayrDjJac/ByEDdsFp+Jm1VeWy7i1hHo9X8mfQBmSIJD /j4OC4lVYmOTEpKSOFd4rCHBkMQ3Juw0v2FmCQn2JOpK8Vt7x/RO8DuKpCLdYGWgdVjMkIRh 9kGOwUkLE1ZQJdHJmM1p0MX5XBj0CC9DbIIm6jVpxFeKBOs1wu8Q3NdEnxBrxLa4VdPjKE8h KRaf2EO5gelITI7G+uFgvyRquXtd9c0LDPhjFHDnchGaqj57awXycsHagmLADyPIfNLqbdL1 xargzr1HgjUb3iQpHx0nSdO+feTd4Ef0EBlHnt4ffO7EqeDaHW+SIf8I/hY8QlqQpO3E8Fjw q3Csz+tQuk1gh0p/41HWsbG0p9Iz9hblllhuMDrRwkCCPRzr2Xxa9emSVonY3kj0o3W4HAT/ Oeym/zYE/GsEm9jwGIs8cZpYEn7mVB8Ehn1uDGXUwN1JkTdutxXz9TE7zXy0112PFv8YfCs4 n9y/Z3XJTc1nBxdINWbbqJ3jdgfr6jYzsmjm0IfiTEJy1qGOb0Eu2CGNXPa7bQYzsbVKHpJ6 u3ZcKtepXxbRqqlGTdOFIyvWoX51Q2SM0YwhmrFVh77YbnO0QHphe1pGC6sop2S0UCLUEqHY /vH2FF+4HfsrESra/d0x4zX3SO7h6m8YmjwueZLuXvM0yxz9fMuTpo2WastZ8zcWBU87l9US a7VarBajzpZE3Y54vWwT3/aQ7DpdfIIj0ZkgTIn65aSEBHCnqftpt1ssZq3TZ14lR78WJUe3 Sg220tSwS1YfMJa40iekl6ez9DT7f7rH8r+1Rx7hGF4T5kcUIPGMXTzeEQdGZK+zsa0gv5n6 rYzwlzKk+u9/NfiBSJzi12v9lnyL0tZqayvMBpmonhhmtD6OxHwr2icbwuxPzlfQzVPSUhH1 Bqe4waPKhPiEGA9rSlGcPKpoqS/J3OtoxYF37jt0tFejgTeFLu4fePfgJu6en5N1c5bd/OQz wRyppveb01YdS/Gm3zwlOJE0n72ojUFTN4XltZ7WbbT6LaehoW/499JRyKFx/owRbAQvY5M5 92a0ZPnJnVl3zU0pXVIL07tm9GfFmqEpgxstiDF7xKMHwe/0aMYbzfiimYxoxqNuRbhzOOON ZnzRTIaI97qKXCOTL52mswxvK0sLT6G3S7MhrkGegd67DGNMY823x46yTzPcZ7rP8oAyJb3M O5dVGBaYKiyLlTnpD3kfNS2zLItzRjy1Jm6fLcnn0PkyMSCDTIeN5zb3wShULlOTaUkLkmiS N97UxJnhJV4pXhK2I/zGwtlE53TGM9XmZVtt+SXhxyGClKjf22h2LvxJ8jfxpptNBsmdnOJM 0mpkzqhMvOlpWCdLzqQmDr8QuyVoh87FQxP14Y56yirERfqQUjKBLCUyhp4Bf0wTMaQYGmfc Q+eDTJIpTLjZTAdmiqmZxHWZjlxcE/HZxPEtmmxRIbfVvxixDRC6kNg88rCnpNcZNc48pz4l v/L4VsGY+YxILooVoRiLNxXiCXmxiD8nXpFitPkxrZ00Lzfy9DE9w+dr2SL8pZTIM9642IR4 nqAKKYaq6b6hL5uGvfnA+E39+wxtF7yr7513zPj58Wf+mCvVWLZsDKzLb0M+KSq/b27t0weD v6wgHyl3Lx7cqaywyx2ehOHZrZ8ZNf7VkXe+M8u88OFZt/TOyxvbqN2OqVOOlE3+VkhqDp4N Neo7qAV+k0SdyHBQ/1i7rpqWbXeF3+S8LLsIbcYIw/wOEnkWc9ZvUM2DNmIbfo6GLV9EjcTl qFEIhh1ocUftzhUNIxhkJ3onZ0q+VtRvvoaf94ovhIinfjQmmMIrgkmSacuWP38Rs00E0EwV Npwc9/sywWfNtPns+dDKmm9rZe8O3azdbd3sRTDYWmQbbFeWa5dbaER08xTiSMyOayG1MBZK hcaecQOkAcZb4kZKI41j4yZLk433x1mkOBEh2DCAtlCtsJ4dxI/YzRL1tVOS38k4+uGyRovR PRpAnclssRhjY2w28f9h2eOqQwXbJbC7BDXarIL6h8Shm4exOUVfL5YQsEtarTPOHhsXZ7cZ dTpnnA2zNqvRYnEp1lhFsdp0Rq09TrJYFSNQnJLE7IrFosNQn+Kc7Dab1QpaR0KCQ+moI33B BUZM4xB+kEjfnS7xyiExsZos3BY2wCWOxF516LbXORLr7Dd3GVX4db3tjbrtwu6K12pRoIvY q6ETfzXBjZtnVg4cwKTgQDTXMEGv3oJevRW9+kqbXrxaD7v6XqzMUl19EH/eOhIYmLFmu9Ev +cUXT9HkTypxk7wY1ZHPi7EhiclDZ168rCNkdfD+g6fSHW30JOG793t7kpt8/Vrw7t3BtzM0 CbHBt6Sayx2efOL7dHayzhH84ZeFVewldBxLFrlGdat9Rrhm6AF0RekxkjE7tbq2jLfTVYe+ 2W5LEA9bvvGbMcMTMWEi0Ykz264+n/nY3w4zvBEmNh/P1Gbpm5n5aDJaHm04KXOJMyZrNTpZ 1slMpzeKdyUuvSFWjzEzk3VMmOF4UctclMTiHspGg0xQzYihmib6dXq9jlFUOnM1tft1Rl0/ v75cjwEq2eE3GQxGF7B+vekSSqmo0aEExUZPZb9BVT1jRN2+iCggte80mfe7S3H7sy+F/f+L JWiewuRroWUYtV1U41fc9nlNs7O1eNpK6itWkZsnXqwqmPQMJOAGJYtXqlqjzshrQhcxWrio vphXrRpRT2Od+rwFwdH/35YoDtorf2PRbSV54bAMXXvaru7tH4i7T5dOt5LkL+pepuNYr2DX 6dPLlpKtl7fXPSb8tB6hszyZt4dG0Jo28TfWmXRZiSZHVqYpKwtD5bjWSW2zumeVmEqyxpju zCrNqTDNzVwZ/5RjoymuUfQ5Yob6zW+Rez5xU6OdibsbHUg80uj9uM8aaQvjiVNYf6swTTbb lRfqLYU3NFDkUhNS7dmNs1rk8/zG3fmNjQdpi7Nv196ZPdU4z/iW8Q/TH9nW1i3MhCvN0lsk 5Lpj7cMyx2fSzORm5g7mJeY15pBZWmPeaj5vZmZj5HcQvov+VsJFf5z47q9Z/UaJWRbfODGb k1lCNd200/5EbHKyBkQnh2o4u2Toc5OZIXO4MhxkdZO97nRxUEXchB/CcWY6F/ueLt5hiO/y pgvvVKw9XTwgNYjh0tWB0qMWOb2a3uI3Z/jFdzFdvpz/p7VvAYyqOhM+59479zl37p1H5p3k 5jFJIDEBkhCC0QwiICIJEkBBogzJhAzkOTMhoKjYqmi1Su22ah8rPuqjteUVEamuaWvtqmXB Fe2WrpX+Yqu2VLZL2Qom+c/57p3JALbd/f9NMne+e+55fq/zne9856ZsZ5mtkVq7dP4j5sM7 +wCY3ghL04KSummNo43Mjkbc6KN9m0Nr9EX8xTWlL/OHeKaQb+YZ3gGmJbAi7web0k47w8Mi gHeAfQm7Jvz0WTmB1mTyrCTL1EqIdsrYimTtWvnBB3RSPV6ZCfPM5B80TYdMuCcCAxEi19Bg BPy6dCptgN/6unIziO1SBuZWb16ex+srKWN5wcGY0SIkE9vU+cL6nS8uSF1Rv+HoOlw7765b N+fv8vcdvvuu7y7RJV/xi2Hf2lf6V8/oTXQ/Vpb/xeXzv3dHy20tHocaLI3IfRddsnLQP3jP omjsyupNJ8/eccks/G5FWK9YXHPFmutaLxkmHH0n4WjqXaDnFbZGv4ltdq3UVm+bZ7M1F+4q ZAoLi8O14cvCA4XbC/nZ7iZvU/Aq71XBdrFdvVZr914fXC/2qN1an7cvOFr4S/tR39HA/3H/ wfeHwPv5xwonCgOGrUar8UyzNWtR21XaEluX7Wj+n7kzul3Pc3A8g0JhojrlvLBD8ZceVrCu RJU1ylaFM3d3FeBRxW859k5nVjgnMx558wiEQgPhwDNPeaCG0lNJk7U64ky/BEzwtWyEYUYx scF24F34JOYKcTNuxSymJgBlWgJ8Fs2n7IWBVTDsR2AXZRUMrIKpu41yGGT10qaxH7bvIAgC BwoWNOSuK4ArknTPjaQQ82syEawy8geRCqayGkyiwaISZ62T2FpkQamjkuJylpha2eA4fNFT I8nda3cORsf/9NKLG5i65V/Z+Ox3hjY+azsw9uf7W+9/PTX+yfg738Zff3n5PQffOPzqQTKr LJn4kD1B9FUQr7KiGusct2pYUzDdpBlALOJcYUXwhzkFO/IEkY5egNELENsl6HT0AnD4wSOv mrbkK+0z6IdGbi2Q7LgwPNc919fmbvOtca/xfZP5JvsN9Qn9iaBdVAPyeibBrrcN2QfUreqT 9uekffJzdrvXfqf9fYZ1FN+g9Wu3aqyGiYqJbp4GO0drSLe2ox3oGDqJJKRpCprsY5h0vdQh gn4qDpHxlSqVhWTWwTSghxIoCtS5AmgSBJosDOeVHhJwodAsMIIDfCQyzSSAehWmh+pesWw+ ujNg7pImrX/5AOG7s1aeSJ6qPJHM7Jg6G2v09uPkDyxnQreV2GcGNNbBuZSslUwpxzbtzv/k B0fH/yv50d3f//fCnYFbV9313SduX38fvsP3/CGcj+VnMXPbzkdDG3p+8tY7P/4CnWPmE5q9 Z8bz4OXRJ2SGUyNqnXq5aqv31IevYZbJSz1t4XVMpy0udXjWhEcLj9jedr8b+MD9gecT3+8D H4DkeQsLK4NUXBcFqewK1UypWu2dzdSri5h56nzPwvA18gp1nfoB/zvvGXzKoeM81qHoGpFI RXAiIpKs4q+lkX9aRNcPO7HujDrXOLc6iWhSnjAF1OmikuOESYuKqpOnHOQEgXWCs5Fi3Omg GHdmvNlOunq5DMIW067Sl4VDwnvChMBRErUKrFAALAd6WigwWRHIBtOSALOPECioW5IbZzC4 +MRYrtDBEbWm45RmTfQzKWfUI1tUT3UxUcYmwegGiicnCHVW/JVb3x5af+SLa75es3fMeHZo 43eevmnTo3f+471nH38Es1+6eg7jODOfcf389R+9evTnr1CaLSJatIDIWR6hWVvUV4jCecSm are1S8uVOLvB1i/FFTHPPO8HCDgeXUqh/DBE+Lp+aTvjOR3kprtmB6aH57gWB+eEr3atDiwN x1y9wVh4E78p7zRz2q8jL9ZUn2+Jd413wMt6w9p2fYfO6DoXCssCOsB8l3JsRpuNEmkgeNeJ dHzNTaTHF1XJrAsLIDUTkq9mdixVml8qn1q3S8VqsJBu9EXK6uh3dA6dZgtxobdWLxWipVPr MpQycigVBkqZAhYGGsGeNqVUrk5sr1w8drxFJyvO07DqXGwGVhL1aIZWNo0NNlmxiVbwFux1 ZUTMdD16hCLYMMVFEFnMs9cfqPrjCx+Nf4I9//42duDPPpT33NFx79hR5mr7rBV3b3kGr/A9 PoILibK344rxX49/qhs7D3Tjr905t/tJokXchIRbbW8hH1ajBR4Ja4GawLRANDAQ+Kb9W+oz qhhUK9RdgdEAF6D4qAgW1uWLKmvXwjLOYyo9bo7lkfyIB3sm3FHOF+EQyzyAwX2+d/qsOnCj V4YL67YjHIhSMQlEVSImlrFcAYZyMRUcVGWZy3+yXFgey4X1MUw7sKEFh8j2T5yBqG30uD/w Ij6AitBpLKOMTZ0RA7CuyRLqhH7iRLtpWtMzRo1OM8zDozt5SeBFYiHpkiuEnLwWwpW4cupt t+FKIifJWmdJfW19XQNd/hO1RrVaHj0JseeRR9zBL268anVo1oyllx86xH7j3sENdfOvcX1b nr9m7b2fdRGJuGz8avZjIhE0nrk/ukZRbJ4qJeK5Spnn4aX8QH6VUuapKmlUZnquVOZ7VgjX Kt3KGfnPeY7qkqryS0suLb+qfHvVjiphZtHMKc1V85X5RfOmLCtaNiUhdBR1TFlTtbXqaPmH RX8s+aTc6fPyefuZ3SMVYbcAM4luoGkwj2xFo+gwImYrc3N0hi0c1uR5xWG77M2rjdTKEb// sA/rvqhvjW+rj6siKGeWV4Fa84Fa82XVmg/UGg2Dh9SPTbVGc9GweEut+ahRcCVEyqc1HEHF haUva4e097QJjSvUmrVWMtGBxGhBSlutmNamhWlN5pEODXSbFqisShdR9VbZkqPeTp3Qz9Nw Y8dP09MTx63A5OPm+eBBMin5aCgZGJDlZjwy1XO++kxwgTtH2XXtVGbMTd98l9+BN+761cm+ N7/84o1Pxn+1458+fvjJm7c8/f0bNz19bfDqyIzOVQ277sFN7z6E8b0Pbf1s/V8ObfoeO/XN 0Zd//pNXf0K9H9sQYmmsmQfHXkBewvh5vjo4oQXmdYSrZ+exB1QOkmb7AnU+0Wl3elgbRlrY JngU2R6RorUz6yYkPCphL8wx3igE91XA1UNJINGFhRPC/MC2k4I0nwTrTTj56qEkkegEAwcl aGAg3J/eB1uyLV4qi766mXW7vCe9zIB3h3eXd8LLeRlPxNzu0kkfTtJzwwbhnGOIgz0Ca1F7 JuoDKeUyYTw5m15nTHsQMSCWDJicLXkLluTsJcDZTdj5qsyxECEZzhaDOUhXvSCdDt4hRBy8 PYRVkcgloptRtyEi1Gaoj3lMzFniBDLyec5tI7eMbvzBopGhDUu+3ERMwj890P7Et8ZuYB7d dlPbfTeP/ZDI5F2EUE0Q/yOgg9HrpZl0BK3SdmmHtEsald6TTkoCkgqlAWmr9IiVdEyakORC idhYAsewEs/eghFv4zmZFyI2BP+Uchc3yh3j+FHuJMcgzuAOkzuOM21lZjmXxRsHeONk2ioH mo3LaDYu44fjqBDJFIdci3g+9pJNcOCLYApn3EGU5ZODlRDETrBy18jICPf7Q4fO5nFlZ48S tT7x2PjVeDaM2YXejs7jbBHbxVyt7U6bzSfabALHMZzNjbCqMKzHzjltikBHqPBC2KltJxrd 5yNSqUZkebuCC5VmpVVhaYhBtIGOyAo5gIWCAmtKpQBWJnY6KEWENQnIthJwe75ftCBXqkGK aTxei04dX4OoeTFdE0AYXnZ8ztrabbpoxpk6RF0rE3U5hCWHEEImR9DD8rV52DxDSOOH6Emo O0fGu4tnFjbMHKmd8+BC7qM33/z0pocdCx/gVp/d8criTiqvhBfYv9D4ISYWDfGmbcWv4FdJ rKb+p+00z0qZAHBzO0nOAFIGgL1n2I5azg7LjIs33OCROrnXVU49VCdHyLfLBglFkBC9naTw HGfj+AZpASEFf5F8rTzMDslH2fd54Ukel/BlQkRs5GdJzWqrupJbyV8rrJRu5jbbHpZe5f+V e4c/zn8k/Bf/qZjnkmUb/ce8NPJIEsmNJIoRM96I5biIGYMkE4blREzY0kYdo4qCZG4/1qKS jQPvSrFI74oMWB3o5nbpdmIAKRHERMhaEeFm1Eokh8Z+TQfZB4ojM1QNOBm5QAPAcgLB0gQF 7OpvihZ05dIaSA1++cHT4JevnNxlIuapr5FGJnCZECQaiyQQsotNLFwtP7G6SMKF0u0sI/lV uh1O1h7mKceoLFXlN0pifn4TjSHak09DiY7sMeBrd5F1lhFiEQaR9Z9E+InRPUWwbb7HS79+ vUeHACTyBXd2+NqtZGIZ6F44bcr1LodFj5e05vE0wYVu2u3x08J/2B0ys+P2lab3g24omCFK tRiXYIFIKP7uR+Pr8cu/Hn/0VtuBz17Eu8Y3jnUyhTeOX0f58ovk0gDy+v4+GygoCDpsmGUG H9bVm9/TppvfxWZwYjRCphvNVmh7xPaejWsll5M2ttA2YNtqm7BxRJvLDGsqeFoTKPo8Ytk8 gvAoWWYyudr+L5PaPj9H25u0Nu0x0TLGMlsHExOZzQRLd6EW7lzdRZUXdR2ZAYsY7ugPxcwX RyB00ZxD+TJiM5Xgn9EQk1OZiKFTmfc7/Ft0saLWRbjj3HHpN74PDNvbttMG4xONEskfMiSW LSkI83nUpBAwXxIM6PLhCN4e2RFhIkSPOSLbndjJwYrND6s1cNPBis0DJ7ngxD8dqJOBdRuo MSc46JyZvXJnJubIuR+3R+3+yPYQDkF1oWx1IaguROO2nLS6EMySIVh4h6gsweQcstOKQxnP X4jW50VMbUkEH0aY+gCYQkTljwX5y79A/kDjIq81A3+WsZFPRT0wFZukcJgiWRrZjzftPV8D m/6ZseM5LpscVx+5GYNNicGkGS3YbAqx05cbLe2we9xlHrszhF1qXmaitpYu9OQwbJ754Gg+ TNdgR+dO3I/OeHL9xgcLb3n9H7+7t2T1pQP/MHJt51W3zebKvtZyw9prD+zcN1bOfLvnhtlf e2LsQWbPpk1LvvGVsV9mbK7fEn7x4pujbhvLu5mn9f36++zv3CfZ026eoyq3iTDMZh0/pB/2 H/NP+DlD9Dg8XhexuTDvVWXVYXeU+sHO8oPNpYC1pYC1pWStLQWEQCmGHBTDYG0pYG2R+09N giqy5Y07HQV1qIBBp2Dyp7T4qdAFqeXlP+lnBvw7/Lv8o37OzzK1eV6QzdMjTqcVZPi5Bpd8 nsHlzDG4OEsSR6Ou8w24Fh8c4cv+ECk8BUbYOamVEJQLoUhkDs5aYV7eKcmiLMgsr5c5eUcI a7LLIjINZh+kWhiobHlxc0i87bGhd9c8ukSXR6ZuuCL1FFf24M55A4tn3DyWYu7s653zwM/H 4LTL5RMfcuWEiioK4A378uCtBG66WwBrAiqSKQoF4IFLkAP2BfwV4gp+pbiOT4hinT7bNdtb 75+nL3It8s7zr7atlpbq7a5271J/r61X6tR7Xb3eTv8wzpN4m3odu8y2TL7O3sPGbXG5xy77 wpzgJCrDUxqCtU8I2EDIvsZEAGeO5QjMuF4BsOKMTsKS1IpFAmA06i6N1E0TMBJ0wRBYYfp7 REfQ9IXUlUBgRymyO+iyF06VIfA1ojDQF1wIltSC/kEQdI2ipEqqDhg0PUhdCtbrkUzK6YOV 7afbcwIysjFM1N8D+0BttjZprW2txNG5iWZxwwFkZB1Hzl0UXf7E3T/9Ffbe9Pt73hs/8cKe bXfu2XvHtj2MG5fft3H8N2MHf/8FXIDVn7/x8zd/+sbrpEPbxhNcEaGgCxXgtdH77PpF+iX6 Ip1rNnYZTKExxV6SPyNvRv5l+QPGdkOc7ZsdutJ3ZWileJ19tW91aL24wZ7Qe30bQqPGW553 /e8G3yo47jlecMyYMLwlXKVemVfPzdbnc1fqq/QPlN/nj+uK08F6w9R1znvDDgU5AqWHZazL UXmNvFXmDCChEbVevvBbcy9O9lv3ZzIGXTbK1HSjy5TXSiDeNI3dtUytK4LQ53vMM45yPcdR rp/jKD99vqMcNrKIigRHeeGCBj8+x1OecZSf7yYHP7mzMddL7s4oVW+eB47YljvZHOpte2L2 A913HV4/9N5Nq+6vdj65cdP3nkqndo8nbC996eqr75146PHxs/dcNXvsLPvEwVfeePuN139B pfCK8QR7jNBQR2E8M3qfwlQyU/0XM4uYzXa+Oa85sCiwvWBHga3OXRdqLrjcfXmozd0W6nB3 hNYUbC04wr/t+i3/kf1jvz6FKbZX5jUy9faFzHz7KibB/NL+K//73o8Cvw19xmiYUz3BsCI4 eE+YI4TzOWoR9a9qWNei2hptq8YVgCOiAKingSNCyzoiNHBEaOCI0GAiBVeCl+JaM08h8Gb2 ZtAeaeeF/tVSkGTwQQjggxC8puFr+uvyC871PnyOb3XsVNOFhEGD2Gn5wWda7oZzvKpVUx9c /tL4J/1v3fLTwcfGip7dlHpy58ahx8cTjHhxC67Gwo7xLz5535m57PcPHvzJz4688zM6w91B SPMqoYoTvRa9uMaNdQ6XcHXcXK6N6+LSHC85RUmUVLdTUhErYgVEAslSxXYRi8WGG7uZYudf X9lnbb2/RJ05Ew0Piugci8Jc3PM5Rn6La8ErFyzuj+vtp5L0rBhFTWPmpSRIf22bA8KN25P0 rJ/JvqZHTSATxR2PXZpovu76Sy+77OLrPQVc2aODV8x+qnxB85rk2BGKheaJD9ndBAvTWF/0 Jq7YUzxbulK6vHRFcbx4i3SfdHvpk+7vVf2YVSVf0O+btqjqHZ8txCxnGH0Glv2rxdXSanm1 stq+Wl0vrpfWy+uV9fb16kjZSLlGA3xKp8wsXSWvVDrLOivSJenSraVflb9lf6DiwaqvTXtC fsb+ePkTFXvLflrmrchYosUZoCQDlGaACnN1aOWhQEkGKM0A+TQS11XQuEosj9hlLmiU5XFK dX6Quu6KA1WwuxBoDrQGbgjsDBwK8FqgMNAfeC/AFQbuDzCBlwht8ghfgK876qHZdRpuruPD ZKGHdQznfPZ6vHWmD9zhrMO4enV+Tz6TH84TOHMLGhwTv804H34bdVMCc+FqpTCIg6WBqNtf N4MWrwF/rd+8UmkJwHvaAgYtGTBoqQAsHAPg7w7sZ67bI5ROJUWfCzcenoqn0lZoiamZGMep GTklwMfwjpupQWiqqHxq3ZoZozOY5hlbZzAzqN++FPlNexdYzjCxTFQ7BWgHDHgJCe2EUaqB Atage5phaYgzUQP0BpxIsNyMxe9llrWB6ZZzngi5pYrpS7t08pVssba+KysHc05bV5o7YZX0 hVuDsPVN1zI0tIx+ZU8S+kzrKVp+UUGJzVNV5tRdultn+WLVCCGpQghh20XkUuAht0WOkhAq LlHt4hQ5hCvKJZmv5EKoUM+ndpZ5fhAuEI09tfK2225DOeqI+n/asy+GKS8rr2bq62Y2XBCy Rn5pnC54QJv3aHfftGVTfeSrrz7cOmfW1K+03fzSKucueyqxZb3XWxO6/eUHVyRevfnQL/El 4Q3J+OWXlPgjMxbe1rJgc0Vh5RU3rfMvXb20oSSc75ZLa+dsWb3qkWuepXJaOvEnZqrtYeSj pwxlenSujPo9RqNzCLA1gBG2qzJmkVeXKjWZTN2sounFqBirrogdTwjiPGneGmFA2CpsFzhE LKcdwi5hVDgs8BDybcV+nwIuEmhQG2zXmusxC7Ciwc8Ad1CbjM791LVjmWamVSkcYNYjP565 u+u8RSq85nGsST9ONfwJGvFGNbyztlZ/zQx4jfjMrTO6M+BsgPciwQtcGD14VdPanqrbb9/7 3HPuyoqCRx/RL40/xnTci4We8S/fO/bVxVVBWN8TXXaM/sdQ3PoCCtI9J7JyZwy3lwYcn4zW ujx1lW5cKrq9duz2KkSZOwmaUK034vfR5UQQ1io+WKX4XOCWzwab+EB9+7LrE5/HctBb3mAf LDh9dH2iUnxM+PCoD/taguAPoEuT4MkgMxDcEdwVnAhyQXtEyk4c9M2FhnRYOiZxUmbikLIT h+WNlsEHDUFV4HeGtYkEzmCpJXCOS4A6fS9chJAZBCIDmhqtV8kQIQpyukPVVBrZRw+Zk4UI Zw8hVXSaLsCpU28j8y8pa+1qlpeBG9A3eaSQbd7y9vWPt+rKiOLsu/rq+y4e+dbIFb2t9Snm gbG9X56+4Oq2++9iGs8eJdQJUi8+oY6MP7biBXw2Eckij3kZ2STRhhlbKZwkqal896D+7kHC GnS2o10NPV9vw6jY2ShT/a46GyWyzKwT6YUhmm4v+cbWt0xdGVJBUR2qIBewO6XiSB3ykgu5 Oxq9paK6DhnkotmnoAqpTG5E9fIVaIG8Aq9gVorXSl24i0mICWkTGsbDzGZxkzQsb8PbmDvZ u4W7xC9J30YPSV+Rn0WPyS+h54Xd8mvop/JR9Lb8B/S+fBadkqvIcGQ/8soVqExukFtRVJZs UZe3zkZYpS7zhkQyHjp0RE3kqAavMEOgQykuaBqYsxQrkMrYbHaFBgS9W0lwQz4HKw9Wohoa pknxE22QBVGMSLJHkmTEMkzEjLq0yTKSzRBKXpAlFmFbjR3bi8VoNCptlRhpPw49F7VttTE2 AkUlg4niYuXjf6XcdCIYGGsfaw/6Txxvt17pkvUrOhvPPe5Eo+KseKTJH9S+MhPS6K7F+Afj Pf90PFLor/zDC+N9XNnY7ev6l21k7qK+dDNG8XnCHS4uP3Nmz0UtU9A+ZhAYb60xjsBL/ziI xKWQ07CbD0ZHHOamAJlaKeSMwr3sZDGyE2sI8xrBhmqHF43YnZjhZM4pW94pU9E56QvSDurv HNSPwPE9Kw4WRkd/qDCEiAR68FRuisxc6bzOeZ+TdRrmK+isl2lxGcBJ1Y5UWFSnh/NNv3X0 +cLSOo63S24+JAVcNg5xvCIpDtGlIzfrEcJiSMknK9iIMFWsdNShemG2eLHjcnYBHxUWi4uU udoC55Wu67Slrg1Cp7jOtZm/UUiLL/AHtH2uP/NnpQrFWYEq1HJHhVbuqvHMQg2uYfFO8SH2 QftT+GnmaeVJ+3NoH3/A8c/cO/wvpQ+5D7XfuU7xZ6SwAmch7HDVeTNMD6Z0uLostg3JDo1z IacoiBFBizjoMs4hsCq2R9T9E+9EG6iWUgn3TYW1moo9bl5WnGVypXMZt1Re7exxbnF+ySk7 ZY7wIiWHSZjzQ45rKk/VmAHl+nH6a87+5C8U9bAQiizYJFkWyRpF1p1Oot8X7bUhF7FZFka7 ZM1h/MQpiIbgdLkqbYLHZhMchM4R1eFRVYdIljuVsughxWl8siUpiMGCixM1p92hQvdcRI/T t1pQ0XFp9KyQ7Dmtq5geoN+qsup+/FRUNlpl3C/fSuNWmeVRqdWJ+523OhknvVN0G14DfmKW CNdTz+HT7tNdYBIFFp9qb/cTu4b8USFr939+bLIldU64/jdCkwWH3kQ/FKafRbsK264dUQ27 wbw4cYzYtMeQY+LwCJqmGS7CoxDPCjGti3bVtcEp2cO7Bfr+KZJQ1LZoVy0EKokTx3YLhpnq sk400kMnh/cRU5DUTbTV4T3CNFrjHjSLOWC2lK08W84H5ZwTx/bKBmegWVbcs3WE5cg+VyOq Ih+6reCejKU1/dlU/OC0I1UooE/cPgiQZstZvGj8hweeaeZqn3nhkfpL9u0cH/nhM1N+QRTM N487X2f6xh564yDTdfYos+W5zw4RTaOReeg/iKbR8b9b81CehhWeYySe4VXCkRpY5FpNJTAl vJ0m9LzmwlpxwDxGvSTQuEr7Ovd18WHHN7RR2yg/KryhSVrU2xhk3VKeGtTr8WzlNnyfIta4 ruFWCiuVax0P4ofkh5Tnmf32f1Zed/xcP8q+Lb2p/kr/QHZlhEuxI5dT86vEsKCnlqIOCmk8 YlQkywwPRxkpSxA1ZIbld/E8K4iShHleouHYxB4j87mKNU3VFWJUMKrC2nWZ1xhN1l9Fr0qM HkGSByGJZdRXVaxG7KzHbmdlSWJZhicrAbsdya0u7Fqo3mIvlrUYL90SlcnM8HyUX8JvhRdh zY06DPYWpriV4HKhc8sr1rtmYbIgc4X+gX7qBJzOnuRneLG1xa3t1ssXGzVtmwhcal7JF2Xd JrHJYooRhz+/UYGTlfmN9mJfI0s+9H5PUaMOR1XzGnFxUaMUDWePsK8EpynsEZEJp9ZHp54G ujvElmMN3z7+8G8erw5XRfb+Yvwr+J53j84e/4ipwOOfLph2We3ZcfvYv+ArV463k3EVjV/N /pHwSBD/l8Uj+bJHYxU2HNBcvMK7oy7NUKJ2w+KVQE1l8N2g/2AwoNMvWKTDtBHaq4WxRgfR G26s8KzQdspsVI0SghgV0+p0ehHsksur+l3lSrm9XJ1pn6nWOx52KhWuCvcV3pWule6VeQlX wp3I28xvVDc7b/TcmHeH+iXnva573Xd7HpKfVl7Uf+g84PlY/p3nz+qY/qlnIlyQ4SivWwmH OO1y7XaN1QLZ7ptOBFf2eEeDptl1oiuJ5RDwuN0Rl+whN5qdKMOIIpNlsOymIeMKTytAYT3M 1IRfDjPh/UzzcxrBRdSzn1kWVZpdURdzg+tlF+Pajy/bp+FiNC8k00eArahhn2ZvtbNL7BN2 xk5y7K3RCG6Y5pGQsYUoRoK8MfpGNMJE9Jy1Xz91PEDfUH0i6NdPAIT8dOGQ4Sgxd0uTstQ2 4B+i9RxE2/iJtvkhsk98iJSJD3GurvFM/HpfQ6Nc3NDoIFL2XF6j0zokt5Lay/TFB4R93OVm lEsDHMewTBj68uOS4ls9F1c1XeFzltmU8d4fv1tZXFj5/sh4z5zSaVtW1I2ve0avKA1t0PK5 irGHh27bspHZcPafd162so1aORVE9xwhfOXAO6Oqaz/zmsi48AzzIMa/RCUC4EsLYKf7x9Er CTCFqZBq9EbcKC/E85n54kKpVV+NlzHLxFXSEr0HdzAd4nrpJpwWb5LuwXeId0uf4lNMKCCW 4SlipdQofkf8BRaotDyv59UxRL1K9GW1JWQhzcyWZEaU5QhmyPTHYPqCPCZmqyRDlGMqMt+j DbN5pUNm9mNthEyGNv6HzHUIIYG6rcBZX6zucGDkiDrWOLY6TjpsEOtfSh850ki+BeOdCLei fjSBWAQvuEEBTU8XUbVBvYDW3vUYBY5XQkSZPkadAE36B2SJ+AEEV1qmpu54xXqFwmA7mGOE ms9NwWUidcqY2BMpLsndj5+nWKSoNF8VNLgSTmzQuezXezSKBOvrw+dDjZLoDV1CjbM9vkZY dsneRsZDPkHvpGKprcd8CT2ehYWZtUV5FcwTqWvHW9nOsR/1b16Pf/8AK/IPDI9df5P0Terx bWP/k1llewspdL0eXf1IYGeA+UT4xM28J7znZg4Jh9zMy8LLbmansNPNPCI84mbuF+53M7cI t7iZs+JZD9Mj9niYVeIqD2MX7R7G4xYFssJUEKt96mA/ZRwqg+1NKmqi715dEq1x9wu3CvcL rIDdszxNDtXeRAyWqC9Y5xjCwiyxicGoiWXvZzAT8A8+ZbplID5EHzsOLwkHCDXTI8kndHiL iW69yZH8If01ukZHycHBQTxo/eB2nFdCA/gafDwvFOXA2PMjY+p1VQ11LP6HDMS98uZ37mxa MmW+77prJiGCqQXsR0yL7TXA1K+iLYCpk+JJD4NF7GGOCcfczGHhsJsZFUbdzC5hl5t5THjM zTwgPOBmviB8wc0MCANuJi7GPUyb2GZhSrMrLPJ8z01xY1cJyhwEWVj8nkATpmGCQAY1YezQ muwEX+Wq71K7XaXoUocYhm1CBGXliJ4nWw/YIvNbE908aAJUHdcBhn9XQf9ZReb7XGRl8TQ4 SPBmRtJ4BPO/WdTmwNf8qLDyuqqZ9ey/ZQDuLwRBF189ZYH3hrZJiGqPHvYjfAngKh0te0t4 X2B2Cz8RmD+J+KvioyKTEr8gMsvFOFnsiVgkGLAGXAADxgoZMsqODoYXsH97c5YZrFGN5f4T DpQhO6V77hC2fF5vaR/3oLu5EvYMUsnNDOs144geTWE29B3ZOD6+7/nx8Y1H2DPJI0kCYeb5 1FtJBD/z2RZE3zlJf8bhSmGMZHypBTPIYfu1BbPoetuoBXM5eWzIb/ujBfPIwRdYsIBe4ass WERlwhYLltCX1CcsWOZ+DC1TWEFrHdUWbEddju0WrPIj/EkLdqDVjtPU6w8/t2pLLZgsu7X/ sGAGCa45FsyiGtcMC+Zy8tiQ3bXQgnmSP2bBAlrr6rZgEbndugVLaJ631IJlJqa9acEKmu5N WLAd1Xq/YcEqu8r1ugU7ULWX/rcTTNZfDLJ7zwJsI7DuUwDmabovBLAA6eUAiwA3ACxZNDJh k0YmbNLIhE0amTCXk8ekkQmbNDJhk0YmbNLIhE0ambBJIxM2aWTCJo1M2KSRCZs0orCcM14F xrIAYHtOugPGfg3AOh2Lbx3AbgK7fEMAe3Ly59F6LNibkx6AstsADkFbZp35OXkKc+BSyP81 gKcC/DjAFwG8m8JiTv/FnLbsOen2zFiWoc1oAMVRF4qhDvJtoGfIZxnqBngxmY/7yCdt5TLQ XHKXJDC9xkh6AnIYJKWHlK8m0OWQHvv/rKkm2zMDtZEnPWgomydF0haSb7O96aiR/E5DF1nQ DEidQ0r0kO+lpMw60oc0lFpK6kuRTxJtJNdO6EMfeRZHvdmeJEm7BskVs1oy8ycIhgxSgpan NfahKmiFPolBSx1WXTGSYpbshRrpCLpJ73uhxgR5kobc3dAWxXraaiEFI+yAsml43ge10G/a p37oQ8IaywDUTXvUAb1KQWv0Cc3fCd9m/4egNQNayO1VAupPk+d9cD8MdXdbrcetvP1Ql9l2 Jr0H6k5bGOkgdyZmzs+XJnXGASsJ8m3W3WGlDAGmKa0muaQf6JIEjPZAedpTyh29VqlMCx1Q fqPVasIaKX1mYnMSC10kJ63NTJ3Ea8LCbr81kgTkH4K7SaqmgGN7oHefzxMZyUllx0Kf9UJ9 k3UkSTsbrN7GLPx3AE8bFt9ncNYJba+DVLP8MHmSsGhI8/QQ2ps80k+u68izjRa2zRomZTkG tDK5wwAcdljjTwDVeiDPAMiZyY19UNIcSS53J7KcZZDnmyzK9EJvKG+adEtZktyT7Ucv3E1y b/o8fZM6b3wdVhtroYYhwHTnObwZR4MkPYNZytsd2RF2AW8bwAObALcp4Ls0UGNdluq076a8 U1mqykpTyuKySX1kPu0FisTQjVDe7DWttwOeTnKa2XonYGsApGRzdhSZtmn5YXgeA0wkrTao DJlYTEP5TI8ztQ8AD/WCDs30rfoCvTr7HKpRfbcO+J9SdzZaYbWX0bW1pIZp5Ncg683FQIMk yIMpR1Ny6lpM+Hry7gfA50lL7nuh9g1ZGv+/6nyTLussTRi39NuknjJrXU7mAwMtgfIGKoP2 FpNrK2m7Czg3gzHKmynAdrdVWzVqIfmWkdljPvnMJSOicCtJpeXnk+tVkD6PpLSRK5WBBQSL 88jvYkhdRuxVGT7LgGtTn8PTRjbd7LFJuQGLtpOycCF+zDmvn+AgCdzRDbkz48lo/gw/rYWn m0n+oWybHVkdauJuCMpO6r64JR1UQ03qa1NPJCzdnLJ0xzqoJZ7VvRS3K63WqBbZaOnstdlZ z2wz/Tcwk+Gt4awWjFuSHc/KThL0VNrSG10W338evjLSTjEWz6llUltc2F6nxV+Ul9eCBjZ7 vdaiTJ9V8+dRqBxGdS6mTM1/IVdc2HJGh1JtGQOLJkZa7bGwnbJ01V9ruxp4vy9Hn2++gBZx y5rJlRxzlohBjwYAs3TeSoC8/X2aGxYv9uXo0Ey7VPo7AdOJnNkqmWNxVWVzJ3P4dtJG+NuY or3rhfozfNV/Tn3DQP8NQM1cbZLRw5M5+0leU88MAcZp/d3Z8Zj9yuXuXktzm/g3pWrA4o9J DX8uD/2tEU3yx0IY+4WUy9h4dG6LW5agORrTruwAqvadR4PkefierJmOrx80f6elVzeCDTaM cq24v0/9TH2mTMYtW+PcGTlT34V0NLE1aRl3QJ0XynGGYrHzcN31P+rtJJYvbOFcu+LcHsUt azlNZshMDXSWmUNSL0J0bpyF6lADmQ8Ncp1O7i4ic2YdzJx0zbkcLbJyTiNPp5MndRbcQGbY Big1E9WTtQn90Nq7wSYZIO3VkN9h+K2Guf1cie8AzffX5gkKXQ7SOZzlC3MWTFjalvZpKWho cw5tseysfsuCp/JpzqRJeJIACrSR6+S8QbmKrqxmkZXV/6zfNZC/l7RVQ65p0BCUVjUw99wA XGLaE9XZnP+7LQyDDWDmjf+vtJJ5VnMeP2brXrZ5IN4V64gbzxjLuuPG4v6+/jRJMub2Jwf6 k7F0or/PGOjpqDYuj6VjfydTDa3MaOvvGaIpKWNhHyk3vbFx2kXkMqPamNPTYyxNrOtOp4yl 8VQ8uTHeObe/Lx3vpZUkNxupGClE0hNdRmc8lVjXV2XMSSZiPUYHyRVLkIe9/cm40T3UG+tL pNJGR3csGetIkwKpdKIjZaS7Y30GebbZ6O8yEqSVgWS8M94RT6X6kykj1tdpxEj9Qx3dRsKq KtFnpIf64sZwIt1NisdJan8nLU3hnhhpg5SPkc5k0tLD8b50Ik5ydxBgKLm52gCU9G+MJ2Nk eOlkPJbuJY9ogY4hMsQUbSzV30W6CV3oGurpISD0lTTf208aSfR1DqXSMNRUenNPPBcTlDgp 2ko82ZvogxzJ/g2k2hjpf8cQaagPetaZiK3rp8+HuxNkhN3xngGCkX5jXWJjHDIAlWNGD0GH 0RsnuOtLdJDssYGBOEFjX0ecNGKiO0GRZcQ3kcH0xns2G2RsKULkHlpHb6IH0Ju2+CZltddB SqyNG0OpeKeJzfjgEO3sUAfFv9HVT4ZMaiSDSqcTfevo0JNxQvd0qoqSKUVQBnxEbntj62I3 JvpI1fF0R5WJNFK8M5Ea6Iltpk3Q0n3x4dRAbIB0jWTpJF1MJ1K0Ypp9INnf2w+1VWd4dbY5 tKXxdUM9seTsFaQc5dra6mnTjIrFiY5kP6XRFMi1eBl8PW0sSxLa98aSG+iI/xbnk7GsI0wY J/wGPEWyLm8zlsTSRpmxbLHR2tVVDR2L96Tiw90kW3VL67KF8xfOnbNsYWuL0TrfuGrh3Hkt bfOMOQuWzpu3eF7LMlVW5WXdhBQZTFOy0IrJ4Mio00CFbH+I5PWvS8YGujdDO5T5KZ7WbjY2 9w/Rkh2UQ0nvhvo6gfsITxCGAr4mPJEg3Eyyx9Yl43HKvdXGSlKsO0ZYp38tFT1SMn1OZyi2 hikLxgmx45Q6yXhHmvBGF8H9ZL8o2fvXxSELsEW2HCEn4fi1Q2lSNelmP5HCnAGVpzKdIsyf RUW2MOVQY2OsZyi2lnBlLEW4Krd0tbG8D/h8c2YUZEwWcYhIxIzUQLwj0ZXouHDkBsFiH3Ao LRvr7ExQGhPOSYLiqqLJScAtaITzOtWT6E3QAZFGIN9wf3JDymRs4GFI7B8mPDO0tieR6qbt kLpMdPcS5ib9J6Qa2GyYDG9h6NyGAB8LuyYHRzXe4FA8Bc0QXdkRT/ZZI0ha/YbMqe7+oZ5O wqsbE/FhU8VdMHyaj1AyTrRG56RazI6RdAuUcUd6ksZ0YDGr112fXy10OVvA0hVWRaSdWHo2 zbC8bY5xkVExq65hitEwfdZF0+qmTZOk5YtI4rTp0+vqyLWhtsFomFnfWN+oyt3p9MDsmprh 4eHq3gzhO/p7c2UiblyejA1TXBARJJ0iNS3tX0sktIXorH6i4KuokCYTHYmY0RYD2UiRGWvW jL9Sd013urenpjfdF+uN1/SmbohRPVFNE/+bBYbjPSQ1/veL0LsaC4+QmxhD/bAMpgZIHxi6 ZAmIVTKZryf3H4EpkHneBsYiNYmo0dLJfoPdzb7Evkw+L7AH2Gdz6oqBYZC5/w3UHT+nrfg5 tUF9XAE3nVvELeAuIddGkjsGS8ROyxzpxrvwoywCE486YZJgntE6EPq//RKXCAplbmRzdHJl YW0KZW5kb2JqCjEwIDAgb2JqCjw8L0ZpbHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aCAzMTkK Pj4gc3RyZWFtCnicXZLLboMwEEX3fIWX7SLCdiAPCSEFokgs+lBpP4DYQ2qpGMuQBX9feyZN pC4AnfHcO1dj0ro5NtbMLH33o2phZr2x2sM0Xr0CdoaLsYmQTBs13wjfauhckgZxu0wzDI3t x6QoGEs/wuk0+4U9HfR4huckffMavLEX9vRVt4Hbq3M/MICdGU/Kkmnog9NL5167AViKslWj w7mZl1XQPDo+FwdMIgtKo0YNk+sU+M5eICk456JkBd/s9mUCVv87z0l17tV357F7Hbu55GWk 9QEp3xLVRHukahNIcoEk9lmkvD7hlJvf9s/9EaZCC05OcodO/IQkaJissSioRRzxs6aZMiOi kJmgWDkVt5ROYjGjzpzkG+qsSFdllLy+ZaV0cTnxEu+bV1fvw9LxpnHbcc/Gwv1ncKOLqvj8 AvxMoGgKZW5kc3RyZWFtCmVuZG9iagoyIDAgb2JqCjw8L1R5cGUgL1BhZ2UKL1BhcmVudCAx IDAgUgovUmVzb3VyY2VzIDw8L1Byb2NTZXRzIFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdl QyAvSW1hZ2VJXQovRXh0R1N0YXRlIDw8L0cwIDYgMCBSCj4+Ci9Gb250IDw8L0YwIDcgMCBS Cj4+Cj4+Ci9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Db250ZW50cyAzIDAgUgo+PgplbmRv YmoKMSAwIG9iago8PC9UeXBlIC9QYWdlcwovQ291bnQgMgovS2lkcyBbNSAwIFIgMiAwIFJd Cj4+CmVuZG9iagozIDAgb2JqCjw8L0ZpbHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aCAxODU2 Cj4+IHN0cmVhbQp4nI1a62pcNxD+76fYF0gjzUXnHCiFJHbyu8XQByhNoJBC0/eHrrTuHn0z mmExGONvNfebRlt+2vRSrj/vyu2v7aDLH9+f/nnq/9xru9Si7fLjz6ffL39f/1vHh/vvdwO4 frRe+s9vXy63P358e3r/pVy+/XulMD4yE/l6J0u10v//CT5WOtHbH1eiH1+f3n++flYvr1/f xHhXL8f1UG3t8vr96edSaP/l8vrXidaCcDNw3WaYi4Fph9NiYIbThQ0sFYhvBtaSitbgdHXw AfCnAb+8Jlaicuf1bK3EM6xkrVRnWD5a+IDT1Rpxm2FnJQbibE8L8rb+FeRtYQXeav27FSBu /bvtqWJ7S+FDQO/PFt4zs1Ah8JhxP1XOXEJUM8WIwGryycAMvFUtvGWKEXrMKSYKihmPkQIs Vu/GmUNpa6neu6Si7eASm7B0bJlLuMBpm7BcQbSHEpbuvGztKNsM+4RVgG1WEM+wfFhl5Anb wGUB2CaNEPC2datXvRN21UCBuC+KqJiu8jk2y8hnimLrls8n/GITFq12WDh1CZVUcqogudjQ qyC5SzmizKgdmY1qU45bZnMSUMz2SFIQzfZIanC6uoQFyavVewez1GXCxqcxiaxZuABxtjC6 xHqMTY4Zf7PJsWcLY6wZl7DJMVtLTI5tFs71xhS04cAtDUVumESmd/BWU9G23Go7pzbf0zTg I00DxnBgQ1ywppLJb6lplghtGW/BmmojVfgA2PLGFKxWcgWjVlPPpXEqGmaoreeypb1EjMes YjsSN3OKHGk4aFmFQ94zJZzWRwW+w66tjfYdw2MGlihhbzPwHV7PwBK54NZx7zDbhiygmE25 2wwsUdLcWup52vYtBb1dv27A29bvuoHkZHnvNRVtB+KuXx8ouW1MY0Q+4RcLg1lczxwTdOgS quAx1zPRoa5nMhjV9Uz0mOuZ6BLXMxtIbqsBoUtsLaHtSE/vaaTSgZHqWmrqby6pv7miv23P RJe4nkmaRQszWM01Jk71ZqlZOLBidbDE9cgSmBulorXcapssbJ4XyXilMYrkHV4XyRa5oFYg rnZRMGaieF8ycurcl9hiwcDbXWoEebt7h6TwcEGs2LhYxGbZeAHnLtjvelpRCsDufjWS5A67 lcYw4h7aeHSak7e9V0oB4rYgyw6iuU6Dkts+NbLgJG57ZAPJfaehGSYbWzulkh+gmLv6HaiY XaegS2zwkHHJ8vIWOvR2Ozthe5pXxNPY4nC7MmKLw83OGHI43AuN0Jtge0EmOO3TW0E0t0yV VLQ+IU+wnWKkpZILnLY2HmvCifhq65DAPfsn2IbeDmZ5C/vcgeclxSrS6zOH98bahxoOx+2b h5K90AGnrZV6i+TwolAFRPPbcCBONnj0SIk34G1TbIyhE/z8gI3DZn5LknhoHUkST+MjScIx pPZVDYdzRiUUzYY5KxB3PZBTyXv5TmCF094Fud4N9HaxtYHePkkKELcNdufF6dy/8SDRL/on 7B1YAHZPRjvArgjqDHv/HjPsuhgD7GcclNyVMeDtyxgD7LajFeBH6tQ5SNhuPWycDDE6wy6d +206gfscyfGMQ8DbzVcMsLrL9g6SuxellsIjC+IZZ2RBfHpkwXn6gTcCKWmYS9LMC8CrMJek 1+sML8N8Es3ZWIC4jQ4lgG0xUODtsqCHucSDRAPFfBaAUR/JAsmfaU7Yz+plhp2HephL3PMI ibuBiQC2xHulkaRbA2+XQ4qiWSP2VjHBq7driaeUDRVzz66aWq3viCfYveJoJjkVVOx4wP0S WqkA7Ic1Adg6sE8KErdjLjPsbNxvyxLuFMYrncTNvM9yCe/h/njbOdwfzzgNiLvWsbWU9w5W 8yvFA04797fM5lQk400VrWbKGlFZ+DsPnnMUcOUb4HXw2G5tgicZQ4C4+9IF57wFedvqPurz CVv/jgLcQv9ubaFYbsSz1y97YNxv+xgi8cJi9MDwZn4zYrJqKTPs/CsA+1EPeC9n9Uk0G+at LPROjahxt+4XHo27dR/WNO7WPRI17tbdShNszdDL2Am7WNJcNAXR/CggM+zrFPB2s/qGorkb TUt5HyC5zaHxthErNr4uMJ1+YCmk4Qv+SBKNr949STSeM3rR07jfEhBf7iMT0Xqb0rjXC4jm Qq/nUAIr8PaT/rHQO7dx/BBWAF7uFDRux73Ya9wSR4rF7XikWPL4CMT9SpiBt7NSTRVT0Nu7 4IDTblDcAHazui70zj2Uv3xo3FD7Zk3jqzdVOO2SBHj7KicAr75SpcnTRpnh5VeqNN6GNNTb 2ZhT3nvN4QMUc0Vwy8xCxiWr70xNpz884P64HReA1wmaDBIHnF49/2s8SPStnsbLkpGBMXEF 0bz7gbhbdjbk7bZ6O8Bu9Q1We7vJpS5oZ0Nd3ZZbMmfoDLsXgF4Ep9PuMg2nvQt4hn2NBNHc KCAouauRKLnLwAKwuw9xapa9wul7Efz1+vMfPB5gWAplbmRzdHJlYW0KZW5kb2JqCnhyZWYK MCAxMwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwNDI4NzkgMDAwMDAgbiAKMDAwMDA0MjY4 MyAwMDAwMCBuIAowMDAwMDQyOTQxIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAw MDAwMDA2MyAwMDAwMCBuIAowMDAwMDEwNDc4IDAwMDAwIG4gCjAwMDAwMTA1NzIgMDAwMDAg biAKMDAwMDAwMDUzOCAwMDAwMCBuIAowMDAwMDEwNzAyIDAwMDAwIG4gCjAwMDAwNDIyOTIg MDAwMDAgbiAKMDAwMDAxMTQwNyAwMDAwMCBuIAowMDAwMDExNjIxIDAwMDAwIG4gCnRyYWls ZXIKPDwvU2l6ZSAxMwovUm9vdCA0IDAgUgo+PgpzdGFydHhyZWYKNDQ4NjkKJSVFT0Y= --------------060209060405000409050707-- From paul.hoffman@vpnc.org Mon Nov 25 09:18:15 2013 Return-Path: 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 3F1161ADF62; Mon, 25 Nov 2013 09:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 gRt4xaLfOPUY; Mon, 25 Nov 2013 09:18:14 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 240BF1ADF65; Mon, 25 Nov 2013 09:18:12 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rAPHHds8078190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Nov 2013 10:18:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <52938515.6070702@qti.qualcomm.com> Date: Mon, 25 Nov 2013 09:17:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52938515.6070702@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1822) Cc: "iab@iab.org" , The IESG , "json@ietf.org" Subject: Re: [Json] Ecma TC39 Comments on RFC 4727bis X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 17:18:15 -0000 On Nov 25, 2013, at 9:12 AM, Pete Resnick = wrote: > Barry and I received this liaison statement from the Ecma Secretary = General regarding the draft. The chairs and I will chat, we may consult = with the IESG and/or IAB, and then propose some text to the WG as a = response to the statement. As per RFC 4053, I'll also post this to the = Liaison Statements website for reference. I'll also send an = acknowledgment to the Secretary General that we have received the = message and are working on a response. >=20 > Please don't respond directly to this, and please let's hold off of = discussion of it on the list until the chairs and I get you some = proposed text. Thanks, Pete. I'm sure we can come up with some response wording and = then get the WG involved. > As the Hitchhiker's Guide says: "Don't Panic". Towel in hand. --Paul Hoffman= From derhoermi@gmx.net Mon Nov 25 14:48:16 2013 Return-Path: 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 9A7261AE06D for ; Mon, 25 Nov 2013 14:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 AcD4j8JxLO8G for ; Mon, 25 Nov 2013 14:48:15 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 097971AE06A for ; Mon, 25 Nov 2013 14:48:15 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.12.181]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MVedf-1W9ViL2ILn-00YzSx for ; Mon, 25 Nov 2013 23:48:14 +0100 From: Bjoern Hoehrmann To: json@ietf.org Date: Mon, 25 Nov 2013 23:48:16 +0100 Message-ID: <6fk7995rbhc7596p5a7jc4alcm8sr4d7cp@hive.bjoern.hoehrmann.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:2Od4+BaxpwXT0a5uGe8cejDl8Eclp+sQ6ANDh5XGaoK1xd9njSy LCdGNaD5LdGLxYfcBhaCkQyyH69gd3IRx1M7DFZ7eOoJ9ulxvCuqZsA9WA3hkZrfC1IwA92 CalCZo6r0yCUgN9COiJ4RONMx9plJpMmwS1flfEYQ47u7CAqRvN+sLEd01TzQOlPi6Vf1KW Cu9Buglt9oBjuiGGilEkQ== Subject: [Json] JSON extensions X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 22:48:16 -0000 Hi, In http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07#section-9 we still have "A JSON parser MAY accept non-JSON forms or extensions". Some have argued that if one adds extensions that one should not call the result JSON anymore, so I wanted to highlight this. Also, since the draft does not require parsers to reject unrecognised constructs, this "MAY" does not really add to the document. And note that ECMA-262 calls this out as a difference between RFC 4627 and the `JSON.parse(...)` API since the latter explicitly prohibits extensions. The IESG has asked for comments by today, by the way. regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From allen@wirfs-brock.com Mon Nov 25 16:29:31 2013 Return-Path: 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 303D91AE0E2 for ; Mon, 25 Nov 2013 16:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 d2_v_Vwgshp0 for ; Mon, 25 Nov 2013 16:29:29 -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 C3C7A1AE07D for ; Mon, 25 Nov 2013 16:29:29 -0800 (PST) Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.25]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Vl6Wn-000LjI-M8; Tue, 26 Nov 2013 00:29:22 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.64.236.244 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/KGUy44EV+jumqrIdjeXkAEB+jF6GXsvU= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-131--903340370 From: Allen Wirfs-Brock In-Reply-To: <52931A67.7010309@it.aoyama.ac.jp> Date: Mon, 25 Nov 2013 16:29:12 -0800 Message-Id: <0021FE1E-FA6D-4410-9CD8-FF3C2775D2A3@wirfs-brock.com> References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <52931A67.7010309@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1085) X-Mailman-Approved-At: Mon, 25 Nov 2013 17:40:08 -0800 Cc: John Cowan , Pete Cordell , Paul Hoffman , JSON WG , Henri Sivonen , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "www-tag@w3.org" , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 00:29:31 -0000 --Apple-Mail-131--903340370 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 25, 2013, at 1:37 AM, Martin J. D=FCrst wrote: >=20 >=20 > On 2013/11/23 1:54, Allen Wirfs-Brock wrote: >>=20 >>>=20 >>=20 >> 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. >=20 > 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. >=20 > Regards, Martin. It still seems pretty clear. Anything feed as input into an actual = parser for the JSON grammar as standardized by ECMA-404 must not contain = any U+feff code points other than as part of JSON string values. If the = application/json wire format chooses to to use BOMs, then they must be = removed before processing by a standard JSON parser. =46rom a JSON = parser prospect, I think that's pretty much all you need to say.=20 allen= --Apple-Mail-131--903340370 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


    On 2013/11/23 1:54, Allen Wirfs-Brock = wrote:



    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.

    It still = seems pretty clear.  Anything feed as input into an actual parser = for the JSON grammar as standardized by ECMA-404 must not contain any = U+feff code points other than as part of JSON string values.  If = the application/json wire format chooses to to use BOMs, then they must = be removed before processing by a standard JSON parser.   =46rom= a JSON parser prospect, I think that's pretty much all you need to = say. 

    allen
    = --Apple-Mail-131--903340370-- From petejson@codalogic.com Tue Nov 26 02:56:46 2013 Return-Path: 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 D03061AE1A2 for ; Tue, 26 Nov 2013 02:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 rzbfuekXmoZG for ; Tue, 26 Nov 2013 02:56:45 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id A34701AE1A7 for ; Tue, 26 Nov 2013 02:56:44 -0800 (PST) Received: (qmail 7192 invoked from network); 26 Nov 2013 10:56:23 +0000 Received: from host86-167-12-24.range86-167.btcentralplus.com (HELO codalogic) (86.167.12.24) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 26 Nov 2013 10:56:23 +0000 Message-ID: <01320F468A324337AF1784853F7C7E39@codalogic> From: "Pete Cordell" To: "Larry Masinter" References: <7404D1DCC5E84DC3B8F8CD300274962D@codalogic> <7468141ce23a4984a99486c70284ef72@BL2PR02MB307.namprd02.prod.outlook.com> X-Unsent: 1 Date: Tue, 26 Nov 2013 10:56:58 -0000 MIME-Version: 1.0 x-vipre-scanned: 008BA024005CB6008BA171 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: json@ietf.org Subject: Re: [Json] Wording on encoding; removing the table X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 10:56:47 -0000 ----- Original Message From: "Larry Masinter" > To: "Pete Cordell" > > " The transfer encoding > used to represent the characters on-the-wire is beyond the scope > of this document." > > On the contrary, it seems to me that this document is (or should be) > MAINLY ABOUT normatively establishing how JSON text is encoded > in an application/json message body "on the wire" -- something > ECMA 404 doesn't do. Maybe the MIME type description could say only UTF-8 with or without a BOM, but the RFC is now the JSON Data Interchange Format, not just the MIME type. I think the JSON Data Interchange Format suggests wider applicability and should allow wider choice of UTFs. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From hsivonen@hsivonen.fi Tue Nov 26 06:10:17 2013 Return-Path: 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 4A8221AE207 for ; Tue, 26 Nov 2013 06:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-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 bbNslNbDB-Gv for ; Tue, 26 Nov 2013 06:10:14 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BE9A21AE217 for ; Tue, 26 Nov 2013 06:10:14 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id wp18so5801189obc.2 for ; Tue, 26 Nov 2013 06:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hsivonen.fi; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JPuNIv+qkz782plFkCzxkpJpr5ohLmujKe0B4ZMfZrE=; b=BJ6KfEp+W/EG6CfLnYdAylHofUpZDMx8lr5jxQvZ5TQSc3E/mLpOYl3nuFDS2eTGlS Cch3nhlvv6Mqh7pAx8Z62Wxi6ACNQ/U+2h5aTpB7fRxFvOdkC9XVy2Ao9JD6Ynub5Smg 5wVH3TIAgOCj/5dNksV8uYw2nGoDExbsmq30A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JPuNIv+qkz782plFkCzxkpJpr5ohLmujKe0B4ZMfZrE=; b=XiAn53RoDjyg4DHc3jdEoNzbkUXVPL2VbbQhz0mIwJGLAiczJ/Og5pF5hOHMmMEIlv QDaY5K0S7lkK/jH3yzLn8wolSpuvwurnQENm5S69PFDFkQxLZqBFbQNlmojPcwaek5cm NBjTB4ysMaxL+YgmSK3W3r4ih24fbg8DgdSuUVppRtdgYv5kXyzXK3kLLtMNvnRqXw7n OrtdMdbDLgfO2xzcMJMxwSC8rfqbtycS7BOTriVhf1nC4rJ/DOgcLLsoSUCvjRk3T7BO CAtmzU+TlqivPDDNR4hJiqlqZUj815vb5sUmzK1NrJsZmmDvpAMZiE6tjxTNw5yBi5UE ah9A== X-Gm-Message-State: ALoCoQngrofv+cOJ2FgEYAsn4WfhkesEbKPrDezFEf2q1ufdDmJQBBIBc+bexvki4PacGW8JeDpP MIME-Version: 1.0 X-Received: by 10.182.219.197 with SMTP id pq5mr1507532obc.64.1385475014280; Tue, 26 Nov 2013 06:10:14 -0800 (PST) Received: by 10.182.119.130 with HTTP; Tue, 26 Nov 2013 06:10:14 -0800 (PST) In-Reply-To: <54E53D571E5E4589B2E9FA17DC816002@codalogic> References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> Date: Tue, 26 Nov 2013 16:10:14 +0200 Message-ID: From: Henri Sivonen To: Pete Cordell Content-Type: text/plain; charset=UTF-8 Cc: John Cowan , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , www-tag , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 14:10:17 -0000 On Fri, Nov 22, 2013 at 1:33 PM, Pete Cordell wrote: > Personally I think we have to be careful not to fall into the trap of > assuming that the only use-case for JSON will be in "to browser" > communications. I don't expect it to be the only use. > I'm hoping that for the IETFs purposes we'll be looking at > JSONs wider utility into broader areas, which may even include logging to > files and interprocess communication where there might be sensible reasons > to choose something other than UTF-8. What sensible reasons could there possibly be? The one reason for using UTF-16 is contrived. (Your JSON consists almost entirely of East Asian string literals with next to no JSON syntax itself, you are bandwidth-constrained and, magically, simultaneously so CPU-constrained that you can't use gzip.) For UTF-32 not even contrived reasons exist. (If you use shared-memory IPC between processes that use non-UTF-8 for representing Unicode strings, you shouldn't treat the exchange as happening via char* plus the encoding layer and the JSON MIME type but using char16_t* or char32_t* without the encoding layer involved. For example, if you JSONify data to communicate from Web Workers to the main thread, conceptually, the JSONification happens to Unicode strings--not to bytes, so the JSON RFC doesn't get involved.) On Fri, Nov 22, 2013 at 6:39 PM, John Cowan wrote: > Henri Sivonen scripsit: > >> Even if no one or approximately no one (outside test cases) actually >> emits JSON in UTF-32? > > How on earth would you know that? There exists no situation where using UTF-32 for interchange makes sense. I think proponents of craziness of the level of using UTF-32 for interchange should show evidence of existing crazy deployments instead of asking future implementers to support UTF-32 just because it wasn't possible to prove non-existence. On Fri, Nov 22, 2013 at 9:28 PM, Pete Cordell wrote: > 00 00 -- -- UTF-32BE > 00 xx -- -- UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 00 xx UTF-16LE > xx 00 xx -- UTF-16LE > xx xx -- -- UTF-8 I continue to strongly disapprove of non-BOM-based sniffing rules unless there's compelling evidence that such rules are needed in order to interoperate with bogus existing serializers. -- Henri Sivonen hsivonen@hsivonen.fi http://hsivonen.fi/ From markus.lanthaler@gmx.net Tue Nov 26 06:23:11 2013 Return-Path: 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 A544D1AE20B for ; Tue, 26 Nov 2013 06:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 QqjafjTCmp7y for ; Tue, 26 Nov 2013 06:23:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 033F61AE201 for ; Tue, 26 Nov 2013 06:23:10 -0800 (PST) Received: from Vostro3500 ([37.116.127.110]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M86PB-1VPXVF3RZ3-00vhZm for ; Tue, 26 Nov 2013 15:23:09 +0100 From: "Markus Lanthaler" To: References: <20131122221940.GD3655@localhost> <00a401cee853$777307c0$66591740$@lanthaler@gmx.net> In-Reply-To: Date: Tue, 26 Nov 2013 15:23:05 +0100 Message-ID: <027801ceeab3$066a5300$133ef900$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7oVGzDV3JWtdTcT8y6W93pPQgDCgCXmnIQ Content-Language: de X-Provags-ID: V03:K0:HjBxg3vMK/3PsvViHyGTObOkTGlzl3zSH5f6M8KJbR7lYkhtC4f 8kAlpZm3o2tfpEcNGRaYcC2zFQ+x9cYkMEpV17B2vQgLHnxqSCHQ9SZdUlQDQl++zaX5Y+K sIN0FDSrcPIwQDLEogCGeXeRcafCQ8SsJI4pMgmnMw4znTmpceXRaG4f5U3fjY5aLEBTsP8 ktwP7hJRhkaxlmHgTL4mQ== Subject: Re: [Json] First two characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 14:23:11 -0000 On Saturday, November 23, 2013 3:01 PM, Bjoern Hoehrmann wrote: > * Markus Lanthaler wrote: > >On Fri, Nov 22, 2013 at 07:59:36PM +0100, Bjoern Hoehrmann wrote: > >> Now that string literals can occur at the top level, ... > > > >Can they? When did we decide that? > > http://www.ietf.org/mail-archive/web/json/current/msg02040.html Thanks, I missed that. Could someone please explain how this doesn't break existing implementations relying on the fact that valid application/json documents are always objects or arrays at the top-level? -- Markus Lanthaler @markuslanthaler From cabo@tzi.org Tue Nov 26 06:37:31 2013 Return-Path: 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 5418B1AE218 for ; Tue, 26 Nov 2013 06:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 qT-G4kuUJNBP for ; Tue, 26 Nov 2013 06:37:30 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E1C301AE211 for ; Tue, 26 Nov 2013 06:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAQEbRox015366; Tue, 26 Nov 2013 15:37:27 +0100 (CET) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E61395ED; Tue, 26 Nov 2013 15:37:26 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <027801ceeab3$066a5300$133ef900$@lanthaler@gmx.net> Date: Tue, 26 Nov 2013 15:37:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <112F2DBE-7950-4F8E-B585-1024480125B2@tzi.org> References: <20131122221940.GD3655@localhost> <00a401cee853$777307c0$66591740$@lanthaler@gmx.net> <027801ceeab3$066a5300$133ef900$@lanthaler@gmx.net> To: Markus Lanthaler X-Mailer: Apple Mail (2.1822) Cc: JSON WG Subject: Re: [Json] First two characters X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 14:37:31 -0000 On 26 Nov 2013, at 15:23, Markus Lanthaler = wrote: > Could someone please explain how this doesn't break > existing implementations relying on the fact that valid = application/json > documents are always objects or arrays at the top-level? No, you can=92t. But given that this was unilaterally changed in the ECMA world already, = this breaking change may still be the right thing to do. (I don=92t = have a strong opinion either way, but the chairs have found WG consensus = to do this.) Gr=FC=DFe, Carsten From nico@cryptonector.com Tue Nov 26 07:27:11 2013 Return-Path: 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 396381ACCF6 for ; Tue, 26 Nov 2013 07:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 aYePu9LXEnAh for ; Tue, 26 Nov 2013 07:27:09 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id DA5531ACCE8 for ; Tue, 26 Nov 2013 07:27:08 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 971242005D905; Tue, 26 Nov 2013 07:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=aE2g+Akc/Vr9kX vNAFE4DSZXExs=; b=bpO0O6unccCmDfvYiBSNx+LJDT+unkkmK4FtWu/SGRAvW0 YourF6RlOdH5e+JSO5CCNMhWHWBhv5oCgR0OfecIh0V279VPtabZUDNWW3AhmlBd 8nWy7BCPz+OsiscNlPqKv0RmYdxAHjaPzqupljly/M2ohmePWcR2ru+C44fu8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 0B5522005D903; Tue, 26 Nov 2013 07:27:06 -0800 (PST) Date: Tue, 26 Nov 2013 09:27:05 -0600 From: Nico Williams To: Henri Sivonen Message-ID: <20131126152700.GN3655@localhost> References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: John Cowan , Pete Cordell , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , www-tag , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 15:27:11 -0000 On Tue, Nov 26, 2013 at 04:10:14PM +0200, Henri Sivonen wrote: > On Fri, Nov 22, 2013 at 1:33 PM, Pete Cordell wrote: > > I'm hoping that for the IETFs purposes we'll be looking at > > JSONs wider utility into broader areas, which may even include logging to > > files and interprocess communication where there might be sensible reasons > > to choose something other than UTF-8. > > What sensible reasons could there possibly be? I can't think of any either. UTF-32 is superficially appealing (O(1) indexing!) but it's only O(1) indexing by codepoint counts, not character counts so it's still lame and you pay for longer strings. It's possible that on some architectures / for some use cases it performs fabulously better than the alternatives, and though I doubt it, that would be a reason not to *forbid* the use of UTF-32. What we clearly don't have consensus for is requiring support of UTF-32. > There exists no situation where using UTF-32 for interchange makes > sense. I think proponents of craziness of the level of using UTF-32 > for interchange should show evidence of existing crazy deployments > instead of asking future implementers to support UTF-32 just because > it wasn't possible to prove non-existence. No, I think this is too much. If someone wants to use UTF-32 because they have numbers showing that for IPC and local processing it's faster, that might be compelling; let them. Anyways, I think we're focusing too hard on details that aren't terribly important. The "non-BOM-based sniffing rules" work and can be derived by any capable implementor whether stated or not by the RFC. > I continue to strongly disapprove of non-BOM-based sniffing rules > unless there's compelling evidence that such rules are needed in order > to interoperate with bogus existing serializers. I think it's fair to object to requiring sniffing, and I support not requiring it. I don't see anything wrong with leaving those in for those who want to include support for it. Nico -- From cowan@ccil.org Tue Nov 26 08:01:42 2013 Return-Path: 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 9BB821AD8F3 for ; Tue, 26 Nov 2013 08:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] 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 eKkqM3ASDYC7 for ; Tue, 26 Nov 2013 08:01:41 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B3CF21AD7C0 for ; Tue, 26 Nov 2013 08:01:40 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VlL4p-0004i9-Hd; Tue, 26 Nov 2013 11:01:27 -0500 Date: Tue, 26 Nov 2013 11:01:27 -0500 From: John Cowan To: Henri Sivonen Message-ID: <20131126160127.GE20755@mercury.ccil.org> References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Pete Cordell , Paul Hoffman , JSON WG , "Joe Hildebrand \(jhildebr\)" , www-tag , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 16:01:42 -0000 Henri Sivonen scripsit: > What sensible reasons could there possibly be? The fact that you (or even I) can't think of them doesn't mean they don't exist. There would be no sensible reason for me to write to you in Finnish: your command of written English is near-native, and my command of Finnish is zero. But it would be absurd of me to say that people should not communicate in Finnish because it harms interoperability. It so happens that I know that there are five million people cheerfully writing to each other in Finnish, under the impression that it is allowed. But even if I didn't happen to know that, the point would be the same. Now Finnish is a natural language, and JSON is not: it exists only by virtue of its definition. But that definition explains how to communicate in JSON, and anyone who adheres to it is communicating correctly. For us to chop their feet out from under them by saying that what they are doing does not count as JSON would be just as arbitrary as banning Finnish because almost nobody speaks it. We can say that we think it's a bad idea to use non-UTF-8 encodings in JSON, and that's as far as we can justly go. -- John Cowan Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz. --Calvin, giving Newton's First Law "in his own words" From cromis@gmail.com Tue Nov 26 09:19:10 2013 Return-Path: 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 29C481ADF30 for ; Tue, 26 Nov 2013 09:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-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 VDbblVtd49YF for ; Tue, 26 Nov 2013 09:19:08 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A0BF91ADF23 for ; Tue, 26 Nov 2013 09:19:08 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id um1so8413542pbc.20 for ; Tue, 26 Nov 2013 09:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=NlQ+uiHksN5jmIB5Ry9zK0+mPdDZoDEYq51kqU/ny28=; b=u88OF0gfK74x58CdYYyTn2NaA6xodKjR8qjxA2PtyhEEF3V3jUpKimtHKkmdI4d1rQ Qo35FRHQT414XEwY84FDztAo0kTuUNQ23IZNUpuzFLK6BXhMsnn0hw9B0Za0aAbHSY0g wU2Go9nmK9aNRt51ctbcVeMqcXJ6Is3FIzD/KoH4ElmigeBv+SctY2kdR1F48E9OIwDU eRYneWxevME5eX9b0omDGpwoVAJCSbtyzQknFNnyq8ycI4cWigSKfG0z12zsgeZC5qu/ G6aWjBwvFH0tzfVBiPB0b2pVvMliQnQJSTBRTLJaBNdYB7w01eZz4jDhDZgDWz5nWMJt eq9w== X-Received: by 10.66.197.164 with SMTP id iv4mr36215168pac.18.1385486348566; Tue, 26 Nov 2013 09:19:08 -0800 (PST) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.70.93.228 with HTTP; Tue, 26 Nov 2013 09:18:48 -0800 (PST) In-Reply-To: <20131126160127.GE20755@mercury.ccil.org> References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126160127.GE20755@mercury.ccil.org> From: Jacob Davies Date: Tue, 26 Nov 2013 09:18:48 -0800 X-Google-Sender-Auth: 9ECOgXSUJ3VbOzzW2jHhCE-FKCg Message-ID: To: John Cowan Content-Type: text/plain; charset=ISO-8859-1 Cc: Pete Cordell , Paul Hoffman , JSON WG , Henri Sivonen , "Joe Hildebrand \(jhildebr\)" , www-tag , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 17:19:10 -0000 The Finns can be verified to exist (or at least are a very convincing hoax), but I think there is a real question whether anyone actually uses anything other than UTF-8 with JSON. If nobody does, then support for UTF-16 and UTF-32 autodetection is pointless and at least potentially dangerous or buggy in the way that such features tend to be. On Tue, Nov 26, 2013 at 8:01 AM, John Cowan wrote: > Henri Sivonen scripsit: > >> What sensible reasons could there possibly be? > > The fact that you (or even I) can't think of them doesn't mean they > don't exist. There would be no sensible reason for me to write to you in > Finnish: your command of written English is near-native, and my command > of Finnish is zero. But it would be absurd of me to say that people > should not communicate in Finnish because it harms interoperability. > It so happens that I know that there are five million people cheerfully > writing to each other in Finnish, under the impression that it is allowed. > But even if I didn't happen to know that, the point would be the same. > > Now Finnish is a natural language, and JSON is not: it exists only by > virtue of its definition. But that definition explains how to communicate > in JSON, and anyone who adheres to it is communicating correctly. For us > to chop their feet out from under them by saying that what they are doing > does not count as JSON would be just as arbitrary as banning Finnish > because almost nobody speaks it. We can say that we think it's a bad idea > to use non-UTF-8 encodings in JSON, and that's as far as we can justly go. > > -- > John Cowan > Yakka foob mog. Grug pubbawup zink wattoom gazork. Chumble spuzz. > --Calvin, giving Newton's First Law "in his own words" > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nico@cryptonector.com Tue Nov 26 09:24:18 2013 Return-Path: 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 C98031ADF5E for ; Tue, 26 Nov 2013 09:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 WVNoJ5bd3qng for ; Tue, 26 Nov 2013 09:24:17 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3BD1ADF59 for ; Tue, 26 Nov 2013 09:24:17 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 089312005D10A; Tue, 26 Nov 2013 09:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ABVqv9vJ8vpT0P AHKRXQVuWLg60=; b=uOgvE4byiMzlW7PZy3/C6plAVt4s7kAUDd5MZVOYk15eB3 QA8pDmcO+9U/bN7n5ZMfH9Pyxbcw/lFI6EQAUMc+lggpUKJPcaPmQrXUJMMyTFxb g6TOP0iAKlW/QwfWWPei7muoVtd1gsaPZ4am3e0DonrpUUwQjgB04lrIwnJMk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id 995DF2005D106; Tue, 26 Nov 2013 09:24:15 -0800 (PST) Date: Tue, 26 Nov 2013 11:24:14 -0600 From: Nico Williams To: Jacob Davies Message-ID: <20131126172410.GC21240@localhost> References: <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126160127.GE20755@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: John Cowan , Pete Cordell , Paul Hoffman , JSON WG , Henri Sivonen , "Joe Hildebrand \(jhildebr\)" , www-tag , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 17:24:19 -0000 On Tue, Nov 26, 2013 at 09:18:48AM -0800, Jacob Davies wrote: > The Finns can be verified to exist (or at least are a very convincing > hoax), but I think there is a real question whether anyone actually > uses anything other than UTF-8 with JSON. If nobody does, then support > for UTF-16 and UTF-32 autodetection is pointless and at least > potentially dangerous or buggy in the way that such features tend to > be. There are human cultures with which we don't have enough contact to learn their languages. This is silly. We must not forbid the use of any other encodings than UTF-8. We must encourage the use of UTF-8 for interop by, for example, stating that only UTF-8 is known to interop well. We must not require encoding detection functionality in parsers. We must not forbid it either. We might need to say that encodings other than UTF-8/16/32 may not be reliably detected, therefore they are highly discouraged, even forbidden except where protocols specifically call for them. But really, we can't forbid the use of UTF-16/32, we can only require parser support for UTF-8. Nico -- From derhoermi@gmx.net Tue Nov 26 12:15:41 2013 Return-Path: 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 548251AE1A2 for ; Tue, 26 Nov 2013 12:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 SJeSf4BRZ_B2 for ; Tue, 26 Nov 2013 12:15:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE061AE000 for ; Tue, 26 Nov 2013 12:15:39 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.22.249]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MBaDy-1Vth2F2Uuk-00AU76 for ; Tue, 26 Nov 2013 21:15:38 +0100 From: Bjoern Hoehrmann To: Nico Williams Date: Tue, 26 Nov 2013 21:15:38 +0100 Message-ID: References: <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126160127.GE20755@mercury.ccil.org> <20131126172410.GC21240@localhost> In-Reply-To: <20131126172410.GC21240@localhost> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:+ZQWlfcAmhFrKU1EDzH8FXGHb4yN+c7FzEHbvyC67yRyqBGdZLy n99anLFPqqJEMCAOKw3sXRUqCQZVxRJppo4RCbD+JvnrfNqBYQu81HJ5a4F459g1EbIMO9m HvOBYf9cZIg2lhjQvZ6zFX9GnZUPm8mt7CSL5+Q195Q4Bcs7/mL1Nkpf5iHtfy9wy/y761p BJb8kMZiXB1irbJrAzmJw== Cc: es-discuss , www-tag , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 20:15:41 -0000 * Nico Williams wrote: >We must not require encoding detection functionality in parsers. We >must not forbid it either. We might need to say that encodings other >than UTF-8/16/32 may not be reliably detected, therefore they are highly >discouraged, even forbidden except where protocols specifically call for >them. When I pass a fully conforming UTF-8 encoded application/json entity to a fully conforming JSON parser I do not want the parser to do something funny like interpreting the document as if it were Windows-1252 encoded. I am amazed how many people here think a parser that does that should not be considered broken. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From julian.reschke@gmx.de Tue Nov 26 12:22:34 2013 Return-Path: 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 01AEF1AE069 for ; Tue, 26 Nov 2013 12:22:34 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 3fS3jeVeDBtG for ; Tue, 26 Nov 2013 12:22:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 563691AE010 for ; Tue, 26 Nov 2013 12:22:31 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MZOan-1W3uRP36U9-00LDkd for ; Tue, 26 Nov 2013 21:22:30 +0100 Message-ID: <52950304.8080403@gmx.de> Date: Tue, 26 Nov 2013 21:22:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Bjoern Hoehrmann , Nico Williams References: <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126160127.GE20755@mercury.ccil.org> <20131126172410.GC21240@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:N+uchVyi/qaoRK2Y07AY5pr/poKVoE25IytXJzyQof0yv3k3AVN qqL0BUWe4VEK9ANE3f+c28Hwnd1Iq70tFmVj+RfDBVR/a7M9lfAw9vQAdutUCsCzfsg5PyO cP50jIua1hyTHzz6N6+F86whtKNAUk1eVpPMPKu1MtNR7q0J227nxUYbD9/6cFKBQIZBf0k 0oQCiGCS73q38whFOT7KQ== Cc: JSON WG , www-tag , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 20:22:34 -0000 On 2013-11-26 21:15, Bjoern Hoehrmann wrote: > * Nico Williams wrote: >> We must not require encoding detection functionality in parsers. We >> must not forbid it either. We might need to say that encodings other >> than UTF-8/16/32 may not be reliably detected, therefore they are highly >> discouraged, even forbidden except where protocols specifically call for >> them. > > When I pass a fully conforming UTF-8 encoded application/json entity to > a fully conforming JSON parser I do not want the parser to do something > funny like interpreting the document as if it were Windows-1252 encoded. > I am amazed how many people here think a parser that does that should > not be considered broken. +1 From nico@cryptonector.com Tue Nov 26 14:00:45 2013 Return-Path: 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 EEDD11ADF95 for ; Tue, 26 Nov 2013 14:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mEBrNPAq5i9e for ; Tue, 26 Nov 2013 14:00:42 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBD81ADF7F for ; Tue, 26 Nov 2013 14:00:42 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 4A0972005D107; Tue, 26 Nov 2013 14:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=5jgEo/2Nr55kW9 rE7Xm/+HI5inI=; b=gkKx0R3ACOD1CPFg1hFEtm1Hs7FRzTohxQilpkURxJ/BOw TyzQ67CNa56KGFnMsRoFO6L1kca6C+aBeSgPYKCIG59yrqA7DmR/I5b9NrDP5QhI AiWgfLRD7eIS4pbJxNhBm8ok5K/nrfeUzvreDMY/P6mL6B7yDHZn92sj7/Ezg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id D9A832005D105; Tue, 26 Nov 2013 14:00:41 -0800 (PST) Date: Tue, 26 Nov 2013 16:00:41 -0600 From: Nico Williams To: Bjoern Hoehrmann Message-ID: <20131126220036.GG21240@localhost> References: <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126160127.GE20755@mercury.ccil.org> <20131126172410.GC21240@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: es-discuss , www-tag , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 22:00:45 -0000 On Tue, Nov 26, 2013 at 09:15:38PM +0100, Bjoern Hoehrmann wrote: > * Nico Williams wrote: > >We must not require encoding detection functionality in parsers. We > >must not forbid it either. We might need to say that encodings other > >than UTF-8/16/32 may not be reliably detected, therefore they are highly > >discouraged, even forbidden except where protocols specifically call for > >them. > > When I pass a fully conforming UTF-8 encoded application/json entity to > a fully conforming JSON parser I do not want the parser to do something > funny like interpreting the document as if it were Windows-1252 encoded. > I am amazed how many people here think a parser that does that should > not be considered broken. You missed the point. I'm outlining what we can and should do. We should strongly encourage UTF-8 (require it, even, for parsers). We should not forbid other encodings -- at least not UTF-16 nor UTF-32 -- though we might agree to say nothing about them. As to non-UTF encodings, well, think of something like the Korn Shell, with it's... very strange "compound variables", and consider something more like the Windows Power Shell. It might be awesome to have a Unix shell that uses JSON as a [far] superior alternative to the Korn Shell's compound variable disaster. But you see, if you have any non-Unicode locales, how would such a shell encode its JSON values? Obviously: not in any UTF (except, maybe, UTF-7). It'd not be hard for such a shell to handle non-Unicode locales just fine. Not that such a shell's JSON parser should auto-detect encodings (no way), but you know well enough that there's text documents lying around in all sorts of encodings without the encoding metadata being recorded anywhere. If you wanted to forbid non-Unicode, non-UTF encodings, then you'd be preventing such a shell, and for what reason? If you only mean that auto-detection of encoding should not even be mentioned, I'm fine with that, and I've already said so earlier. (Of course I'd love to see non-Unicode locales disappear, but I don't think that's in the cards. And yes, I had a Unix Power-like shell in mind when I wrote the text you quoted.) Nico -- From cabo@tzi.org Tue Nov 26 15:00:48 2013 Return-Path: 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 94D621AE021 for ; Tue, 26 Nov 2013 15:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 kZb_MypymgRb for ; Tue, 26 Nov 2013 15:00:43 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 156031AE026 for ; Tue, 26 Nov 2013 15:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAQN0aM8028967; Wed, 27 Nov 2013 00:00:36 +0100 (CET) Received: from [192.168.217.105] (p548937CC.dip0.t-ipconnect.de [84.137.55.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 163F985C; Wed, 27 Nov 2013 00:00:34 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <20131126220036.GG21240@localhost> Date: Wed, 27 Nov 2013 00:00:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95E46767-DBBF-489F-83BD-80BEC697C999@tzi.org> References: <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126160127.GE20755@mercury.ccil.org> <20131126172410.GC21240@localhost> <20131126220036.GG21240@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1822) Cc: JSON WG , Bjoern Hoehrmann , www-tag , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 23:00:49 -0000 On 26 Nov 2013, at 23:00, Nico Williams wrote: > But you see, if you have any non-Unicode locales, how would such a = shell > encode its JSON values? =20 In UTF-8? > Obviously: not in any UTF (except, maybe, > UTF-7). =20 I don=92t see the obviousness here. The locale is irrelevant for the encoding of JSON values. > If you wanted to forbid non-Unicode, non-UTF encodings, then you'd be > preventing such a shell,=20 This is a very strange argument. If your application needs a JSON-like interchange format that is encoded = in Windows-1252, just go ahead and create that, it=92s not hard. Just = don=92t call it JSON. (I think KSON is still free except as a radio = station call sign.:-) Nothing here is prevented by keeping JSON useful = as an interchange format. Gr=FC=DFe, Carsten From nico@cryptonector.com Tue Nov 26 15:07:39 2013 Return-Path: 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 EEB621AE03C for ; Tue, 26 Nov 2013 15:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 R88Dd2TZqfYr for ; Tue, 26 Nov 2013 15:07:36 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 0483D1AE048 for ; Tue, 26 Nov 2013 15:07:36 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id DB6C410059; Tue, 26 Nov 2013 15:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=1zz20NtlcLgSGW zxn4z7A4pZQgQ=; b=FuwHPVqjLNu6w0NvVfyrq3uiN/7j+W12X5OniGrse9CO+P rFhXfIdsNgNXBRVzQX5rJuDYMjUzUC8QWp8J2cTOQHF7sLMB1qI79gV8O6BT5Zxx kti1AtkLgrsta0oQBoyzJe83qWYRtkCk529g88VpQj3/j4EA61uo5Jw/bIYA4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 682D510058; Tue, 26 Nov 2013 15:07:35 -0800 (PST) Date: Tue, 26 Nov 2013 17:07:34 -0600 From: Nico Williams To: Carsten Bormann Message-ID: <20131126230730.GH21240@localhost> References: <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126160127.GE20755@mercury.ccil.org> <20131126172410.GC21240@localhost> <20131126220036.GG21240@localhost> <95E46767-DBBF-489F-83BD-80BEC697C999@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95E46767-DBBF-489F-83BD-80BEC697C999@tzi.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: JSON WG , Bjoern Hoehrmann , www-tag , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 23:07:39 -0000 On Wed, Nov 27, 2013 at 12:00:33AM +0100, Carsten Bormann wrote: > [...] Did you actually disagree with any of my recommendations? Please point out which. I'll repeat them here to make it easy: We should strongly encourage UTF-8 (require it, even, for parsers). We should not forbid other encodings -- at least not UTF-16 nor UTF-32 -- though we might agree to say nothing about them. Do you want to say anything about other encodings? What would that be? And why? Nico -- From cabo@tzi.org Tue Nov 26 15:20:34 2013 Return-Path: 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 836321AE054 for ; Tue, 26 Nov 2013 15:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 kAAKfCZjsbLY for ; Tue, 26 Nov 2013 15:20:33 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 77A621AE052 for ; Tue, 26 Nov 2013 15:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAQNKSMV007067; Wed, 27 Nov 2013 00:20:28 +0100 (CET) Received: from [192.168.217.105] (p548937CC.dip0.t-ipconnect.de [84.137.55.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4EAB0865; Wed, 27 Nov 2013 00:20:27 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <20131126230730.GH21240@localhost> Date: Wed, 27 Nov 2013 00:20:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8F52BEE2-F477-4C5A-AD7E-3FCB5765706C@tzi.org> References: <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126160127.GE20755@mercury.ccil.org> <20131126172410.GC21240@localhost> <20131126220036.GG21240@localhost> <95E46767-DBBF-489F-83BD-80BEC697C999@tzi.org> <20131126230730.GH21240@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1822) Cc: es-discuss , Bjoern Hoehrmann , www-tag , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 23:20:34 -0000 On 27 Nov 2013, at 00:07, Nico Williams wrote: > Do you want to say anything about other encodings? What would that = be? JSON is encoded in UTF-8. There is no need to discuss JSON in other encodings, because it wouldn=92t= be JSON. (And no, I see no need to handle UTF-16LE, UTF-16BE, UTF-32LE or = UTF-32BE in any special way, even if RFC 4627 was written at a time when = it still seemed useful to pay them lip service. But I recognize that = there appears to be WG consensus to keep these corpses on life support, = maybe because UTF-16 is the internal encoding of the programming = language that gave JSON its name.) Gr=FC=DFe, Carsten From plh@w3.org Tue Nov 26 14:31:38 2013 Return-Path: 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 692CE1ADF7C for ; Tue, 26 Nov 2013 14:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 BQ-_dv8DmhQK for ; Tue, 26 Nov 2013 14:31:34 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id BC9181ADFA6 for ; Tue, 26 Nov 2013 14:31:33 -0800 (PST) Received: from 30-5-213.wireless.csail.mit.edu ([128.30.5.213] helo=[10.0.2.15]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VlRAI-00025W-I6; Tue, 26 Nov 2013 17:31:30 -0500 Message-ID: <1385505093.3251.101.camel@chacal> From: Philippe Le Hegaret To: Mark Nottingham , paul.hoffman@vpnc.org, mamille2@cisco.com, json@ietf.org Date: Tue, 26 Nov 2013 17:31:33 -0500 Organization: World Wide Web Consortium Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailman-Approved-At: Tue, 26 Nov 2013 15:34:34 -0800 Cc: Tim Berners-Lee , Daniel Appelquist , Peter Linss , Yves Lafon , public-ietf-w3c , Wendy Seltzer Subject: [Json] Concerns from the W3C Technical Architecture Group regarding JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 22:31:39 -0000 Dear All, The W3C Technical Architecture Group has a concern regarding the ongoing coordination of the industry standardization work on JSON. JSON is a key integration technology for Web applications and a key data interchange format for the Web. The current state of affairs, where there are now two different JSON specifications which may be normatively referenced, one developed in ECMA as ECMA-404 and one developed in IETF as RFC 4627 and in last call as RFC 4627bis is not ideal and could lead to confusion in the industry. Because the two specs vary slightly, we believe this could lead to interoperability issues. For example, today there are JSON parsers (conforming to ECMA-404) that can parse "42" (a JSON document consisting of a single integer). There are also parsers (conforming to RFC 4627/draft-ietf-json-rfc4627bis-07) that cannot parse "42" today, but they can be meaningfully upgraded to do so too. This would not break applications using those parsers, unless they depend on parsing "42" as an error, which is a far more unlikely scenario than parsing it as 42 given precedence. Regardless of the historical reasons for the current situation, the W3C TAG believes that having one definition of JSON would be beneficial for the Web and for the wider community of JSON implementors and JSON consuming and producing applications. We suggest that the IETF JSON working group should re-enter discussions with ECMA TC39 in order to facilitate aligning RFC 4627bis with the current ECMA-404 specification. Thank you, Philippe Le Hegaret, IETF co-team contact for the W3C From mnot@mnot.net Tue Nov 26 14:35:34 2013 Return-Path: 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 3E3121AE012 for ; Tue, 26 Nov 2013 14:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-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 HJIOGHCApjOA for ; Tue, 26 Nov 2013 14:35:32 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id A731C1AE011 for ; Tue, 26 Nov 2013 14:35:32 -0800 (PST) Received: from [192.168.0.22] (unknown [203.45.170.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0927222E256; Tue, 26 Nov 2013 17:35:23 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Mark Nottingham In-Reply-To: <1385505093.3251.101.camel@chacal> Date: Wed, 27 Nov 2013 09:34:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <1B42C7AD-3C31-4C1E-814F-65D744DD1DB4@mnot.net> References: <1385505093.3251.101.camel@chacal> To: =?windows-1252?Q?Philippe_Le_H=E9garet?= X-Mailer: Apple Mail (2.1822) X-Mailman-Approved-At: Tue, 26 Nov 2013 15:34:34 -0800 Cc: Peter Linss , Daniel Appelquist , Tim Berners-Lee , Paul Hoffman , JSON WG , mamille2 , Yves Lafon , public-ietf-w3c , Wendy Seltzer Subject: Re: [Json] Concerns from the W3C Technical Architecture Group regarding JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 22:35:34 -0000 Thanks, Philippe. I=92ve forwarded to the IESG and my IAB contact for = their information. Cheers, On 27 Nov 2013, at 9:31 am, Philippe Le Hegaret wrote: > Dear All, >=20 > The W3C Technical Architecture Group has a concern regarding the = ongoing > coordination of the industry standardization work on JSON. JSON is a > key integration technology for Web applications and a key data > interchange format for the Web. The current state of affairs, where > there are now two different JSON specifications which may be = normatively > referenced, one developed in ECMA as ECMA-404 and one developed in = IETF > as RFC 4627 and in last call as RFC 4627bis is not ideal and could = lead > to confusion in the industry. Because the two specs vary slightly, we > believe this could lead to interoperability issues. >=20 > For example, today there are JSON parsers (conforming to ECMA-404) = that > can parse "42" (a JSON document consisting of a single integer). There > are also parsers (conforming to RFC = 4627/draft-ietf-json-rfc4627bis-07) > that cannot parse "42" today, but they can be meaningfully upgraded to > do so too. This would not break applications using those parsers, = unless > they depend on parsing "42" as an error, which is a far more unlikely > scenario than parsing it as 42 given precedence. >=20 > Regardless of the historical reasons for the current situation, the = W3C > TAG believes that having one definition of JSON would be beneficial = for > the Web and for the wider community of JSON implementors and JSON > consuming and producing applications. We suggest that the IETF JSON > working group should re-enter discussions with ECMA TC39 in order to > facilitate aligning RFC 4627bis with the current ECMA-404 = specification. >=20 > Thank you, >=20 > Philippe Le Hegaret, > IETF co-team contact for the W3C >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From nico@cryptonector.com Tue Nov 26 16:11:35 2013 Return-Path: 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 31AE01AE070 for ; Tue, 26 Nov 2013 16:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 BwOYBg2dOUZN for ; Tue, 26 Nov 2013 16:11:33 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 083E31AE06D for ; Tue, 26 Nov 2013 16:11:33 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 6FDEF598065; Tue, 26 Nov 2013 16:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=lqfhBaOEMxsuKyABXHCraKUboy0=; b=v6DNbueIs46 VZMrpnNGxNW3e6PRMEj4jl2XsqbqeeR0HOkUraq8qquDoWIZIygwR7xFpHg1sxzG 2pvEKpkPpOKdOnNfN0o/WN7TpAbebq3qLduKGVFkhbRjouGVv8SOyY9o3lFozJ8w yANPM7vUJqGJcXgWFWdqYhbdtpuCeoeA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id EB3BB598060; Tue, 26 Nov 2013 16:11:31 -0800 (PST) Date: Tue, 26 Nov 2013 18:11:31 -0600 From: Nico Williams To: Carsten Bormann Message-ID: <20131127001127.GI21240@localhost> References: <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126160127.GE20755@mercury.ccil.org> <20131126172410.GC21240@localhost> <20131126220036.GG21240@localhost> <95E46767-DBBF-489F-83BD-80BEC697C999@tzi.org> <20131126230730.GH21240@localhost> <8F52BEE2-F477-4C5A-AD7E-3FCB5765706C@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8F52BEE2-F477-4C5A-AD7E-3FCB5765706C@tzi.org> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Cc: es-discuss , Bjoern Hoehrmann , www-tag , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 00:11:35 -0000 On Wed, Nov 27, 2013 at 12:20:25AM +0100, Carsten Bormann wrote: > On 27 Nov 2013, at 00:07, Nico Williams wrote: > > Do you want to say anything about other encodings? What would that b= e? >=20 > JSON is encoded in UTF-8. >=20 > There is no need to discuss JSON in other encodings, because it > wouldn=E2=80=99t be JSON. Thanks. My opinion as to MIME contexts: I'm not opposed to saying that the application/json media type requires UTF-8. Others have objected, and I believe the WG consensus to be that the application/json media type allows all of UTF-8/16/32. I believe we should settle for an interop note noting that UTF-8 has the best interoperability, and a recommendation that UTF-8 be used. My opinion as to non-MIME contexts: I'm not opposed to recommending that JSON texts for interchange in non-MIME contexts be encoded in UTF-8, and I'm not opposed to requiring that use of any other encoding be expressed as metadata. I do object to requiring that under all circumstances -even in non-MIME contexts- UTF-8 must be used. > (And no, I see no need to handle UTF-16LE, UTF-16BE, UTF-32LE or > UTF-32BE in any special way, even if RFC 4627 was written at a time > when it still seemed useful to pay them lip service. But I recognize > that there appears to be WG consensus to keep these corpses on life > support, maybe because UTF-16 is the internal encoding of the > programming language that gave JSON its name.) Right, that appears to be the consensus, and more than that, it seems extremely unlikely to change. Assuming *that*, what are you willing to settle for? Nico PS: Back to my hypo... If my hypothetical JSON-using shell were to escape all non-ASCII characters in JSON string values, then encode the JSON text in UTF-8, then convert the result to the current locale's codeset (doing the reverse to parse), and the resulting texts either never leak to other locales, why should anyone care? Most (but not all) non-Unicode locales use ASCII-compatible codesets, thus the result would be "proper" JSON texts in most cases anyways... As to why one might want to do that: because JSON texts are... *text*, i.e., editable in your favorite $EDITOR, readable with your favorite $PAGER, and so on. It might be a problem if such texts leaked outside that locale, but we already have that problem in spades, and no JSON parser would be called upon to try to auto-detect any encodings other than UTF-8/16/32. From derhoermi@gmx.net Tue Nov 26 16:14:03 2013 Return-Path: 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 724D11AE070 for ; Tue, 26 Nov 2013 16:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 zmTLo-31JSby for ; Tue, 26 Nov 2013 16:14:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 118241AD698 for ; Tue, 26 Nov 2013 16:14:01 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.19.159]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0M6874-1VSOgX0XYQ-00y5e6 for ; Wed, 27 Nov 2013 01:14:00 +0100 From: Bjoern Hoehrmann To: Nico Williams Date: Wed, 27 Nov 2013 01:14:00 +0100 Message-ID: References: <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126160127.GE20755@mercury.ccil.org> <20131126172410.GC21240@localhost> <20131126220036.GG21240@localhost> In-Reply-To: <20131126220036.GG21240@localhost> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:1UeF2ZVmXwsTOT0oYDwYzb5158LbIPYHeF2rIuQhlV1/evN852j /AV3xluOlVf02uzf73drEigAfm/hD01ZLna09oKHb0ijG1kucdkZCK0wF9ORDHl6UjM3MSa 7fx9SqTdHCXnrjiWxVTU7g3J1grYNguEMfLTeUadnnivwDL23fWxBh+TI6YpXuF/4ob20OR g4IUc+WWuJUWgWSLAAabQ== Cc: es-discuss , www-tag , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 00:14:03 -0000 * Nico Williams wrote: >On Tue, Nov 26, 2013 at 09:15:38PM +0100, Bjoern Hoehrmann wrote: >> * Nico Williams wrote: >> >We must not require encoding detection functionality in parsers. We >> >must not forbid it either. We might need to say that encodings other >> >than UTF-8/16/32 may not be reliably detected, therefore they are highly >> >discouraged, even forbidden except where protocols specifically call for >> >them. >> >> When I pass a fully conforming UTF-8 encoded application/json entity to >> a fully conforming JSON parser I do not want the parser to do something >> funny like interpreting the document as if it were Windows-1252 encoded. >> I am amazed how many people here think a parser that does that should >> not be considered broken. > >You missed the point. "We must require encoding detection functionality in parsers. We must forbid encoding detection functionality beyond that. We must say that encodings other than UTF-8/16/32 are forbidden in any and all cases." is how I would modify what you said above (with some caveats). Note that I am talking about labeled sequences of octets, application/ json entities, not paintings on a cave wall that look similar to JSON text in a strange font. In a labeled sequence of octets I can tell for sure whether there are invisible characters in it if I know the en- coding. There are two forms to consider. One is the labeled sequence of octets that we call "application/json entity". The other is a sequence of Uni- code scalar values. That is the alphabet of the ABNF grammar in the specification. If you have anything else, then the specification does not apply to your situation. >If you wanted to forbid non-Unicode, non-UTF encodings, then you'd be >preventing such a shell, and for what reason? If you only mean that >auto-detection of encoding should not even be mentioned, I'm fine with >that, and I've already said so earlier. Above I said that there are two forms to consider. Encoding detection is what allows us to convert the "application/json entity" form into the "sequence of Unicode scalar values" form. We need the latter form in order to apply the ABNF grammar. Imagine you receive this: HTTP/1.1 200 OK Content-Type: application/json ... ABCD... There would be at least two specifications that apply here, the HTTP and the application/json specification. Would you like them to say that you are on your own, "ABCD..." could mean anything? I would like them to say "ABCD..." is an array with three times the integer zero, like `[0,0,0]`. I can build robust software based on that. I cannot build robust software based on "well, maybe it's EBCDIC? Have you tried GB 18030? UTF-7 might be worth a try otherwise. Are you sure this matters at all?" -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From nico@cryptonector.com Tue Nov 26 16:39:51 2013 Return-Path: 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 65F1B1AE0CB for ; Tue, 26 Nov 2013 16:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 4iwEA7092K5Q for ; Tue, 26 Nov 2013 16:39:50 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9851AE0A4 for ; Tue, 26 Nov 2013 16:39:50 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id F15933B805B; Tue, 26 Nov 2013 16:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=qACmxpGXYl5HGR IogCbbeaHOpDo=; b=vX5r40iwdDW9Eh7zXx0yHZcVP+jk9Deq619uKOQFGHU5Eg hIU1iCeAbcqY+vCDLcEecuzR6DBz7r3A+dJ1+siwJd7lBvELa1UnkUJ/MRr79h0J 4QfAH5p7sLXn/pxjmQhsxGSAHYAUYn6zU9ShXTTHPZY4Muk/WluZCMatwWtMY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id 9B7EE3B8005; Tue, 26 Nov 2013 16:39:49 -0800 (PST) Date: Tue, 26 Nov 2013 18:39:49 -0600 From: Nico Williams To: Bjoern Hoehrmann Message-ID: <20131127003945.GK21240@localhost> References: <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126160127.GE20755@mercury.ccil.org> <20131126172410.GC21240@localhost> <20131126220036.GG21240@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: es-discuss , www-tag , JSON WG 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 00:39:51 -0000 On Wed, Nov 27, 2013 at 01:14:00AM +0100, Bjoern Hoehrmann wrote: > HTTP/1.1 200 OK > Content-Type: application/json > ... > > ABCD... > > There would be at least two specifications that apply here, the HTTP > and the application/json specification. Would you like them to say > that you are on your own, "ABCD..." could mean anything? [...] Absolutely not, and I didn't say that either. The application/json media type absolutely has to be in a UTF, and preferably UTF-8. > I cannot build robust software based on "well, maybe it's EBCDIC? > Have you tried GB 18030? UTF-7 might be worth a try otherwise. Are > you sure this matters at all?" That is not even remotely what I want. Either you misunderstood me or I wasn't specific or clear enough. Either way, I think it should be clear as of my last message (though you might find things there to disagree with). Nico -- From sayrer@gmail.com Tue Nov 26 23:58:00 2013 Return-Path: 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 823151AE24E; Tue, 26 Nov 2013 23:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 MTj7-qnx24XD; Tue, 26 Nov 2013 23:57:59 -0800 (PST) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8971ADEA6; Tue, 26 Nov 2013 23:57:58 -0800 (PST) Received: by mail-qe0-f43.google.com with SMTP id 2so6916125qeb.2 for ; Tue, 26 Nov 2013 23:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CFXdat3BTZ1Jk0K1DKjKLAwYgAWenF3DJAKAR0uKEyQ=; b=vgf2eYet+gikiAigyVeJkPVbX29eKnxHhPL0QRQ113vG0gcYnp7SUnyIrvpUXfOzRg EDuZb9Nfp2B2r9Zv75qtXvylm6WYwvBWzdVy2vM/AB+t8ugI+fu7ZqPUGvjnrdFlIvKM OrSCB1YRwwLmNsdG1qun7Kq/r6YpJpCBLboqouKtQQxrfM5TLc0Kxl+3zqtVV4kJH1sC YA+zAwgINk/4zqVGNW2jR375my6N7T49oyEhV3XTGncQOMcNHQVQcAMJudXJf9/74cJ9 Kdc/tLRsYrbJhXOPSHa1SzYO1eKMjAj/L7jeqYEtjd3Vo6DQtRVsJrMY75Cb6sM97pxu xn5A== MIME-Version: 1.0 X-Received: by 10.224.21.197 with SMTP id k5mr1765014qab.62.1385539078428; Tue, 26 Nov 2013 23:57:58 -0800 (PST) Received: by 10.140.101.40 with HTTP; Tue, 26 Nov 2013 23:57:58 -0800 (PST) Date: Tue, 26 Nov 2013 23:57:58 -0800 Message-ID: From: R S To: "json@ietf.org" , IESG Content-Type: multipart/alternative; boundary=047d7bdc8cd897b87504ec23f429 Subject: [Json] JSON document (revision of RFC 4627) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 07:58:01 -0000 --047d7bdc8cd897b87504ec23f429 Content-Type: text/plain; charset=ISO-8859-1 The IETF should not publish this document. - Rob --047d7bdc8cd897b87504ec23f429 Content-Type: text/html; charset=ISO-8859-1 The IETF should not publish this document.

    - Rob
    --047d7bdc8cd897b87504ec23f429-- From cabo@tzi.org Wed Nov 27 00:30:55 2013 Return-Path: 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 BF1CF1AC7F2; Wed, 27 Nov 2013 00:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 nmZdIByqysVT; Wed, 27 Nov 2013 00:30:53 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 05BAB1AE246; Wed, 27 Nov 2013 00:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAR8Uk1u015522; Wed, 27 Nov 2013 09:30:46 +0100 (CET) Received: from [192.168.217.140] (p548937CC.dip0.t-ipconnect.de [84.137.55.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ABCB1984; Wed, 27 Nov 2013 09:30:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (11B554a) In-Reply-To: Date: Wed, 27 Nov 2013 09:30:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FC0ABB3-270B-4B56-BB27-7179D07485EF@tzi.org> References: To: R S Cc: IESG , "json@ietf.org" Subject: Re: [Json] JSON document (revision of RFC 4627) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 08:30:56 -0000 > The IETF should not publish this document. Of course not, it needs to be fixed first. Or are there any other reasons for this considered opinion you can divulge? Gr=C3=BC=C3=9Fe, Carsten From hsivonen@hsivonen.fi Wed Nov 27 05:14:14 2013 Return-Path: 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 8AA041AE1C9 for ; Wed, 27 Nov 2013 05:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-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 y4rGLfLuo_1M for ; Wed, 27 Nov 2013 05:14:12 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADC61AE1B8 for ; Wed, 27 Nov 2013 05:14:12 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id gq1so7330034obb.17 for ; Wed, 27 Nov 2013 05:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hsivonen.fi; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PYv3RaLxTo5EIKThPd4OAksHSyoX8gHbYHImlsBpXuA=; b=M+faFXjco2rmdG8PZsmNLCp2hqrI3QEkfzwapB541Il9Pd74UNoEImNRkdkt4W7v9O kpSENdxf75R+B8TbaH7tKO8eoC6dmnWAgwvxMJlJex21SjyOF/xQ7nS+EZ0fy/ll0nZO AifCQzkTT6jpbRqFpixOYEDOKHSAcdrWdg/r0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PYv3RaLxTo5EIKThPd4OAksHSyoX8gHbYHImlsBpXuA=; b=R4oyeMY+PaD4BS6oTiPkHePammxFEpl0ptXPLPoI7biSg+/g/BwEMupLYU5Z+BrVjX lI9izEzNwQjpBkNbE1BHlL7dUzCaoik9ajK1i0A1mPWxDiZXowD++7iM4otetF3HMzXr EqP2pFD8izhr/JwYaecbs4kBq8wnTApr1IZo3NIxldrWhtimOvfboW3zxTf0UuJ/hwcA WjqOVXIEI5M7YMLwEzMIjDRA1uAtEjxLIp+MCBuUgclkXuzdkCktcWPfQ1C55+wVcs2v vR6hAOCo1kfC2RNEvqyL56Mb5t13g047aFscTGG5k8WLyHhxAmWkp/K75Leipe82FuBa u2zg== X-Gm-Message-State: ALoCoQl3UAgDUx9NR25Qlw0j1Db8PPqhTRAOfNBKnpwDMg6mZXuaLXbPOXBb63GO6SKvVGdX2NPc MIME-Version: 1.0 X-Received: by 10.182.74.137 with SMTP id t9mr38218obv.79.1385558051831; Wed, 27 Nov 2013 05:14:11 -0800 (PST) Received: by 10.182.119.130 with HTTP; Wed, 27 Nov 2013 05:14:11 -0800 (PST) In-Reply-To: <20131126152700.GN3655@localhost> References: <8413609C8A86497F856897AF2AA24960@codalogic> <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126152700.GN3655@localhost> Date: Wed, 27 Nov 2013 15:14:11 +0200 Message-ID: From: Henri Sivonen To: www-tag Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: John Cowan , Pete Cordell , Paul Hoffman , JSON WG , tbray@textuality.com, "Joe Hildebrand \(jhildebr\)" , Nico Williams , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 13:14:15 -0000 On Tue, Nov 26, 2013 at 5:27 PM, Nico Williams wrot= e: > I can't think of any either. UTF-32 is superficially appealing (O(1) > indexing!) but it's only O(1) indexing by codepoint counts, not > character counts so it's still lame and you pay for longer strings. It doesn't matter for the interchange encoding, which is a different issue from in-RAM string representation (where indeed O(1) indexing by code point is overrated but appeals to people who have heard about astral characters but haven't yet considered considered that due to combining characters, they can't treat treat code units independently of the adjacent code units anyway). > No, I think this is too much. If someone wants to use UTF-32 because > they have numbers showing that for IPC and local processing it's faster, > that might be compelling; let them. If someone wants to use UTF-32 for local shared-memory IPC, the communicating parties are tightly-coupled and don't need a standard to authorize whatever they are doing. Standards are for loosely-coupled communication where there aren't bilateral arrangements between the communicating parties. (Also, UTF-32 doesn't make sense even for local IPC if it happens over a socket rather than over shared memory.) > Anyways, I think we're focusing too hard on details that aren't terribly > important. The "non-BOM-based sniffing rules" work and can be derived > by any capable implementor whether stated or not by the RFC. Has anyone tested whether a substantial proportion of the existing implementations already support the non-BOM-based sniffing rules? That is, can the rules be relied on with existing implementations? >> I continue to strongly disapprove of non-BOM-based sniffing rules >> unless there's compelling evidence that such rules are needed in order >> to interoperate with bogus existing serializers. > > I think it's fair to object to requiring sniffing, and I support not > requiring it. I don't see anything wrong with leaving those in for > those who want to include support for it. Optional features are a trap. They are used to get the appearance of consensus when people who are oppose to misfeatures are told that they don't need to implement them. However, when some implementations start emitting syntax that exercises optional features (or someone writes test cases just to smugly point out the lack of support for optional features), everyone ends up having to implement optional features in order to be compatible. On Tue, Nov 26, 2013 at 6:01 PM, John Cowan wrote: > Henri Sivonen scripsit: > >> What sensible reasons could there possibly be? > > The fact that you (or even I) can't think of them doesn't mean they > don't exist. You and I have a pretty good idea of Unicode stuff. If we can't think of sensible reasons and others in the discussion haven't seen UTF-32 (or UTF-16) JSON in the wild, either, we should have enough confidence to say that UTF-8 is enough and not suggest that future implementors waste implementation and QA effort on UTFs that don't make sense for interchange. The notion that in theory, maybe, someone might use a non-UTF-8 encoding for something, even if there's no data to support such conjecture, is the source of a lot of harmful inertia around character encodings. > There would be no sensible reason for me to write to you in > Finnish: your command of written English is near-native, and my command > of Finnish is zero. But it would be absurd of me to say that people > should not communicate in Finnish because it harms interoperability. > It so happens that I know that there are five million people cheerfully > writing to each other in Finnish, under the impression that it is allowed= . > But even if I didn't happen to know that, the point would be the same. > > Now Finnish is a natural language, and JSON is not: it exists only by > virtue of its definition. But that definition explains how to communicat= e > in JSON, and anyone who adheres to it is communicating correctly. For us > to chop their feet out from under them by saying that what they are doing > does not count as JSON would be just as arbitrary as banning Finnish > because almost nobody speaks it. We can say that we think it's a bad ide= a > to use non-UTF-8 encodings in JSON, and that's as far as we can justly go= . This is the bad analogy for several reasons: * Banning a particular layout of bits among equally expressive alternatives is not the same thing as banning someone's native natural language. * Finnish has uses other than test cases for the sake of test cases or XSS exploits. * Communication in Finnish can actually be shown to happen in practice. * It would be unreasonable to suggest that everyone ought to support the receipt of Finnish communication in addition to supporting the receipt of English communication. * Accepting your analogy leads not only to supporting UTF-32 but also to supporting various non-UTF encodings, which would be even worse than suggesting that UTF-16 and UTF-32 be supported in addition to UTF-8. On Fri, Nov 22, 2013 at 6:39 PM, Tim Bray wrote: > I=E2=80=99ve been using JSON for quite a few years, but hardly ever in ei= ther 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 scenario= s, > it would be seen as wildly inappropriate to use anything but UTF-8; I=E2= =80=99ve > never actually seen anything else. In practice, it would be very unlikel= y > for anyone to deploy UTF-16 or any other non-UTF-8 flavor in a non-browse= r > scenario. Right. > Having said that, I=E2=80=99m still, hundreds of messages later, not 100%= sure what > our draft should say about BOMs :( When not considering JSON specifically, it is unusual to use BOMless UTF-16 (unusual even if the use of UTF-16 is assumed; it is itself unusual) and in the context of other textual formats, BOMless UTF-16 is a pain. It seems to me if support for UTF-16 (or UTF-32) is retained, it would be good to test a bunch of existing implementations (that section 11 of the draft mentions) to see how they behave with BOMful and BOMless input. Of course, such testing takes work, so banning UTF-16 and UTF-32 would avoid such work. :-) --=20 Henri Sivonen hsivonen@hsivonen.fi http://hsivonen.fi/ From cowan@ccil.org Wed Nov 27 09:23:01 2013 Return-Path: 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 C845C1ADF69 for ; Wed, 27 Nov 2013 09:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] 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 TB3aGwH4ufFZ for ; Wed, 27 Nov 2013 09:22:59 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B7B691AD79D for ; Wed, 27 Nov 2013 09:22:59 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Vlip9-0005XO-Il; Wed, 27 Nov 2013 12:22:51 -0500 Date: Wed, 27 Nov 2013 12:22:51 -0500 From: John Cowan To: Henri Sivonen Message-ID: <20131127172251.GB29489@mercury.ccil.org> References: <20131120223305.GB5476@mercury.ccil.org> <20131121165615.GA12138@mercury.ccil.org> <54E53D571E5E4589B2E9FA17DC816002@codalogic> <20131126152700.GN3655@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Pete Cordell , Paul Hoffman , JSON WG , tbray@textuality.com, "Joe Hildebrand \(jhildebr\)" , Nico Williams , www-tag , es-discuss 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 17:23:02 -0000 Henri Sivonen scripsit: > > I think it's fair to object to requiring sniffing, and I support not > > requiring it. I don't see anything wrong with leaving those in for > > those who want to include support for it. > > Optional features are a trap. No doubt. But what's stated in the RFC is given as a matter of fact, with no MUST, SHOULD, or even MAY. Since we have adopted a change which makes it no longer factual, we should IMO revise it so it is again factual, and leave it at that. > The notion that in theory, maybe, someone might use a non-UTF-8 > encoding for something, Not "might use", but "may already be using". > * Accepting your analogy leads not only to supporting UTF-32 but also > to supporting various non-UTF encodings, which would be even worse > than suggesting that UTF-16 and UTF-32 be supported in addition to > UTF-8. They are already banned by the SHALL in section 3. > Of course, such testing takes work, so banning UTF-16 and UTF-32 would > avoid such work. :-) Banning unpaired surrogates, non-integers, etc. etc. would have saved us work too. -- John Cowan http://ccil.org/~cowan Micropayment advocates mistakenly believe that efficient allocation of resources is the purpose of markets. Efficiency is a byproduct of market systems, not their goal. The reasons markets work are not because users have embraced efficiency but because markets are the best place to allow users to maximize their preferences, and very often their preferences are not for conservation of cheap resources. --Clay Shirky From cabo@tzi.org Wed Nov 27 12:22:58 2013 Return-Path: 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 BD9FB1AC441 for ; Wed, 27 Nov 2013 12:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 iSOMd0oDia-p for ; Wed, 27 Nov 2013 12:22:57 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5F11C1ADFFF for ; Wed, 27 Nov 2013 12:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rARKL3cX004334; Wed, 27 Nov 2013 21:21:03 +0100 (CET) Received: from [192.168.217.105] (p54891F61.dip0.t-ipconnect.de [84.137.31.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 90F4EB0; Wed, 27 Nov 2013 21:21:02 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann X-Priority: 3 In-Reply-To: <87FBA1C2000449EBBED94BDB0485829F@codalogic> Date: Wed, 27 Nov 2013 21:20:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> To: Pete Cordell X-Mailer: Apple Mail (2.1822) Cc: JSON WG Subject: Re: [Json] ***SPAM*** 5.294 (5) UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 20:22:59 -0000 On 27 Nov 2013, at 21:07, Pete Cordell wrote: > UTF-8 with BOM Why would we add tolerance for BOMs after a decade of living very well = without them? Gr=FC=DFe, Carsten From nico@cryptonector.com Wed Nov 27 12:54:15 2013 Return-Path: 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 AF7881ADFFF for ; Wed, 27 Nov 2013 12:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] 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 XcGWKXK2tX65 for ; Wed, 27 Nov 2013 12:54:13 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id B69AD1ADFFD for ; Wed, 27 Nov 2013 12:54:13 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 577982005D909 for ; Wed, 27 Nov 2013 12:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=DhnIfMlAT/nagOah74U4 wXBkRpg=; b=TUr3BUPb5BaaBgV4Lm1n6KyM3BKv1X0nNTdmV63JwgkoWFgqoj/v uB43byk67dhM2sZNyOxwshIBLF/abwGYP3aYDa6LRvc9rtIjHnUtu7YTAtChgFX3 fmLpyUPTWPpth8ypFPJFfefR7MArKbubeainCbhuxy7Y0pv/OhtMDFQ= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id F369E2005D908 for ; Wed, 27 Nov 2013 12:54:12 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id y10so5567317wgg.12 for ; Wed, 27 Nov 2013 12:54:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l+Dj2cfpho2yFiUXOkO+6aAr43CG17oyy+7snB9JyZA=; b=HuPNin1O+uUGIOGjDCzGlPwXyQATqP24hs3WIneSIWjWs4luf8I3KJGNC02aWp+SGb ZIDOsCNXb+wv3iGoMARLXWu0C8pyUWx+PW5LQdFMj8VThu9Mu82Rcam4i2orbbgmh/nj WOJZ6IiWgLoGeuG+tmqDB0zPLbMgoy18trmufgmwG/XRvygJhd0YOOAddOv1oMLpktVa imet3MeuB0dNz3MoNIJBBKjsQ+xmt8xvnBdfOWXvA60ZL/c1OtUHuZstWmo+RnL2T4Ru yYaJfJ1V2NKzUVtHZqKnbVJDcjosZswYyLw4MQQuEhgqP6FEj40d0XQ8IqPk9vIeMqyj Fy0w== MIME-Version: 1.0 X-Received: by 10.180.12.70 with SMTP id w6mr4706953wib.4.1385585651047; Wed, 27 Nov 2013 12:54:11 -0800 (PST) Received: by 10.216.151.136 with HTTP; Wed, 27 Nov 2013 12:54:10 -0800 (PST) In-Reply-To: <87FBA1C2000449EBBED94BDB0485829F@codalogic> References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> Date: Wed, 27 Nov 2013 14:54:10 -0600 Message-ID: From: Nico Williams To: Pete Cordell Content-Type: text/plain; charset=UTF-8 Cc: JSON WG Subject: Re: [Json] ***SPAM*** 5.294 (5) UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 20:54:15 -0000 There's no need for BOMs when using UTF-8 -- there's no case where a multi-byte UTF-8 codepoint encoding would have more than one ordering of its bytes. BOMs are only of interest for UTF-16 and UTF-32. We don't need BOMs for UTF-16-/UTF-32-encoded JSON texts either because having the first character of a JSON text be an ASCII character is sufficient to permit detection of the text's byte order. Nico -- From petejson@codalogic.com Wed Nov 27 12:54:20 2013 Return-Path: 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 A78A21AE139 for ; Wed, 27 Nov 2013 12:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 4rmonStp6TPH for ; Wed, 27 Nov 2013 12:54:19 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 5106E1AE11E for ; Wed, 27 Nov 2013 12:54:19 -0800 (PST) Received: (qmail 1259 invoked from network); 27 Nov 2013 20:53:58 +0000 Received: from host86-167-12-24.range86-167.btcentralplus.com (HELO codalogic) (86.167.12.24) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 27 Nov 2013 20:53:54 +0000 Message-ID: <7209315EBB2F4DA1928B26C6B36191AF@codalogic> From: "Pete Cordell" To: "Carsten Bormann" References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> X-Unsent: 1 Date: Wed, 27 Nov 2013 20:55:41 -0000 MIME-Version: 1.0 x-vipre-scanned: 07D61DDB005CEA07D61F28 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: JSON WG Subject: Re: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 20:54:20 -0000 ----- Original Message From: "Carsten Bormann" >On 27 Nov 2013, at 21:07, Pete Cordell wrote: >> UTF-8 with BOM > Why would we add tolerance for BOMs after a decade of living very well > without them? Microsoft's editor development team's opinion may differ on that. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From petejson@codalogic.com Wed Nov 27 13:19:37 2013 Return-Path: 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 240D61ADFB1 for ; Wed, 27 Nov 2013 13:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.537 X-Spam-Level: *** X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 1Ij5W_FgKaMO for ; Wed, 27 Nov 2013 13:19:36 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id B15B21ADFE4 for ; Wed, 27 Nov 2013 13:19:35 -0800 (PST) Received: (qmail 1602 invoked from network); 27 Nov 2013 21:19:14 +0000 Received: from host86-167-12-24.range86-167.btcentralplus.com (HELO codalogic) (86.167.12.24) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 27 Nov 2013 21:19:14 +0000 Message-ID: <8FFA65BA9ACB45F9BFEECC205C7FAF30@codalogic> From: "Pete Cordell" To: "Nico Williams" References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> X-Unsent: 1 Date: Wed, 27 Nov 2013 21:21:03 -0000 MIME-Version: 1.0 x-vipre-scanned: 07ED573B005CEA07ED5888 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: JSON WG Subject: Re: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 21:19:37 -0000 ----- Original Message From: "Nico Williams" > There's no need for BOMs when using UTF-8 -- there's no case where a > multi-byte UTF-8 codepoint encoding would have more than one ordering > of its bytes. > > BOMs are only of interest for UTF-16 and UTF-32. We don't need BOMs > for UTF-16-/UTF-32-encoded JSON texts either because having the first > character of a JSON text be an ASCII character is sufficient to permit > detection of the text's byte order. A number of editors on Windows want to insert a UTF-8 BOM at the start of a file to differentiate it from Windows cp1252 etc. It's important to be pragmatic, not just theoretically correct. A little leeway here could make some developers' lives much easier and avoid a few pointless gotchas. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From cabo@tzi.org Wed Nov 27 13:39:03 2013 Return-Path: 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 7B8EE1ADFE4 for ; Wed, 27 Nov 2013 13:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 pSitY7aQQiC2 for ; Wed, 27 Nov 2013 13:39:02 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1042B1ADED9 for ; Wed, 27 Nov 2013 13:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rARLcwtc007819; Wed, 27 Nov 2013 22:38:58 +0100 (CET) Received: from [192.168.217.105] (p54891F61.dip0.t-ipconnect.de [84.137.31.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5AFDDEF; Wed, 27 Nov 2013 22:38:58 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann X-Priority: 3 In-Reply-To: <8FFA65BA9ACB45F9BFEECC205C7FAF30@codalogic> Date: Wed, 27 Nov 2013 22:38:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D24653D-C98B-4FDE-801D-9759FBD696FF@tzi.org> References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> <8FFA65BA9ACB45F9BFEECC205C7FAF30@codalogic> To: Pete Cordell X-Mailer: Apple Mail (2.1822) Cc: JSON WG Subject: Re: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 21:39:03 -0000 On 27 Nov 2013, at 22:21, Pete Cordell wrote: > A number of editors on Windows want to insert a UTF-8 BOM at the start = of a file to differentiate it from Windows cp1252 etc. It's important = to be pragmatic, not just theoretically correct. A little leeway here = could make some developers' lives much easier and avoid a few pointless = gotchas. You can be pragmatic all you want in your code. Don=92t forget to skip = comments, accept tabs and newlines in strings, skip trailing commas, = automatically close unbalanced delimiters, and support lots of other = non-JSON things people will type up in these editors. Retrofitting hundreds of production JSON decoder implementations with = BOM tolerance is a non-starter. If JSON is to be useful as an interchange format for small devices, we = have to work towards removing fluff, not adding it. =20 The only reasonable move towards reality here would be getting rid of = the illusion of UTF-16/UTF-32 support. Gr=FC=DFe, Carsten From tsaloranta@gmail.com Wed Nov 27 15:40:54 2013 Return-Path: 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 2514E1ADFA6 for ; Wed, 27 Nov 2013 15:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 O-3CvHfJW9t2 for ; Wed, 27 Nov 2013 15:40:52 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 44DE21ADF7C for ; Wed, 27 Nov 2013 15:40:52 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hq4so106485wib.15 for ; Wed, 27 Nov 2013 15:40:51 -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=U52eRvaSoXlT/LpFHFTGYymJg2B54mXQTMHE7HJ9QlE=; b=iQU1xj1FG8s9G5s5ITJu+6Vyk1RUli6cnrGinreSmTs7p6tHkn0hYgqYnog0gXfaRB QjM33Mh0zHxkPT/Fqv6mcsWNHpL4geEaNmeQketdfBfQXUc7VWEV4sf9RKLF4Ey7Z/NT Tq5l6iua6t+77qGFtuOHn5MfxlxhW4R2JQTuJHfeIDYx1FHzVLFIyZe6p/d5yC02rlFB zhokkvRfDvrM9u8btoUJ2fQ1WHGrL9ofGTJJl/n23MvuJWvq7yj/3KYE24IXqiAbAIJj N8NMz9cySa/RMff5ynZ34vwUR19a7cuCSssAg9mxNbfpHdQDZY88tWWMInE04nCzU8jx EUOg== MIME-Version: 1.0 X-Received: by 10.194.219.1 with SMTP id pk1mr17028589wjc.36.1385595651077; Wed, 27 Nov 2013 15:40:51 -0800 (PST) Received: by 10.227.61.196 with HTTP; Wed, 27 Nov 2013 15:40:50 -0800 (PST) In-Reply-To: <6D24653D-C98B-4FDE-801D-9759FBD696FF@tzi.org> References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> <8FFA65BA9ACB45F9BFEECC205C7FAF30@codalogic> <6D24653D-C98B-4FDE-801D-9759FBD696FF@tzi.org> Date: Wed, 27 Nov 2013 15:40:50 -0800 Message-ID: From: Tatu Saloranta To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c1a2f095bd9704ec312055 Cc: Pete Cordell , JSON WG Subject: Re: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 23:40:54 -0000 --001a11c1a2f095bd9704ec312055 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 1:38 PM, Carsten Bormann wrote: > On 27 Nov 2013, at 22:21, Pete Cordell wrote: > > > A number of editors on Windows want to insert a UTF-8 BOM at the start > of a file to differentiate it from Windows cp1252 etc. It's important to > be pragmatic, not just theoretically correct. A little leeway here could > make some developers' lives much easier and avoid a few pointless gotchas= . > > You can be pragmatic all you want in your code. Don=92t forget to skip > comments, accept tabs and newlines in strings, skip trailing commas, > automatically close unbalanced delimiters, and support lots of other > non-JSON things people will type up in these editors. > > Retrofitting hundreds of production JSON decoder implementations with BOM > tolerance is a non-starter. > Perhaps implementors of JSON decoders should have done better job to begin with and support BOMs. XML parsers do this, good JSON libs do as well. I feel very little sympathy towards dozens of toy implementations that have been hacked together with little care towards actual interoperability. And this knowing exactly how much effort goes into supporting above-mentioned features; done that. Same goes for UTF-16 and even UTF-32 support; those were explicitly spelled out in JSON specification, and at this point I find it little bit ridiculous that it is possible to both claim "no one should do BOMs since they were not discussed in the spec" AND "no one ever supported UTF-16 anyway". -+ Tatu +- --001a11c1a2f095bd9704ec312055 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

    = On Wed, Nov 27, 2013 at 1:38 PM, Carsten Bormann <cabo@tzi.org> w= rote:
    On 27 Nov 2013, at 22:21, = Pete Cordell <petejson@codalog= ic.com> wrote:

    > A number of editors on Windows want to insert a UTF-8 BOM at the start= of a file to differentiate it from Windows cp1252 etc. =A0It's importa= nt to be pragmatic, not just theoretically correct. =A0A little leeway here= could make some developers' lives much easier and avoid a few pointles= s gotchas.

    You can be pragmatic all you want in your code. =A0Don=92t forget to = skip comments, accept tabs and newlines in strings, skip trailing commas, = =A0automatically close unbalanced delimiters, and support lots of other non= -JSON things people will type up in these editors.

    Retrofitting hundreds of production JSON decoder implementations with BOM t= olerance is a non-starter.


    Perhaps implementors of JSON decoders = should have done better job to begin with and support BOMs. XML parsers do = this, good JSON libs do as well.
    I feel very little sympathy = towards dozens of toy implementations that have been hacked together with l= ittle care towards actual interoperability. And this knowing exactly how mu= ch effort goes into supporting above-mentioned features; done that.

    Same goes for UTF-16 and even UT= F-32 support; those were explicitly spelled out in JSON specification, and = at this point I find it little bit ridiculous that it is possible to both c= laim "no one should do BOMs since they were not discussed in the spec&= quot; AND "no one ever supported UTF-16 anyway".

    -+ Tatu +-

    --001a11c1a2f095bd9704ec312055-- From tbray@textuality.com Wed Nov 27 16:13:42 2013 Return-Path: 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 D50711AE01A for ; Wed, 27 Nov 2013 16:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Lc1ioE5mpnN4 for ; Wed, 27 Nov 2013 16:13:41 -0800 (PST) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id 133821AE013 for ; Wed, 27 Nov 2013 16:13:40 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id x11so5439814vbb.34 for ; Wed, 27 Nov 2013 16:13:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fAcbBKAw/W9zP8br9rJ7JmKighsJaezqSZ4z5Q7Svyc=; b=UaGl0yb9tZf70JkGsY4RIPkyG0a1zNB8mj6f78y98Im0qbIXtTOhZVWH2L4jr1Thup WRuOQ+gUNXt4cS3K9v4/z8fBpauG+KyK05DkLNDGGBsa5UWH2IS2oOORs7hr5HfAHsmu sdzV/lMI4OcrXe/r1irEoztWR7yQ7qPt4YdY3GfRtblJA+HJtLJDPN1Ozuf31OBa2ZM5 Hh+xSoDcS4KwYPtsI8FDvJ/P3RRqHTq9XS5oBogm3CdJXYlHDubLZjfquMwFPTgOjq7g 1pkYpfqGGSSUlS9cSD6xSqdEwaU1s+/PHFWCe1HNQaI9iee21UFDogH5v5gOEcRRtWLg 9Q8g== X-Gm-Message-State: ALoCoQloZhiDHPpl2m20LNYrACR96H8HAvDLtUYHB/Y6B2DOdKxWSM0D7HOmMvRXyAP1L77Z5lPj MIME-Version: 1.0 X-Received: by 10.52.164.203 with SMTP id ys11mr1768506vdb.37.1385597620098; Wed, 27 Nov 2013 16:13:40 -0800 (PST) Received: by 10.220.198.199 with HTTP; Wed, 27 Nov 2013 16:13:40 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Wed, 27 Nov 2013 16:13:40 -0800 Message-ID: From: Tim Bray To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=001a11c2cc40f2e76104ec319516 Cc: es-discuss , IETF Discussion , "www-tag@w3.org" , JSON WG Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 00:13:43 -0000 --001a11c2cc40f2e76104ec319516 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To do this, I think the draft requires these changes: - Remove the trailing section of section 1.2, starting with =E2=80=9CECMAsc= ript 5.1 enumerates...=E2=80=9D [because the difference no longer exists] - In section 2: -- remove =E2=80=9CA JSON text is a serialized object or array.=E2=80=9D -- Insert: =E2=80=9CA JSON text is a serialized value. Note that certain p= revious specifications of JSON constrained a JSON text to be an object or an array. Implementations which generate only objects or arrays where a JSON text is called for will be interoperable in the sense that all implementations will accept these as conforming JSON texts.=E2=80=9D -- Change the JSON-text production to read: JSON-text =3D value On Fri, Nov 22, 2013 at 10:21 AM, Matt Miller (mamille2) wrote: > There appears to be consensus to change JSON-text to allow for any JSON > value -- not just object / array -- while noting that object or array as > the top-level is the most interoperable. > > We will ask the Document Editor to make this change to > draft-ietf-json-rfc4627bis. > > > - Paul Hoffman and Matt Miller > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a11c2cc40f2e76104ec319516 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    To do this, I think the draft requires these changes:=C2= =A0

    - Remove the trailing section of section 1.2, starti= ng with =E2=80=9CECMAscript 5.1 enumerates...=E2=80=9D [because the differe= nce no longer exists]

    - In section 2:

    -- remove =E2= =80=9CA JSON text is a serialized object or array.=E2=80=9D

    <= /div>
    -- Insert: =E2=80=9CA JSON text is a serialized value. =C2=A0Note= that certain previous specifications of JSON constrained a JSON text to be= an object or an array. =C2=A0Implementations which generate only objects o= r arrays where a JSON text is called for will be interoperable in the sense= that all implementations will accept these as conforming JSON texts.=E2=80= =9D

    -- Change the JSON-text production to read:
    <= br>
    JSON-text =C2=A0=3D value


    <= br>



    On Fri, Nov 22, 2013 at 10:21 AM, Matt Miller (mamille2) = <mamille2@cisco.= com> wrote:
    There appears to be consensus to change JSON-text to allow for any JSON val= ue -- not just object / array -- while noting that object or array as the t= op-level is the most interoperable.

    We will ask the Document Editor to make this change to draft-ietf-json-rfc4= 627bis.


    - Paul Hoffman and Matt Miller


    _______________________________________________
    json mailing list
    json@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/json


    --001a11c2cc40f2e76104ec319516-- From slightlyoff@google.com Wed Nov 27 17:01:03 2013 Return-Path: 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 34CF31AE073 for ; Wed, 27 Nov 2013 17:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 y6MuS_LBnx9d for ; Wed, 27 Nov 2013 17:01:01 -0800 (PST) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 16B401AE069 for ; Wed, 27 Nov 2013 17:01:00 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id w5so173438qac.20 for ; Wed, 27 Nov 2013 17:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7+NsX+VtV6X4f5LBjFwEpbkkYOy6GgOBo2ofq3pfvzQ=; b=eEwLJ9NJiSn97R8ikAVuxIBiLTu7Jl4QRhuzEve51plruyl637B5KQMO0pokzy+K7c X8Ru+/zt6oj7eoc3gJuBut0MNo1qSCWgOVZKyBtKlo0s1Ia4UWVNIgyO/CHcce9/k0iQ 4v51y7KTB91fVmC4EgABeEULlocjtvZZ6h6tUcbKSvB94Le7qsMmFsZ0Y/KXGScWpDOo v5ohe9nF+4VYN2U2VxErMMapr+/MTLjMpccFZ5vrZJcUwiFFSU6u0m9eq357ui0nXvkK IzMRHS0V6b8IaZ7BQNVMKi4srthYIrk2v72t87ac4oQ3TrKzWde13noN6p+xQdcLgWtL snLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7+NsX+VtV6X4f5LBjFwEpbkkYOy6GgOBo2ofq3pfvzQ=; b=joPR14E7z3Flp+S78UUo+w6/hYHyymXIed7FUx0g8p82c8ApZjdPVHFyIVGrN4B5Nu Bi+mwEH0O8WufizyVNFRdeS92dJTBc1bTg3UU2zTpKktTcC44IQGdTbQGrl0iepJIJls MxvWEQBUUiHfJ+0Xj3TnXG/8/pIF7a/PzhhOYM5VfIrv5jPOz1xAL3OkNNJG4ubaPaJn WVRroVtGqO6uYq1QsxOaSlYS54naMixajPv/yRZNPRt3y0v4//5gk/mTiSGb7hKK4qMg O34AAHjSjslhgQl3Chh/lFclB2GTkMJbIZaszGvzhMxV6cy8X76PrwxY+6bk8HbIspSw USDg== X-Gm-Message-State: ALoCoQmJBlWGbHkPifBe5j7Rln7CA0ysHbfu/1uF//ca+w7yri5MjriJ+fuIGDkBTJDw1ihY2lugcjLY4w7WovcuvkcZpT3QrMFCUn2N4PA9038DOSwGzLTnaPppx3xRjgOVZbKzaMAJfii2lEqV9swZ8npZSujVD0dQ9wWhi3iHx8bhdXm06gQIcacy36w7vUO9jZDz95+I X-Received: by 10.49.25.16 with SMTP id y16mr72043010qef.20.1385600460119; Wed, 27 Nov 2013 17:01:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.138.195 with HTTP; Wed, 27 Nov 2013 17:00:30 -0800 (PST) In-Reply-To: References: From: Alex Russell Date: Wed, 27 Nov 2013 17:00:30 -0800 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=047d7b62224439fd9d04ec323f68 X-Mailman-Approved-At: Wed, 27 Nov 2013 19:22:30 -0800 Cc: es-discuss , JSON WG , IETF Discussion , "www-tag@w3.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 01:01:03 -0000 --047d7b62224439fd9d04ec323f68 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Will you also be citing ECMA-404 normatively to avoid this sort of divergence in the future? On Wed, Nov 27, 2013 at 4:13 PM, Tim Bray wrote: > To do this, I think the draft requires these changes: > > - Remove the trailing section of section 1.2, starting with =93ECMAscript > 5.1 enumerates...=94 [because the difference no longer exists] > > - In section 2: > > -- remove =93A JSON text is a serialized object or array.=94 > > -- Insert: =93A JSON text is a serialized value. Note that certain previ= ous > specifications of JSON constrained a JSON text to be an object or an arra= y. > Implementations which generate only objects or arrays where a JSON text = is > called for will be interoperable in the sense that all implementations wi= ll > accept these as conforming JSON texts.=94 > > -- Change the JSON-text production to read: > > JSON-text =3D value > > > > > > > On Fri, Nov 22, 2013 at 10:21 AM, Matt Miller (mamille2) < > mamille2@cisco.com> wrote: > >> There appears to be consensus to change JSON-text to allow for any JSON >> value -- not just object / array -- while noting that object or array as >> the top-level is the most interoperable. >> >> We will ask the Document Editor to make this change to >> draft-ietf-json-rfc4627bis. >> >> >> - Paul Hoffman and Matt Miller >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> > --047d7b62224439fd9d04ec323f68 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    Will you also be citing ECMA-404 normatively to avoid this= sort of divergence in the future?


    =
    On Wed, Nov 27, 2013 at 4:13 PM, Tim Bray <t= bray@textuality.com> wrote:
    To do this, I think the dra= ft requires these changes:=A0

    - Remove the trailing sect= ion of section 1.2, starting with =93ECMAscript 5.1 enumerates...=94 [becau= se the difference no longer exists]

    - In section 2:

    -- remove =93A= JSON text is a serialized object or array.=94

    -- = Insert: =93A JSON text is a serialized value. =A0Note that certain previous= specifications of JSON constrained a JSON text to be an object or an array= . =A0Implementations which generate only objects or arrays where a JSON tex= t is called for will be interoperable in the sense that all implementations= will accept these as conforming JSON texts.=94

    -- Change the JSON-text production to read:
    <= br>
    JSON-text =A0=3D value



    =



    On Fri, Nov 22, 2013 at 10:21 AM, Matt Miller (mamille2) = <mamille2@cisco.= com> wrote:
    There appears to be consensus to change JSON-text to allow for any JSON val= ue -- not just object / array -- while noting that object or array as the t= op-level is the most interoperable.

    We will ask the Document Editor to make this change to draft-ietf-json-rfc4= 627bis.


    - Paul Hoffman and Matt Miller


    _______________________________________________
    json mailing list
    json@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/json



    --047d7b62224439fd9d04ec323f68-- From paul.hoffman@vpnc.org Wed Nov 27 19:29:25 2013 Return-Path: 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 355D31AE094; Wed, 27 Nov 2013 19:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 N2MzrYOTWtuk; Wed, 27 Nov 2013 19:29:24 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAD01AC828; Wed, 27 Nov 2013 19:29:24 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rAS3TJGu020742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Nov 2013 20:29:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: Date: Wed, 27 Nov 2013 19:29:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92E7AA8E-F77C-4552-B463-D65703576AB9@vpnc.org> References: To: Alex Russell X-Mailer: Apple Mail (2.1822) Cc: JSON WG , IETF Discussion , "www-tag@w3.org" , es-discuss Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 03:29:25 -0000 On Nov 27, 2013, at 5:00 PM, Alex Russell = wrote: > Will you also be citing ECMA-404 normatively to avoid this sort of = divergence in the future? If you believe that ECMA-404 will change in the future, that would = indicate that ECMA might break interoperability with current = implementations, even for what they perceive as "good reasons". In = general, the IETF tries not to have its long-lived standards normatively = latch on to moving targets for this very reason. Even when other SDOs = have assured us that they will not make backwards-incompatible changes, = they have done so anyway (cue the Klensin-esqe theme music...), and that = has caused serious interoperability problems for the IETF specs. --Paul Hoffman= From cowan@ccil.org Wed Nov 27 19:49:45 2013 Return-Path: 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 46E9A1AE0EF; Wed, 27 Nov 2013 19:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] 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 TV1DuoJQwYL5; Wed, 27 Nov 2013 19:49:43 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 87DF11AE0AD; Wed, 27 Nov 2013 19:49:43 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Vlsbl-0001pp-BF; Wed, 27 Nov 2013 22:49:41 -0500 Date: Wed, 27 Nov 2013 22:49:41 -0500 From: John Cowan To: Paul Hoffman Message-ID: <20131128034941.GK29489@mercury.ccil.org> References: <92E7AA8E-F77C-4552-B463-D65703576AB9@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92E7AA8E-F77C-4552-B463-D65703576AB9@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: es-discuss , Alex Russell , IETF Discussion , "www-tag@w3.org" , JSON WG Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 03:49:45 -0000 Paul Hoffman scripsit: > If you believe that ECMA-404 will change in the future, that > would indicate that ECMA might break interoperability with current > implementations, even for what they perceive as "good reasons". In > general, the IETF tries not to have its long-lived standards normatively > latch on to moving targets for this very reason. Even when other SDOs > have assured us that they will not make backwards-incompatible changes, > they have done so anyway (cue the Klensin-esqe theme music...), and > that has caused serious interoperability problems for the IETF specs. Binding specifically to the first edition of ECMA-404 would resolve that problem. Binding to a specific edition doesn't work so well with Unicode, but that is because Unicode is a special case: it expands its coverage in successive editions to ever-larger portions of the world of writing systems. It would have been impossible to do the whole thing at once, unlike even the largest ordinary technical standard. ECMA-404 is not in that league. -- Not to perambulate John Cowan the corridors http://www.ccil.org/~cowan during the hours of repose in the boots of ascension. --Sign in Austrian ski-resort hotel From cabo@tzi.org Wed Nov 27 19:51:25 2013 Return-Path: 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 6A0181AE0EF; Wed, 27 Nov 2013 19:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 HuL2Rkoa5u2Z; Wed, 27 Nov 2013 19:51:24 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F05D31AE0AD; Wed, 27 Nov 2013 19:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAS3pCn7024786; Thu, 28 Nov 2013 04:51:12 +0100 (CET) Received: from [192.168.217.105] (p54891F61.dip0.t-ipconnect.de [84.137.31.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 206F814D; Thu, 28 Nov 2013 04:51:10 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 28 Nov 2013 04:51:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Bray X-Mailer: Apple Mail (2.1822) Cc: JSON WG , es-discuss , IETF Discussion , "www-tag@w3.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 03:51:25 -0000 On 28 Nov 2013, at 01:13, Tim Bray wrote: > JSON-text =3D value Add optional whitespace around that. Gr=FC=DFe, Carsten From tbray@textuality.com Wed Nov 27 20:00:16 2013 Return-Path: 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 9B8AA1AE1C4 for ; Wed, 27 Nov 2013 20:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 qPksoR_lpLaJ for ; Wed, 27 Nov 2013 20:00:14 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id CD3811AE1C8 for ; Wed, 27 Nov 2013 20:00:13 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id if17so5384762vcb.39 for ; Wed, 27 Nov 2013 20:00:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JoXQE8ydz4NWZCf9Zx+4tKCmOm0oTBthWhcmakybZjA=; b=Lk7aAM8LUYjHevzZFpUrzxgxPNKfnfxnypapP5GvKpEONaBQVR3221aLQTyIYDtmgF qgBRas3MY52zLVVGkBZKO/M50/bD1pQAOdzIhf+LkY85G9rEukHlBimM2MFvmzz6un4L ayJznNvG+Qvoq/fcbRGe4AducSIrSrXykC6WqW2lOB2sNAjx+1c2m3XbGnJvryDfcowK TYeYaiuJBYhms7eCvYyteNBF5qxnCesftwhrehr6bUOezyANXaessEmQIo7TPAboFa0z lkeqdt7Uhr2toTO1YVq65WzKMrafZJHBMv6u8MeAP4Fu0oYplz9ovqJ+3F1f1glNesFp 5B+A== X-Gm-Message-State: ALoCoQliSQLXEVvf24Flfon8s+OrrpTUwI2EHK+Kdf6o7VlW0AzNzp8VXK5zrBw/HHRKrJmOltt0 MIME-Version: 1.0 X-Received: by 10.52.0.9 with SMTP id 9mr1866077vda.47.1385611212861; Wed, 27 Nov 2013 20:00:12 -0800 (PST) Received: by 10.220.198.199 with HTTP; Wed, 27 Nov 2013 20:00:12 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Wed, 27 Nov 2013 20:00:12 -0800 Message-ID: From: Tim Bray To: Alex Russell Content-Type: multipart/alternative; boundary=e89a8ffba4d923c72204ec34c0a5 Cc: es-discuss , JSON WG , IETF Discussion , "www-tag@w3.org" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 04:00:16 -0000 --e89a8ffba4d923c72204ec34c0a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I listed some arguments against this in http://lists.w3.org/Archives/Public/www-tag/2013Oct/0041.html and at the moment I still believe them. Is there new information? On top of that, I have no fear of anyone trying to change JSON in the future; they would be resoundingly ignored by the community of implementers. I speak as one who would love to add built-in date/time literals but know that it won=E2=80=99t happen. -T On Wed, Nov 27, 2013 at 5:00 PM, Alex Russell wrote= : > Will you also be citing ECMA-404 normatively to avoid this sort of > divergence in the future? > > > On Wed, Nov 27, 2013 at 4:13 PM, Tim Bray wrote: > >> To do this, I think the draft requires these changes: >> >> - Remove the trailing section of section 1.2, starting with =E2=80=9CECM= Ascript >> 5.1 enumerates...=E2=80=9D [because the difference no longer exists] >> >> - In section 2: >> >> -- remove =E2=80=9CA JSON text is a serialized object or array.=E2=80=9D >> >> -- Insert: =E2=80=9CA JSON text is a serialized value. Note that certai= n >> previous specifications of JSON constrained a JSON text to be an object = or >> an array. Implementations which generate only objects or arrays where a >> JSON text is called for will be interoperable in the sense that all >> implementations will accept these as conforming JSON texts.=E2=80=9D >> >> -- Change the JSON-text production to read: >> >> JSON-text =3D value >> >> >> >> >> >> >> On Fri, Nov 22, 2013 at 10:21 AM, Matt Miller (mamille2) < >> mamille2@cisco.com> wrote: >> >>> There appears to be consensus to change JSON-text to allow for any JSON >>> value -- not just object / array -- while noting that object or array a= s >>> the top-level is the most interoperable. >>> >>> We will ask the Document Editor to make this change to >>> draft-ietf-json-rfc4627bis. >>> >>> >>> - Paul Hoffman and Matt Miller >>> >>> >>> _______________________________________________ >>> json mailing list >>> json@ietf.org >>> https://www.ietf.org/mailman/listinfo/json >>> >>> >> > --e89a8ffba4d923c72204ec34c0a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I listed some arguments against this in=C2=A0http://lists.w= 3.org/Archives/Public/www-tag/2013Oct/0041.html and at the moment I sti= ll believe them. Is there new information?

    On top of that, I have no fear of anyone trying to change JS= ON in the future; they would be resoundingly ignored by the community of im= plementers. =C2=A0I speak as one who would love to add built-in date/time l= iterals but know that it won=E2=80=99t happen. =C2=A0-T


    On Wed,= Nov 27, 2013 at 5:00 PM, Alex Russell <slightlyoff@google.com>= ; wrote:
    Will you also be citing ECM= A-404 normatively to avoid this sort of divergence in the future?


    On Wed, Nov 27, 2013 at 4:13 PM, Tim Bray <tbray@textuality.com> wrote:
    To do this, I think the dra= ft requires these changes:=C2=A0

    - Remove the trailing s= ection of section 1.2, starting with =E2=80=9CECMAscript 5.1 enumerates...= =E2=80=9D [because the difference no longer exists]

    - In section 2:

    -- remove =E2= =80=9CA JSON text is a serialized object or array.=E2=80=9D

    <= /div>
    -- Insert: =E2=80=9CA JSON text is a serialized value. =C2=A0Note= that certain previous specifications of JSON constrained a JSON text to be= an object or an array. =C2=A0Implementations which generate only objects o= r arrays where a JSON text is called for will be interoperable in the sense= that all implementations will accept these as conforming JSON texts.=E2=80= =9D

    -- Change the JSON-text production to read:
    <= br>
    JSON-text =C2=A0=3D value


    <= br>



    On Fri, Nov 22, 2013 at 10:21 AM, Matt Miller (mamille2) = <    mamille2@cisco.= com> wrote:
    There appears to be consensus to change JSON-text to allow for any JSON val= ue -- not just object / array -- while noting that object or array as the t= op-level is the most interoperable.

    We will ask the Document Editor to make this change to draft-ietf-json-rfc4= 627bis.


    - Paul Hoffman and Matt Miller


    _______________________________________________
    json mailing list
    json@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/json




    --e89a8ffba4d923c72204ec34c0a5-- From cabo@tzi.org Wed Nov 27 20:00:58 2013 Return-Path: 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 42A1A1AE1C4 for ; Wed, 27 Nov 2013 20:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 0iXoltDIH0Vz for ; Wed, 27 Nov 2013 20:00:57 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 473C91AE1C9 for ; Wed, 27 Nov 2013 20:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAS40nbo013572; Thu, 28 Nov 2013 05:00:50 +0100 (CET) Received: from [192.168.217.105] (p54891F61.dip0.t-ipconnect.de [84.137.31.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 27D2614F; Thu, 28 Nov 2013 05:00:42 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Thu, 28 Nov 2013 05:00:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C3C8ADB-DE73-4B1F-A4FC-D70BE87FA0DA@tzi.org> References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> <8FFA65BA9ACB45F9BFEECC205C7FAF30@codalogic> <6D24653D-C98B-4FDE-801D-9759FBD696FF@tzi.org> To: Tatu Saloranta X-Mailer: Apple Mail (2.1822) Cc: Pete Cordell , JSON WG Subject: Re: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 04:00:58 -0000 On 28 Nov 2013, at 00:40, Tatu Saloranta wrote: > Same goes for UTF-16=20 No, that=92s completely different. BOM tolerance was never in JSON, and arguing that you should add it is = like arguing that you should accept tabs in strings or trailing commas. UTF-16 *was* in the spec. We have just learned in the intervening time = that there is no point. Completely different situations. I=92m still = arguing that now is the time to simplify and recognize UTF-16 as a = legacy part of the spec that is going away, but that is a completely = different, more tenuous argument. Yes, I know that =93serious=94 implementations can be made to support = all this (including trailing commas), and you have all reasons to be = proud that yours is a serious one. But that doesn=92t detract one iota = from my point. Gr=FC=DFe, Carsten From tbray@textuality.com Wed Nov 27 20:12:05 2013 Return-Path: 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 D9BB71AE1B7 for ; Wed, 27 Nov 2013 20:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 v9apP_PdUm0t for ; Wed, 27 Nov 2013 20:12:03 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 645071AE0EF for ; Wed, 27 Nov 2013 20:12:03 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so5386255vcb.19 for ; Wed, 27 Nov 2013 20:12:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OKrzMez7CgfIZX3ka71P2jVZ4LLpNBQ5TDgyBaTEkok=; b=OaOU6xUCw0TIoId0zLCyQuJbBMRPjCHaa9vgyGZsmlL3+eYhykuore4hKRSfQE0bX8 051Sq9n4Wf8fUjCzRpMq2q8tJUmk67a4PM4DO03vViEcfpCmTcKP238gDP+SqSuMNTQu pJB5yW184ClJlu5xwXQBzMZvux0CykqOJh95i72J3ZySdriqMu7hOrF4i/RZ6SNDz+bR 55YevjjsE5SjqF9eW8JZWDitzEr7GwJ30NRlXlsi5MbNekgW20eiNbJXIaXGe/mFB/o8 9pW3A2pvszuCWQ0ql+RQHWKtGKsseNSN1w0ipxA6Q/fQhyWWT6iA5DWK67f4wZs8V4n0 smdQ== X-Gm-Message-State: ALoCoQkazYet2i/5vJ+FSh7THTmRf8eWFwMyapdxjXj6jEHDzlQCQQEvtQtRfwMpiQ5zj8OtCtpR MIME-Version: 1.0 X-Received: by 10.52.164.203 with SMTP id ys11mr2218950vdb.37.1385611922516; Wed, 27 Nov 2013 20:12:02 -0800 (PST) Received: by 10.220.198.199 with HTTP; Wed, 27 Nov 2013 20:12:02 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <3C3C8ADB-DE73-4B1F-A4FC-D70BE87FA0DA@tzi.org> References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> <8FFA65BA9ACB45F9BFEECC205C7FAF30@codalogic> <6D24653D-C98B-4FDE-801D-9759FBD696FF@tzi.org> <3C3C8ADB-DE73-4B1F-A4FC-D70BE87FA0DA@tzi.org> Date: Wed, 27 Nov 2013 20:12:02 -0800 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c2cc4070457404ec34ea14 Cc: Tatu Saloranta , Pete Cordell , JSON WG Subject: Re: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 04:12:06 -0000 --001a11c2cc4070457404ec34ea14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FWIW, in the years that I=E2=80=99ve been using JSON as a nice compact expr= essive wire format, I have never even once encountered an instance of JSON being transmitted over the wire in a format other than UTF-8. Even those languages which unfortunately use UTF-16 internally have nice JSON libraries that serialize as UTF-8. I=E2=80=99m pretty sure that if you st= arted sending JSON in UTF-16 or (gasp) UTF-32 to well-known public REST-flavored APIs out there, a substantial proportion of them would just blow up, because NOBODY DOES THAT. I still haven=E2=80=99t made up my mind as to what the spec should say, but= I sure wouldn=E2=80=99t go out of my way to serve the interests of wire formats th= at are not in practice used. -T On Wed, Nov 27, 2013 at 8:00 PM, Carsten Bormann wrote: > On 28 Nov 2013, at 00:40, Tatu Saloranta wrote: > > > Same goes for UTF-16 > > No, that=E2=80=99s completely different. > > BOM tolerance was never in JSON, and arguing that you should add it is > like arguing that you should accept tabs in strings or trailing commas. > > UTF-16 *was* in the spec. We have just learned in the intervening time > that there is no point. Completely different situations. I=E2=80=99m st= ill > arguing that now is the time to simplify and recognize UTF-16 as a legacy > part of the spec that is going away, but that is a completely different, > more tenuous argument. > > Yes, I know that =E2=80=9Cserious=E2=80=9D implementations can be made to= support all this > (including trailing commas), and you have all reasons to be proud that > yours is a serious one. But that doesn=E2=80=99t detract one iota from m= y point. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c2cc4070457404ec34ea14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    FWIW, in the years that I=E2=80=99ve been using JSON as a = nice compact expressive wire format, I have never even once encountered an = instance of JSON being transmitted over the wire in a format other than UTF= -8. =C2=A0Even those languages which unfortunately use UTF-16 internally ha= ve nice JSON libraries that serialize as UTF-8. =C2=A0 I=E2=80=99m pretty s= ure that if you started sending JSON in UTF-16 or (gasp) UTF-32 to well-kno= wn public REST-flavored APIs out there, a substantial proportion of them wo= uld just blow up, because NOBODY DOES THAT.

    I still haven=E2=80=99t made up my mind as to what the spec = should say, but I sure wouldn=E2=80=99t go out of my way to serve the inter= ests of wire formats that are not in practice used. =C2=A0-T


    On Wed, Nov 27, 2013 at 8:00 PM, Carsten= Bormann <cabo@tzi.org> wrote:
    On 28 Nov 2013, at 00:40, Tatu Saloranta <tsaloranta@gmail.com> wrote:

    > Same goes for UTF-16

    No, that=E2=80=99s completely different.

    BOM tolerance was never in JSON, and arguing that you should add it is like= arguing that you should accept tabs in strings or trailing commas.

    UTF-16 *was* in the spec. =C2=A0We have just learned in the intervening tim= e that there is no point. =C2=A0Completely different situations. =C2=A0I=E2= =80=99m still arguing that now is the time to simplify and recognize UTF-16= as a legacy part of the spec that is going away, but that is a completely = different, more tenuous argument.

    Yes, I know that =E2=80=9Cserious=E2=80=9D implementations can be made to s= upport all this (including trailing commas), and you have all reasons to be= proud that yours is a serious one. =C2=A0But that doesn=E2=80=99t detract = one iota from my point.

    Gr=C3=BC=C3=9Fe, Carsten

    _______________________________________________
    json mailing list
    json@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/json

--001a11c2cc4070457404ec34ea14-- From cowan@ccil.org Wed Nov 27 20:48:02 2013 Return-Path: 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 4B7EB1ADFC4 for ; Wed, 27 Nov 2013 20:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] 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 0ZKQt8OEJzpL for ; Wed, 27 Nov 2013 20:48:01 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 266811ACCE8 for ; Wed, 27 Nov 2013 20:48:01 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1VltVx-0007Ul-L2; Wed, 27 Nov 2013 23:47:45 -0500 Date: Wed, 27 Nov 2013 23:47:45 -0500 From: John Cowan To: Tim Bray Message-ID: <20131128044745.GN29489@mercury.ccil.org> References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> <8FFA65BA9ACB45F9BFEECC205C7FAF30@codalogic> <6D24653D-C98B-4FDE-801D-9759FBD696FF@tzi.org> <3C3C8ADB-DE73-4B1F-A4FC-D70BE87FA0DA@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Carsten Bormann , Tatu Saloranta , Pete Cordell , JSON WG Subject: Re: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 04:48:02 -0000 Tim Bray scripsit: > I still haven’t made up my mind as to what the spec should say, but I sure > wouldn’t go out of my way to serve the interests of wire formats that are > not in practice used. -T So let it say (right after UTF-8 being the default) "The use of other encodings is known to produce interoperability problems." (Which it is; we know at least some JSON decoders that won't accept them). Finis. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Most languages are dramatically underdescribed, and at least one is dramatically overdescribed. Still other languages are simultaneously overdescribed and underdescribed. Welsh pertains to the third category. --Alan King From hallam@gmail.com Wed Nov 27 20:55:05 2013 Return-Path: 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 1775F1AE0B4; Wed, 27 Nov 2013 20:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 jaVLHgh18Vny; Wed, 27 Nov 2013 20:55:03 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id CFB741ACCE8; Wed, 27 Nov 2013 20:55:02 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id c11so6005183lbj.9 for ; Wed, 27 Nov 2013 20:55:01 -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=UqjisRkEsWKx2nDr+7C6lR9Tn5zdzD9t9y1zv2YOR9o=; b=KQQ4pN7WRfkwbxdsedg9S/crZsU9zHqvuRX80xH2XPoiMfmPfP0wt65brJes6wXzmh 1W3sHoh1GGzYRS6A8DLgdkRgdlofNHAwzXQf6Q66xhpOJZMd59erd9VDTLDlgs+W/Kpo Zq/OoB6WXFZ7/Gel5a6GPar4EXxMGPYEKWTOLOfeh3r/07If2S5c4wIZq9imk1NWERXr wwO9nzpQdXNjaoXSFjTnXyLCgHZDH6UKKN63jAtF3lnpqebJqpA/d4gMoVhHkitBx4dD WPkOFR1wHMWV5xGLoFxOJYBEK++95TFZILZMzGgGn6vpCoCrBtJ5JhUjYmYOTvyzdvt+ R04w== MIME-Version: 1.0 X-Received: by 10.112.151.42 with SMTP id un10mr30335463lbb.7.1385614501437; Wed, 27 Nov 2013 20:55:01 -0800 (PST) Received: by 10.112.37.172 with HTTP; Wed, 27 Nov 2013 20:55:01 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Nov 2013 23:55:01 -0500 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: multipart/alternative; boundary=047d7b3435b627670104ec3584ce Cc: IETF Discussion , JSON WG , Alex Russell , "Matt Miller \(mamille2\)" , "www-tag@w3.org" , es-discuss Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 04:55:05 -0000 --047d7b3435b627670104ec3584ce Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Nov 27, 2013 at 11:00 PM, Tim Bray wrote: > I listed some arguments against this in > http://lists.w3.org/Archives/Public/www-tag/2013Oct/0041.html and at the > moment I still believe them. Is there new information? > > On top of that, I have no fear of anyone trying to change JSON in the > future; they would be resoundingly ignored by the community of > implementers. I speak as one who would love to add built-in date/time > literals but know that it won=92t happen. -T > The JavaScript variant may stay the same but people will add features if they find they are necessary to meet their requirements. As was previously established, many implementations already support a list of values so as to enable use in append only logs. I have added length encoded blocks so as to avoid repeatedly base64 encoding binary blobs. The Javascript world can ignore me, I try my best to ignore the javascript world. But if people are implementing one of my protocols they will find that while it will work perfectly OK with JSON, implementations will be more efficient if they support JSON-A or JSON-B. Suggesting that people will never change a spec is silly. Of course specs will be changed. --=20 Website: http://hallambaker.com/ --047d7b3435b627670104ec3584ce Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 27, 2013 at 11:00 PM, Tim Bray <tbray@textuality.com> wrote:
I listed some arguments aga= inst this in=A0http://lists.w3.org/Archives/Public/www-tag= /2013Oct/0041.html and at the moment I still believe them. Is there new= information?

On top of that, I have no fear of anyone trying to change JS= ON in the future; they would be resoundingly ignored by the community of im= plementers. =A0I speak as one who would love to add built-in date/time lite= rals but know that it won=92t happen. =A0-T

The JavaScrip= t variant may stay the same but people will add features if they find they = are necessary to meet their requirements.

<= div> As was previously established, many implementations already support a list = of values so as to enable use in append only logs. I have added length enco= ded blocks so as to avoid repeatedly base64 encoding binary blobs.


The Javascript world can ignore me, I tr= y my best to ignore the javascript world. But if people are implementing on= e of my protocols they will find that while it will work perfectly OK with = JSON, implementations will be more efficient if they support JSON-A or JSON= -B.

Suggesting that people will never change a spec is sill= y. Of course specs will be changed.

--
Website: http://hallambaker.com/
--047d7b3435b627670104ec3584ce-- From jhildebr@cisco.com Wed Nov 27 23:42:14 2013 Return-Path: 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 C930E1AE182 for ; Wed, 27 Nov 2013 23:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 6c0vtUcfM7sQ for ; Wed, 27 Nov 2013 23:42:13 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8617E1AC7EE for ; Wed, 27 Nov 2013 23:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=828; q=dns/txt; s=iport; t=1385624533; x=1386834133; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qE8CnSq03edq2nv3IOm6yH7PXYo1XIevrq4+vpqa/aU=; b=gU5+zPOhe9ZczePD7NFZtvQ5KjcYDmmj1Hn/FQJM4xOjr+3WRWVacAOb fgxqBBNVeGhy3YH3jJarrdOkbRo92oak4urd27cUllkOBrXDy7T5mQXVz dNxof3LTQBbEMStZiN6+ma39B8tlZ2rFTiSxL9MbCtaT2dcGJF+OsyuQK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAMjyllKtJXG+/2dsb2JhbABZgweBC7hDgR8WdIImAQEEeRACAQhGMiUCBAENBYgBwBUXjwcHhDMDiQqPCpITgymCKg X-IronPort-AV: E=Sophos;i="4.93,789,1378857600"; d="scan'208";a="288089821" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 28 Nov 2013 07:42:12 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAS7gC7Z027651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Nov 2013 07:42:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 01:42:12 -0600 From: "Joe Hildebrand (jhildebr)" To: John Cowan , Tim Bray Thread-Topic: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts Thread-Index: AQHO6/UHq/u85OWsJ0uhLCuSQFx4FJo5/7gA Date: Thu, 28 Nov 2013 07:42:11 +0000 Message-ID: References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> <8FFA65BA9ACB45F9BFEECC205C7FAF30@codalogic> <6D24653D-C98B-4FDE-801D-9759FBD696FF@tzi.org> <3C3C8ADB-DE73-4B1F-A4FC-D70BE87FA0DA@tzi.org> <20131128044745.GN29489@mercury.ccil.org> In-Reply-To: <20131128044745.GN29489@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.125.245] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Carsten Bormann , Tatu Saloranta , Pete Cordell , JSON WG Subject: Re: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 07:42:15 -0000 On 11/27/13 6:47 PM, "John Cowan" wrote: >Tim Bray scripsit: > >> I still haven=B9t made up my mind as to what the spec should say, but I >>sure >> wouldn=B9t go out of my way to serve the interests of wire formats that >>are >> not in practice used. -T > >So let it say (right after UTF-8 being the default) "The use of other >encodings is known to produce interoperability problems." (Which it is; >we know at least some JSON decoders that won't accept them). Finis. +0.9. We *could* also add language that allows you to claim to be fully JSON-compliant while only supporting UTF-8, which is just a small step further. That way, if you want to send UTF-[16,32], you MAY, but you can't really expect it to interop, which is more-or-less the status quo. --=20 Joe Hildebrand From jhildebr@cisco.com Wed Nov 27 23:44:25 2013 Return-Path: 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 BE11A1AE1D1; Wed, 27 Nov 2013 23:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 74NiwhvC8pTs; Wed, 27 Nov 2013 23:44:24 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3751AC7EE; Wed, 27 Nov 2013 23:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=235; q=dns/txt; s=iport; t=1385624664; x=1386834264; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bBtg4BW6covZggsu1oot4Kjm/K82F27JxcfrDOz2Ops=; b=XK9S+fm8pDUQYdKF0uo0xVBcMxFL+GF2TjauATFZltCKnv2gDqoydphr VVUfJCSiHlrSw+9gie9Y1ooWTQ8Uk1zaSf0tBLRlIGZysf3L7341/DWdD mkVE4nBaRmBrJ+gMX2pcNgTWVHOuRQFlL2xkx3V6QJLCdszJFj6KjWSJb E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAEjzllKtJV2b/2dsb2JhbABZgweBC7hDgR8WdIImAQEEOj8QAgEIDigQMiUCBAENBYgBwBUXjwcHhDMDmBSSE4FrgT6CKg X-IronPort-AV: E=Sophos;i="4.93,789,1378857600"; d="scan'208";a="288061843" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 28 Nov 2013 07:44:23 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAS7iNDw029223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Nov 2013 07:44:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 01:44:23 -0600 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , "Matt Miller (mamille2)" Thread-Topic: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft) Thread-Index: AQHO687A/Cahfs0JVUKfQoxm3AjFiJo6AKGA Date: Thu, 28 Nov 2013 07:44:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.125.245] Content-Type: text/plain; charset="us-ascii" Content-ID: <2B73CACE7AAD5E449DF06E01681D7342@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: JSON WG , IETF Discussion , "www-tag@w3.org" , es-discuss Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 07:44:26 -0000 On 11/27/13 2:13 PM, "Tim Bray" wrote: >-- Change the JSON-text production to read: > >JSON-text =3D value We also need to make an explicit decision about whitespace-tolerance. --=20 Joe Hildebrand From cabo@tzi.org Thu Nov 28 00:41:21 2013 Return-Path: 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 454B31ACCDA; Thu, 28 Nov 2013 00:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 Ao8ILkGMOpUe; Thu, 28 Nov 2013 00:41:19 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DD1EC1A1F5E; Thu, 28 Nov 2013 00:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rAS8f8V8026682; Thu, 28 Nov 2013 09:41:08 +0100 (CET) Received: from [134.102.116.187] (unknown [134.102.116.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E453F255; Thu, 28 Nov 2013 09:41:07 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Thu, 28 Nov 2013 09:41:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <558DF938-2B50-45B0-9696-03D9B9F98690@tzi.org> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1822) Cc: IETF Discussion , JSON WG , Tim Bray , "Matt Miller \(mamille2\)" , "www-tag@w3.org" , es-discuss Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 08:41:21 -0000 On 28 Nov 2013, at 08:44, Joe Hildebrand (jhildebr) = wrote: >> JSON-text =3D value >=20 > We also need to make an explicit decision about whitespace-tolerance. If the point is to track the changes made by ECMA-404 that decision has = been made for us (see end of section 4 in 404). (Note also that JSON is whitespace-tolerant today, so not having that = for the new non-containers at top-levels but everywhere else would be = rather surprising.*) Minimal change appears to be: JSON-text =3D ws value ws Gr=FC=DFe, Carsten *) The other interesting practical usage here is removing newlines from = the allowed whitespace for a single JSON-text and joining sequences of = these by newlines to form streams of JSON values. But that is outside the scope of application/json and = application/__+json, an instance of which is exactly one JSON-text. (truenull3true is a valid stream of JSON texts if you don=92t require = adding whitespace as delimiters. Implementations that employ a typical form of tokenization without = knowing what those tokens can be in JSON won=92t like that. In any = case, whitespace is needed to separate numbers.) From petejson@codalogic.com Thu Nov 28 01:10:56 2013 Return-Path: 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 6D6A71AD8F4 for ; Thu, 28 Nov 2013 01:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.951 X-Spam-Level: *** X-Spam-Status: No, score=3.951 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215] 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 FjElS2rujehT for ; Thu, 28 Nov 2013 01:10:53 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 66AAA1AD8DA for ; Thu, 28 Nov 2013 01:10:53 -0800 (PST) Received: (qmail 7475 invoked from network); 28 Nov 2013 09:10:32 +0000 Received: from host86-167-12-24.range86-167.btcentralplus.com (HELO codalogic) (86.167.12.24) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 28 Nov 2013 09:10:32 +0000 Message-ID: <5F878A83858043CBB7A0D194CB413DEF@codalogic> From: "Pete Cordell" To: "Carsten Bormann" References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> <8FFA65BA9ACB45F9BFEECC205C7FAF30@codalogic> <6D24653D-C98B-4FDE-801D-9759FBD696FF@tzi.org> X-Unsent: 1 Date: Thu, 28 Nov 2013 09:11:58 -0000 MIME-Version: 1.0 x-vipre-scanned: 001AAA7A005CEE001AABC7 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: JSON WG Subject: Re: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 09:10:56 -0000 ----- Original Message From: "Carsten Bormann" On 27 Nov 2013, at 22:21, Pete Cordell wrote: >> A number of editors on Windows want to insert a UTF-8 BOM >> at the start of a file to differentiate it from Windows >> cp1252 etc. It's important to be pragmatic, not just >> theoretically correct. A little leeway here could make >> some developers' lives much easier and avoid a few pointless gotchas. > > You can be pragmatic all you want in your code. Don’t forget to > skip comments, accept tabs and newlines in strings, skip trailing > commas, automatically close unbalanced delimiters, and support > lots of other non-JSON things people will type up in these editors. I don't see those things as in any way equivalent. > Retrofitting hundreds of production JSON decoder implementations > with BOM tolerance is a non-starter. The reports received so far seem to suggest that the JSON stack (as opposed to just the JSON grammer parser) of most parsers are quite capable of handling BOMs. > If JSON is to be useful as an interchange format for small > devices, we have to work towards removing fluff, not adding it. > The only reasonable move towards reality here would be getting > rid of the illusion of UTF-16/UTF-32 support. I don't find the 'small device' argument a compelling reason to disallow BOMs. But I agree that if you are using JSON is a application/json / HTTP / MIME context then we should limit it to UTF-8. I think other applications should be allowed a little more latitude to decide which of the Unicode encodings they want to use without being told that they a not using valid JSON. Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From timbl@w3.org Wed Nov 27 20:51:39 2013 Return-Path: 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 B5DB61AE089; Wed, 27 Nov 2013 20:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 c_KHjgF8Z0rZ; Wed, 27 Nov 2013 20:51:37 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id E4F071ACCE8; Wed, 27 Nov 2013 20:51:36 -0800 (PST) Received: from c-24-62-225-11.hsd1.ma.comcast.net ([24.62.225.11] helo=[192.168.0.106]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VltZf-0001eL-AK; Wed, 27 Nov 2013 23:51:35 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_24FD0091-DEAA-4304-8384-61C19B3C492A" From: Tim Berners-Lee In-Reply-To: Date: Wed, 27 Nov 2013 23:51:29 -0500 Message-Id: <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> References: To: Tim Bray X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Thu, 28 Nov 2013 07:38:15 -0800 Cc: IETF Discussion , JSON WG , Alex Russell , "Matt Miller \(mamille2\)" , "www-tag@w3.org" , es-discuss Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 04:51:40 -0000 --Apple-Mail=_24FD0091-DEAA-4304-8384-61C19B3C492A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2013-11 -27, at 23:00, Tim Bray wrote: > I listed some arguments against this in = http://lists.w3.org/Archives/Public/www-tag/2013Oct/0041.html and at the = moment I still believe them. Is there new information? >=20 > On top of that, I have no fear of anyone trying to change JSON in the = future; they would be resoundingly ignored by the community of = implementers. I speak as one who would love to add built-in date/time = literals but know that it won=92t happen. -T >=20 JSON is interesting in being a subset of ECMAscript. That is a big = dependency -- will it be preserved? However as it is unwise to feed JSON into an ECMAscript processor for = security reasons, that dependency may not affect code, just mean that = JSON and ECMAscript parsers can share parts at the moment. One could imagine that the arc of ECMAscript's evolution could end up=20 having all kinds of impact on the data structure syntax and semantics. (unordered sets as alternative to lists? who knows). So in that case = one could imagine pressure to make a new version of JSON to match. Yes, literal ISO dates and dateTimes -- I added them to my own N3/turtle = parsers without much fanfare, wish they had been put in the Turtle = language too. Maybe they will.=20 -timbl > On Wed, Nov 27, 2013 at 5:00 PM, Alex Russell = wrote: > Will you also be citing ECMA-404 normatively to avoid this sort of = divergence in the future? >=20 >=20 > On Wed, Nov 27, 2013 at 4:13 PM, Tim Bray = wrote: > To do this, I think the draft requires these changes:=20 >=20 > - Remove the trailing section of section 1.2, starting with = =93ECMAscript 5.1 enumerates...=94 [because the difference no longer = exists] >=20 > - In section 2: >=20 > -- remove =93A JSON text is a serialized object or array.=94 >=20 > -- Insert: =93A JSON text is a serialized value. Note that certain = previous specifications of JSON constrained a JSON text to be an object = or an array. Implementations which generate only objects or arrays = where a JSON text is called for will be interoperable in the sense that = all implementations will accept these as conforming JSON texts.=94 >=20 > -- Change the JSON-text production to read: >=20 > JSON-text =3D value >=20 >=20 >=20 >=20 >=20 >=20 > On Fri, Nov 22, 2013 at 10:21 AM, Matt Miller (mamille2) = wrote: > There appears to be consensus to change JSON-text to allow for any = JSON value -- not just object / array -- while noting that object or = array as the top-level is the most interoperable. >=20 > We will ask the Document Editor to make this change to = draft-ietf-json-rfc4627bis. >=20 >=20 > - Paul Hoffman and Matt Miller >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 >=20 >=20 >=20 --Apple-Mail=_24FD0091-DEAA-4304-8384-61C19B3C492A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I listed some arguments against this in htt= p://lists.w3.org/Archives/Public/www-tag/2013Oct/0041.html and at = the moment I still believe them. Is there new information?

On top of that, I have no fear of anyone trying to change = JSON in the future; they would be resoundingly ignored by the community = of implementers.  I speak as one who would love to add built-in = date/time literals but know that it won=92t happen.  -T


JSON is = interesting in being a subset of ECMAscript.  That is a big = dependency -- will it be preserved?
However as it is unwise = to feed JSON into an ECMAscript processor for security reasons, = that dependency may not affect code, just mean that JSON and = ECMAscript parsers can share parts at  the = moment.

One could imagine that the arc of = ECMAscript's evolution could end up 
having all kinds of = impact on the data structure syntax and semantics.
(unordered = sets as alternative to lists? who knows).  So in that case = one
could imagine pressure to make a new version of JSON to = match.

Yes, literal ISO dates and dateTimes -- = I added them to my own N3/turtle parsers without much fanfare, = wish they had been put in the Turtle language too.  Maybe they = will. 

-timbl

On = Wed, Nov 27, 2013 at 5:00 PM, Alex Russell <slightlyoff@google.com> wrote:
Will = you also be citing ECMA-404 normatively to avoid this sort of divergence = in the future?


On Wed, Nov 27, 2013 at 4:13 PM, Tim Bray <tbray@textuality.com> wrote:
To do = this, I think the draft requires these = changes: 

- Remove the trailing section of = section 1.2, starting with =93ECMAscript 5.1 enumerates...=94 [because = the difference no longer exists]

- In section 2:

-- remove = =93A JSON text is a serialized object or = array.=94

-- Insert: =93A JSON text is a = serialized value.  Note that certain previous specifications of = JSON constrained a JSON text to be an object or an array. =  Implementations which generate only objects or arrays where a JSON = text is called for will be interoperable in the sense that all = implementations will accept these as conforming JSON texts.=94

-- Change the JSON-text production to = read:

JSON-text  =3D = value






On Fri, Nov 22, 2013 at 10:21 AM, Matt Miller (mamille2) <mamille2@cisco.com> = wrote:
There appears to be consensus to change JSON-text to allow for any JSON = value -- not just object / array -- while noting that object or array as = the top-level is the most interoperable.

We will ask the Document Editor to make this change to = draft-ietf-json-rfc4627bis.


- Paul Hoffman and Matt Miller


_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json





= --Apple-Mail=_24FD0091-DEAA-4304-8384-61C19B3C492A-- From cabo@tzi.org Thu Nov 28 08:16:43 2013 Return-Path: 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 206C11ACCFC; Thu, 28 Nov 2013 08:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-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 ZfFx7X2fFnji; Thu, 28 Nov 2013 08:16:42 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 011DF1AC404; Thu, 28 Nov 2013 08:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rASGGZ7C012519; Thu, 28 Nov 2013 17:16:35 +0100 (CET) Received: from [192.168.217.105] (p5489053C.dip0.t-ipconnect.de [84.137.5.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4254F70A; Thu, 28 Nov 2013 17:16:34 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> Date: Thu, 28 Nov 2013 17:16:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38918D14-D7ED-4983-8A46-4CA4D1C7BE96@tzi.org> References: <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> To: Tim Berners-Lee X-Mailer: Apple Mail (2.1822) Cc: IETF Discussion , JSON WG , Alex Russell , Tim Bray , "Matt Miller \(mamille2\)" , "www-tag@w3.org" , es-discuss Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 16:16:43 -0000 On 28 Nov 2013, at 05:51, Tim Berners-Lee wrote: > JSON is interesting in being a subset of ECMAscript. =20 That was a clever device used by Douglas Crockford to minimize the bike = shedding that was inevitable when he designed the data format. That = device is no longer necessary, indeed, it has become a liability as = ECMAscript moved forward. > That is a big dependency -- will it be preserved? There is no dependency any more, and the subset relationship has already = been destroyed by the introduction of Line/Paragraph separators = (U+2028/U+2029) in recent versions of ECMAscript (these are valid in = JSON strings but not in ECMAscript 5 strings). It is best to acknowledge the role of JavaScript as the inspiration for = the JSON data interchange format (and one of its biggest customers), but = otherwise consider the two specifications independent of each other. Gr=FC=DFe, Carsten From allen@wirfs-brock.com Thu Nov 28 09:37:40 2013 Return-Path: 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 CDEDA1AD7C0; Thu, 28 Nov 2013 09:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] 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 IGg0oJIluN0v; Thu, 28 Nov 2013 09:37:38 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id AF5141ACCFC; Thu, 28 Nov 2013 09:37:38 -0800 (PST) Received: from [192.168.0.15] (069-064-236-244.pdx.net [69.64.236.244]) (Authenticated sender: allenwb@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 1600DF249E; Thu, 28 Nov 2013 09:37:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Allen Wirfs-Brock In-Reply-To: <92E7AA8E-F77C-4552-B463-D65703576AB9@vpnc.org> Date: Thu, 28 Nov 2013 09:37:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <92E7AA8E-F77C-4552-B463-D65703576AB9@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1085) Cc: es-discuss , Alex Russell , IETF Discussion , "www-tag@w3.org" , JSON WG Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 17:37:41 -0000 On Nov 27, 2013, at 7:29 PM, Paul Hoffman wrote: > >=20 > On Nov 27, 2013, at 5:00 PM, Alex Russell = wrote: >=20 >> Will you also be citing ECMA-404 normatively to avoid this sort of = divergence in the future? >=20 > If you believe that ECMA-404 will change in the future, that would = indicate that ECMA might break interoperability with current = implementations, even for what they perceive as "good reasons". In = general, the IETF tries not to have its long-lived standards normatively = latch on to moving targets for this very reason. Even when other SDOs = have assured us that they will not make backwards-incompatible changes, = they have done so anyway (cue the Klensin-esqe theme music...), and that = has caused serious interoperability problems for the IETF specs. Stability of ECMA-404 should not be a concern. As far as I can observe = TC39 has absolutely no interest in every changing or extending the JSON = grammar. I'm confident TC39 would record that as a statement of policy = if asked. In fact, the reason TC39 chose to issue ECMA-404 was because = there was concern that the JSON WG was on a path to modify and possibly = extend JSON syntax. The only sort of changes to ECAM-404 I ever expect = to see would be technical corrections to errors found in the current = specification language or the addition of informative material to help = clarify understanding of the specification. For example, if there was = sufficient public interest we might consider adding an informative Annex = that restates the grammar using ABNF notation. The JSON syntax has its roots in the ECMAScript syntax but is not at all = linked to the ECMAScript syntax. The ECMAScript object and array = literal constructs were the inspiration for JSON. But even in the = beginning, the JSON syntax was only a subset set of the full syntax of = those ECMAScript language features. ECMAScript object literal syntax = has been significantly extended in both the ECMA-262 5th Edition(2009) = and the forthcoming 6th Edition. But those extensions have and will not = ever be added to the JSON syntax defined in ECMA-404. Allen Wirfs-Brock ECMA-262 Project Editor From allen@wirfs-brock.com Thu Nov 28 12:00:32 2013 Return-Path: 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 D72A91AE22A for ; Thu, 28 Nov 2013 12:00:32 -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 liODU8vCoIeX for ; Thu, 28 Nov 2013 12:00:31 -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 590731AE21E for ; Thu, 28 Nov 2013 12:00:26 -0800 (PST) Received: from 069-064-236-244.pdx.net ([69.64.236.244] helo=[192.168.0.15]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Vm7l1-0008wp-0R; Thu, 28 Nov 2013 20:00:15 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 69.64.236.244 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+jFxQ5Ik8ukaAWWIVveHJhG5+fmt9LRVI= Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Allen Wirfs-Brock In-Reply-To: Date: Thu, 28 Nov 2013 12:00:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> <8FFA65BA9ACB45F9BFEECC205C7FAF30@codalogic> <6D24653D-C98B-4FDE-801D-9759FBD696FF@tzi.org> <3C3C8ADB-DE73-4B1F-A4FC-D70BE87FA0DA@tzi.org> <20131128044745.GN29489@mercury.ccil.org> To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1085) Cc: John Cowan , Pete Cordell , JSON WG , Tim Bray , Tatu Saloranta , Carsten Bormann Subject: Re: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 20:00:33 -0000 On Nov 27, 2013, at 11:42 PM, Joe Hildebrand (jhildebr) wrote: > On 11/27/13 6:47 PM, "John Cowan" wrote: >=20 >> Tim Bray scripsit: >>=20 >>> I still haven=B9t made up my mind as to what the spec should say, = but I >>> sure >>> wouldn=B9t go out of my way to serve the interests of wire formats = that >>> are >>> not in practice used. -T >>=20 >> So let it say (right after UTF-8 being the default) "The use of other >> encodings is known to produce interoperability problems." (Which it = is; >> we know at least some JSON decoders that won't accept them). Finis. >=20 > +0.9. We *could* also add language that allows you to claim to be = fully > JSON-compliant while only supporting UTF-8, which is just a small step > further. That way, if you want to send UTF-[16,32], you MAY, but you > can't really expect it to interop, which is more-or-less the status = quo. >=20 > --=20 > Joe Hildebrand This is a good example where your wording creates concerns for TC39 = members. If you were to say that "to be fully application/json = compliant..." then TC39 wouldn't have any issues with it. But saying = "JSON-compliant" raises many concerns. Allen= From jhildebr@cisco.com Fri Nov 29 15:01:22 2013 Return-Path: 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 7E26D1AE206 for ; Fri, 29 Nov 2013 15:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 jzpoF3p7VrHz for ; Fri, 29 Nov 2013 15:01:21 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7459F1AE204 for ; Fri, 29 Nov 2013 15:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=778; q=dns/txt; s=iport; t=1385766080; x=1386975680; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yIz+2N+D5yWXwfO9YIy6UCYnoPbZHj+cOOp+g7BlFH8=; b=CqImsJHxwY/K2uGXgd4UB+m71ApnhI9GzEogHP/LY2DxbckQRPCG1+4p xbBQCBzo9XjbPlUERJCSSZpvEW56SbLuIrSPNzQlmdTmi3KIGxFndzgkV 4tBAhL/erFLQhkWaFDKl/nRKkWc+IcIEmsRu1l9RbtykZE2/LP37gTD1X 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOYbmVKtJXG8/2dsb2JhbABZgweBC7hZgR4WdIImAQEEOj8QAgEINhAyJQIEDgWIAb9jF48IB4QzA5gUkhODKYIq X-IronPort-AV: E=Sophos;i="4.93,799,1378857600"; d="scan'208";a="3227123" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-1.cisco.com with ESMTP; 29 Nov 2013 23:01:19 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rATN1JQW031413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Nov 2013 23:01:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 29 Nov 2013 17:01:18 -0600 From: "Joe Hildebrand (jhildebr)" To: Allen Wirfs-Brock Thread-Topic: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts Thread-Index: AQHO6/UHq/u85OWsJ0uhLCuSQFx4FJo5/7gAgAF10YCAAR1MAA== Date: Fri, 29 Nov 2013 23:01:17 +0000 Message-ID: References: <87FBA1C2000449EBBED94BDB0485829F@codalogic> <8FFA65BA9ACB45F9BFEECC205C7FAF30@codalogic> <6D24653D-C98B-4FDE-801D-9759FBD696FF@tzi.org> <3C3C8ADB-DE73-4B1F-A4FC-D70BE87FA0DA@tzi.org> <20131128044745.GN29489@mercury.ccil.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.74.212] Content-Type: text/plain; charset="us-ascii" Content-ID: <73F03B1F989ED144B51D6EA19EF0838E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John Cowan , Pete Cordell , JSON WG , Tim Bray , Tatu Saloranta , Carsten Bormann Subject: Re: [Json] UTF-8 for application/json contexts, UTF-8/16/32 for other contexts X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 23:01:22 -0000 On 11/28/13 10:00 AM, "Allen Wirfs-Brock" wrote: >>=20 >> +0.9. We *could* also add language that allows you to claim to be fully >> JSON-compliant while only supporting UTF-8, which is just a small step >> further. That way, if you want to send UTF-[16,32], you MAY, but you >> can't really expect it to interop, which is more-or-less the status quo. >This is a good example where your wording creates concerns for TC39 >members. If you were to say that "to be fully application/json >compliant..." then TC39 wouldn't have any issues with it. But saying >"JSON-compliant" raises many concerns. Sorry, I was imprecise. I meant compliant with the doc at hand, 4627bis, which is the scope of this discussion. --=20 Joe Hildebrand From nrm@arcanedomain.com Sat Nov 30 10:57:14 2013 Return-Path: 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 603F51AE1B1; Sat, 30 Nov 2013 10:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mJz1Q2Z63GWM; Sat, 30 Nov 2013 10:57:13 -0800 (PST) Received: from homiemail-a5.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9CF1AE1AB; Sat, 30 Nov 2013 10:57:13 -0800 (PST) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 3A94170406A; Sat, 30 Nov 2013 10:57:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=arcanedomain.com; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s= arcanedomain.com; bh=USq/aRfi019ci5J9/EFqepOH5kQ=; b=KegB4DL6rjA LlKF4kujsO6BYIpeZmFR5MIMTy/qlCeIYxU56ZK6oNItF9fRoKtfQuNnXYWvbtey p7O2yLfbmnIgIqvR68Mnn4L+PoJeo39KzvdkpJpzd+mC+2gySiD8LKbDT9LAVdC1 fQjWY2ZJojwJz/ncmNixlzwHE2vdjJWw= Received: from [192.168.1.102] (unknown [146.115.66.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: webmaster@arcanedomain.com) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id 099B5704063; Sat, 30 Nov 2013 10:57:09 -0800 (PST) Message-ID: <529A350A.60602@arcanedomain.com> Date: Sat, 30 Nov 2013 13:57:14 -0500 From: Noah Mendelsohn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Tim Berners-Lee , Tim Bray References: <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> In-Reply-To: <6C28E0DD-5E45-42DB-A915-795EE0A489CC@w3.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 30 Nov 2013 13:44:33 -0800 Cc: IETF Discussion , JSON WG , Alex Russell , "Matt Miller \(mamille2\)" , "www-tag@w3.org" , es-discuss Subject: Re: [Json] Consensus on JSON-text (WAS: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 18:57:14 -0000 On 11/27/2013 11:51 PM, Tim Berners-Lee wrote: > JSON is interesting in being a subset of ECMAscript. That is a big > dependency -- will it be preserved? > However as it is unwise to feed JSON into an ECMAscript processor for > security reasons, that dependency may not affect code, just mean that > JSON and ECMAscript parsers can share parts at the moment. There may be many other situations in which there is benefit to having JSON be a proper subset of ECMAscript. For example, one can imagine tool chains used for development or testing that would depend on the ability to copy text fragments between JSON and ECMAscript source documents, and one might foresee more "vertical" standards that would depend on the commonality as well. Noah