From mamille2@cisco.com Mon Jul 1 15:58: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 25A4C11E8319 for ; Mon, 1 Jul 2013 15:58:36 -0700 (PDT) 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 PH0s4xtwWn6J for ; Mon, 1 Jul 2013 15:58:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 748E311E82EF for ; Mon, 1 Jul 2013 15:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7456; q=dns/txt; s=iport; t=1372719510; x=1373929110; h=from:to:subject:date:message-id:mime-version; bh=2tCWYGxDRFJYpDvTxVft4GMywUkF9FTDNkZ86xMZFFQ=; b=BzXWAlMtofbXvTSTwbrkIP5pBPz1QtMMklWDm5DSW2dDh+fBu/eeyK9f pw1+sLdubQfFxa3j+M68WX3hUGkofcA0CkrUkEhxPV+IEty/S58sGGzZm J7S/vu/Nc1l+eYisADKdkB2Ghv1NPgLN++thAHgdV5Xf8IAfWJ6Ifv9bv 0=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAH0I0lGtJV2c/2dsb2JhbABagwl7v0h9FnSCJQEEgQsBKiYwJwQbBogBm0mgGY8tgzxjA5AIgS2XWIMRgig X-IronPort-AV: E=Sophos;i="4.87,976,1363132800"; d="p7s'?scan'208";a="229669694" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 01 Jul 2013 22:58:21 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r61MwLDs023171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 1 Jul 2013 22:58:21 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 1 Jul 2013 17:58:20 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org WG" Thread-Topic: Moving Forward Thread-Index: AQHOdq576cippTpnWEelXFGS8WUNbw== Date: Mon, 1 Jul 2013 22:58:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.90] Content-Type: multipart/signed; boundary="Apple-Mail=_38B9591C-3C04-4615-BCB8-75765C6B714C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Json] Moving Forward 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, 01 Jul 2013 22:58:36 -0000 --Apple-Mail=_38B9591C-3C04-4615-BCB8-75765C6B714C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you all for providing feedback on the minimal proposal edit. = Clearly there is no consensus for it because the resulting document does = not lead to interoperable implementations. However, the chairs also = think it is premature to declare failure now. Instead, we suggest the = Working Group consider the fewest possible changes that can be made to = then get consensus on the "minimal changes" proposal. The responses focused on the need to make changes to the draft with = respect to what is allowed in strings. Off-list, we heard a strong = desire to make parsing objects that have duplicate names interoperable = as well. The chairs will soon start two threads, one on each topic. If = we get rough consensus on each of those, we can see whether that will be = sufficient for us to revisit the "minimal changes" proposal; otherwise, = we'll use those results and forge ahead with non-minimal changes, and = possibly look at rechartering if we can't reach consensus under the = current charter. A personal plea from the chairs: let's avoid rechartering if at all = possible. It delays things, it has failure modes, and it can lead to = worse situations. If we have to, we have to, but we would really like = y'all to think in terms of coming to consensus on the current charter if = at all possible. Thank you, Paul Hoffman and Matt Miller= --Apple-Mail=_38B9591C-3C04-4615-BCB8-75765C6B714C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MDEyMjU4 MjBaMCMGCSqGSIb3DQEJBDEWBBSYldxMyE2h+RpxAKkz8DeqmaTnMDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAGMh 43mck+77YbKyRvXN2tKaqFyO5KXIkvYi+tXN1jJZ+aijAbCL8Axj/xucSP9qU971qQMLVIMWaDqm nS6BrLWlUIAApgMJp5yhMix9Wv+kAYs/81nWkbKkghvYtQ4BvpC4OMaZ8gdVoHusNDM4/osV6ebn 6Bo8SOOpf9ahVB+yD9aLouuxiiNcZPviPQYW5j+PYsWqBD/XWLaa+p5A0XgemUPjPR3/f1Fw47Hu u5/PA33SoRp10wosTcx1rJ7cdtAnOPpDBCvOvd2h1WVsJ//8nM4OeniJLnm7EVZBz0Wd2EPBfMJv bCCv1fQvNbmyh0aIG0lz6Hl16S1qAuM9UkcAAAAAAAA= --Apple-Mail=_38B9591C-3C04-4615-BCB8-75765C6B714C-- From paul.hoffman@vpnc.org Tue Jul 2 16:25: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 CE67C11E80F3 for ; Tue, 2 Jul 2013 16:25:51 -0700 (PDT) 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 1uqc2QJfLTcc for ; Tue, 2 Jul 2013 16:25:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5003611E80EC for ; Tue, 2 Jul 2013 16:25:51 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r62NPnbK017500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Jul 2013 16:25:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 2 Jul 2013 16:25:48 -0700 To: "json@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Proposed minimal change for duplicate names in objects 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, 02 Jul 2013 23:25:51 -0000 Do either or both of these proposals work for people in the WG? --Matt Miller and Paul Hoffman The following are proposed minimal changes to make the JSON spec = interoperable with respect to objects that have duplicate names. Proposal 1: In section 2.2 (Grammar -> Objects): No change In section 4 (Parsers): Add: "If a parser encounters an object with duplicate names, the = parser MUST use only the last name/value pair that has the duplicate name. In section 5 (Generators): Add: "The names within an object SHOULD be unique." Proposal 2: Same as Proposal 1 *except* that a second sentence is added for section = 4: "A parser that streams its outputs MUST fail to finish parsing if it encounters more than one = name/value pair with the same name." From paul.hoffman@vpnc.org Tue Jul 2 16: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 6887B11E80EC for ; Tue, 2 Jul 2013 16:27:17 -0700 (PDT) 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 WWLkV1VOiS2X for ; Tue, 2 Jul 2013 16:27:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8FE21F9AC2 for ; Tue, 2 Jul 2013 16:27:17 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r62NRFuY017537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Jul 2013 16:27:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> Date: Tue, 2 Jul 2013 16:27:15 -0700 To: "json@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] Proposed minimal change for strings 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, 02 Jul 2013 23:27:17 -0000 Do either or both of these proposals work for people in the WG? --Matt Miller and Paul Hoffman The following are proposed minimal changes to make the JSON spec = interoperable with respect to which unescaped code units are legal in strings. Proposal 1 (allow all code units in their unescaped form): In section 1 (Introduction): Change the sentence about Unicode characters to: A string is a sequence of zero or more Unicode code units [UNICODE]. In section 2.2 (Strings): Leave the production for "unescaped" as-is. In section 3 (Encoding): Add "Some strings, notably those that have unescaped surrogate code = units (value 0xD800 to 0xDFFF), cannot be encoded in UTF-8." Proposal 2 (prohibit unescaped surrogates): In section 1 (Introduction): A string is a sequence of zero or more Unicode scalar values = [UNICODE]. In section 2.2 (Strings): Change the production for "unescaped" to be: unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF From jsontest@yahoo.com Tue Jul 2 16:33: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 743AE21F9AD6 for ; Tue, 2 Jul 2013 16:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 2XocxVJv+Ro7 for ; Tue, 2 Jul 2013 16:33:46 -0700 (PDT) Received: from nm13-vm4.bullet.mail.ne1.yahoo.com (nm13-vm4.bullet.mail.ne1.yahoo.com [98.138.91.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCB921F9ACD for ; Tue, 2 Jul 2013 16:33:46 -0700 (PDT) Received: from [98.138.90.53] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 02 Jul 2013 23:33:44 -0000 Received: from [98.138.89.175] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 02 Jul 2013 23:33:44 -0000 Received: from [127.0.0.1] by omp1031.mail.ne1.yahoo.com with NNFMP; 02 Jul 2013 23:33:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 537078.12723.bm@omp1031.mail.ne1.yahoo.com Received: (qmail 16354 invoked by uid 60001); 2 Jul 2013 23:33:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1372808024; bh=RAjPVvjJ0WCAugS8aBCFHQR0YgkjxwukXNEKGBwWfDg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=QiDLUfpqGtcZSCzZlW+xTg9XHZ9GgT9WYI9jJ7P3tng7m7RHJCtB4rLGfggz/Dh8bHz9E2I+ei6TwC7oL3geK0zRn5G8CRrwkpdna1JW/jx2iV3Zla0VC3QAnNs6zcjnyBZ+jaHVHs550aWvTzws/JbQ7gPclxQ9nCcUd5w5Mb8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=PoobaLvxFswc2VMxyAyQzKUXe8qVwcJRUd4dWpLwTRRHyWlL6fCXRjzI+8ncA3j0/+D6n0LOUgFOBWHGHopTWakqzD2ZREKwM/glUdPobvWrLI46LNiE78kaJcKGbumea6MYtTHoSOMqqUIWsk+nvdrk7IZDlFA2RK5f7cIAuGw= ; X-YMail-OSG: D4I2Ac4VM1kn.eGq3xVhjP1K.FUUhPgofbA_friBmzdZb64 _zfeLTKpzQB8n543gW4cbLUQqRZoVhdYTwLk0GazEfx0z9_Png1KCh8wi0uz V55tenMPatlFSN07ziF0630.axY7pjtc9Zvwr_bdf618vrpVcVK2aelej7Tr q8abgrnde0l367QerxHmwQK6Luy1huPypEbtyEJCUeZP7AJSq58GJ30BJvop iaefi54g2AmbL3drjIp76HB1NAgDNGDDKvBL_Al1iOYe03bteRyw7UC_PhT9 zfLN0FgtUUSsbq7HCg4xIDRje7xu5htUtPmT6umjhzTvv.GdWO7Vv00aEJBb D_Aw8V98xmxMYWFkdyZiuuBMS9yTlH3YuEJtcZxKdOTHRakbc6AA80ug0oiK oCsQTCxmr1ld5B_1g2CAqcAXpMFbaQYQC6e7jmVQkfFH7z4dFayxsyOfXwRc iaRVJ0.cKuxzEZucn2JYyyqtNPhVh2J.gEhHyG16CpPvgN8yVJBV_Rj2SS0P nnnsyNzD8BLGtf66SlG4yym6W0Mu4.5.YqXN.BtM4cg4C05EaHhBQzHHI9kB 3DF_HRSzFlwdIAr561_j72UkBW9TOs4Hx6CeUWtqSxpKDWNg- Received: from [76.29.100.42] by web125604.mail.ne1.yahoo.com via HTTP; Tue, 02 Jul 2013 16:33:44 PDT X-Rocket-MIMEInfo: 002.001, SSBwcmVmZXIgcHJvcG9zYWwgMSwgYXMgcHJvcG9zYWwgMiBtYXkgY2F1c2UgdW5kdWUgYnVyZGVuIG9uIHBhcnNlcnMgKHRoZXkgbXVzdCBrZWVwIHRyYWNrIG9mIGFsbCBwYXN0IGtleXMsIHRoZW4gd2UgYWxzbyBoYXZlIHRvIGRpc2N1c3Mgc3RyaW5nIGtleSBjb21wYXJpc29uIHdoaWNoIGlzIGRlY2lkZWRseSBub3QgYSBtaW5pbWFsIHRvcGljKS4KwqAKLS0tLS0tLS0tLS0tLS0tLQotVmlubnkKd3d3Lmpzb250ZXN0LmNvbQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogUGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 References: Message-ID: <1372808024.6200.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Tue, 2 Jul 2013 16:33:44 -0700 (PDT) From: Vinny A To: Paul Hoffman , "json@ietf.org WG" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-553746768-1372808024=:6200" Subject: Re: [Json] Proposed minimal change for duplicate names in objects X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Vinny A List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 23:33:51 -0000 ---685807438-553746768-1372808024=:6200 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I prefer proposal 1, as proposal 2 may cause undue burden on parsers (they = must keep track of all past keys, then we also have to discuss string key c= omparison which is decidedly not a minimal topic).=0A=A0=0A----------------= =0A-Vinny=0Awww.jsontest.com=0A=0A=0A=0A________________________________=0A= From: Paul Hoffman =0ATo: "json@ietf.org WG" =0ASent: Tuesday, July 2, 2013 6:25 PM=0ASubject: [Json] Proposed= minimal change for duplicate names in objects=0A =0A=0A=0A= =0ADo either or both of these proposals work for people in the WG?=0A=0A--M= att Miller and Paul Hoffman=0A=0AThe following are proposed minimal changes= to make the JSON spec interoperable with respect to=0Aobjects that have du= plicate names.=0A=0AProposal 1:=0A=0AIn section 2.2 (Grammar -> Objects):= =0A=A0 No change=0AIn section 4 (Parsers):=0A=A0 Add: "If a parser encounte= rs an object with duplicate names, the parser MUST use only the last=0A=A0 = name/value pair that has the duplicate name.=0AIn section 5 (Generators):= =0A=A0 Add: "The names within an object SHOULD be unique."=0A=0AProposal 2:= =0A=0ASame as Proposal 1 *except* that a second sentence is added for secti= on 4: "A parser that streams=0A=A0 its outputs MUST fail to finish parsing = if it encounters more than one name/value pair with the=0A=A0 same name."= =0A=0A_______________________________________________=0Ajson mailing list= =0Ajson@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/json ---685807438-553746768-1372808024=:6200 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I prefer p= roposal 1, as proposal 2 may cause undue burden on parsers (they must keep = track of all past keys, then we also have to discuss string key comparison = which is decidedly not a minimal topic).
 =
----------------
-Vinny
www.jsontest.com

From: Paul Hoffman <paul.hoffman@vpnc.org>
To: "json@ietf.org WG" <json@ietf.org>
Sent: Tuesday, July 2, 2013 = 6:25 PM
Subject: [Json] Proposed = minimal change for duplicate names in objects

=0A<chair hats on>

Do either or both = of these proposals work for people in the WG?

--Matt Miller and Paul= Hoffman

The following are proposed minimal changes to make the JSON= spec interoperable with respect to
objects that have duplicate names.
Proposal 1:

In section 2.2 (Grammar -> Objects):
  = No change
In section 4 (Parsers):
  Add: "If a parser encounters= an object with duplicate names, the parser MUST use only the last
 = ; name/value pair that has the duplicate name.
In section 5 (Generators)= :
  Add: "The names within an object SHOULD be unique."

Prop= osal 2:

Same as Proposal 1 *except* that a second sentence is added = for section 4: "A parser that streams
  its outputs MUST fail to fi= nish parsing if it encounters more than one name/value pair with the
&nb= sp; same name."

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

---685807438-553746768-1372808024=:6200-- From cowan@ccil.org Tue Jul 2 18:11: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 00CD511E8111 for ; Tue, 2 Jul 2013 18:11:36 -0700 (PDT) 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 6+IBPqFHT2XX for ; Tue, 2 Jul 2013 18:11:31 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id A835611E810F for ; Tue, 2 Jul 2013 18:11:30 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuBbU-0001Xc-Qk; Tue, 02 Jul 2013 21:11:28 -0400 Date: Tue, 2 Jul 2013 21:11:28 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130703011128.GK31347@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: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 01:11:36 -0000 Paul Hoffman scripsit: > Proposal 1: > > In section 2.2 (Grammar -> Objects): > No change > In section 4 (Parsers): > Add: "If a parser encounters an object with duplicate names, the parser MUST use only the last > name/value pair that has the duplicate name. I object to this, because it is unclear what "use" means. If it means "report to the application", then a streaming parser cannot do this without ceasing to be streaming: that is, it must buffer up the whole object in order to be sure not to report any inappropriate pairs. If "use" means something else, it must be explained more clearly. > In section 5 (Generators): > Add: "The names within an object SHOULD be unique." I approve of this. However, an additional sentence is required to explain which names are distinct and which are not. > Proposal 2: > > Same as Proposal 1 *except* that a second sentence is added for section 4: "A parser that streams > its outputs MUST fail to finish parsing if it encounters more than one name/value pair with the > same name." This puts only a slightly lower burden on streaming parsers: they now do not need to buffer up the whole object, but may report it on the fly, keeping track of the names already seen in order to fail if one of them is a duplicate. I still think this burden is excessive. I therefore propose that nothing be said about parsers, but that generators SHOULD NOT generate duplicate names, where "duplicate" is defined to mean consisting of the same code points or scalar values, as the case may be, in the same order. -- 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 cowan@ccil.org Tue Jul 2 18:26: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 8F0F411E8128 for ; Tue, 2 Jul 2013 18:26:19 -0700 (PDT) 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 vPooTWKss7xL for ; Tue, 2 Jul 2013 18:26:15 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 41F9411E8111 for ; Tue, 2 Jul 2013 18:26:15 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuBpm-0002zL-Dq; Tue, 02 Jul 2013 21:26:14 -0400 Date: Tue, 2 Jul 2013 21:26:14 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130703012614.GL31347@mercury.ccil.org> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 03 Jul 2013 01:26:19 -0000 Paul Hoffman scripsit: > Proposal 1 (allow all code units in their unescaped form): > > A string is a sequence of zero or more Unicode code units [UNICODE]. I object to this, because "code unit" is not well defined without mentioning its size. I suppose it is 16-bit code units that are meant, but if so, that must be said. "If Parliament does not mean what it says, it must say so." > In section 2.2 (Strings): > Leave the production for "unescaped" as-is. > In section 3 (Encoding): > Add "Some strings, notably those that have unescaped surrogate code units > (value 0xD800 to 0xDFFF), cannot be encoded in UTF-8." While this statement is true, it is not the whole truth, which is that unescaped surrogate code units cannot be encoded in *any* encoding. Indeed, it is useless to permit unescaped surrogate code units at all. Therefore, I reject this proposal in toto. > Proposal 2 (prohibit unescaped surrogates): > > In section 1 (Introduction): > A string is a sequence of zero or more Unicode scalar values [UNICODE]. > In section 2.2 (Strings): > Change the production for "unescaped" to be: > unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF I approve of this proposal. -- John Cowan cowan@ccil.org http://ccil.org/~cowan "The exception proves the rule." Dimbulbs think: "Your counterexample proves my theory." Latin students think "'Probat' means 'tests': the exception puts the rule to the proof." But legal historians know it means "Evidence for an exception is evidence of the existence of a rule in cases not excepted from." From cowan@ccil.org Tue Jul 2 20:02:03 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 8F70811E8135 for ; Tue, 2 Jul 2013 20:02:03 -0700 (PDT) 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 1Bbg5ebQtSxP for ; Tue, 2 Jul 2013 20:01:59 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB9521F9971 for ; Tue, 2 Jul 2013 20:01:59 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuDKP-0003Rt-UE for json@ietf.org; Tue, 02 Jul 2013 23:01:57 -0400 Date: Tue, 2 Jul 2013 23:01:57 -0400 From: John Cowan To: json@ietf.org Message-ID: <20130703030157.GR31347@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Subject: [Json] Streaming JSON parsers 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, 03 Jul 2013 03:02:03 -0000 I was asked in private mail if there actually were any streaming JSON parsers. I googled for that phrase, and immediately found that mentions at least eight of them: Jackson, Json-simple, Gson, YAJL, Clarinet, LitJSON, the JSON Streaming Parser for PHP, and Software Monkey's parser (the last two appear not to have names). I have not verified this claim. It was suggested to me that list members may not be aware of this. -- Principles. You can't say A is John Cowan made of B or vice versa. All mass http://www.ccil.org/~cowan is interaction. --Richard Feynman From paul.hoffman@vpnc.org Tue Jul 2 20:07: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 8326B11E8135 for ; Tue, 2 Jul 2013 20:07:32 -0700 (PDT) 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 gbGH4BH7bBLo for ; Tue, 2 Jul 2013 20:07:32 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 002FD21F9B0A for ; Tue, 2 Jul 2013 20:07:31 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r6337UV9022107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 2 Jul 2013 20:07:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130703012614.GL31347@mercury.ccil.org> Date: Tue, 2 Jul 2013 20:07:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2CD8DA4E-8E03-4B4A-AC99-166B7094DCF9@vpnc.org> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> <20130703012614.GL31347@mercury.ccil.org> To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1508) Subject: Re: [Json] Proposed minimal change for strings 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, 03 Jul 2013 03:07:32 -0000 On Jul 2, 2013, at 6:26 PM, John Cowan wrote: > Paul Hoffman scripsit: >=20 >> Proposal 1 (allow all code units in their unescaped form): >>=20 >> A string is a sequence of zero or more Unicode code units = [UNICODE]. >=20 > I object to this, because "code unit" is not well defined without > mentioning its size. I suppose it is 16-bit code units that are = meant, > but if so, that must be said. "If Parliament does not mean what it = says, > it must say so." It does not appear that the Unicode Standard requires mentioning its = size, at least in the definition of "code unit" in D77. >> In section 2.2 (Strings): >> Leave the production for "unescaped" as-is. >> In section 3 (Encoding): >> Add "Some strings, notably those that have unescaped surrogate code = units >> (value 0xD800 to 0xDFFF), cannot be encoded in UTF-8." >=20 > While this statement is true, it is not the whole truth, which is that > unescaped surrogate code units cannot be encoded in *any* encoding. John is correct. After further review, we should have worded the above = as "...cannot be encoded in any Unicode encoding form". --Paul Hoffman= From nico@cryptonector.com Tue Jul 2 20:30: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 4326D11E814D for ; Tue, 2 Jul 2013 20:30:53 -0700 (PDT) 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=-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 UBE4OCCqPgHc for ; Tue, 2 Jul 2013 20:30:48 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC2711E8149 for ; Tue, 2 Jul 2013 20:30:48 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 1A0947E406F for ; Tue, 2 Jul 2013 20:30:48 -0700 (PDT) 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=QRUZM0hT0Cc1ywk3MAic 2D6b5aA=; b=UpWs09z2DLMTRH0E52Gf9TSyxggFT4d4/ULdCxOtpsOCu5/8re4A zUnWG+DUL5Hgg9T0RnqDNDrVS9Ty7symTrNna2tnWEBQZ3Fywx3gEXNHZztYF8JJ 7imcYIMeWPPNV92vBf6UYDFFfZ21iL6eh6SkcVQk8eEKIimPYnMkaCQ= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id BA0817E4065 for ; Tue, 2 Jul 2013 20:30:47 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so4779701wes.41 for ; Tue, 02 Jul 2013 20:30:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6+Z1r8tCmlQCzrKMtuUHDlYh7n9+cok5aRKvlcdBR1E=; b=LL1WA71FyHhSZija2S05I1pHPL81DcD4MgublO7209EsTC8TFc1yt1ygRtM2S6UAsj lyWsaO6xPY7E9WTLhNkaxli4VWhi4VYzKcK93vPFkTB6f68FdC23zz6OCingwJEV46EH COBnUOy1r5PxuLuVzm5t2hLryfpXZqVKlXCzIqYo3LQHC6TV+ildIZJZCaUm36exBvSm ebMLr/PQv4A6DrpjhYg41aVasTamnT+v+vbm/r8XMw2qSV/j7eY/R5mcClldBJ+oL37O t5D61lc8neMkk89KnsH/chKI1H7clO2CgdJmquZ8YBvN+a3O7edfhnaU1aB4YcHdGpgS saTQ== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr16839760wiw.28.1372822246244; Tue, 02 Jul 2013 20:30:46 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Tue, 2 Jul 2013 20:30:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jul 2013 22:30:46 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 03:30:53 -0000 On Tue, Jul 2, 2013 at 6:25 PM, Paul Hoffman wrote: > > > Do either or both of these proposals work for people in the WG? No way. The threads on this were long, I know, but it should be clear that streaming parsers cannot even detect that there are duplicates, much less do something about them. In short, for streaming parsers (and generators) there's nothing we can do. What we can do is RECOMMEND that a) generators not produce duplicates (and explain how streaming ones cannot prevent dups), and b) that parsers use the last name (and explain how streaming ones will produce all dups). (We might as well point out that some parsers produce the first name, but I don't mind saying those are on the wrong side of this SHOULD.) Nico -- From nico@cryptonector.com Tue Jul 2 20:44: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 BC24B21F9950 for ; Tue, 2 Jul 2013 20:44:21 -0700 (PDT) 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=-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 hL1fqlCzMRVX for ; Tue, 2 Jul 2013 20:44:16 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2721F8C4B for ; Tue, 2 Jul 2013 20:44:16 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id A60ADB806B for ; Tue, 2 Jul 2013 20:44:16 -0700 (PDT) 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=q4B0kjJ+n+MseCxinMuv ZA2iiUI=; b=M3aVA0V1j1/lV5tO8199SaRVfRDWFr8icRSEDskY5skSlUIGW+mE p3I//Qj756yILyN5MHBXMV0CiXhV/wBnL+DeL3q6QHCmsYmfh3zBe5h1VQYUbqUp 4SoBug8ocsqjaTPytwnDWPg8PkURcLcyEckcc13t4UXk95mMrqaS1XE= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 5A8FFB805C for ; Tue, 2 Jul 2013 20:44:16 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so5353414wgh.14 for ; Tue, 02 Jul 2013 20:44:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=heX7D/KW8i5Px0l8dKIJEpe+Bgn+EymQDI6NAjldyoA=; b=O6eYdFki9EUgebepDPnmmyE7U2C5tT78W9zf1Fi9j9Y9v7rTIsJMSGWTISYY1wYda+ IjD2F5tOgfuhy+4/57h/Vs9IdT14dotrjcF3oG27v3fsPMuG68cOT0TwE8i+IoDN1mFi pctZZiapotvKq8cTJkL3AxOv7TBxBeNVaxoO5JhJpJ9bYT/HnmwLFO9oV9DSUozpkzWi Y4R0RgTzyBDc5UTYdEoI3YkVIHZ8aHCFmiC84yJfifOk6YcmGbbJxSylGZC8h0NSfLzv uKCFIDCT7HJKuP4L8AfRF7qre1wYk2dGtJAWQCSr+oZI6xMqUk0InPZ+xgalXBJZUwgR HBlA== MIME-Version: 1.0 X-Received: by 10.194.7.137 with SMTP id j9mr25595317wja.11.1372823055023; Tue, 02 Jul 2013 20:44:15 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Tue, 2 Jul 2013 20:44:14 -0700 (PDT) In-Reply-To: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> Date: Tue, 2 Jul 2013 22:44:14 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 03 Jul 2013 03:44:21 -0000 On Tue, Jul 2, 2013 at 6:27 PM, Paul Hoffman wrote: > > > Do either or both of these proposals work for people in the WG? > > --Matt Miller and Paul Hoffman > > The following are proposed minimal changes to make the JSON spec interoperable with respect to > which unescaped code units are legal in strings. > > Proposal 1 (allow all code units in their unescaped form): Huh? Do you mean that any code unit may be allowed if escaped? Or did you really mean that any code unit may be sent unescaped? Certainly the latter would be bad (e.g., double-quotes and newline must be escaped at the very, very least). > In section 1 (Introduction): > Change the sentence about Unicode characters to: > A string is a sequence of zero or more Unicode code units [UNICODE]. These aren't Unicode things though. They are 16-bit values that usually can be interpreted as part of UTF-16-encoded Unicode text. > In section 2.2 (Strings): > Leave the production for "unescaped" as-is. > In section 3 (Encoding): > Add "Some strings, notably those that have unescaped surrogate code units > (value 0xD800 to 0xDFFF), cannot be encoded in UTF-8." Unescaped and *unpaired*. Note that parsers can unescape escaped characters/code points/code units, and many do. Therefore banning unescaped unpaired surrogate halves is not sufficient. We must say something about what parsers SHOULD do when they see these, whether escaped or unescaped. > Proposal 2 (prohibit unescaped surrogates): > > In section 1 (Introduction): > A string is a sequence of zero or more Unicode scalar values [UNICODE]. > In section 2.2 (Strings): > Change the production for "unescaped" to be: > unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF I don't think we need to make this change: parsers can be expected to do something with unpaired surrogate halves, like either throw them away or escape them (if it makes sense in whatever context the parser is executing in) or even output a binary string instead of a text string. Certainly, if we don't make this change, then we should say something about what parsers SHOULD do in the face of such things. Anyways, I'd +1 this, but we need to discuss what to do with these when they are escaped. Nico -- From James.H.Manger@team.telstra.com Tue Jul 2 20:56: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 EBAF411E815E for ; Tue, 2 Jul 2013 20:56:55 -0700 (PDT) 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=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 54hPqc9nN417 for ; Tue, 2 Jul 2013 20:56:49 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8215D11E8151 for ; Tue, 2 Jul 2013 20:56:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,985,1363093200"; d="scan'208";a="137318841" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 03 Jul 2013 13:56:37 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7124"; a="143113680" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbni.tcif.telstra.com.au with ESMTP; 03 Jul 2013 13:56:37 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Wed, 3 Jul 2013 13:56:37 +1000 From: "Manger, James H" To: Paul Hoffman , "json@ietf.org WG" Date: Wed, 3 Jul 2013 13:56:37 +1000 Thread-Topic: [Json] Proposed minimal change for strings Thread-Index: Ac53e7VCKrUVeAyrSO+04fT4GYGEyAAImh6w Message-ID: <255B9BB34FB7D647A506DC292726F6E1151C10CC2D@WSMSG3153V.srv.dir.telstra.com> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> In-Reply-To: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] Proposed minimal change for strings 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, 03 Jul 2013 03:56:56 -0000 PiA8Y2hhaXIgaGF0cyBvbj4NCj4gDQo+IERvIGVpdGhlciBvciBib3RoIG9mIHRoZXNlIHByb3Bv c2FscyB3b3JrIGZvciBwZW9wbGUgaW4gdGhlIFdHPw0KPiANCj4gLS1NYXR0IE1pbGxlciBhbmQg UGF1bCBIb2ZmbWFuDQo+IA0KPiBUaGUgZm9sbG93aW5nIGFyZSBwcm9wb3NlZCBtaW5pbWFsIGNo YW5nZXMgdG8gbWFrZSB0aGUgSlNPTiBzcGVjDQo+IGludGVyb3BlcmFibGUgd2l0aCByZXNwZWN0 IHRvIHdoaWNoIHVuZXNjYXBlZCBjb2RlIHVuaXRzIGFyZSBsZWdhbCBpbg0KPiBzdHJpbmdzLg0K PiANCj4gUHJvcG9zYWwgMSAoYWxsb3cgYWxsIGNvZGUgdW5pdHMgaW4gdGhlaXIgdW5lc2NhcGVk IGZvcm0pOg0KPiANCj4gSW4gc2VjdGlvbiAxIChJbnRyb2R1Y3Rpb24pOg0KPiAgIENoYW5nZSB0 aGUgc2VudGVuY2UgYWJvdXQgVW5pY29kZSBjaGFyYWN0ZXJzIHRvOg0KPiAgICAgQSBzdHJpbmcg aXMgYSBzZXF1ZW5jZSBvZiB6ZXJvIG9yIG1vcmUgVW5pY29kZSBjb2RlIHVuaXRzDQo+IFtVTklD T0RFXS4NCj4gSW4gc2VjdGlvbiAyLjIgKFN0cmluZ3MpOg0KPiAgIExlYXZlIHRoZSBwcm9kdWN0 aW9uIGZvciAidW5lc2NhcGVkIiBhcy1pcy4NCj4gSW4gc2VjdGlvbiAzIChFbmNvZGluZyk6DQo+ ICAgQWRkICJTb21lIHN0cmluZ3MsIG5vdGFibHkgdGhvc2UgdGhhdCBoYXZlIHVuZXNjYXBlZCBz dXJyb2dhdGUgY29kZQ0KPiB1bml0cw0KPiAgICh2YWx1ZSAweEQ4MDAgdG8gMHhERkZGKSwgY2Fu bm90IGJlIGVuY29kZWQgaW4gVVRGLTguIg0KPiANCj4gUHJvcG9zYWwgMiAocHJvaGliaXQgdW5l c2NhcGVkIHN1cnJvZ2F0ZXMpOg0KPiANCj4gSW4gc2VjdGlvbiAxIChJbnRyb2R1Y3Rpb24pOg0K PiAgIEEgc3RyaW5nIGlzIGEgc2VxdWVuY2Ugb2YgemVybyBvciBtb3JlIFVuaWNvZGUgc2NhbGFy IHZhbHVlcw0KPiBbVU5JQ09ERV0uDQo+IEluIHNlY3Rpb24gMi4yIChTdHJpbmdzKToNCj4gICBD aGFuZ2UgdGhlIHByb2R1Y3Rpb24gZm9yICJ1bmVzY2FwZWQiIHRvIGJlOg0KPiAgICAgdW5lc2Nh cGVkID0gJXgyMC0yMSAvICV4MjMtNUIgLyAleDVELUQ3RkYgLyAleEUwMDAtMTBGRkZGDQoNCg0K WWVzLCBwcm9wb3NhbCAyIHdvcmtzIGZvciBtZS4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From cowan@ccil.org Tue Jul 2 21:41: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 6086E11E8166 for ; Tue, 2 Jul 2013 21:41:57 -0700 (PDT) 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 lh7fLcR6VPwY for ; Tue, 2 Jul 2013 21:41:53 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1203411E80A5 for ; Tue, 2 Jul 2013 21:41:52 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuEt4-0004aR-Ar; Wed, 03 Jul 2013 00:41:50 -0400 Date: Wed, 3 Jul 2013 00:41:50 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130703044150.GW31347@mercury.ccil.org> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> <20130703012614.GL31347@mercury.ccil.org> <2CD8DA4E-8E03-4B4A-AC99-166B7094DCF9@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2CD8DA4E-8E03-4B4A-AC99-166B7094DCF9@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 03 Jul 2013 04:41:57 -0000 Paul Hoffman scripsit: > It does not appear that the Unicode Standard requires mentioning its > size, at least in the definition of "code unit" in D77. That is so. But are we to understand, then, that a JSON string is a sequence of code units of some unspecified size? For example, is the 8-bit code unit sequence a JSON string? How about the 32-bit code unit sequence ? Might 3-bit or 17-bit or 99-bit code unit sequences be allowed also? Surely not. > John is correct. After further review, we should have worded the above > as "...cannot be encoded in any Unicode encoding form". As noted, that should have been "unpaired unescaped surrogate code units". -- John Cowan cowan@ccil.org http://ccil.org/~cowan If I have seen farther than others, it is because I was standing on the shoulders of giants. --Isaac Newton From cowan@ccil.org Tue Jul 2 21:53: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 E6ACF21F99D1 for ; Tue, 2 Jul 2013 21:53:54 -0700 (PDT) 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 LK2XVEinYXvw for ; Tue, 2 Jul 2013 21:53:37 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8B30121F99CF for ; Tue, 2 Jul 2013 21:53:37 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuF4R-0005eh-H5; Wed, 03 Jul 2013 00:53:35 -0400 Date: Wed, 3 Jul 2013 00:53:35 -0400 From: John Cowan To: Nico Williams Message-ID: <20130703045335.GX31347@mercury.ccil.org> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@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: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 03 Jul 2013 04:53:55 -0000 Nico Williams scripsit: > Note that parsers can unescape escaped characters/code points/code > units, and many do. Therefore banning unescaped unpaired surrogate > halves is not sufficient. We must say something about what parsers > SHOULD do when they see these, whether escaped or unescaped. Parsers may safely report 16-bit code units as 16-bit unsigned integers. -- Verbogeny is one of the pleasurettes John Cowan of a creatific thinkerizer. http://www.ccil.org/~cowan --Peter da Silva From tbray@textuality.com Tue Jul 2 22:01: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 3A6F221F9B0F for ; Tue, 2 Jul 2013 22:01:46 -0700 (PDT) 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 0SjT4eCnbiUG for ; Tue, 2 Jul 2013 22:01:40 -0700 (PDT) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3063021F9AE9 for ; Tue, 2 Jul 2013 22:01:40 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id pb11so5626153veb.9 for ; Tue, 02 Jul 2013 22:01:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=lNfXBvufsZKQrpTJS8IFDfRAno0o9zXjOVRHzEl8gi0=; b=k/981xL9S6IqshOj5xs7ZgyH55/Ea+N4w2nP25drZpoxznrJXLqlvRkMtBBxzJo/y/ 2gvf8S+ki8xmfv+01DFkV3LaX9pN2Kiho7wm3k0c+Wc3TS4x5vM8vuRbT8ooXaxCQSgi QC47zmd6e9hk7Hq/x2R6vyZ0kAPDvlOC1gJr85RGzwxQgCSXevHJY2nBZPtfvWsqD1aM RtgaC7M28sRxmTigH3yqyqgG7WN+bXNls+IL5rH+BKbkNIUFE27QdVUIs2VY4+Ym6Fy7 Umkc+mNb9QsukZGA6YlmeIU5MMYQNdWFUBjI1RVIhb/e7EMjoqDSwcYCDH9JGng+NTR+ vq5w== MIME-Version: 1.0 X-Received: by 10.58.2.137 with SMTP id 9mr325502veu.50.1372827699450; Tue, 02 Jul 2013 22:01:39 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Tue, 2 Jul 2013 22:01:38 -0700 (PDT) X-Originating-IP: [209.121.225.215] Date: Tue, 2 Jul 2013 22:01:38 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e75cc5d257d04e0945b81 X-Gm-Message-State: ALoCoQlWVzdRrdl09BkNNBOfVP6QPMLADOV18oIotkSXQ7cL1dZ74VfPCKwVwzH1xQ2HpHdDGUae Subject: [Json] What are we trying to do? 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, 03 Jul 2013 05:01:46 -0000 --047d7b2e75cc5d257d04e0945b81 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m having trouble dealing with the recent proposals from our co-ch= airs because I don=E2=80=99t think I understand what they=E2=80=99re trying to a= chieve. Just to refresh, our charter says =E2=80=9CThe work is essentially a reclassification in place, with minimal = changes. The working group will eview errata and update the document as needed to incorporate those, and will correct significant errors and inconsistencies, but will keep changes to a minimum. It is acknowledged that there are differences between RFC 4627 and the ECMAScript specification in the rules for parsing JSON. 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. =E2=80=9D The changes proposed by the chairs are pretty big. Maybe the problem is that any change which would actually CORRECT the two biggest errors/inconsistencies in 4267 would necessarily be pretty significant. When your charter is self-contradictory, you can either re-charter or decide to ignore one of the two contradictory directives. I was getting really comfortable with the minimal proposal, which noted that while the spec more or less means what it says (strings should be Unicode, objects should have unique keys), there are other standards with different interpretations. Also, there is variation among observed behavior in software, when the JSON RFC=E2=80=99s high-level directives are contravened. What the industry really needs is a document normatively describing JSON-as-best-practiced, with an RFC number. It would say that senders MUST NOT do X and Y, and that receivers, upon encountering X OR Y, MUST DO Z. Thus other spec writers can say =E2=80=9CDo what RFCXXXX says=E2=80=9D and= not have to resort to the sort of drafting pain that the people in Jose are experiencing right now in order to avoid attacks on cryptographically signed protocol elements by exploiting variation in dupe-key handling. Is it the sense of the WG that such a document is within our mandate? -T --047d7b2e75cc5d257d04e0945b81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99m having trouble dealing with the recent pr= oposals from our co-chairs because I don=E2=80=99t think I understand what = they=E2=80=99re trying to achieve.=C2=A0 Just to refresh, our charter says =

=E2=80=9CThe work is essentially a reclassification in place, with = minimal changes. The working group will=C2=A0=C2=A0 eview errata and update= the document as needed to incorporate those, and will correct significant= =C2=A0 errors and inconsistencies, but will keep changes to a minimum.

It is acknowledged that there are differences between RFC 4627 and the = ECMAScript specification=C2=A0 in the rules for parsing JSON. Any changes t= hat break compatibility with existing implementations of=C2=A0 either RFC 4= 627 or the ECMAScript specification will need to have very strong justifica= tion and broad support. =E2=80=9D

The changes proposed by the chairs are pretty big. Maybe the= problem is that any change which would actually CORRECT the two biggest er= rors/inconsistencies in 4267 would necessarily be pretty significant. When = your charter is self-contradictory, you can either re-charter or decide to = ignore one of the two contradictory directives.

I was getting really comfortable with the minimal proposal, = which noted that while the spec more or less means what it says (strings sh= ould be Unicode, objects should have unique keys), there are other standard= s with different interpretations.=C2=A0 Also, there is variation among obse= rved behavior in software, when the JSON RFC=E2=80=99s high-level directive= s are contravened.

What the industry really needs is a document normatively des= cribing JSON-as-best-practiced, with an RFC number.=C2=A0 It would say that= senders MUST NOT do X and Y, and that receivers, upon encountering X OR Y,= MUST DO Z.=C2=A0 Thus=C2=A0 other spec writers can say =E2=80=9CDo what RF= CXXXX says=E2=80=9D and not have to resort to the sort of drafting pain tha= t the people in Jose are experiencing right now in order to avoid attacks o= n cryptographically signed protocol elements by exploiting variation in dup= e-key handling.

Is it the sense of the WG that such a document is within our= mandate?=C2=A0 -T
--047d7b2e75cc5d257d04e0945b81-- From stefan@drees.name Tue Jul 2 22:23: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 3EF1A21F9CDE for ; Tue, 2 Jul 2013 22:23:00 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 fa2-y8ofLR65 for ; Tue, 2 Jul 2013 22:22:54 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3938621F9CDA for ; Tue, 2 Jul 2013 22:22:53 -0700 (PDT) Received: from newyork.local.box ([93.129.117.152]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0MgwO8-1UYIpc0ZFY-00M7Vm; Wed, 03 Jul 2013 07:22:49 +0200 Message-ID: <51D3B527.1090200@drees.name> Date: Wed, 03 Jul 2013 07:22:47 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Cowan References: <20130703011128.GK31347@mercury.ccil.org> In-Reply-To: <20130703011128.GK31347@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0://+/mY7+Expro2qg8Op4aFmXMZXF0/eaGuDUPT8xuab4F5c+KN5 hCLCpXrSeGsvD1JIPDXLyCTcOhyTLFpJUVbttLkfVk1B87ZDyTyfHswAqTOPHnUz4wiaR5k vdLMhg+jVwq+O/PHjMpU2iFS7e8im86gnGz+X7bynbXpY4U+FN/BVBGSRF7r/6KqFJbNepX Q7OJ7sLNSaXz+GLH8IMwg== Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 05:23:00 -0000 I fully second the below points that John makes. {"Stefan":true} Am 03.07.13 03:11, schrieb John Cowan: > Paul Hoffman scripsit: > >> Proposal 1: >> >> In section 2.2 (Grammar -> Objects): >> No change >> In section 4 (Parsers): >> Add: "If a parser encounters an object with duplicate names, the parser MUST use only the last >> name/value pair that has the duplicate name. > > I object to this, because it is unclear what "use" means. If it means > "report to the application", then a streaming parser cannot do this > without ceasing to be streaming: that is, it must buffer up the whole > object in order to be sure not to report any inappropriate pairs. > If "use" means something else, it must be explained more clearly. > >> In section 5 (Generators): >> Add: "The names within an object SHOULD be unique." > > I approve of this. However, an additional sentence is required to explain > which names are distinct and which are not. > >> Proposal 2: >> >> Same as Proposal 1 *except* that a second sentence is added for section 4: "A parser that streams >> its outputs MUST fail to finish parsing if it encounters more than one name/value pair with the >> same name." > > This puts only a slightly lower burden on streaming parsers: they now > do not need to buffer up the whole object, but may report it on the fly, > keeping track of the names already seen in order to fail if one of them > is a duplicate. I still think this burden is excessive. > > I therefore propose that nothing be said about parsers, but that generators > SHOULD NOT generate duplicate names, where "duplicate" is defined to mean > consisting of the same code points or scalar values, as the case may be, > in the same order. > From peter.h.m.brooks@gmail.com Tue Jul 2 22:32:10 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 3861021F9C69 for ; Tue, 2 Jul 2013 22:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=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 9pzpP9LNumL1 for ; Tue, 2 Jul 2013 22:32:09 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7D19621F9C66 for ; Tue, 2 Jul 2013 22:32:09 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so5141914wgg.0 for ; Tue, 02 Jul 2013 22:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=TkfmYShkI76dc5dXX+5l8hE89HfAZxOEjPt3/yHwkOU=; b=uADis82/gljII61rt11RMsbLkFrGpoaUp2gXaK6KV2DKQcwZ47nrgIzk3RYGyBT4fc SiA/1wVBNE7+3FjDNYPQXqlUubm9NkmAbXgkCQU3IYBTIf7+2hVIxxAgpIh/FqvAmcxv X3cvTiFZiaFkOzgAq90ClopOQxYuzPZhiO8QT+AMZL2S2hkwsTRLHdXroEMkHbB3V7Hr jHjL2RMd82PHaN87UmqoY1KgniuU7AsOrrw/1thMFXBLiSJyb2q0dTWHGAoJEGFM32/n 7jg1bbget+Y3h82HUJVPFOrDJeSHNkex3xj9DktYLrb+nYhCIeU7OHiM7DTiYwFrTy7Y zMlg== X-Received: by 10.180.21.209 with SMTP id x17mr17018042wie.47.1372829527442; Tue, 02 Jul 2013 22:32:07 -0700 (PDT) Received: from [105.251.10.36] ([105.251.10.36]) by mx.google.com with ESMTPSA id nb12sm26392926wic.7.2013.07.02.22.32.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 22:32:06 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=cp932 Message-Id: <10069A61-7DDC-4CCA-BA30-A12C0CFECD4E@gmail.com> X-Mailer: iPad Mail (10B329) From: Peter brooks Date: Wed, 3 Jul 2013 07:32:00 +0200 To: Tim Bray Cc: "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 03 Jul 2013 05:32:10 -0000 Excellent points, Tim! I support this. Sent from my iPad On 3 Jul 2013, at 07:01, Tim Bray wrote: > I=81fm having trouble dealing with the recent proposals from our co-chairs= because I don=81ft think I understand what they=81fre trying to achieve. J= ust to refresh, our charter says=20 >=20 > =81gThe work is essentially a reclassification in place, with minimal chan= ges. The working group will eview errata and update the document as needed= to incorporate those, and will correct significant errors and inconsistenc= ies, but will keep changes to a minimum. >=20 > It is acknowledged that there are differences between RFC 4627 and the ECM= AScript specification in the rules for parsing JSON. Any changes that break= compatibility with existing implementations of either RFC 4627 or the ECMA= Script specification will need to have very strong justification and broad s= upport. =81h >=20 > The changes proposed by the chairs are pretty big. Maybe the problem is th= at any change which would actually CORRECT the two biggest errors/inconsiste= ncies in 4267 would necessarily be pretty significant. When your charter is s= elf-contradictory, you can either re-charter or decide to ignore one of the t= wo contradictory directives. >=20 > I was getting really comfortable with the minimal proposal, which noted th= at while the spec more or less means what it says (strings should be Unicode= , objects should have unique keys), there are other standards with different= interpretations. Also, there is variation among observed behavior in softw= are, when the JSON RFC=81fs high-level directives are contravened. >=20 > What the industry really needs is a document normatively describing JSON-a= s-best-practiced, with an RFC number. It would say that senders MUST NOT do= X and Y, and that receivers, upon encountering X OR Y, MUST DO Z. Thus ot= her spec writers can say =81gDo what RFCXXXX says=81h and not have to resort= to the sort of drafting pain that the people in Jose are experiencing right= now in order to avoid attacks on cryptographically signed protocol elements= by exploiting variation in dupe-key handling. >=20 > Is it the sense of the WG that such a document is within our mandate? -T > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From stefan@drees.name Tue Jul 2 22:44: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 09B8D21F9017 for ; Tue, 2 Jul 2013 22:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_57=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 DekNlgi25FpO for ; Tue, 2 Jul 2013 22:44:21 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 73CD221F8F4A for ; Tue, 2 Jul 2013 22:44:20 -0700 (PDT) Received: from newyork.local.box ([93.129.117.152]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0MFvnC-1Uz9g12tcs-00EvYM; Wed, 03 Jul 2013 07:44:00 +0200 Message-ID: <51D3BA1E.30401@drees.name> Date: Wed, 03 Jul 2013 07:43:58 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Cowan References: <20130703030157.GR31347@mercury.ccil.org> In-Reply-To: <20130703030157.GR31347@mercury.ccil.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:k7lPjidiqo8Jsxd9JzISSyOTU2clrnIuqXp8lUXxv3kaNW4UoPy obY3gN7y3CldrgVNQK1c0boY89MQCuiRmrTd6oQBE9ANNMz/yZ4wyoTWRs07ZreYIyGiKql RdWyZ/T5YF8ehRByfrYkqBNcSO1THiuZwfvo1lAVQkWdwFeFHjHXlZO8qMAhyUBmSKg97+s zPb8RQAstgzZCFVBEodkg== Cc: json@ietf.org Subject: Re: [Json] Streaming JSON parsers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 05:44:26 -0000 On 2013-07-03 05:01 +02:00, John Cowan wrote: > I was asked in private mail if there actually were any streaming JSON > parsers. I googled for that phrase, and immediately found that > > mentions at least eight of them: Jackson, Json-simple, Gson, YAJL, > Clarinet, LitJSON, the JSON Streaming Parser for PHP, and Software > Monkey's parser (the last two appear not to have names). I have not > verified this claim. > > It was suggested to me that list members may not be aware of this. > also while developing the version 4.0 Open Data specification at OASIS extra care is taken to ease the life for streaming JSON parsers, where the main notion for streaming there indicates at least stable ordering of names in objects and preferrably the semantically most useful ordering (for processing on the client side). As OData defines a base protocol to deliver even high volume data (including navigateable metadata) this is important for most usage scenarios out in the wild. The current second committee specification draft (going into public review this week) states eg. in section 2 "JSON Format Design" """ JSON, as described in [RFC4627], defines a text format for serializing structured data. Objects are serialized as an unordered collection of name-value pairs. JSON does not define any semantics around the name/value pairs that make up an object, nor does it define an extensibility mechanism for adding control information to a payload. OData’s JSON format extends JSON by defining general conventions for name-value pairs that annotate a JSON object, property or array. OData defines a set of canonical annotations for control information such as ids, types, and links, and custom annotations MAY be used to add domain-specific information to the payload. [...] To optimize streaming scenarios, there are a few restrictions that MAY be imposed on the sequence in which name/value pairs appear within JSON objects. """ And esp. in section 4.4 "Payload Ordering Constraints" this: """ Ordering constraints MAY be imposed on the JSON payload in order to support streaming scenarios. These ordering constraints MUST only be assumed if explicitly specified as some clients (and services) might not be able to control, or might not care about, the order of the JSON properties in the payload. Clients can request that a JSON response conform to these ordering constraints by specifying a media type of application/json with the odata.streaming=true parameter in the Accept header or $format query option. Services MUST return 406 Not Acceptable if the client only requests streaming and the service does not support it. Processors MUST only assume streaming support if it is explicitly indicated in the Content-Type header via the odata.streaming=true parameter. Example 3: a payload with Content-Type: application/json;odata.metadata=minimal;odata.streaming=true can be assumed to support streaming, whereas a payload with Content-Type: application/json;odata.metadata=minimal cannot be assumed to support streaming. JSON producers are encouraged to follow the payload ordering constraints whenever possible (and include the odata.streaming=true content type parameter) to support the maximum set of client scenarios. To support streaming scenarios the following payload ordering constraints have to be met: * If present, the odata.context annotation MUST be the first property in the JSON object. * The odata.type annotation, if present, MUST appear next in the JSON object. * The odata.id and odata.etag annotations MUST appear before any property or property annotation. * All annotations for a structural or navigation property MUST appear as a group immediately before the property they annotate. The one exception is the odata.nextlink annotation of an expanded collection which MAY appear after the navigation property it annotates. * All other odata annotations can appear anywhere in the payload as long as they do not violate any of the above rules. * Annotations for navigation properties MUST appear after all structural properties. """ URL: https://www.oasis-open.org/committees/document.php?document_id=49674&wg_abbrev=odata I cited quite greedily because the URL points to a zip file containing a document in the OfficeXML format, which might not be the most directly accessible format for everyone on the list wanting to just skim through. {"Stefan":true} From lear@cisco.com Tue Jul 2 23:35: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 CD8F121F9D15 for ; Tue, 2 Jul 2013 23:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.317 X-Spam-Level: X-Spam-Status: No, score=-110.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 x4M3KwLuBvKc for ; Tue, 2 Jul 2013 23:35:45 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id CF22421F9CF3 for ; Tue, 2 Jul 2013 23:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=727; q=dns/txt; s=iport; t=1372833344; x=1374042944; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=v/AuofiWmRYIXm5DCzuPQsV2GVaTWFPJe9cULqEws0M=; b=FQ/b5mibJ/lC4Abk2Z7M0Onsgc3IrftdshrAxBlqYbyVtHBAtxOzOt34 eJs4hQCE128lXVdmdDelhRNy96aVJwOgW2e9kVC8hVMRCnOlTbSCwGZMB Vk5cNmVan0QA9HwrbQjOwj7R04K87kDdjbDXCRr6M1T+FHsW5WFtvfCWr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0JAHLF01GQ/khR/2dsb2JhbABagwmEAr0SBAQBgQAWdIIkAQEEI1UBEAsaAgUWCwICCQMCAQIBKxoGDQEHAQGIC6oTkR6BJo4/B4JRgRwDl0qRRYMTOg X-IronPort-AV: E=Sophos;i="4.87,986,1363132800"; d="scan'208";a="15253423" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 03 Jul 2013 06:35:43 +0000 Received: from mctiny.local ([10.61.175.226]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r636Zegb005371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 06:35:41 GMT Message-ID: <51D3C63C.5030703@cisco.com> Date: Wed, 03 Jul 2013 08:35:40 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 06:35:51 -0000 Nico, > > In short, for streaming parsers (and generators) there's nothing we can do. > > What we can do is RECOMMEND that a) generators not produce duplicates > (and explain how streaming ones cannot prevent dups), and b) that > parsers use the last name (and explain how streaming ones will produce > all dups). To me this isn't strong enough. I have some sympathy for both the existing base and for parsers, but generators as an architectural component should generate unambiguous output, streaming or otherwise. And that follow's Postel's Law: "In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior." -- RFC 791 Section 3.2 Eliot From nico@cryptonector.com Tue Jul 2 23:37: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 0A28311E816F for ; Tue, 2 Jul 2013 23:37:13 -0700 (PDT) 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=-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 J6yGv4SkT4hg for ; Tue, 2 Jul 2013 23:37:08 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9F121F9D15 for ; Tue, 2 Jul 2013 23:37:08 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 750546B0070 for ; Tue, 2 Jul 2013 23:37:01 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=1wfea5abY9oGhE47//HvT/43Xnc=; b=bEQg1k3Xxu2 BQn7dIWKSWDGWAaLRvoRA6tvdCIqlsJLWqOtMUvz/fF3xTQpelGePh0xdlFAypuE 1FETiF/y1yLwXkenWyG5kODGLxgqv0OEMp0UP2hwdnBesWeCI/2vken123SdKWKb GBD3dzIyW3rs4V/jApmp++iSuQA2RqEM= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 29F9A6B0059 for ; Tue, 2 Jul 2013 23:37:01 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k14so5342393wgh.17 for ; Tue, 02 Jul 2013 23:36:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wMLkRbGiVs1jcoju30eFYxIhJVBdEYbp28NRcBqWWLk=; b=pnuxpjfT8mm3PLLEPRT08oGlnDNBvdap3kBUSa9hYCxs0/HdaMZgXS20lqzlKaquSB 79KI9nOMh3TonMbWWUAQ/DPCyP+UzQl0nJ+aVzpk+udGhaXRTpg5cRJsRlIJW1TtHbm3 kRuwdfl+ozNvjnK92MOwW618W1uC4KGR+BVy2LeHowF2vJtKwyii84QIA/fHr07jdiVp a7NVy/yJXwDe79PCOmANprR4sGfLXCqvCq6uFVcdtj5ZioopfCD0vBqVGe9t14rv4dG5 4IQbeYlZsfvrimfrluB59NXBpe90cupL7hZmmgWoVQhQit/IBWjJMT7z4AEwaEWNuVji 7P/w== MIME-Version: 1.0 X-Received: by 10.180.76.206 with SMTP id m14mr17091224wiw.38.1372833419316; Tue, 02 Jul 2013 23:36:59 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Tue, 2 Jul 2013 23:36:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 01:36:59 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 03 Jul 2013 06:37:13 -0000 On Wed, Jul 3, 2013 at 12:01 AM, Tim Bray wrote: > [...] +1. > What the industry really needs is a document normatively describing > JSON-as-best-practiced, with an RFC number. It would say that senders MU= ST > NOT do X and Y, and that receivers, upon encountering X OR Y, MUST DO Z. > Thus other spec writers can say =E2=80=9CDo what RFCXXXX says=E2=80=9D a= nd not have to > resort to the sort of drafting pain that the people in Jose are experienc= ing > right now in order to avoid attacks on cryptographically signed protocol > elements by exploiting variation in dupe-key handling. I'd be happy with either of: - no update to RFC4627, but a BCP, and possibly an FYI about what ECMAScript (and others) do, or - an update to RFC4627 noting the divergent interpretations and only absolute minimal normative language additions for which we have consensus (possibly none) (and remove the safe-for-eval regexp nonsense), plus a BCP. I might be happy with just concluding, but only as a last resort. > Is it the sense of the WG that such a document is within our mandate? -T We should recharter if it isn't, and either way we should then publish. If we can't either find it in the charter nor get consensus to re-charter then we should conclude (and take some more painkillers, then promptly forget this episode). So that's a big +1 from me. Nico -- From nico@cryptonector.com Tue Jul 2 23:45: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 A4F5A21F9A84 for ; Tue, 2 Jul 2013 23:45:26 -0700 (PDT) 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=[AWL=-0.000, 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 MQdeP+BYaKyF for ; Tue, 2 Jul 2013 23:45:21 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id C41C821F9C63 for ; Tue, 2 Jul 2013 23:45:21 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 30D0020203C for ; Tue, 2 Jul 2013 23:45:19 -0700 (PDT) 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=itr8nUQGeMQaxiYfnTjR QAlidr0=; b=gxy5+LEOe8632U2NAGqBBZWMGeXhIFgzxYMI7uEcqZxH96i5rQel QByIifRQZSvgmPK8NBC/rWvPbgmOfBIXkAZVRwbCiq89VyRqWGbSGwXsCgk9dmk1 n91fdn7N0gw7c9r1OoqHJDEMRa3enxlGxhSkeEvbcLhWdcdCMhmwPIA= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id BC968202038 for ; Tue, 2 Jul 2013 23:45:18 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so4820865wes.7 for ; Tue, 02 Jul 2013 23:45:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F8pZ8ecaZqAvK2il6Pm8BGEcKVMd6wXr7Q71jnwASvE=; b=FB0ZKNAVFmzIit91regdWgXO0e6DSFkgv/oNUMIkgDw+HAmDxrnHIkmiRY88eZNzrH JkbQBBieA3N7WCc45ZCLrd1s9kH4CgxJ1763BJKW3ClDnjaY9A6nhmSCClN7tAN5E5T/ PTW2IJcOB0ANfZDXWHyg49hoD7mdcZ7fMrdi6pxWa5KFgMWCDUSQRxOA7xYY4qU4d5dY NLfr+pv5NokIsUTKi+fqm+4c+WCl2+ZT3aZ0oCQTUDyrKRR0WdETdeyN5jFBTQqvnj5b MR9V/8JqhzM+MSgIReprC9hV/+dsQUmCzZkzfELBO0h345q6pAOjY8e4lOAndd56jZbV luIA== MIME-Version: 1.0 X-Received: by 10.180.84.193 with SMTP id b1mr8337182wiz.28.1372833917282; Tue, 02 Jul 2013 23:45:17 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Tue, 2 Jul 2013 23:45:17 -0700 (PDT) In-Reply-To: <51D3C63C.5030703@cisco.com> References: <51D3C63C.5030703@cisco.com> Date: Wed, 3 Jul 2013 01:45:17 -0500 Message-ID: From: Nico Williams To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 06:45:26 -0000 On Wed, Jul 3, 2013 at 1:35 AM, Eliot Lear wrote: >> In short, for streaming parsers (and generators) there's nothing we can do. >> >> What we can do is RECOMMEND that a) generators not produce duplicates >> (and explain how streaming ones cannot prevent dups), and b) that >> parsers use the last name (and explain how streaming ones will produce >> all dups). > > To me this isn't strong enough. I have some sympathy for both the > existing base and for parsers, but generators as an architectural > component should generate unambiguous output, streaming or otherwise. > And that follow's Postel's Law: How can a streaming generator do that? The API for one might look like: ObjectStart(context) ObjectAdd(context, name, value) ... There's no way a minimal-state streaming generator (but I repeat myself; the whole point of a streaming interface is to keep minimal state :) can detect duplicates with O(1) state (probabilistic structures with false positives won't be acceptable either). > "In general, an implementation must be conservative in its sending > behavior, and liberal in its receiving behavior." I've seen this maligned too. How many times have we heard this as a root cause of security vulnerabilities on receiver sides? We should be much more exacting, but in *this* case we can't be. It's not a question of what is ideal... If we were starting from scratch we might forbid O(1) state generators and even parsers. But it's too late for that and we have consensus to achieve. BTW, we're retreading. We should try not to, but it's difficult to avoid as no one can have read *every* post since the WG's inception. I think it's fair to say that on this issue there's no consensus to ban the bad behavior (duplicate names). Please don't blame me for that lack of consensus. Nico -- From lear@cisco.com Tue Jul 2 23:57: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 87ACD11E8166 for ; Tue, 2 Jul 2013 23:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.331 X-Spam-Level: X-Spam-Status: No, score=-110.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 1nefrLjdStir for ; Tue, 2 Jul 2013 23:57:26 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0C58811E8168 for ; Tue, 2 Jul 2013 23:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2754; q=dns/txt; s=iport; t=1372834646; x=1374044246; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Fny5qZ0RSDKcPAxekgZZmZhLfPZu1TqYRMC2qRRWqAk=; b=WZbBm+sxJph8UoieeW1E5IzTANx45MYMx4/I3TBfzLH5QVXtemA2kPTB kjvdzacUWid7mYQ/WeER0kxPcL6tDJtZ3teMCLECZ6jc+Gs23Ip2E2OFv mg2ykWieSsX4haqsCfX/YbdsAnX501kTHM71U9wYMa9hSTWlSqT2lsNxc g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOzK01GQ/khN/2dsb2JhbABagwmEAr0bgQAWdIIjAQEBAwEjVQEQCxgCAgUWCwICCQMCAQIBKxoGDQEFAgEBiAUGqX6RHoEmjj8HglGBHAOTd4NTkUWDEzo X-IronPort-AV: E=Sophos;i="4.87,986,1363132800"; d="scan'208";a="14783660" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 03 Jul 2013 06:57:24 +0000 Received: from mctiny.local ([10.61.175.226]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r636vMuC019790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 06:57:23 GMT Message-ID: <51D3CB52.7040902@cisco.com> Date: Wed, 03 Jul 2013 08:57:22 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: <51D3C63C.5030703@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 06:57:31 -0000 Hi Nico, On 7/3/13 8:45 AM, Nico Williams wrote: > On Wed, Jul 3, 2013 at 1:35 AM, Eliot Lear wrote: >>> In short, for streaming parsers (and generators) there's nothing we can do. >>> >>> What we can do is RECOMMEND that a) generators not produce duplicates >>> (and explain how streaming ones cannot prevent dups), and b) that >>> parsers use the last name (and explain how streaming ones will produce >>> all dups). >> To me this isn't strong enough. I have some sympathy for both the >> existing base and for parsers, but generators as an architectural >> component should generate unambiguous output, streaming or otherwise. >> And that follow's Postel's Law: > How can a streaming generator do that? The API for one might look like: > > ObjectStart(context) > ObjectAdd(context, name, value) > ... > > There's no way a minimal-state streaming generator (but I repeat > myself; the whole point of a streaming interface is to keep minimal > state :) can detect duplicates with O(1) state (probabilistic > structures with false positives won't be acceptable either). You've got to retain state. You don't have to retain the value, but you do have to retain the name. It's O(k), and knowing you I know you're smart enough to approach that (because I am and so I'm using inductive theory ;-). And I'll bet you a nickel that this is not going to be anyone's high order bit. > >> "In general, an implementation must be conservative in its sending >> behavior, and liberal in its receiving behavior." > I've seen this maligned too. How many times have we heard this as a > root cause of security vulnerabilities on receiver sides? We should > be much more exacting, but in *this* case we can't be. That's a fair point about security, but even in THAT context one should be conservative in what one sends. And yes we CAN be more exacting, but at a cost. What we're debating is the cost of ambiguity. > > It's not a question of what is ideal... If we were starting from > scratch we might forbid O(1) state generators and even parsers. But > it's too late for that and we have consensus to achieve. Nothing to be done about installed base, as I wrote. Let's write down what the right thing to do is. These are RFCs we're generating, now laws. > > BTW, we're retreading. We should try not to, but it's difficult to > avoid as no one can have read *every* post since the WG's inception. > I think it's fair to say that on this issue there's no consensus to > ban the bad behavior (duplicate names). Please don't blame me for > that lack of consensus. > WGs often retread. Sometimes we find ways to get around our blocks. We both have no time for blame. Eliot From stefan@drees.name Wed Jul 3 01:09: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 518BB21F9C75 for ; Wed, 3 Jul 2013 01:09:54 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 bw8HGqp8T5US for ; Wed, 3 Jul 2013 01:09:48 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id 430B321F942B for ; Wed, 3 Jul 2013 01:09:47 -0700 (PDT) Received: from newyork.local.box ([93.197.219.73]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MMn1H-1UsL8905jb-008c6i; Wed, 03 Jul 2013 10:09:38 +0200 Message-ID: <51D3DC41.4020808@drees.name> Date: Wed, 03 Jul 2013 10:09:37 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nico Williams References: <51D3C63C.5030703@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:skwXIYyf9hCYAxWITuwvNBKNKTcD2bQmTLpcC0EpsWdlYL+rziv iGh+92L9wSGkCvPhhEOAeVldWPE5/K/wn3XQSmTB9WhL3MKNSZMtpdzhPsGbJssdf+n4IEt zaUE5to3MF+knkwTTahrQFDlEU9AUoX77yyTDWGngUqzNoUwt8/rh0RIWm9swduWw12XfAq 0r5daW7/NiesZZeEcyiiQ== Cc: Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 08:09:54 -0000 On 2013-07-03 08:45 +02:00, Nico Williams wrote: > On Wed, Jul 3, 2013 at 1:35 AM, Eliot Lear wrote: >>> ... > BTW, we're retreading. We should try not to, but it's difficult to > avoid as no one can have read *every* post since the WG's inception. > I think it's fair to say that on this issue there's no consensus to > ban the bad behavior (duplicate names). ... JSON in the role of data interchange format allows at that point the multiset use case. Bad behaviour IMO is when misusing this. The expectation, that the unordered list of names in a single object must form a set and not a multiset is questionable. Just because everyone and her dog "blindly" feeds this into a keyed map structure does not mean, the format is to blame I think :-) {"Stefan":"male","Stefan":"native German","could not resist":true} From markus.lanthaler@gmx.net Wed Jul 3 01:31: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 4B6CA21F9C20 for ; Wed, 3 Jul 2013 01:31:20 -0700 (PDT) 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 90kV+EkwgSVJ for ; Wed, 3 Jul 2013 01:31:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDD321F9ACA for ; Wed, 3 Jul 2013 01:31:15 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M3xlc-1U2kLI0jru-00rUbM for ; Wed, 03 Jul 2013 10:31:14 +0200 Received: (qmail invoked by alias); 03 Jul 2013 08:31:13 -0000 Received: from 178.115.249.85.wireless.dyn.drei.com (EHLO Vostro3500) [178.115.249.85] by mail.gmx.net (mp031) with SMTP; 03 Jul 2013 10:31:13 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/WQzI4JPLWn34wbQIAlPCqSpnJjcZArg/BOIiPBF mOyQXfyrJ8FHWI From: "Markus Lanthaler" To: References: In-Reply-To: Date: Wed, 3 Jul 2013 10:31:09 +0200 Message-ID: <00e301ce77c7$aca7d300$05f77900$@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: Ac53e4ELd2GZQxDZTbqu9paZqIauaAASw6IA Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 08:31:20 -0000 On Wednesday, July 03, 2013 1:26 AM, Paul Hoffman wrote: > Do either or both of these proposals work for people in the WG? I would be fine with proposal 1. I think we should really ask ourselves what we would do if we could start with a clean slate and try "approximate" that by tweaking the RFC in that direction. There may be *some* situations where we have to fall back to say how it should be done (no duplicates names in objects) but acknowledging that, due to historic reasons, there are implementations which do it differently. If we do that too often, however, I don't see any value in this exercise and we should stop it. > Proposal 1: > > In section 2.2 (Grammar -> Objects): > No change > In section 4 (Parsers): > Add: "If a parser encounters an object with duplicate names, the > parser MUST use only the last > name/value pair that has the duplicate name. > In section 5 (Generators): > Add: "The names within an object SHOULD be unique." > > Proposal 2: > > Same as Proposal 1 *except* that a second sentence is added for section > 4: "A parser that streams > its outputs MUST fail to finish parsing if it encounters more than > one name/value pair with the > same name." > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From markus.lanthaler@gmx.net Wed Jul 3 03:44: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 7A80021F9C8E for ; Wed, 3 Jul 2013 03:44:05 -0700 (PDT) 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 fARzW4KH3rlr for ; Wed, 3 Jul 2013 03:43:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 75B8321F9C21 for ; Wed, 3 Jul 2013 03:43:59 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Mgqx4-1UYPwU2j6u-00M203 for ; Wed, 03 Jul 2013 12:43:58 +0200 Received: (qmail invoked by alias); 03 Jul 2013 10:43:58 -0000 Received: from 178.115.249.85.wireless.dyn.drei.com (EHLO Vostro3500) [178.115.249.85] by mail.gmx.net (mp028) with SMTP; 03 Jul 2013 12:43:58 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/vu5YnpT3vZ1o2xtqjxH/H0DxXyNKAIf1fgGv3vo 0K4B35Nwho8vY0 From: "Markus Lanthaler" To: References: In-Reply-To: Date: Wed, 3 Jul 2013 12:43:53 +0200 Message-ID: <012f01ce77da$37d7f9c0$a787ed40$@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: Ac53qm5cglCPBnZWTFiwDtvoFmMNKAAL6FJA Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [Json] What are we trying to do? 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, 03 Jul 2013 10:44:05 -0000 On Wednesday, July 03, 2013 7:02 AM, Tim Bray wrote: > What the industry really needs is a document normatively describing > JSON-as-best-practiced, with an RFC number. It would say that senders > MUST NOT do X and Y, and that receivers, upon encountering X OR Y, > MUST DO Z. Thus other spec writers can say =E2=80=9CDo what RFCXXXX = says=E2=80=9D > and not have to resort to the sort of drafting pain that the people in > Jose are experiencing right now in order to avoid attacks on > cryptographically signed protocol elements by exploiting variation in > dupe-key handling. +1 > Is it the sense of the WG that such a document is within our mandate? I hope so as it would be my preferred way forward. -- Markus Lanthaler @markuslanthaler From derhoermi@gmx.net Wed Jul 3 07:17: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 CA8C621F9D52 for ; Wed, 3 Jul 2013 07:17:42 -0700 (PDT) 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 jEuEdRwBVgFw for ; Wed, 3 Jul 2013 07:17:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id CC38A21F9D50 for ; Wed, 3 Jul 2013 07:17:37 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lsdt9-1UF2jp3Cif-012FJH for ; Wed, 03 Jul 2013 16:17:36 +0200 Received: (qmail invoked by alias); 03 Jul 2013 14:17:35 -0000 Received: from p5B230246.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.2.70] by mail.gmx.net (mp030) with SMTP; 03 Jul 2013 16:17:35 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18kj2I/qh8kf3p2Ir4PHrVKmkCYb8ZNKAPpJwE7T/ dQfrgBd9M91UkH From: Bjoern Hoehrmann To: Tim Bray Date: Wed, 03 Jul 2013 16:17:35 +0200 Message-ID: <6qa8t8tpvt2asjo819nk7bgds7vrtqbsoc@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 03 Jul 2013 14:17:42 -0000 * Tim Bray wrote: >I’m having trouble dealing with the recent proposals from our co-chairs >because I don’t think I understand what they’re trying to achieve. The chairs would like to identify patches to draft-ietf-json-rfc4627bis that reflect rough consensus and running code. I think we should accept that this approach has failed and return to the traditional approach of identifying substantive issues, discuss and resolve them, and then let editors or other volunteers figure out how to implement decisions in the draft. >What the industry really needs is a document normatively describing >JSON-as-best-practiced, with an RFC number. It would say that senders MUST >NOT do X and Y, and that receivers, upon encountering X OR Y, MUST DO Z. I am more interested in one describing the application/json format. It would say this is JSON and that isn't JSON and note that certain kinds of JSON have interoperability problems and possibly note what's usually done to mitigate them. -- 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 Wed Jul 3 08:15: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 3371811E81B4 for ; Wed, 3 Jul 2013 08:15:20 -0700 (PDT) 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 ap4sIKAKnHue for ; Wed, 3 Jul 2013 08:15:19 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D37C511E81CF for ; Wed, 3 Jul 2013 08:15:18 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r63FFD2f050579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Jul 2013 08:15:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Wed, 3 Jul 2013 08:15:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 15:15:20 -0000 On Jul 2, 2013, at 8:30 PM, Nico Williams wrote: > No way. The threads on this were long, I know, but it should be clear > that streaming parsers cannot even detect that there are duplicates, > much less do something about them. The earlier threads indicated that some people felt streaming parsers = could not retain the names they had emitted, while others didn't.=20 > In short, for streaming parsers (and generators) there's nothing we = can do. The more recent threads indicated that predictable interoperability was = important to many people on the list. The purpose of this thread, and its companion, is to propose changes to = the spec that would be to see if there is rough consensus for proposals = that bring predictable interoperability. If such rough consensus is not = possible, that is valuable input for the Working Group. --Matt Miller and Paul Hoffman= From paul.hoffman@vpnc.org Wed Jul 3 08:28: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 327A721F9CD0 for ; Wed, 3 Jul 2013 08:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=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 9f4J7KzC5WuK for ; Wed, 3 Jul 2013 08:28:46 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BC4D921F9CCE for ; Wed, 3 Jul 2013 08:28:46 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r63FSiiH051111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Jul 2013 08:28:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Wed, 3 Jul 2013 08:28:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0194C74E-3866-48B1-A6F8-69802FA30609@vpnc.org> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 03 Jul 2013 15:28:47 -0000 On Jul 2, 2013, at 8:44 PM, Nico Williams wrote: > Huh? Do you mean that any code unit may be allowed if escaped? =20 That is exactly what the current document says, I believe. Do you see = anything in the grammar that says differently? >> In section 1 (Introduction): >> Change the sentence about Unicode characters to: >> A string is a sequence of zero or more Unicode code units = [UNICODE]. >=20 > These aren't Unicode things though. =20 Yes, they are. See the Unicode Standard, definition D77. Do you see = anything in the Unicode Standard that disagrees with D77? >> In section 2.2 (Strings): >> Leave the production for "unescaped" as-is. >> In section 3 (Encoding): >> Add "Some strings, notably those that have unescaped surrogate code = units >> (value 0xD800 to 0xDFFF), cannot be encoded in UTF-8." >=20 > Unescaped and *unpaired*. No, any surrogate code point. RFC 3629, the IETF's definition of UTF-8, = says: The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF, which are reserved for use with the UTF-16 encoding form (as surrogate pairs) and do not directly represent characters. Similar language is used in The Unicode Standard's definition of UTF-8 = (D92), and of UTF-32 (D90). --Paul Hoffman From paul.hoffman@vpnc.org Wed Jul 3 08:31:25 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 5250211E81CB for ; Wed, 3 Jul 2013 08:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 B0Nz1r9RugFX for ; Wed, 3 Jul 2013 08:31:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D4F6811E81AA for ; Wed, 3 Jul 2013 08:31:24 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r63FVNRU051187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Jul 2013 08:31:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130703044150.GW31347@mercury.ccil.org> Date: Wed, 3 Jul 2013 08:31:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> <20130703012614.GL31347@mercury.ccil.org> <2CD8DA4E-8E03-4B4A-AC99-166B7094DCF9@vpnc.org> <20130703044150.GW31347@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 03 Jul 2013 15:31:25 -0000 On Jul 2, 2013, at 9:41 PM, John Cowan wrote: > Paul Hoffman scripsit: >=20 >> It does not appear that the Unicode Standard requires mentioning its >> size, at least in the definition of "code unit" in D77. >=20 > That is so. =20 Good. > But are we to understand, then, that a JSON string is a > sequence of code units of some unspecified size? =20 That appears to be the case for the current document. If you have a = preferred size, by all means propose it to the list. If we can get rough = consensus on that, it would help this discussion. >> John is correct. After further review, we should have worded the = above >> as "...cannot be encoded in any Unicode encoding form". >=20 > As noted, that should have been "unpaired unescaped surrogate code = units". That is only true for UTF-16. The definitions of UTF-8 and UTF-32 say = that you cannot encode any surrogate code points, paired or not. --Paul Hoffman= From paul.hoffman@vpnc.org Wed Jul 3 08:35: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 7540E11E81CA for ; Wed, 3 Jul 2013 08:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 tor5v2xihO+7 for ; Wed, 3 Jul 2013 08:35:11 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFC111E81C1 for ; Wed, 3 Jul 2013 08:35:11 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r63FZ9xU051362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Jul 2013 08:35:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Wed, 3 Jul 2013 08:35:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Bray X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 03 Jul 2013 15:35:11 -0000 On Jul 2, 2013, at 10:01 PM, Tim Bray wrote: > Is it the sense of the WG that such a document is within our mandate? = -T Our mandate is completely specified in our current charter at any given = moment. Such a document is not yet there, even though it has been widely = discussed on this list for the very reasons you gave. --Matt Miller and Paul Hoffman From paul.hoffman@vpnc.org Wed Jul 3 08:37: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 419DB11E81CA for ; Wed, 3 Jul 2013 08:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 PEkjh13ZZser for ; Wed, 3 Jul 2013 08:37:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DA4B811E81B5 for ; Wed, 3 Jul 2013 08:37:04 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r63Fb3pY051439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Jul 2013 08:37:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Wed, 3 Jul 2013 08:37:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Bray X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 03 Jul 2013 15:37:05 -0000 +1 to everything Tim said, particularly "charter is self-contradictory". = We didn't realize this when we put together the charter (a process in = which dozens of people participated), but we do now. --Paul Hoffman= From cowan@ccil.org Wed Jul 3 09:02: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 974CE11E81EC for ; Wed, 3 Jul 2013 09:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 IOJ+I24CTjtM for ; Wed, 3 Jul 2013 09:02:32 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 40F2E11E81C8 for ; Wed, 3 Jul 2013 09:02:32 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuPVk-0006Ki-Tp; Wed, 03 Jul 2013 12:02:29 -0400 Date: Wed, 3 Jul 2013 12:02:28 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130703160228.GA32044@mercury.ccil.org> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> <0194C74E-3866-48B1-A6F8-69802FA30609@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0194C74E-3866-48B1-A6F8-69802FA30609@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Nico Williams , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 03 Jul 2013 16:02:36 -0000 Paul Hoffman scripsit: > >> Add "Some strings, notably those that have unescaped surrogate code units > >> (value 0xD800 to 0xDFFF), cannot be encoded in UTF-8." > > > > Unescaped and *unpaired*. > > No, any surrogate code point. RFC 3629, the IETF's definition of UTF-8, says: > The definition of UTF-8 prohibits encoding character numbers between > U+D800 and U+DFFF, which are reserved for use with the UTF-16 > encoding form (as surrogate pairs) and do not directly represent > characters. You are conflating code points (integers in the range 0-0x10FFFF, definition D10) with code units (bit-strings of a specified length, definition D77). The code *points* corresponding to surrogates (0xD800-0xDFFF) cannot be encoded with any encoding. The 16-bit code *units* corresponding to surrogates are used in pairs to represent characters from U+10000 to U+10FFFF. There are, obviously, no such 8-bit code units, as the numbers involved will not fit in 8 bits, and the equivalent 32-bit code units are not used. Now you make me wonder if your proposal 1 was supposed to be about code points rather than code units. (from another email in this thread) > That appears to be the case for the current document. If you have a > preferred [code unit] size, by all means propose it to the list. If > we can get rough consensus on that, it would help this discussion. In the JSON context, the only code unit size that makes sense is 16-bit, because JavaScript (from which JSON comes) deals in 16-bit code units, sequences of which are called "strings". But if you mean to talk of code points rather than units, then of course there is no size to specify, as integers don't have a size. > > As noted, that should have been "unpaired unescaped surrogate > > code units". > > That is only true for UTF-16. The definitions of UTF-8 and UTF-32 say > that you cannot encode any surrogate code points, paired or not. This is the same conflation. -- John Cowan http://www.ccil.org/~cowan Sir, I quite agree with you, but what are we two against so many? --George Bernard Shaw, to a man booing at the opening of _Arms and the Man_ From nico@cryptonector.com Wed Jul 3 09:04: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 280C121F9CB1 for ; Wed, 3 Jul 2013 09:04:57 -0700 (PDT) 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=-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 prR5YVStozq6 for ; Wed, 3 Jul 2013 09:04:52 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4777521F99D5 for ; Wed, 3 Jul 2013 09:04:52 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id F0E7B6B007B for ; Wed, 3 Jul 2013 09:04:51 -0700 (PDT) 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=dIlNIuUJ+3swuTxK33lQ 3AdJi7E=; b=jISMwCsMxLpaDUYunDBqxBDUCaRTrFaaM7XV0L/CBfsMoguKhHN5 wHHHZ3rdBq66QWu047bik5zdaDWW7rNSh8oPxdMIjlcEa3RmORcDn+L/BAwyQUms o6DpHVAjSqzFK9RXvOjJfEwMFxc7D9kFGpHBVjuaXQt5EOEgWShJQNg= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 812436B0056 for ; Wed, 3 Jul 2013 09:04:51 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so285125wes.15 for ; Wed, 03 Jul 2013 09:04:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1DHDv/rX+BM+OdJSOuKSI0MHYWEnlU+k7cZnP9JKyRE=; b=AgC55TWErFuodCmeK4t2bmxTSG69mCGkugJedRfoE6tFn7Oij9mNRm1v8gTtvDEnYp WclW385lmWFoH7wrhthXCuNrHpfCwnCigMojGe2T+bmos5PF/ZTqyVvgt6VOVaQaGMP9 FjzabVLDEJeGKsc9667/TkgGaylotJbiQ8FK0krtjNwjG+xGrJyNBGsWhCmCZj+LRnGR qJxdF01UotqTIk2noasfAeIdxKyAQ9zmawA7pzrxtLDLQie+r3uhV5J+Yk21n6Xuy0wY 8b3SuMOpLQJCU5qcLyONi6aHBP38JoqP5HIks7qzP9dx1Ag5KaMvH/ZrjimtSitT3rWr adtQ== MIME-Version: 1.0 X-Received: by 10.180.107.71 with SMTP id ha7mr763627wib.28.1372867490164; Wed, 03 Jul 2013 09:04:50 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 09:04:50 -0700 (PDT) In-Reply-To: <51D3CB52.7040902@cisco.com> References: <51D3C63C.5030703@cisco.com> <51D3CB52.7040902@cisco.com> Date: Wed, 3 Jul 2013 11:04:50 -0500 Message-ID: From: Nico Williams To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 16:04:57 -0000 On Wed, Jul 3, 2013 at 1:57 AM, Eliot Lear wrote: > On 7/3/13 8:45 AM, Nico Williams wrote: >> On Wed, Jul 3, 2013 at 1:35 AM, Eliot Lear wrote: >>> To me this isn't strong enough. I have some sympathy for both the >>> existing base and for parsers, but generators as an architectural >>> component should generate unambiguous output, streaming or otherwise. >>> And that follow's Postel's Law: >> How can a streaming generator do that? The API for one might look like: >> >> ObjectStart(context) >> ObjectAdd(context, name, value) >> ... >> >> There's no way a minimal-state streaming generator (but I repeat >> myself; the whole point of a streaming interface is to keep minimal >> state :) can detect duplicates with O(1) state (probabilistic >> structures with false positives won't be acceptable either). > > You've got to retain state. You don't have to retain the value, but you > do have to retain the name. It's O(k), and knowing you I know you're > smart enough to approach that (because I am and so I'm using inductive > theory ;-). And I'll bet you a nickel that this is not going to be > anyone's high order bit. You'd only have to retain state to satisfy this up-till-now non-existent requirement. >>> "In general, an implementation must be conservative in its sending >>> behavior, and liberal in its receiving behavior." >> I've seen this maligned too. How many times have we heard this as a >> root cause of security vulnerabilities on receiver sides? We should >> be much more exacting, but in *this* case we can't be. > > That's a fair point about security, but even in THAT context one should > be conservative in what one sends. And yes we CAN be more exacting, but > at a cost. What we're debating is the cost of ambiguity. It's a psychological cost too. No one wants their code rendered non-compliant by a new RFC. That's part of what's making it hard to get consensus. To be clear I have no implementations that would be broken (because I own no implementations, but I've worked on two that also wouldn't be broken) by any of the proposed changes. But I have written a streaming XML encoder, for example, and I wouldn't want to have to write O(N) state streaming encoders for JSON. >> It's not a question of what is ideal... If we were starting from >> scratch we might forbid O(1) state generators and even parsers. But >> it's too late for that and we have consensus to achieve. > > Nothing to be done about installed base, as I wrote. Let's write down > what the right thing to do is. These are RFCs we're generating, now laws. There's no IETF police, that's for sure, but these are law-like documents. We should write ones that people can strive to meet. *My* opinion here is that in the case of streaming generators and parsers the burden of avoiding/dealing with duplicate names should be one layer higher: at the applications using them. But it's also my opinion that some such apps may not be able to do anything about this either, which is why my proposal is we write SHOULD and explain when it's OK to not stick to the SHOULD. >> BTW, we're retreading. We should try not to, but it's difficult to >> avoid as no one can have read *every* post since the WG's inception. >> I think it's fair to say that on this issue there's no consensus to >> ban the bad behavior (duplicate names). Please don't blame me for >> that lack of consensus. >> > > WGs often retread. Sometimes we find ways to get around our blocks. We > both have no time for blame. Understood. I was voicing what I thought the consensus was. I wanted to make sure that was clear. Nico -- From cowan@ccil.org Wed Jul 3 09:13: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 4DCF721F9D9B for ; Wed, 3 Jul 2013 09:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 eWSB6kQ-uQs2 for ; Wed, 3 Jul 2013 09:13:13 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0D21F9D91 for ; Wed, 3 Jul 2013 09:13:13 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuPg8-0007Px-9z; Wed, 03 Jul 2013 12:13:12 -0400 Date: Wed, 3 Jul 2013 12:13:12 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20130703161312.GB32044@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: Nico Williams , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 16:13:19 -0000 Paul Hoffman scripsit: > The earlier threads indicated that some people felt streaming parsers > could not retain the names they had emitted, while others didn't. It seems to me that a little practical work is in order. Someone needs to try out the eight streaming parsers I mentioned, and any others that they know of, to find out which, if any, (a) report errors on input containing duplicate names or (b) report only the first value named by a duplicate name. A parser that guarantees to return only the last value cannot, per definitionem, be a streaming parser. Unfortunately, I have my hands full with Scheme (45 implementations, anybody?) and can't take this on. I will iterate, like Cato the Censor, that we cannot avoid talking about name equality even if we make no changes in this part of 4627, since it already says (2.2) that the names within an object SHOULD be unique. A unique name is one that is not equal to any other name, and if this is to mean anything, we have to know what name equality is. In practice it is clear that name equality is defined as "the same code points [not units!] in the same order", but this isn't said anywhere. -- John Cowan cowan@ccil.org http://ccil.org/~cowan The present impossibility of giving a scientific explanation is no proof that there is no scientific explanation. The unexplained is not to be identified with the unexplainable, and the strange and extraordinary nature of a fact is not a justification for attributing it to powers above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913) From cowan@ccil.org Wed Jul 3 09:27: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 91E1111E81F3 for ; Wed, 3 Jul 2013 09:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 oj5lxcaMfEHT for ; Wed, 3 Jul 2013 09:27:32 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 138CA11E81E8 for ; Wed, 3 Jul 2013 09:27:32 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuPtx-0000F3-WA; Wed, 03 Jul 2013 12:27:30 -0400 Date: Wed, 3 Jul 2013 12:27:29 -0400 From: John Cowan To: Nico Williams Message-ID: <20130703162729.GC32044@mercury.ccil.org> References: <51D3C63C.5030703@cisco.com> <51D3CB52.7040902@cisco.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: Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 16:27:36 -0000 Nico Williams scripsit: > > You've got to retain state. You don't have to retain the value, but you > > do have to retain the name. It's O(k), and knowing you I know you're > > smart enough to approach that (because I am and so I'm using inductive > > theory ;-). And I'll bet you a nickel that this is not going to be > > anyone's high order bit. I do not understand the third sentence. If k is a constant, then O(k) is the same as O(1), and it is palpable that you cannot pack all the names of a JSON object into O(1) space, since the amount you need varies as the product of the (mean) length of the names and the number of names. As such, it is not even O(n). You can get an O(n) probabilistic implementation by retaining fixed-length hashes of the names already seen, though. > You'd only have to retain state to satisfy this up-till-now > non-existent requirement. Quite so. > It's a psychological cost too. No one wants their code rendered > non-compliant by a new RFC. That's part of what's making it hard to > get consensus. True, but we gave way to that feeling, we'd never have any new standards, as the first thing a standard does is to break existing implementations. ("The first thing a principle does is kill somebody." --Peter Wimsey) We must simply take the view of the ANSI C Rationale, which wisely said "Existing code [meaning user code, the equivalent of JSON data] is important; existing implementations are not." > *My* opinion here is that in the case of streaming generators and > parsers the burden of avoiding/dealing with duplicate names should be > one layer higher: at the applications using them. But it's also my > opinion that some such apps may not be able to do anything about this > either, +1 > which is why my proposal is we write SHOULD and explain when > it's OK to not stick to the SHOULD. In that case, we should write a conditional MUST. We use SHOULD when we want to provide scope for implementer judgement. But that is an editorial detail. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org "After all, would you consider a man without honor wealthy, even if his Dinar laid end to end would reach from here to the Temple of Toplat?" "No, I wouldn't", the beggar replied. "Why is that?" the Master asked. "A Dinar doesn't go very far these days, Master. --Kehlog Albran Besides, the Temple of Toplat is across the street." The Profit From nico@cryptonector.com Wed Jul 3 09:29: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 C69A021F995E for ; Wed, 3 Jul 2013 09:29:33 -0700 (PDT) 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=[AWL=-0.000, 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 7ZnHfaKkv-gi for ; Wed, 3 Jul 2013 09:29:28 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id EA00D21F995B for ; Wed, 3 Jul 2013 09:29:28 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 8A32627BC061 for ; Wed, 3 Jul 2013 09:29:27 -0700 (PDT) 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=CKjXAIou5qn0np+5/3Vd tZlR22c=; b=YengaXzNAoaMH8Gs5I4XTbaawec+8PXomLrV6LeoNeVEDMiegHfs NXxkzcROV/vAOLf4TV3XG/9bNATXm4emDZqZy1V0np1+9V1+B7vHug55scNU7uGs TzspDENYjYl+KwYdVW8UzPinuN3++oo9eV2hK5r8hTdRibjgOclGrW0= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (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 343EF27BC05D for ; Wed, 3 Jul 2013 09:29:27 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so5671920wgg.1 for ; Wed, 03 Jul 2013 09:29:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XP7BUBjFnz3E/TOzZNiu4HfKTevZE11W4BjxBINgn5s=; b=b0XDvOhz0L2cEYKdNQ45lUApk/YmzHYlWfIl7VAgN3uqV/BSbFg7kY0+cCotE2Y6X7 uXVq4KgCGZ8V1Ba5iNBOK9xSRL2/O8wRKq4/kAPsV1DrpCagrKs8sTX8FFdgy6x8hJpl J5nVVcfB1/2YbIjgD0L4+zFZkwpXr33bQXiG2b6dNle6WQ/4h60pp1vlpv+pmBmr8lzv dbM6KlI4kl6ai7TJQGIjTQiFWHMtvw/dXxn+P1NSEncXCSwYkJukU9xkA8xN2ND3ccia 0Jo1k8r+USyx/7tHCxriagIN86B85M2kqYqrFyRbowoHylAYT4rMeaxKMXxiTNOLNg0y PgbQ== MIME-Version: 1.0 X-Received: by 10.180.76.206 with SMTP id m14mr1014715wiw.38.1372868965702; Wed, 03 Jul 2013 09:29:25 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 09:29:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 11:29:25 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 03 Jul 2013 16:29:33 -0000 On Wed, Jul 3, 2013 at 10:37 AM, Paul Hoffman wrote: > > > +1 to everything Tim said, particularly "charter is self-contradictory". We didn't realize this when we put together the charter (a process in which dozens of people participated), but we do now. Re-reading the charter I'm not sure that there's a contradiction. We can do something: - remove the safe-for-eval regexp silliness - add a section describing divergent interpretations - leave the rest mostly as-is with only those changes for which we can get consensus E.g., we can probably get consensus for "generators SHOULD NOT output duplicate names" and "parsers SHOULD use the last of any duplicate names" with appropriate text describing when and why one might deviate from this guidance. E.g., we can probably get consensus for describing a subset of JSON strings that is guaranteed to interoperate, even though we can't ban unpaired surrogates. Then re-charter and publish a BCP. Alternatively, we could re-charter now. I can propose text as soon as we decide to start that discussion. Nico -- From tbray@textuality.com Wed Jul 3 09:34: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 75A4621F9DEC for ; Wed, 3 Jul 2013 09:34:07 -0700 (PDT) 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 xUp-5C6BaxeU for ; Wed, 3 Jul 2013 09:34:01 -0700 (PDT) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id 64A1321F9DDD for ; Wed, 3 Jul 2013 09:34:01 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id p14so285204vbm.32 for ; Wed, 03 Jul 2013 09:34:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=eVE4DSeg30kYv/M54FTSGdI+meoIa83KfaVJY51q7v8=; b=cReyEOXQM0PSy2lb7Mc4HAaWpEpeMuLIRauTSTp/pEOeydGJTg9j2ocW0pMRHvKNQZ pVjnTbjJjjmrwYCVV8lVPtGxW/3NDfojHP2EFrnEQ+ZM9AELCUzvWfIfsTsPMeZURj0R bJVBxaTUocL1bPO54N9zERZnlXfiDdCSp9J/CltWUDTGXsANVNbhhmJks+wLgr+zOQrz XtI4OUDB6UAksM58j9ll8VblR+qrJovovMHqr9e9WYFQyS0kkD8RtSQgPNDGzxTHwEWH xeIL8FM0Hp/bk7RPOHB7hfzxQf3usEWsZ4NZx5HypGf+gwk9oxNDpiyk0o/zKVa1mI3T MjFw== MIME-Version: 1.0 X-Received: by 10.52.119.233 with SMTP id kx9mr430901vdb.50.1372869240808; Wed, 03 Jul 2013 09:34:00 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Wed, 3 Jul 2013 09:34:00 -0700 (PDT) X-Originating-IP: [209.121.225.216] Date: Wed, 3 Jul 2013 09:34:00 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc8be46bf80004e09e0766 X-Gm-Message-State: ALoCoQnyis62umskcGjsZpwoqSUVZvT6tg1/6wbLsYlqcYdnbU6L3WMjjDYKNU4jzQn5YAME1BzI Subject: [Json] JSON for Internet messages 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, 03 Jul 2013 16:34:07 -0000 --047d7bdc8be46bf80004e09e0766 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it will be helpful to put a stick in the ground: Most of my professional activity centers around designing and using message-passing application-level APIs. In basically all of them, the payload is JSON. So I care a lot about JSON, but I don=E2=80=99t care in the slightest about= usages where the JSON isn=E2=80=99t being used for application-level message proto= col payloads (are there such usages? I'm curious). Also, I=E2=80=99ve never encountered a scenario where the messages were of sufficient size that anyone gave a rat=E2=80=99s ass about streaming. >From that point of view, the following seem obvious: - All JSON messages MUST be encoded in valid UTF-8. - All numbers MUST be of precision < 2**53 (use strings for your big crypto numbers) - All JSON objects MUST have unique keys - All JSON messages MUST be either arrays or objects - Software receiving something violating any of these MUSTs has encountered conclusive evidence of serious upstream breakage and MUST NOT trust the contents nor act upon them. That=E2=80=99s all. It leaves lots of things to argue about (BOMs? Non-char= acters? Control-characters? Maybe just objects at top-level? Should this flavor of JSON self-identify? If so, how? etc etc) I want there to be an RFC that says these things that protocol designers can point to and just stop thinking about markup syntax. I don=E2=80=99t think our mandate lets us write that RFC. I think we shoul= d write a -bis doc that documents the actual realities in the field (results of using bad Unicode and dupe keys are unpredictable), recharter, and then write that RFC. -T --047d7bdc8be46bf80004e09e0766 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it will be= helpful to put a stick in the ground:=C2=A0 Most of my professional activi= ty centers around designing and using message-passing application-level API= s.=C2=A0 In basically all of them, the payload is JSON.=C2=A0

So I care a lot about JSON, but I don=E2=80=99t care in the sligh= test about usages where the JSON isn=E2=80=99t being used for application-l= evel message protocol payloads (are there such usages?=C2=A0 I'm curiou= s).=C2=A0 Also, I=E2=80=99ve never encountered a scenario where the message= s were of sufficient size that anyone gave a rat=E2=80=99s ass about stream= ing.

From that point of view, the following seem obvious:

- All JSON messages MUST be encoded in valid UTF-8.=C2=A0
- All = numbers MUST be of precision < 2**53 (use strings for your big crypto nu= mbers)
- All JSON objects MUST have unique keys
- All JSON messages MUST = be either arrays or objects
- Software receiving something violati= ng any of these MUSTs has encountered conclusive evidence of serious upstre= am breakage and MUST NOT trust the contents nor act upon them.

That=E2=80=99s all. It leaves lots of things to argue about (BOMs= ? Non-characters? Control-characters? Maybe just objects at top-level? Shou= ld this flavor of JSON self-identify? If so, how? etc etc)

I want th= ere to be an RFC that says these things that protocol designers can point t= o and just stop thinking about markup syntax.

I don=E2=80=99t think our mandate lets us write that RFC.=C2=A0 I= think we should write a -bis doc that documents the actual realities in th= e field (results of using bad Unicode and dupe keys are unpredictable), rec= harter, and then write that RFC.=C2=A0 -T
--047d7bdc8be46bf80004e09e0766-- From nico@cryptonector.com Wed Jul 3 09:41:52 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 E3A4611E81B2 for ; Wed, 3 Jul 2013 09:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=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 herJo9u+iyhy for ; Wed, 3 Jul 2013 09:41:48 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 11EDE21F9D01 for ; Wed, 3 Jul 2013 09:41:48 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id CB2E81006E for ; Wed, 3 Jul 2013 09:41:47 -0700 (PDT) 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=ATR9xAt0zXBpgT7RHJ/3 j8LL02U=; b=cNOi7yTPfJLChcjjDUmlIuxvrCEKTuXUPc3tv5dETA1ScB9A9pyG 6zwLFisyATown40uW91uSY11dkNk7VcDRKKe13y6MDw8l53KaZPjlfK04ZP3YRPZ xRkuwmoRhBdfaR+Ay0OyjHwQ+AbyTnzBzbb2r9SoagTcJ9TGROcmuxY= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 7A7F71005D for ; Wed, 3 Jul 2013 09:41:47 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n11so314814wgh.33 for ; Wed, 03 Jul 2013 09:41:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qvFoVkZ43waE8MlKUQ33pIJVtuK7M/h8G219/h67dD0=; b=AB20dkaiKn1fPfv4mQoddn9or7MR+YXKUDDcvxkKpbzAEM6O5y2hxAgZ8UjaIDzzA8 otbl0d82WOKL8dNpIaQJtKu2X+IFo6hSBjTQpG1B4/oeMEoeDWZf7dHf2aKbhZNMjBzr aI0I4MGfrWf3OlXwyNZfarWZCteBsjy2eG5TmweOHFLGaw6R+EEurFDBPXN8JrQO9HG7 6VSfF3gSUK0gEGfpyH+eCk2S+289WrU6jdikxRieAbgcV2klfFJQWtF9V34HBKSGv42e 60sMK0EwGxXMVPeub7oQ/1Rb2fb8TTFN/lne5UxzPXi2mXErCFXAysZQz6Vkaar2VYzq nFVw== MIME-Version: 1.0 X-Received: by 10.194.7.137 with SMTP id j9mr1196998wja.11.1372869705850; Wed, 03 Jul 2013 09:41:45 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 09:41:45 -0700 (PDT) In-Reply-To: <0194C74E-3866-48B1-A6F8-69802FA30609@vpnc.org> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> <0194C74E-3866-48B1-A6F8-69802FA30609@vpnc.org> Date: Wed, 3 Jul 2013 11:41:45 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 03 Jul 2013 16:41:53 -0000 On Wed, Jul 3, 2013 at 10:28 AM, Paul Hoffman wrote: > On Jul 2, 2013, at 8:44 PM, Nico Williams wrote: >> Huh? Do you mean that any code unit may be allowed if escaped? > > That is exactly what the current document says, I believe. Do you see anything in the grammar that says differently? No, but I couldn't understand what you wrote, which was | Proposal 1 (allow all code units in their unescaped form): surely you did not mean that all 16-bit code units could be sent unescaped. But that is how I read that. I figured you'd typoed. >>> In section 2.2 (Strings): >>> Leave the production for "unescaped" as-is. >>> In section 3 (Encoding): >>> Add "Some strings, notably those that have unescaped surrogate code units >>> (value 0xD800 to 0xDFFF), cannot be encoded in UTF-8." >> >> Unescaped and *unpaired*. > > No, any surrogate code point. RFC 3629, the IETF's definition of UTF-8, says: > The definition of UTF-8 prohibits encoding character numbers between > U+D800 and U+DFFF, which are reserved for use with the UTF-16 > encoding form (as surrogate pairs) and do not directly represent > characters. > Similar language is used in The Unicode Standard's definition of UTF-8 (D92), and of UTF-32 (D90). Yet there are ECMAScript applications that send these. In their escaped form there's no conflict with UTF-8 (nor UTF-32, nor even in UTF-16 if unpaired). In their unescaped form there is most definitely a conflict. Which brings up: what should a parser do when it sees escaped code units? Should it attempt to unescape them in the parsed result? What if the escaped code unit cannot be unescaped because it would result in invalid UTF-8/16/32? RFC4627 says nothing about this. My proposal is to allow any code units as long as they are escaped if they are unpaired surrogate code points or as long as they are unescaped and properly represented in the UTF of the JSON document otherwise (i.e., if a pair of surragates appear in UTF-16 then when re-encoding to UTF-8 the result must be UTF-8, not CESU-8, and the pair must be decoded into a code point then re-encoded in UTF-8). Nico -- From nico@cryptonector.com Wed Jul 3 09:47: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 EC8D121F9D0A for ; Wed, 3 Jul 2013 09:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.037, 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 YCLZy22nGlpO for ; Wed, 3 Jul 2013 09:47:27 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5221F9D05 for ; Wed, 3 Jul 2013 09:47:27 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id E2914768061 for ; Wed, 3 Jul 2013 09:47:26 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=+fGl7kpAxjw4DCGoky+0aSHeh0g=; b=MGKjXKbSpan Jc52qF+GwjZGbq7pn2RfWJEhjDbweXjoiz20qh/2Ut/3M/tafO1kRAwgPDeBw8Ha VJMAcIC8t8i8IsYRD1E3dIC5ZoHFHxizYSxgfycmByV9ykMqTC7YkqaEXi99poCS +1xeaG7nTqg7BsJSEdknPTrQoAnH8rl8= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 8D3C776805C for ; Wed, 3 Jul 2013 09:47:26 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so330450wgh.24 for ; Wed, 03 Jul 2013 09:47:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ujLX9bLQLUsne7vRDswXNWMr/xjkc/T8yXFBWINTtOc=; b=R+7JMNF8Yn9evRRkscvY3x0t0ivT07fX0giV7PWjbNf8626yyius7cChavEnkCnoNn erg/UXuikScQWINjkue/OYH//P3XPmbi6DuwkRA02GJhCp8w09BOBZSypOraJHKHsTeb GMEKW2OOVARTiUPKgLK7nAenkEDWhpf828hQQvAdI9YH6beKt1w0BhDyqNoR3eZIci8H 2ZunAYRItR9MnGJwKA0X4S3wpsX8tS4yO5F6fxWtLe2LJzltNDBIlpJeax7+/7+KeuDz 81CLIpQjZu9TrDBRCpMsnUQk0U/BnrlJx3FyaodbfMCr9cFb0oPpYaPYKlTm9j5gwvh9 sCxQ== MIME-Version: 1.0 X-Received: by 10.194.173.37 with SMTP id bh5mr1187844wjc.30.1372870045230; Wed, 03 Jul 2013 09:47:25 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 09:47:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 11:47:25 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 16:47:32 -0000 On Wed, Jul 3, 2013 at 11:34 AM, Tim Bray wrote: > I don=E2=80=99t think our mandate lets us write that RFC. I think we sho= uld write a > -bis doc that documents the actual realities in the field (results of usi= ng > bad Unicode and dupe keys are unpredictable), recharter, and then write t= hat > RFC. -T We could argue about your list of things to mandate. Are you counting escaped code units in their unescaped forms towards well-formed UTF-8? Would we need a new media type, or could we say it doesn't matter, this is the Internet JSON? That aside, +1, even to the non-duplicate names requirement. Nico -- From tbray@textuality.com Wed Jul 3 09:57: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 7D32D11E81FE for ; Wed, 3 Jul 2013 09:57:00 -0700 (PDT) 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 BC0-oR-wd9vN for ; Wed, 3 Jul 2013 09:56:54 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 873B211E81F2 for ; Wed, 3 Jul 2013 09:56:54 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id c13so333610vea.7 for ; Wed, 03 Jul 2013 09:56:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XvlMjI/HjQ1yvuJ/nD6pCze0xKYrL3zKNy5idgblsHE=; b=BgwHW8kLQ9Z0wYG/iVyBQ+YyXllAesr6JIqbNceqpMPoS6vs4Vjm6qmF5DJhwxO+yS KrRmCPHYuIkwNE73m+394Z4Yz5w02170J6DHA4vIyhmAbLrVD+WBNwbNqNO2DTiWKejw CGH3np0x4VIerlAAXjeLaq+T3ZlScBSAzcOdEmeBEAVxipH2UZVtKoE+mgpVxVumEu3Y 1QYQ4mylPc82wruKFF1OdIRiA2ObTMHXtN+jWj8NqRbfdRlNEAaex6f9mducinwFJE2h K6/h0jLKjwxoOQFp/RARIYX05ujAFQ3pU1THBK29iCifwet0FSUi35SQv3b4Vb8SLGFk IMmw== MIME-Version: 1.0 X-Received: by 10.220.67.137 with SMTP id r9mr532256vci.69.1372870613987; Wed, 03 Jul 2013 09:56:53 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Wed, 3 Jul 2013 09:56:53 -0700 (PDT) X-Originating-IP: [209.121.225.216] In-Reply-To: References: Date: Wed, 3 Jul 2013 09:56:53 -0700 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b3a7db245024804e09e596a X-Gm-Message-State: ALoCoQm8anYbiepKbVWGVqUiceT/Bu2Fp4V6ie4M2yEueBy4AjoHoSjLk3RWz/By9I53naAhhygy Cc: "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 16:57:00 -0000 --047d7b3a7db245024804e09e596a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2013 at 9:47 AM, Nico Williams wrote= : > We could argue about your list of things to mandate. Are you counting > escaped code units in their unescaped forms towards well-formed UTF-8? > Would we need a new media type, or could we say it doesn't matter, > this is the Internet JSON? Well-formed UTF-8 isn=E2=80=99t allowed to encode surrogates. Which meets t= he minimal need; Frankly, I think string-handling code can, in practice, suck it up and deal with all sorts of Unicode inappropriateness... just not surrogates. Also, I explicitly said the question of self-identification (e.g. with a media type) is open. -T > That aside, +1, even to the non-duplicate > names requirement. > > Nico > -- > --047d7b3a7db245024804e09e596a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 9:47 AM, Nico Williams <nico@c= ryptonector.com> wrote:
We could argue about your= list of things to mandate. =C2=A0Are you counting
escaped code units in their unescaped forms towards well-formed UTF-8?
=C2=A0Would we need a new media type, or could we say it doesn't matter= ,
this is the Internet JSON? =C2=A0

Well-formed UTF-8 is= n=E2=80=99t allowed to encode surrogates. Which meets the minimal need; Fra= nkly, I think string-handling code can, in practice, suck it up and deal wi= th all sorts of Unicode inappropriateness... just not surrogates.=C2=A0 Als= o, I explicitly said the question of self-identification (e.g. with a media= type) is open. -T
=C2=A0
That aside, += 1, even to the non-duplicate
names requirement.

Nico
--

--047d7b3a7db245024804e09e596a-- From cowan@ccil.org Wed Jul 3 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 D9C5811E811A for ; Wed, 3 Jul 2013 09:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 z4k-ujKGPMFP for ; Wed, 3 Jul 2013 09:58:13 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 83BD711E80F2 for ; Wed, 3 Jul 2013 09:58:13 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuQNe-00038M-Bq; Wed, 03 Jul 2013 12:58:10 -0400 Date: Wed, 3 Jul 2013 12:58:10 -0400 From: John Cowan To: Stefan Drees Message-ID: <20130703165810.GF32044@mercury.ccil.org> References: <51D3C63C.5030703@cisco.com> <51D3DC41.4020808@drees.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D3DC41.4020808@drees.name> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Nico Williams , Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 16:58:18 -0000 Stefan Drees scripsit: > JSON in the role of data interchange format allows at that point the > multiset use case. Bad behaviour IMO is when misusing this. > > The expectation, that the unordered list of names in a single object > must form a set and not a multiset is questionable. Nevertheless, anyone who generates JSON with duplicate names in order to represent a multimap deserves to lose, because many, many JSON parsers will simply throw away all but the last as an unintended consequence of their implementation strategies. I assume you mean a multimap rather than a multiset: a multiset would be most naturally represented as a JSON object whose values are integers representing the number of occurrences of a particular object in the multiset. By the same token, the natural representation of a multiset is a JSON object whose values are arrays. whose order is semantically irrelevant. > {"Stefan":"male","Stefan":"native German","could not resist":true} { "given name" : "John", "gender" : "male", "citizenship" : {"country" : "US", "source" : "jus soli"}, "ethnicity" : ["German", "Irish"], "annotations" : { "verbose" : true, "machine-processable" : true } } -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Humpty Dump Dublin squeaks through his norse Humpty Dump Dublin hath a horrible vorse But for all his kinks English / And his irismanx brogues Humpty Dump Dublin's grandada of all rogues. --Cousin James From lear@cisco.com Wed Jul 3 10:00: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 D0FE811E81FE for ; Wed, 3 Jul 2013 10:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.4 X-Spam-Level: X-Spam-Status: No, score=-110.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 eYfIcVaLKSr1 for ; Wed, 3 Jul 2013 10:00:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7723811E80F2 for ; Wed, 3 Jul 2013 10:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=406; q=dns/txt; s=iport; t=1372870827; x=1374080427; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3dtrfbpw+pA4p5UsP1gUqUEJzNyyQ2eEYtRvl4AY0e0=; b=JKn045KTOICVdb6Wl/d3KbVyVikap5vVgsSYpX1jwXMyN9cltaNR6scK 4XfHDv1Jq1ctn1zb8vpX/KAn00Xxm3Ngj1w1JXYZFTA8g4cr1NS8XwPQs JOn5Sm0vXxImxN+x4LW1Nq5MqcXlX+r1DKykB4b5U/A70Sh1TSZIKZ31Q s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksLAH1X1FGQ/khL/2dsb2JhbABagwmEA70kAQMBAwGBBBZ0giMBAQEEI1UBEAsYAgIFFgsCAgkDAgECASsaBg0BBwEBiAupeJETgSaNGYEsB4JRgRwDl0mRRYMTOoEt X-IronPort-AV: E=Sophos;i="4.87,989,1363132800"; d="scan'208";a="156132007" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2013 17:00:26 +0000 Received: from mctiny.local ([10.61.175.226]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r63H0OWr024659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 17:00:24 GMT Message-ID: <51D458A8.9070209@cisco.com> Date: Wed, 03 Jul 2013 19:00:24 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Cowan References: <51D3C63C.5030703@cisco.com> <51D3CB52.7040902@cisco.com> <20130703162729.GC32044@mercury.ccil.org> In-Reply-To: <20130703162729.GC32044@mercury.ccil.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Nico Williams , Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 17:00:32 -0000 On 7/3/13 6:27 PM, John Cowan wrote: > I do not understand the third sentence. If k is a constant, then O(k) is > the same as O(1), and it is palpable that you cannot pack all the names > of a JSON object into O(1) space, since the amount you need varies as the > product of the (mean) length of the names and the number of names. I was thinking computational complexity not storage. Eliot From cowan@ccil.org Wed Jul 3 10:03: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 6091A11E8208 for ; Wed, 3 Jul 2013 10:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 dQIHsK4xyLJI for ; Wed, 3 Jul 2013 10:03:07 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 12E5011E8209 for ; Wed, 3 Jul 2013 10:03:07 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuQSP-00040i-P3; Wed, 03 Jul 2013 13:03:05 -0400 Date: Wed, 3 Jul 2013 13:03:05 -0400 From: John Cowan To: Eliot Lear Message-ID: <20130703170305.GG32044@mercury.ccil.org> References: <51D3C63C.5030703@cisco.com> <51D3CB52.7040902@cisco.com> <20130703162729.GC32044@mercury.ccil.org> <51D458A8.9070209@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D458A8.9070209@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Nico Williams , Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 17:03:11 -0000 Eliot Lear scripsit: > I was thinking computational complexity not storage. Oh. But surely the whole point of streaming parsers is to reduce the amount of storage required? > Eliot -- I could dance with you till the cows John Cowan come home. On second thought, I'd http://www.ccil.org/~cowan rather dance with the cows when you cowan@ccil.org come home. --Rufus T. Firefly From lear@cisco.com Wed Jul 3 10:04: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 C8D2811E820B for ; Wed, 3 Jul 2013 10:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.408 X-Spam-Level: X-Spam-Status: No, score=-110.408 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 RDuGlsRwTosi for ; Wed, 3 Jul 2013 10:04:00 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7F64811E8203 for ; Wed, 3 Jul 2013 10:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4013; q=dns/txt; s=iport; t=1372871040; x=1374080640; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ffsKD4Pl5UaBQfs6MUjg+nEP9OqI6u/Jy73WexQtWXg=; b=dzYLpvOXKS2PM/i4GD9CTzZG5iCbhlkBZRrMwEpVI9l6kyG1hP/pnlhD IHjgvBs8Nz0zkDOAe9kiTk/2fP12xk4R3tSx/vImyg5zrULS0O1R4FgbX Zi2kETmZSwGry6x2ECyNSTeMfacrCg6KEpBGUSrTMMSa2shICG5Fv8HpM g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAOhY1FGQ/khR/2dsb2JhbABQCoMJhAOFXbdQgQQWdIIjAQEBBCNWEAsECgoJIQICDwIsGgYNAQcBAYgLqXCRE44vgTwHglGBHAOXSZFFgxM6 X-IronPort-AV: E=Sophos;i="4.87,989,1363132800"; d="scan'208,217";a="83927716" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 03 Jul 2013 17:03:59 +0000 Received: from mctiny.local ([10.61.175.226]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r63H3u1U028335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 17:03:57 GMT Message-ID: <51D4597C.20405@cisco.com> Date: Wed, 03 Jul 2013 19:03:56 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------050907000404030208030702" Cc: "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 17:04:05 -0000 This is a multi-part message in MIME format. --------------050907000404030208030702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 7/3/13 6:34 PM, Tim Bray wrote: > > From that point of view, the following seem obvious: > > - All JSON messages MUST be encoded in valid UTF-8. > - All numbers MUST be of precision < 2**53 (use strings for your big > crypto numbers) > - All JSON objects MUST have unique keys > - All JSON messages MUST be either arrays or objects > - Software receiving something violating any of these MUSTs has > encountered conclusive evidence of serious upstream breakage and MUST > NOT trust the contents nor act upon them. > > That’s all. It leaves lots of things to argue about (BOMs? > Non-characters? Control-characters? Maybe just objects at top-level? > Should this flavor of JSON self-identify? If so, how? etc etc) > > I want there to be an RFC that says these things that protocol > designers can point to and just stop thinking about markup syntax. > > I don’t think our mandate lets us write that RFC. I think it does, if you believe these are the minimal changes necessary for interoperability. The standard for standards goes UP as you go through maturity. Deal with this now or someone else will end up having to. Eliot --------------050907000404030208030702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/3/13 6:34 PM, Tim Bray wrote:

From that point of view, the following seem obvious:

- All JSON messages MUST be encoded in valid UTF-8. 
- All numbers MUST be of precision < 2**53 (use strings for your big crypto numbers)
- All JSON objects MUST have unique keys
- All JSON messages MUST be either arrays or objects
- Software receiving something violating any of these MUSTs has encountered conclusive evidence of serious upstream breakage and MUST NOT trust the contents nor act upon them.

That’s all. It leaves lots of things to argue about (BOMs? Non-characters? Control-characters? Maybe just objects at top-level? Should this flavor of JSON self-identify? If so, how? etc etc)

I want there to be an RFC that says these things that protocol designers can point to and just stop thinking about markup syntax.

I don’t think our mandate lets us write that RFC.

I think it does, if you believe these are the minimal changes necessary for interoperability.  The standard for standards goes UP as you go through maturity.  Deal with this now or someone else will end up having to.

Eliot

--------------050907000404030208030702-- From cowan@ccil.org Wed Jul 3 10:15:52 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 480E021F9D9D for ; Wed, 3 Jul 2013 10:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 q36YtJpRklcA for ; Wed, 3 Jul 2013 10:15:48 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 731EF21F9D98 for ; Wed, 3 Jul 2013 10:15:48 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuQeh-0005D3-RN; Wed, 03 Jul 2013 13:15:47 -0400 Date: Wed, 3 Jul 2013 13:15:47 -0400 From: John Cowan To: Tim Bray Message-ID: <20130703171547.GH32044@mercury.ccil.org> References: 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: "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 17:15:52 -0000 Tim Bray scripsit: > So I care a lot about JSON, but I don’t care in the slightest about usages > where the JSON isn’t being used for application-level message protocol > payloads (are there such usages? I'm curious). I suppose it depends on what you mean by "application-level". There are several NoSQL databases that speak JSON, and I wouldn't call them applications per se. > Also, I’ve never encountered a scenario where the messages were of > sufficient size that anyone gave a rat’s ass about streaming. Well, at least eight programmers have taken the trouble to write such parsers, and I don't think we can assume that they are all works of supererogation. Rob Gonzalez says that he wrote his PHP streaming parser because he needed to be able to react to JSON input on the fly. I quote the first few paragraphs of : Recently I looked around for a JSON streaming parser written in PHP and couldn’t find one. So I wrote my own and am making it available to anyone who wants to use it. For those unfamiliar with streaming parsers I’ll give a brief intro. In short, they’re useful if you have a very large document and don’t want to have to load the whole thing in memory at once. Most (non-streaming) parsers—including, for example, the stock JSON parsers that come with PHP—will load an entire document in memory and then give you access to the whole thing at once. The advantage to this whole-document-at-once approach is that you get random access to every object in the document. Also the programmatic interface they provide can be really convenient. In PHP’s standard library you can get a handle on a native PHP array for the entire JSON document, which is really easy to work with. The downside is, as mentioned, the whole document must be loaded into memory. For most web servers or web services this is a serious constraint. Furthermore, this means that your application can’t start actually doing anything useful with the data until the whole thing is loaded in memory. A streaming parser, in contrast, gives your application access to data almost as soon as the data is read by PHP so can be much faster. As I was writing a plugin for Magento, I needed a JSON streaming parser written in PHP. I looked at StackOverflow, PHP.net, and finally Google. It’s pretty crazy to me that no one seems to have had this need before given the popularity of both JSON and PHP, but there you go! > > - All JSON messages MUST be encoded in valid UTF-8. > - All numbers MUST be of precision < 2**53 (use strings for your big crypto > numbers) Better: All numbers MUST be representable as IEEE 754:2008 binary 64-bit floats. > - All JSON objects MUST have unique keys > - All JSON messages MUST be either arrays or objects > - Software receiving something violating any of these MUSTs has encountered > conclusive evidence of serious upstream breakage and MUST NOT trust the > contents nor act upon them. The trouble with all this is that They Break Data. All of a sudden, what was valid JSON before is not valid JSON now. That's serious, especially as people *do* keep around their JSON rather than using it only transiently See above remarks about databases: it doesn't matter if the JSON is stores as JSON or regenerated on the fly, because if I put in JSON today I expet to get back JSON tomorrow, and not something that no longer counts as JSON. -- All Gaul is divided into three parts: the part John Cowan that cooks with lard and goose fat, the part http://ccil.org/~cowan that cooks with olive oil, and the part that cowan@ccil.org cooks with butter. --David Chessler From paul.hoffman@vpnc.org Wed Jul 3 10:19: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 89F8421F99FA for ; Wed, 3 Jul 2013 10:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 SiNJLPGARrMm for ; Wed, 3 Jul 2013 10:19:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 28DD921F99D0 for ; Wed, 3 Jul 2013 10:19:18 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r63HJGFg055316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Jul 2013 10:19:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130703170305.GG32044@mercury.ccil.org> Date: Wed, 3 Jul 2013 10:19:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7B759FAA-2B78-4A1C-82A1-E8BA7986AD82@vpnc.org> References: <51D3C63C.5030703@cisco.com> <51D3CB52.7040902@cisco.com> <20130703162729.GC32044@mercury.ccil.org> <51D458A8.9070209@cisco.com> <20130703170305.GG32044@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 17:19:18 -0000 On Jul 3, 2013, at 10:03 AM, John Cowan wrote: > Eliot Lear scripsit: >=20 >> I was thinking computational complexity not storage. >=20 > Oh. But surely the whole point of streaming parsers is to reduce > the amount of storage required? In the work I have been doing on CBOR, I have heard both as reasons for = different types of streaming parsers and encoders. It would be unwise for this WG to assume we know the design = considerations for any JSON parser or encoder. There are, as we now see, = a zillion of them with overlapping design goals and constraints. --Paul Hoffman= From derhoermi@gmx.net Wed Jul 3 10:27:10 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 17B6C11E8200 for ; Wed, 3 Jul 2013 10:27:10 -0700 (PDT) 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=[AWL=0.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 ZL3wZIxqktDD for ; Wed, 3 Jul 2013 10:27:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE4B11E8201 for ; Wed, 3 Jul 2013 10:26:59 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LrpCq-1UEAhg2ZYs-013eND for ; Wed, 03 Jul 2013 19:26:58 +0200 Received: (qmail invoked by alias); 03 Jul 2013 17:26:57 -0000 Received: from p5B230246.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.2.70] by mail.gmx.net (mp028) with SMTP; 03 Jul 2013 19:26:57 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+1s7V19Hi1Sy/vTxIo4KkmJKsswq1MhI1LA7dqL7 smtZq1qLnT92h5 From: Bjoern Hoehrmann To: John Cowan Date: Wed, 03 Jul 2013 19:26:49 +0200 Message-ID: <7kn8t8lglsnvn06f6agrmjfkl8c6me656n@hive.bjoern.hoehrmann.de> References: <20130703161312.GB32044@mercury.ccil.org> In-Reply-To: <20130703161312.GB32044@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-Y-GMX-Trusted: 0 Cc: Nico Williams , Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 17:27:10 -0000 * John Cowan wrote: >It seems to me that a little practical work is in order. Someone needs >to try out the eight streaming parsers I mentioned, and any others that >they know of, to find out which, if any, (a) report errors on input >containing duplicate names or (b) report only the first value named by a >duplicate name. A parser that guarantees to return only the last value >cannot, per definitionem, be a streaming parser. http://www.ietf.org/mail-archive/web/json/current/msg00480.html has code testing Microsoft's .NET Framework's System.Runtime.Serialization.Json. It reports duplicate instances and does not report any errors for them. -- 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 Wed Jul 3 10:28: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 5C39911E80F2 for ; Wed, 3 Jul 2013 10:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.033, 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 kflAXMnrgTHv for ; Wed, 3 Jul 2013 10:28:46 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 823A911E80E9 for ; Wed, 3 Jul 2013 10:28:46 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id AFE4067C014 for ; Wed, 3 Jul 2013 10:28:44 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=Jz4E6g785dE8fltuUWGaJS50ez4=; b=hSBmEdQZUe/ +cCz0ZeIGfo+bkkoB2xYU2uoNYN8qKT2hgTNnqH5GinVMRxgA10kJvP2wQRk6xcN rWr0R1836UBYl2c055X2ySGTmb6hROahU7+LWuXaZgBlhC9ygX4H5dtm29VOnai/ XHzW1fTA1tSXV3dIRcxb9Srv/qhWyMyc= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 6371867C06D for ; Wed, 3 Jul 2013 10:28:44 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so359385wgh.15 for ; Wed, 03 Jul 2013 10:28:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=75awCIKcbpSvIJBmPt+JyAkoKiOIg0tP+yCzK2Uou4Q=; b=gGHW9COAUUcXmmPQzS9tep+X6JZlHc6V6mnxsyP+pNv3+DxzxNnfWi8e0TPY4n3ghP ncAWbmctZfLy1r5Xbtas+b07mWNrrxRRxTe7pTVmfV16832HZ2cP0HFYi11ljfeXdGdl show9F7ZGnZwWmXQDdzn5HEEWKlNeS4bezekkQNHU9aJU5/XwxFvHDtFJS4BotmXJALJ HAfb3XTMNRn2Mcs4rAx/0aax3w5xwWNDmLmDltDSUqliIAU4lFFSecHybtIuUxbdkAr5 7tAkm8MJlUmejQ2WCCWFT60+2S3XCLLZ8x/BRy6lciPfHIbvcqrrwf3jzV3yIzLL8gaD negg== MIME-Version: 1.0 X-Received: by 10.194.7.137 with SMTP id j9mr1315439wja.11.1372872522987; Wed, 03 Jul 2013 10:28:42 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 10:28:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 12:28:42 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 17:28:51 -0000 On Wed, Jul 3, 2013 at 11:34 AM, Tim Bray wrote: > So I care a lot about JSON, but I don=E2=80=99t care in the slightest abo= ut usages > where the JSON isn=E2=80=99t being used for application-level message pro= tocol > payloads (are there such usages? I'm curious). Also, I=E2=80=99ve never > encountered a scenario where the messages were of sufficient size that > anyone gave a rat=E2=80=99s ass about streaming. Er, I work with an application where I need to atomically read *all* the data (it's ok if it's slow) once, then poll for / subscribe to an incremental update feed. The first requirement has devolved into doing a single GET with chunked data results -- pagination failed because we couldn't get the application in question to provide atomicity with pagination. That data comes to me as JSON. It can be huge. It happens to be an array of relatively small objects, so it's possible to implement the generation (and parsing) in a streaming way for the top-level value and still prevent / deal with duplicate names one level down. But you can see how one can end up needing streaming generators and parsers= . I could write a parser that streams the array and doesn't stream the objects. But I'm going to use an off-the-shelf parser as much as possible. The pressure to use a streaming parser (and generator) will increase as the dataset increases in size. My fear is that the cost of dealing with this dataset will increase superlinearly with dataset size if I use a non-streaming parser; I fear that eventually I won't be able to use a non-streaming parser at all. For all other purposes the application in question uses small enough JSON documents that I wouldn't need streaming anything. Now, in this application it just so happens that there are other ways to guarantee non-duplicate names that are already in place, so the use of a streaming generator/parser that does nothing about duplicate names would be just fine. I don't mind saying "MUST NOT" have dups. I just want the text written in such a way that this application can use JSON after all. For me that would mean that it's OK to have streaming generators and parsers, as long as the application makes sure there's no dups in that case. Nico -- From nico@cryptonector.com Wed Jul 3 10:31: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 452D821F8956 for ; Wed, 3 Jul 2013 10:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Xgiq54bOVSrU for ; Wed, 3 Jul 2013 10:31:12 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 6C11821F889C for ; Wed, 3 Jul 2013 10:31:12 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 30DD3584059 for ; Wed, 3 Jul 2013 10:31:12 -0700 (PDT) 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=UYq7/A9NT+HeTxcd8ac6 s2P/j0c=; b=XRd7jwf7yAufOnwqpak0tLaUSJkYg434ZodCTtP1JQFuHWg0XP7q 4uwLQ707B5+cTINh2swNCypDqT9RsDWMOkIf7rHNoul3AXqfupDYWIMSndfgCclK 74iimsPsGHpE0pXBuvYjs98CMEcdl7zrkHRFZ9wN2bCmcPNroq3eKK4= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id CCA1F584058 for ; Wed, 3 Jul 2013 10:31:11 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so359158wgh.31 for ; Wed, 03 Jul 2013 10:31:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pG8rcNfHqF+PM6/moQHw8Ty1jPwW+8D3Uig8r/f8zus=; b=HDYDafpCWxkyeW1b/ppAZ4IjcHpYU1DrN0IzS8WDPjnTi8HbAKfHJ8UPVrGeg4UgdE NClJ4lDffsI3oLM81pOqwm4Kd7LvdlYNE+tjVakCVXaoT+9AT3+SmWww+lCDV1Axx3bk 5ztGbPoDTogjc27Spowc7txKOHJnTBBFS1Bd044vaL8D9kyoegi0G9XkynCkOApFWLbo E/jW6tURwTmwhHHakhbf4C9zr7XGj8YGLOiwrOHLT3hms35cgDamO+PNBpBQs8wSZSLv BuFZ9DRc4GMqwdn8xJEseee8Qbryb2tRw5DGqOeV0Uqg00d3JubT5fz8HRYJJBNFDIeA KOvQ== MIME-Version: 1.0 X-Received: by 10.194.20.97 with SMTP id m1mr1256371wje.31.1372872670486; Wed, 03 Jul 2013 10:31:10 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 10:31:10 -0700 (PDT) In-Reply-To: <20130703171547.GH32044@mercury.ccil.org> References: <20130703171547.GH32044@mercury.ccil.org> Date: Wed, 3 Jul 2013 12:31:10 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 17:31:17 -0000 On Wed, Jul 3, 2013 at 12:15 PM, John Cowan wrote: > Tim Bray scripsit: >> - All JSON objects MUST have unique keys >> - All JSON messages MUST be either arrays or objects >> - Software receiving something violating any of these MUSTs has encountered >> conclusive evidence of serious upstream breakage and MUST NOT trust the >> contents nor act upon them. > > The trouble with all this is that They Break Data. All of a sudden, what > was valid JSON before is not valid JSON now. That's serious, especially > as people *do* keep around their JSON rather than using it only transiently > See above remarks about databases: it doesn't matter if the JSON is stores > as JSON or regenerated on the fly, because if I put in JSON today I expet > to get back JSON tomorrow, and not something that no longer counts as JSON. Tim is proposing a different JSON, "Internet JSON", to be used where appropriate. Consider this like the BCP, only as a Standards-Track RFC, and NOT updating/obsoleting RFC4627, but competing with it. I could live with that. From tbray@textuality.com Wed Jul 3 10:31: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 D84B621F9A05 for ; Wed, 3 Jul 2013 10:31:31 -0700 (PDT) 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=[AWL=-0.000, 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 tI0owy9GQd0E for ; Wed, 3 Jul 2013 10:31:26 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id ECB0B21F9A29 for ; Wed, 3 Jul 2013 10:31:22 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id jw11so363991veb.32 for ; Wed, 03 Jul 2013 10:31:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=OAe4oF7XzHBVx5xwEMNiE38gVru3MkGIv50IsAh8qeo=; b=flIhCsZPCd/PPc5782XGkM60HTSWbTu0i0qfDZjkjTXzbjPmT859z/Pw9UjYyZGnFu Tcve1UfWwRPmhac6w5vYNPJXHxouG6XiihpRU0jGtkNGjcfVU74u4sg5sfYOjh79nocQ QH26rH/GrxXAz/q5Drx61ppNNsAup0gg9eY7c94HXhIuOTBAaf8kf7Y4OPgtmYIDF+BJ oXGeE0Z7A/fqYkf/Sm+9PhUk+uDiD63JLH9ZukmHnnz3p+t0lRmapU6h/y6otI3WtAHl hUjCHdiPtAvLerVKL14Ehh1eSWLK0nH8WNp7kWCYG+F5Y0MXIdzHGHwYWBGqfbP/9vfc EGGg== MIME-Version: 1.0 X-Received: by 10.220.41.77 with SMTP id n13mr597945vce.36.1372872682226; Wed, 03 Jul 2013 10:31:22 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Wed, 3 Jul 2013 10:31:22 -0700 (PDT) X-Originating-IP: [209.121.225.216] In-Reply-To: <20130703171547.GH32044@mercury.ccil.org> References: <20130703171547.GH32044@mercury.ccil.org> Date: Wed, 3 Jul 2013 10:31:22 -0700 Message-ID: From: Tim Bray To: John Cowan Content-Type: multipart/alternative; boundary=047d7b3a90ee8bd75604e09ed4ab X-Gm-Message-State: ALoCoQkqHVEWqhEkgISiJ3Hb5+5+wcSImYmzJLO+KusLpl6fftvps94tve4E0o5NX++WMSEj3mpc Cc: "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 17:31:32 -0000 --047d7b3a90ee8bd75604e09ed4ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2013 at 10:15 AM, John Cowan wrote: > Tim Bray scripsit: > > > Also, I=E2=80=99ve never encountered a scenario where the messages were= of > > sufficient size that anyone gave a rat=E2=80=99s ass about streaming. > > Well, at least eight programmers have taken the trouble to write > such parsers Fair enough. If they can=E2=80=99t write them in such a way as to avoid dup= licates, they are NOT USABLE for application-level message passing, because the only use for JSON objects is sending a hash-table (or equivalent) from my computer to a hash-table (or equivalent) on yours, and if there are dupes, that's either a serious bug or a malicious attack on, for example, a JOSE header where they=E2=80=99re trying to fake out the algorithm selection. So= parsers that potentially emit dupes can=E2=80=99t comply with the RFC that I want t= o exist. Acceptable cost. > > - All JSON messages MUST be encoded in valid UTF-8. > > - All numbers MUST be of precision < 2**53 (use strings for your big > crypto > > numbers) > > Better: All numbers MUST be representable as IEEE 754:2008 binary > 64-bit floats. > I think my expression of the constraint is more readable, but I agree that yours is isomorphic. > > > - All JSON objects MUST have unique keys > > - All JSON messages MUST be either arrays or objects > > - Software receiving something violating any of these MUSTs has > encountered > > conclusive evidence of serious upstream breakage and MUST NOT trust the > > contents nor act upon them. > > The trouble with all this is that They Break Data. I care -Inf about this. In my application domain, we cook these up in memory, we send them, we unpack them at the other end. I agree, that if if we impose a new set of rules in a new RFC, previously-existing JSON might not pass muster as =E2=80=9CInternet JSON=E2=80=9D or whatever we cho= ose to call it. It=E2=80=99s still JSON Classic. Fair trade-off. -T --047d7b3a90ee8bd75604e09ed4ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 10:15 AM, John Cowan <cowan@m= ercury.ccil.org> wrote:
Tim Bray scripsit:
=C2=A0
> Also, I=E2=80=99ve never encountered a sce= nario where the messages were of
> sufficient size that anyone gave a rat=E2=80=99s ass about streaming.<= br>
Well, at least eight programmers have taken the trouble to write
such parsers

Fair enough. If they can=E2=80= =99t write them in such a way as to avoid duplicates, they are NOT USABLE f= or application-level message passing, because the only use for JSON objects= is sending a hash-table (or equivalent) from my computer to a hash-table (= or equivalent) on yours, and if there are dupes, that's either a seriou= s bug or a malicious attack on, for example, a JOSE header where they=E2=80= =99re trying to fake out the algorithm selection. So parsers that potential= ly emit dupes can=E2=80=99t comply with the RFC that I want to exist.=C2=A0= Acceptable cost.
=C2=A0
=C2=A0
> - All JSON messages MUST be encoded in valid UTF-8.
> - All numbers MUST be of precision < 2**53 (use strings for your bi= g crypto
> numbers)

Better: All numbers MUST be representable as IEEE 754:2008 binary
64-bit floats.

I think my expression of= the constraint is more readable, but I agree that yours is isomorphic.
=
=C2=A0

> - All JSON objects MUST have unique keys
> - All JSON messages MUST be either arrays or objects
> - Software receiving something violating any of these MUSTs has encoun= tered
> conclusive evidence of serious upstream breakage and MUST NOT trust th= e
> contents nor act upon them.

The trouble with all this is that They Break Data.
=
I care -Inf about this.=C2=A0 In my application domain, we c= ook these up in memory, we send them, we unpack them at the other end.=C2= =A0=C2=A0 I agree, that if if we impose a new set of rules in a new RFC, pr= eviously-existing JSON might not pass muster as =E2=80=9CInternet JSON=E2= =80=9D or whatever we choose to call it.=C2=A0 It=E2=80=99s still JSON Clas= sic.=C2=A0 Fair trade-off.=C2=A0 -T

--047d7b3a90ee8bd75604e09ed4ab-- From presnick@qti.qualcomm.com Wed Jul 3 12:00: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 8BED611E823B for ; Wed, 3 Jul 2013 12:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.266 X-Spam-Level: X-Spam-Status: No, score=-106.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, 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 bAygMFayep0C for ; Wed, 3 Jul 2013 12:00:46 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id BD56311E821E for ; Wed, 3 Jul 2013 12:00:39 -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=1372878039; x=1404414039; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=od0lwqzrVAKnt4CH6c8tAaX+tUW56fpAWOLk3ya7bhk=; b=MsJfxRkIv9MfwrxCoe3Xej7C29w/rYjsUf75xMFHMLsTR1vLDuE4XpzX JPGaPw6mB756iejo4S3WNj6cQPn0ITHNbX3CS6+Tyuo4L2slD3aojiLeT TJc0akTcLi4li9Wa4yCYiLkDchi6WP0AEW0S0hpoN8IlUIc9PHGsL8iaj o=; X-IronPort-AV: E=Sophos;i="4.87,989,1363158000"; d="scan'208";a="60618854" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 03 Jul 2013 12:00:38 -0700 X-IronPort-AV: E=Sophos;i="4.87,989,1363158000"; d="scan'208";a="509221519" Received: from nasanexhc03.na.qualcomm.com ([172.30.48.26]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2013 12:00:19 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC03.na.qualcomm.com (172.30.48.26) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 3 Jul 2013 12:00:14 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 3 Jul 2013 12:00:14 -0700 Message-ID: <51D474BD.7040302@qti.qualcomm.com> Date: Wed, 3 Jul 2013 14:00:13 -0500 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: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [Json] Quick note / People coming to Berlin? 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, 03 Jul 2013 19:00:51 -0000 Speaking as cognizant AD for this group: The running discussion over the past 24 hours has been a bit intense for me to catch up on. I'm hoping to send a message by EOB today with some thoughts. I do not think all hope is lost on doing what this group was chartered to do. A question: Who of this group is going to be at the face-to-face in Berlin? I'm a bit worried that we're spinning our wheels because people seem to be talking past each other and some face-to-face time might do some good. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From cowan@ccil.org Wed Jul 3 12:12: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 DDF6B21F9C8B for ; Wed, 3 Jul 2013 12:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 A7rnjypyoTmp for ; Wed, 3 Jul 2013 12:12:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id C461621F9C5F for ; Wed, 3 Jul 2013 12:12:13 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuSTM-00008l-Of; Wed, 03 Jul 2013 15:12:12 -0400 Date: Wed, 3 Jul 2013 15:12:12 -0400 From: John Cowan To: Tim Bray Message-ID: <20130703191212.GI32044@mercury.ccil.org> References: <20130703171547.GH32044@mercury.ccil.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: "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 19:12:21 -0000 Tim Bray scripsit: > > > - All numbers MUST be of precision < 2**53 > > Better: All numbers MUST be representable as IEEE 754:2008 binary > > 64-bit floats. > > I think my expression of the constraint is more readable, but I agree > that yours is isomorphic. Well, no. 1E400 requires only one bit of precision, but it's not representable as a double, because doubles only go up to 1E308 or so. > > The trouble with all this is that They Break Data. > > I care -Inf about this. That reminds me how *annoying* it is that there's no way to represent Inf, -Inf, or NaN. Too late now, I suppose. > In my application domain, we cook these up in memory, we send them, > we unpack them at the other end. I agree, that if if we impose a > new set of rules in a new RFC, previously-existing JSON might not pass > muster as “Internet JSON†or whatever we choose to call it. How about "Ephemeral Mini-JSON"? Can't be too big, not expected to last. -- With techies, I've generally found John Cowan If your arguments lose the first round http://www.ccil.org/~cowan Make it rhyme, make it scan cowan@ccil.org Then you generally can Make the same stupid point seem profound! --Jonathan Robie From tsaloranta@gmail.com Wed Jul 3 12:21: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 282C521F9DB2 for ; Wed, 3 Jul 2013 12:21:53 -0700 (PDT) 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, 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 S015LjLS+rGu for ; Wed, 3 Jul 2013 12:21:52 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id DAF2C21F9DA5 for ; Wed, 3 Jul 2013 12:21:48 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so498762wib.2 for ; Wed, 03 Jul 2013 12:21:41 -0700 (PDT) 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=23JDE6vCTmtvyhNunSwFvTbNHbksaNeg1cGCFIucUcg=; b=AYRlTg5MOEzeRw7I/jLHpy/5qE8fhb250NLXlgWGAoXF/b7dUWtOSVyLh+m4syhuzl 107mBmYcRVH5A8kfyk2KxGi9NyBCiPr37Wc9qF64+HqWYMc+kV7GuY+bera+TCYXnfVb 5LA8m6VmkRfGeSGGU/qvHrH7Wp9UVtCCD+nGOypHwhc9nIaA43LM7UOtfvbGBoeO9HxX S8HkX1S7cGVUioUNb+lk3xQl6Uz+fXqQGP7YMZo8BJedBfqyOM15abfPNHoui+YNvSV3 OxYbGtZAhGLa2VauM58YNzgiGsQDHU/LsoeO34uUs/Hv2+oriYuFZsyOSD+/GWT68oIz 5cIw== MIME-Version: 1.0 X-Received: by 10.180.206.70 with SMTP id lm6mr19145538wic.50.1372879301609; Wed, 03 Jul 2013 12:21:41 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Wed, 3 Jul 2013 12:21:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 12:21:41 -0700 Message-ID: From: Tatu Saloranta To: Tim Bray Content-Type: multipart/alternative; boundary=001a11c265be1790e904e0a05f6e Cc: "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 19:21:53 -0000 --001a11c265be1790e904e0a05f6e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2013 at 9:34 AM, Tim Bray wrote: > I think it will be helpful to put a stick in the ground: Most of my > professional activity centers around designing and using message-passing > application-level APIs. In basically all of them, the payload is JSON. > > So I care a lot about JSON, but I don=92t care in the slightest about usa= ges > where the JSON isn=92t being used for application-level message protocol > payloads (are there such usages? I'm curious). Also, I=92ve never > encountered a scenario where the messages were of sufficient size that > anyone gave a rat=92s ass about streaming. > > Large payload are commonly used for things like map/reduce jobs and search indexing. And databases of sorts (NoSQL or traditional) are similarly exposing large datasets where one certainly does not want to or even be able to handle all data in memory. There are ways to avoid problems with large Objects for many cases within this domain, for example, by sending sequences of root-level objects. Parsers then need to be able to handle streams of multiple Objects. Streaming is equally important (or perhaps more so) when generating results; for latency (as well as memory usage) reasons large result sets are best sent in streaming manner. Same is true for XML as well, so I don't think this is JSON-specific question. I might as well claim that I have rarely worked on JSON use case where Javascript matters at all. This is a true statement, but I would not draw conclusions from this to allege that Javascript would be largely irrelevant for JSON data exchange. I think part of the challenge is that for many practicioners JSON "Just Works" well enough that they could not care less about further standardization: and in fact the whole notion that duplicate keys are a major problem seems like a red herring. It has never been a problem for me, nor has there been user requests beyond schema (and schema validator) implementors who care more. But it is possible that perhaps this has been a significant problem for others. -+ Tatu +- --001a11c265be1790e904e0a05f6e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 9:34 AM, Tim Bray <tbray@textua= lity.com> wrote:
I think it will be helpful to put a stick in the ground:=A0 Mo= st of my professional activity centers around designing and using message-p= assing application-level APIs.=A0 In basically all of them, the payload is = JSON.=A0

So I care a lot about JSON, but I don=92t care in the slightest a= bout usages where the JSON isn=92t being used for application-level message= protocol payloads (are there such usages?=A0 I'm curious).=A0 Also, I= =92ve never encountered a scenario where the messages were of sufficient si= ze that anyone gave a rat=92s ass about streaming.


<= /div>
Large payload are commonly used for things like map/reduce jobs a= nd search indexing. And databases of sorts (NoSQL or traditional) are simil= arly exposing large datasets where one certainly does not want to or even b= e able to handle all data in memory.

There are ways to avoid problems with large Objects for many cases with= in this domain, for example, by sending sequences of root-level objects. Pa= rsers then need to be able to handle streams of multiple Objects.
Stream= ing is equally important (or perhaps more so) when generating results; for = latency (as well as memory usage) reasons large result sets are best sent i= n streaming manner.

Same is true for XML as well, so I don't think this is JSON-s= pecific question.

I might as well claim that I have rarely worked on JSON us= e case where Javascript matters at all. This is a true statement, but I wou= ld not draw conclusions from this to allege that Javascript would be largel= y irrelevant for JSON data exchange.

I thi= nk part of the challenge is that for many practicioners JSON "Just Wor= ks" well enough that they could not care less about further standardiz= ation: and in fact the whole notion that duplicate keys are a major problem= seems like a red herring.
It has never been a problem for me, nor ha= s there been user requests beyond schema (and schema validator) implementor= s who care more. But it is possible that perhaps this has been a significan= t problem for others.

-+ Tatu +-

--001a11c265be1790e904e0a05f6e-- From cromis@gmail.com Wed Jul 3 12:30: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 A17C011E8202 for ; Wed, 3 Jul 2013 12:30:16 -0700 (PDT) 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 hqZYI8MQLHbe for ; Wed, 3 Jul 2013 12:30:16 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2629C11E81F9 for ; Wed, 3 Jul 2013 12:30:15 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id z10so336638qcx.7 for ; Wed, 03 Jul 2013 12:30:15 -0700 (PDT) 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 :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=7yLcNEaQbe/wgGV77aIfBWIJeW4jvbTa9TVgQ8BP47k=; b=j2gxHey4OwXWQjBFIj2b6p10EQBRNVq8yGhAd5meS/ZQNU3ZmnOG5vYdkfOJj1aY0k 5YjwGjVEDpBobbFLDEuaWimQ5tlIrN/79lSgbwfGZkbbZhBrdeTE40EBlPkujF08HtgA EN2HcNJzAYr5KjA91TYSMHSaKKl2Bzy10bnkNYhFU47vrL/Kx2JZlfaB8/C675rMA313 SbAyRdoXNEuL2DFtI9Bh7d1/KoY2wMwg25GT/bZJDiM8L4vrRFuJOY2E7SXCVAcKWuyk gSOsLBGJ07Q/BFGfl8f3NbdkbsP+LEcAc3YzlvZzLHX/TySeqcE86gNLZb18fApY2NaC 3Zkw== X-Received: by 10.224.7.129 with SMTP id d1mr5741954qad.108.1372879815521; Wed, 03 Jul 2013 12:30:15 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.76.42 with HTTP; Wed, 3 Jul 2013 12:29:55 -0700 (PDT) In-Reply-To: References: From: Jacob Davies Date: Wed, 3 Jul 2013 12:29:55 -0700 X-Google-Sender-Auth: AxJiSCy5xXsUZoqsDF-I8crjkjI Message-ID: To: Tim Bray Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 19:30:16 -0000 On Wed, Jul 3, 2013 at 9:34 AM, Tim Bray wrote: > So I care a lot about JSON, but I don=92t care in the slightest about usa= ges > where the JSON isn=92t being used for application-level message protocol > payloads (are there such usages? I'm curious). There are a number of practical use cases for JSON that don't fall into the neat "externally delimited stream of bytes described by an application/json media-type" category. That is a separate question to whether the RFC needs to do much to accomodate them. 1. Files named ".json" and containing a single JSON object or array. 2. Text documents containing embedded JSON - informally, as in documentation or books, or formally, as in Javascript in HTML or .js files. 3. Database records where text or binary columns store embedded JSON representing complex nested objects. Case 1 is handled the same as a message described as application/json, no big deal. Cases 2 & 3 may require accommodating non-Unicode encodings, and may have some special security concerns (e.g. additional escaping for HTML or Javascript embedding). It would be nice if the spec separated format from encoding, but it's unlikely to be the source of any significant problems since in most cases the handling of encoding will have happened by the time you parse the text, and the security concerns can be addressed in best-practices. > Also, I=92ve never encountered a scenario where the messages were of suff= icient size that > anyone gave a rat=92s ass about streaming. Me either, and even if there were such cases I find the concerns about maintaining state unconvincing - maintaining a seen-keys dictionary for each level of nesting you're in is not all that much of an imposition or incompatible with a streaming API. From tsaloranta@gmail.com Wed Jul 3 12:33:04 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 628D421F9DC6 for ; Wed, 3 Jul 2013 12:33:04 -0700 (PDT) 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, 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 ie0TYEtSJVgN for ; Wed, 3 Jul 2013 12:33:03 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8F07B21F9DCA for ; Wed, 3 Jul 2013 12:33:00 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so454507wgh.6 for ; Wed, 03 Jul 2013 12:32:59 -0700 (PDT) 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=cD4cYaNhDn5b0zLNv25l5RHULUgkyDdv+WXlNzxTLTY=; b=bPicj926L0dLsSX6PGAh9VSiexe7tZzb0MFLmITlBbbE1WDiCJADKZCIukNkSzOilc ng1Y6tP/SbW9+7Mequ+clNz8exAhumUs10bU70yAry6somajoWN1gtl9/8PX24UtknLf Zak/mg61LxYzz/2wDgGRdbtgR4QRBuN0R8WCA6o7IJnYVuvTwJz+d8loN60GotghTod6 Y0k0cCoy/Cjrpjy+3cpZYIPB6GfdL0zOidtpNr2+LRd/UVc0Lnr5PMijn9d3JH+Y6xye ynVRvuSrLE5uxExaWYvNWO0VEB66M9Qzs9b2qCBcCk5tHjdrRB98+Luw+xSEJdPtz+uD YuJQ== MIME-Version: 1.0 X-Received: by 10.180.188.36 with SMTP id fx4mr18846525wic.55.1372879979578; Wed, 03 Jul 2013 12:32:59 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Wed, 3 Jul 2013 12:32:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 12:32:59 -0700 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c25cd8808d6504e0a0870b Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 03 Jul 2013 19:33:04 -0000 --001a11c25cd8808d6504e0a0870b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 3, 2013 at 9:29 AM, Nico Williams wrote: > On Wed, Jul 3, 2013 at 10:37 AM, Paul Hoffman > wrote: > > > > > > +1 to everything Tim said, particularly "charter is self-contradictory". > We didn't realize this when we put together the charter (a process in which > dozens of people participated), but we do now. > > Re-reading the charter I'm not sure that there's a contradiction. We > can do something: > > - remove the safe-for-eval regexp silliness > > - add a section describing divergent interpretations > > - leave the rest mostly as-is with only those changes for which we > can get consensus > > E.g., we can probably get consensus for "generators SHOULD NOT > output duplicate names" and "parsers SHOULD use the last of any > duplicate names" with appropriate text describing when and why one > might deviate from this guidance. > > E.g., we can probably get consensus for describing a subset of JSON > strings that is guaranteed to interoperate, even though we can't ban > unpaired surrogates. > > Then re-charter and publish a BCP. > +1 for this. On unpaired surrogates: since their potential use has been outlined multiple times, I am wondering if this has been substantiated by links to systems that make use of this ability? I assume this potential exists only on some platforms (and specifically not useful for platforms I typically work on), but it would good to see links, similar to recent listing of Streaming JSON processors one can find with bit of googling (happy to see my SO answer being linked :) ). -+ Tatu +- --001a11c25cd8808d6504e0a0870b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 9:29 AM, Nico Williams <nico@c= ryptonector.com> wrote:
On Wed, Jul 3, 2013 at 10:= 37 AM, Paul Hoffman <paul.hoffm= an@vpnc.org> wrote:
> <no hats>
>
> +1 to everything Tim said, particularly "charter is self-contradi= ctory". We didn't realize this when we put together the charter (a= process in which dozens of people participated), but we do now.

Re-reading the charter I'm not sure that there's a contradict= ion. =A0We
can do something:

=A0- remove the safe-for-eval regexp silliness

=A0- add a section describing divergent interpretations

=A0- leave the rest mostly as-is with only those changes for which we
can get consensus

=A0 =A0E.g., we can probably get consensus for "generators SHOULD NOT<= br> output duplicate names" and "parsers SHOULD use the last of any duplicate names" with appropriate text describing when and why one
might deviate from this guidance.

=A0 =A0E.g., we can probably get consensus for describing a subset of JSON<= br> strings that is guaranteed to interoperate, even though we can't ban unpaired surrogates.

Then re-charter and publish a BCP.


= +1 for this.

On unpaired surrogates: since their potentia= l use has been outlined multiple times, I am wondering if this has been sub= stantiated by links to systems that make use of this ability? I assume this= potential exists only on some platforms (and specifically not useful for p= latforms I typically work on), but it would good to see links, similar to r= ecent listing of Streaming JSON processors one can find with bit of googlin= g (happy to see my SO answer being linked :) ).

-+ Tatu +-

--001a11c25cd8808d6504e0a0870b-- From tbray@textuality.com Wed Jul 3 12:35: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 90A6211E821B for ; Wed, 3 Jul 2013 12:35:39 -0700 (PDT) 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 MkWm+v0goPSD for ; Wed, 3 Jul 2013 12:35:33 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9308D21F9D89 for ; Wed, 3 Jul 2013 12:35:28 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id r11so547387lbv.13 for ; Wed, 03 Jul 2013 12:35:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=arcwPPUIqrCHxpDp3QbHZsIKTHxOGLj9uqtwxNEJnJg=; b=MM+xqJq4fjMyis6no4+kcgPS62WmBcJblQkgo4bTw4BH4kB4OBlPBAMcqgCoiEPRW2 eV/3BCHduqyEGhCcgxlyPemxoEezx0zGE324/7dbvpqAunjdgo5rpY5BItLokDz+9rSJ 3TcuqOUdzTj3QYzcbREp7VHnenOXil7cOXfZSQHxIlsL7XKTSsKK7RRxwLTLTZJmgHRP CvSF60MZVH53t8Yvrbsdv4VIukMc/W/nfS69CobGYNXRK4xHd526+0v+XujbFVDITTHZ qvv0I2eTuicRBXgbgG6HcRiD0W7ixwuVtWXf+2FHU5K//8N0U/ZmfhUgPlG/jdntbiJG b81Q== MIME-Version: 1.0 X-Received: by 10.152.25.135 with SMTP id c7mr1172150lag.39.1372880127427; Wed, 03 Jul 2013 12:35:27 -0700 (PDT) Received: by 10.114.71.51 with HTTP; Wed, 3 Jul 2013 12:35:27 -0700 (PDT) X-Originating-IP: [209.121.225.216] In-Reply-To: References: Date: Wed, 3 Jul 2013 12:35:27 -0700 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=089e0160c4065096ce04e0a09021 X-Gm-Message-State: ALoCoQnUAG19b6MshiqgELC7dOSPuSBlqrMz2CGxYLz2V13XRUYLVF1NlXKYeq1djnvEQ4/qIEtn Cc: Paul Hoffman , "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 03 Jul 2013 19:35:39 -0000 --089e0160c4065096ce04e0a09021 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to Nico=E2=80=99s suggestion. -T On Wed, Jul 3, 2013 at 9:29 AM, Nico Williams wrote= : > On Wed, Jul 3, 2013 at 10:37 AM, Paul Hoffman > wrote: > > > > > > +1 to everything Tim said, particularly "charter is self-contradictory"= . > We didn't realize this when we put together the charter (a process in whi= ch > dozens of people participated), but we do now. > > Re-reading the charter I'm not sure that there's a contradiction. We > can do something: > > - remove the safe-for-eval regexp silliness > > - add a section describing divergent interpretations > > - leave the rest mostly as-is with only those changes for which we > can get consensus > > E.g., we can probably get consensus for "generators SHOULD NOT > output duplicate names" and "parsers SHOULD use the last of any > duplicate names" with appropriate text describing when and why one > might deviate from this guidance. > > E.g., we can probably get consensus for describing a subset of JSON > strings that is guaranteed to interoperate, even though we can't ban > unpaired surrogates. > > Then re-charter and publish a BCP. > > Alternatively, we could re-charter now. I can propose text as soon as > we decide to start that discussion. > > Nico > -- > --089e0160c4065096ce04e0a09021 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to Nico=E2=80=99s suggestion.=C2=A0 -T


On Wed, Jul 3, 2013 = at 9:29 AM, Nico Williams <nico@cryptonector.com> wrote:=
On Wed, Jul 3, 2013 at 10:= 37 AM, Paul Hoffman <paul.hoffm= an@vpnc.org> wrote:
> <no hats>
>
> +1 to everything Tim said, particularly "charter is self-contradi= ctory". We didn't realize this when we put together the charter (a= process in which dozens of people participated), but we do now.

Re-reading the charter I'm not sure that there's a contradict= ion. =C2=A0We
can do something:

=C2=A0- remove the safe-for-eval regexp silliness

=C2=A0- add a section describing divergent interpretations

=C2=A0- leave the rest mostly as-is with only those changes for which we can get consensus

=C2=A0 =C2=A0E.g., we can probably get consensus for "generators SHOUL= D NOT
output duplicate names" and "parsers SHOULD use the last of any duplicate names" with appropriate text describing when and why one
might deviate from this guidance.

=C2=A0 =C2=A0E.g., we can probably get consensus for describing a subset of= JSON
strings that is guaranteed to interoperate, even though we can't ban unpaired surrogates.

Then re-charter and publish a BCP.

Alternatively, we could re-charter now. =C2=A0I can propose text as soon as=
we decide to start that discussion.

Nico
--

--089e0160c4065096ce04e0a09021-- From cabo@tzi.org Wed Jul 3 12:42: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 CB3B511E821B for ; Wed, 3 Jul 2013 12:42:24 -0700 (PDT) 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 O5cI+Za1zpCr for ; Wed, 3 Jul 2013 12:42:19 -0700 (PDT) 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 AB79811E821A for ; Wed, 3 Jul 2013 12:42:18 -0700 (PDT) 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 r63Jg5KC008890; Wed, 3 Jul 2013 21:42:05 +0200 (CEST) Received: from [192.168.217.105] (p54893DEB.dip0.t-ipconnect.de [84.137.61.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 484E637D0; Wed, 3 Jul 2013 21:42:05 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 3 Jul 2013 21:42:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1AB34263-877A-43FC-899E-4681F90BD7B8@tzi.org> References: To: Nico Williams X-Mailer: Apple Mail (2.1508) Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 03 Jul 2013 19:42:24 -0000 On Jul 3, 2013, at 18:29, Nico Williams wrote: > leave the rest mostly as-is=20 That means that every user of JSON has to define their own additional = clarifications, as JOSE has started to do. In effect, each user creates their own little dialect. A textbook example for how to create soup. I'd rather have 2 or 3 flavors of JSON than n, where n is the number of = users. (Or, if it has to be, 2 or 3 on/off pizza toppings each of which can be = selected or deselected.) Gr=FC=DFe, Carsten From tsaloranta@gmail.com Wed Jul 3 12:45: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 18E9B11E8212 for ; Wed, 3 Jul 2013 12:45:50 -0700 (PDT) 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, 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 I9mPzPXVBzq8 for ; Wed, 3 Jul 2013 12:45:49 -0700 (PDT) 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 0CFB111E8210 for ; Wed, 3 Jul 2013 12:45:48 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so6622305wiw.2 for ; Wed, 03 Jul 2013 12:45:48 -0700 (PDT) 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=Z2Ng8FZd8GKdxhL6+vGkJ3gbXCKuCgnB/lu3Bp0WT5k=; b=nDxtiGxLKD6F0e8KfUEq+jFdOkwtu0Ep0gbMoJWK3hZAw5/r4gpWIQ+5HDwMv+gRjw 62fhetBnfrya5LclncFWRuzQRvlX6jMA215a0n0pPef7oj4SadhoxZnpmTZMbId4YqLl w1pcG/kT8RZJS7xRVc2SOFyENM5twYySV4D+ZQWv4xnAGrAoiAj9mMzcj1e1+htBJ/NX LYjPSWxhilvuFUa1vVOCnWJrGLLWKnKzBl0yLKtuYbgH1jyoHE6vyrshCqKBHBwktpE7 w0HjQCMYf2c97UgDSLA+Aq9hIXXYDPeu7L5Kid9bn9i9WmCf0JqBmm8tT+ymNPmr7XnD wVjA== MIME-Version: 1.0 X-Received: by 10.194.104.74 with SMTP id gc10mr1533612wjb.48.1372880748193; Wed, 03 Jul 2013 12:45:48 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Wed, 3 Jul 2013 12:45:48 -0700 (PDT) In-Reply-To: <51D3CB52.7040902@cisco.com> References: <51D3C63C.5030703@cisco.com> <51D3CB52.7040902@cisco.com> Date: Wed, 3 Jul 2013 12:45:48 -0700 Message-ID: From: Tatu Saloranta To: Eliot Lear Content-Type: multipart/alternative; boundary=047d7bf10b4650ae1f04e0a0b543 Cc: Nico Williams , Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 19:45:50 -0000 --047d7bf10b4650ae1f04e0a0b543 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 2, 2013 at 11:57 PM, Eliot Lear wrote: > Hi Nico, > > On 7/3/13 8:45 AM, Nico Williams wrote: > > On Wed, Jul 3, 2013 at 1:35 AM, Eliot Lear wrote: > >>> In short, for streaming parsers (and generators) there's nothing we > can do. > >>> > >>> What we can do is RECOMMEND that a) generators not produce duplicates > >>> (and explain how streaming ones cannot prevent dups), and b) that > >>> parsers use the last name (and explain how streaming ones will produce > >>> all dups). > >> To me this isn't strong enough. I have some sympathy for both the > >> existing base and for parsers, but generators as an architectural > >> component should generate unambiguous output, streaming or otherwise. > >> And that follow's Postel's Law: > > How can a streaming generator do that? The API for one might look like: > > > > ObjectStart(context) > > ObjectAdd(context, name, value) > > ... > > > > There's no way a minimal-state streaming generator (but I repeat > > myself; the whole point of a streaming interface is to keep minimal > > state :) can detect duplicates with O(1) state (probabilistic > > structures with false positives won't be acceptable either). > > You've got to retain state. You don't have to retain the value, but you > do have to retain the name. It's O(k), and knowing you I know you're > smart enough to approach that (because I am and so I'm using inductive > theory ;-). And I'll bet you a nickel that this is not going to be > anyone's high order bit. > > > There is difference between retaining parent path (names of "open" Object properties), and retaining names of all preceding siblings. Latter is expensive and/or complicated. Former is indeed done by parsers that try to give useful error information with respect to nesting problems and such. I also think that probabilistic approaches would be problematic from user POV: one has to allocate lots of memory -- not just for hashes for names seen (or derivative thereof like Bloom filter(s)), but also locations for error messages. If spec did mandate requirement to check for dups, then both generators and parsers would have to do it; and at least parsers would need additional metadata to give proper error messages to indicate nature of collision (what, where). -+ Tatu +- --047d7bf10b4650ae1f04e0a0b543 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 2, 2013 at 11:57 PM, Eliot Lear <<= a href=3D"mailto:lear@cisco.com" target=3D"_blank">lear@cisco.com> wrote:
Hi Nico,

On 7/3/13 8:45 AM, Nico Williams wrote:
> On Wed, Jul 3, 2013 at 1:35 AM, Eliot Lear <lear@cisco.com> wrote:
>>> In short, for streaming parsers (and generators) there's n= othing we can do.
>>>
>>> What we can do is RECOMMEND that a) generators not produce dup= licates
>>> (and explain how streaming ones cannot prevent dups), and b) t= hat
>>> parsers use the last name (and explain how streaming ones will= produce
>>> all dups).
>> To me this isn't strong enough. =A0I have some sympathy for bo= th the
>> existing base and for parsers, but generators as an architectural<= br> >> component should generate unambiguous output, streaming or otherwi= se.
>> And that follow's Postel's Law:
> How can a streaming generator do that? =A0The API for one might look l= ike:
>
> ObjectStart(context)
> ObjectAdd(context, name, value)
> ...
>
> There's no way a minimal-state streaming generator (but I repeat > myself; the whole point of a streaming interface is to keep minimal > state :) can detect duplicates with O(1) state (probabilistic
> structures with false positives won't be acceptable either).

You've got to retain state. =A0You don't have to retain the v= alue, but you
do have to retain the name. =A0It's O(k), and knowing you I know you= 9;re
smart enough to approach that (because I am and so I'm using inductive<= br> theory ;-). =A0And I'll bet you a nickel that this is not going to be anyone's high order bit.
>


There = is difference between retaining parent path (names of "open" Obje= ct properties), and retaining names of all preceding siblings. Latter is ex= pensive and/or complicated.
Former is indeed done by parsers that try to give useful error i= nformation with respect to nesting problems and such.

I a= lso think that probabilistic approaches would be problematic from user POV:= one has to allocate lots of memory -- not just for hashes for names seen (= or derivative thereof like Bloom filter(s)), but also locations for error m= essages.

If spec did mandate requirement to check for dups= , then both generators and parsers would have to do it; and at least parser= s would need additional metadata to give proper error messages to indicate = nature of collision (what, where).

-+ Tatu +-
=A0
--047d7bf10b4650ae1f04e0a0b543-- From presnick@qti.qualcomm.com Wed Jul 3 12:49:03 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 5185C11E8224 for ; Wed, 3 Jul 2013 12:49:03 -0700 (PDT) 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 1y3k0yz6vAc3 for ; Wed, 3 Jul 2013 12:48:59 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2F411E8210 for ; Wed, 3 Jul 2013 12:48:59 -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=1372880939; x=1404416939; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OwK/btaplHkITgMqF7uh5tudwe6AZiJdwPE7rgYRzS8=; b=YmwImAZXFr+jCLxHMBI90t6RF8i0aW9hkcpl7zeLXn0f3vvJt/WTkE3/ cIIvmQAQ8z0fPBNNg90jaHPQOGIFEGGv0VB9xNn1p9e1WhZvncavsOVP/ dhrX6MvUJQd42WRNUWldxLlndhQT1UrGO6hXmVBBbRnHBpS/5YbHMt5TN A=; X-IronPort-AV: E=Sophos;i="4.87,990,1363158000"; d="scan'208";a="46702109" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 03 Jul 2013 12:48:53 -0700 X-IronPort-AV: E=Sophos;i="4.87,989,1363158000"; d="scan'208";a="474124229" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2013 12:48:53 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc06.na.qualcomm.com (172.30.48.21) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 3 Jul 2013 12:48:53 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 3 Jul 2013 12:48:52 -0700 Message-ID: <51D48023.1020008@qti.qualcomm.com> Date: Wed, 3 Jul 2013 14:48:51 -0500 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: Eliot Lear References: <51D3C63C.5030703@cisco.com> In-Reply-To: <51D3C63C.5030703@cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Nico Williams , Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 19:49:03 -0000 Speaking strictly as a participant, and just to give guidance, not insist on an outcome. On 7/3/13 1:35 AM, Eliot Lear wrote: > Nico, > >> In short, for streaming parsers (and generators) there's nothing we can do. >> >> What we can do is RECOMMEND that a) generators not produce duplicates >> (and explain how streaming ones cannot prevent dups), and b) that >> parsers use the last name (and explain how streaming ones will produce >> all dups). >> > To me this isn't strong enough. I have some sympathy for both the > existing base and for parsers, but generators as an architectural > component should generate unambiguous output, streaming or otherwise. > Let's remember the meaning of these capitalized words in IETF parlance. We use them "where it is actually required for interoperation or to limit behavior which has potential for causing harm." So a MUST would mean that not doing so would prevent interoperation or cause harm. RECOMMENDED (like SHOULD) would also mean that not doing so would prevent interoperation or cause harm, but "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." In this instance, saying that generators SHOULD not produce duplicates is to say that if you do produce them, you might not interoperate or you might cause harm to some parsers, but there might be valid reasons (i.e., because your storage or compute footprint is too small to retain state) to produce duplicates. And documenting that there may be reasons that generators will produce duplicates (and explicitly stating those reasons) certainly puts parsers on notice that they will need to deal with it. Giving parsers some guidance on what to do in that case is all the better. So I don't think saying RECOMMENDED or SHOULD regarding not producing duplicates should be seen as a non-starter. That's a defensible position for the WG to take. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From cowan@ccil.org Wed Jul 3 12:57: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 BA6B211E8221 for ; Wed, 3 Jul 2013 12:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 wAPiiNK++cRf for ; Wed, 3 Jul 2013 12:57:44 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B0BED11E820F for ; Wed, 3 Jul 2013 12:57:44 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuTBP-0004PE-Th; Wed, 03 Jul 2013 15:57:44 -0400 Date: Wed, 3 Jul 2013 15:57:43 -0400 From: John Cowan To: Pete Resnick Message-ID: <20130703195743.GJ32044@mercury.ccil.org> References: <51D474BD.7040302@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D474BD.7040302@qti.qualcomm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Quick note / People coming to Berlin? 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, 03 Jul 2013 19:57:48 -0000 Pete Resnick scripsit: > The running discussion over the past 24 hours has been a bit intense > for me to catch up on. I'm hoping to send a message by EOB today > with some thoughts. I do not think all hope is lost on doing what > this group was chartered to do. Well, one of the chairs has said (albeit while hatless[1]), that the charter is self-contradictory. While that may not be the voice of the god "coming to tell of doom in words like beaten bronze"[2], it's certainly not encouraging. [1] [2] Mary Renault, _The Mask Of Apollo_ (ch. 2) -- The Imperials are decadent, 300 pound John Cowan free-range chickens (except they have http://www.ccil.org/~cowan teeth, arms instead of wings, and dinosaurlike tails). --Elyse Grasso From tsaloranta@gmail.com Wed Jul 3 13:07: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 3CE8A11E8226 for ; Wed, 3 Jul 2013 13:07:05 -0700 (PDT) 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=[AWL=0.000, 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 XLxEfkkjCxNA for ; Wed, 3 Jul 2013 13:07:04 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id ECA1521F99BB for ; Wed, 3 Jul 2013 13:07:03 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so532155wid.16 for ; Wed, 03 Jul 2013 13:07:03 -0700 (PDT) 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=Lk7+WhP0GQ5Wk712x5/DdfO2by+o+6eNQ764a1/EG00=; b=psyKsk29LnpFt5VsLEm8YwrEirPd2fkD6fqWADvOuSuvkzApWMtLZt7TBacjPt/3HG ykIkTWIWD6ZmLyKwMKS6Vhdy+gmUXknU73fiC5N7nn4eYw3bw7AzMks6S0uXISYH/Lnu KFQS7mQYFENz+9exnix3A/WcEQ6myTadhDgBHvn2UlcZKwuUmwDE+PaoAz2Yl/fRQYk7 Q2vtOZz3a9GB2g1p5HBEdl0naw2FtevVrEHNqBFzokh/90s8jObxf8UiwwQrgW4mO4cM oVJa7KAw8fwqvmWF6/qgggV9fX8/KHGoDTlHdO8jLuVXv6eAK2ltWWqOpzm5jOnFEcID Vu+A== MIME-Version: 1.0 X-Received: by 10.180.188.36 with SMTP id fx4mr18918201wic.55.1372882023041; Wed, 03 Jul 2013 13:07:03 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Wed, 3 Jul 2013 13:07:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 13:07:02 -0700 Message-ID: From: Tatu Saloranta To: Jacob Davies Content-Type: multipart/alternative; boundary=001a11c25cd84d525a04e0a10128 Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 20:07:05 -0000 --001a11c25cd84d525a04e0a10128 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jul 3, 2013 at 12:29 PM, Jacob Davies wrote: > On Wed, Jul 3, 2013 at 9:34 AM, Tim Bray wrote: > > So I care a lot about JSON, but I don=92t care in the slightest about > usages > > where the JSON isn=92t being used for application-level message protoco= l > > payloads (are there such usages? I'm curious). > > There are a number of practical use cases for JSON that don't fall > into the neat "externally delimited stream of bytes described by an > application/json media-type" category. That is a separate question to > whether the RFC needs to do much to accomodate them. > > 1. Files named ".json" and containing a single JSON object or array. > 2. Text documents containing embedded JSON - informally, as in > documentation or books, or formally, as in Javascript in HTML or .js > files. > 3. Database records where text or binary columns store embedded JSON > representing complex nested objects. > > Case 1 is handled the same as a message described as application/json, > no big deal. Cases 2 & 3 may require accommodating non-Unicode > encodings, and may have some special security concerns (e.g. > additional escaping for HTML or Javascript embedding). It would be > nice if the spec separated format from encoding, but it's unlikely to > be the source of any significant problems since in most cases the > handling of encoding will have happened by the time you parse the > text, and the security concerns can be addressed in best-practices. > > > Also, I=92ve never encountered a scenario where the messages were of > sufficient size that > > anyone gave a rat=92s ass about streaming. > > Me either, and even if there were such cases I find the concerns about > maintaining state unconvincing - maintaining a seen-keys dictionary > for each level of nesting you're in is not all that much of an > imposition or incompatible with a streaming API. > > Believe it or not, but this actually would become major overhead for streaming level; as well as for data-binding tools of statically typed languages (Java, C#). I am sure that there are clever ways to limit the overhead, but a naive implementation in Java would give us 30-50% processing time boost, which generally adds no value (assuming "last value wins" is adhered to and/or if generator can avoid producing dups). Common use case for me is as follows: 1. Input comes as a typed object 2. Serializer accesses properties and guarantees uniqueness of keys, calls generator 3. Generator simply outputs tokens as requested (maintaining basic stack to ensure syntactic output) 4. Receiving end uses parser to expose JSON as tokens, without dup checks 5. Deserializer maps properties to local objects created: if duplicates were encountered, last value would stick due overwrites in such a case, duplicates are not problematic; and this without explicit checks. Having to check duplicates on both sending and receiving end (at parser/generator level) would most likely add +50% overhead for processing time, because overhead on generator is relatively higher (JSON can be written about 2x as fast as decoded). Dup detection could work more efficiently on deserializer level, but would require separate null markers to distinguish between JSON nulls and lack of property. Alternate case of using a Tree representation ("JsonNode" etc) would have similar solution to duplicate problem: tree serializer would not produce dups (since tree can not contain them); and tree deserializer would either use last, or (if preferred) signal an error. -+ Tatu +- --001a11c25cd84d525a04e0a10128 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 12:29 PM, Jacob Davies <jacob@well.co= m> wrote:
On Wed, Jul 3, 2013 at 9:34 AM, Tim Bray <tbray@textuality.com> wrote:
> So I care a lot about JSON, but I don=92t care= in the slightest about usages
> where the JSON isn=92t being used for application-level message protoc= ol
> payloads (are there such usages? =A0I'm curious).

There are a number of practical use cases for JSON that don't fal= l
into the neat "externally delimited stream of bytes described by an application/json media-type" category. That is a separate question to<= br> whether the RFC needs to do much to accomodate them.

1. Files named ".json" and containing a single JSON object or arr= ay.
2. Text documents containing embedded JSON - informally, as in
documentation or books, or formally, as in Javascript in HTML or .js
files.
3. Database records where text or binary columns store embedded JSON
representing complex nested objects.

Case 1 is handled the same as a message described as application/json,
no big deal. Cases 2 & 3 may require accommodating non-Unicode
encodings, and may have some special security concerns (e.g.
additional escaping for HTML or Javascript embedding). It would be
nice if the spec separated format from encoding, but it's unlikely to be the source of any significant problems since in most cases the
handling of encoding will have happened by the time you parse the
text, and the security concerns can be addressed in best-practices.

> Also, I=92ve never encountered a scenario where the messages were of s= ufficient size that
> anyone gave a rat=92s ass about streaming.

Me either, and even if there were such cases I find the concerns abou= t
maintaining state unconvincing - maintaining a seen-keys dictionary
for each level of nesting you're in is not all that much of an
imposition or incompatible with a streaming API.

<= br>
Believe it or not, but this actually would become major overh= ead for streaming level; as well as for data-binding tools of statically ty= ped languages (Java, C#).
I am sure that there are clever ways to limit the overhead, but = a naive implementation in Java would give us 30-50% processing time boost, = which generally adds no value (assuming "last value wins" is adhe= red to and/or if generator can avoid producing dups).

Common use case for me is as follows:

1. Input comes as a typed object
2. Serializer accesses properties and guarantees uniquene= ss of keys, calls generator
3. Generator simply outputs tokens as requ= ested (maintaining basic stack to ensure syntactic output)
4. Receiving end uses parser to expose JSON as tokens, = without dup checks
5. Deserializer maps properties to local o= bjects created: if duplicates were encountered, last value would stick due = overwrites

in such a case, duplicates are not problematic; and this without explicit c= hecks.
Having to check duplicates on bo= th sending and receiving end (at parser/generator level) would most likely = add +50% overhead for processing time, because overhead on generator is rel= atively higher (JSON can be written about 2x as fast as decoded).
Dup detection could work more efficiently = on deserializer level, but would require separate null markers to distingui= sh between JSON nulls and lack of property.

Alternate case of using a Tree represe= ntation ("JsonNode" etc) would have similar solution to duplicate= problem: tree serializer would not produce dups (since tree can not contai= n them); and tree deserializer would either use last, or (if preferred) sig= nal an error.

-+ Tatu +-

--001a11c25cd84d525a04e0a10128-- From cowan@ccil.org Wed Jul 3 13:11: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 2580A11E821D for ; Wed, 3 Jul 2013 13:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 dW0tnL7UmPpq for ; Wed, 3 Jul 2013 13:11:48 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id D3E9A21F9C66 for ; Wed, 3 Jul 2013 13:11:46 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuTOx-0006XO-A5; Wed, 03 Jul 2013 16:11:43 -0400 Date: Wed, 3 Jul 2013 16:11:43 -0400 From: John Cowan To: Pete Resnick Message-ID: <20130703201143.GL32044@mercury.ccil.org> References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D48023.1020008@qti.qualcomm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Nico Williams , Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 20:11:53 -0000 Pete Resnick scripsit: > So I don't think saying RECOMMENDED or SHOULD regarding not > producing duplicates should be seen as a non-starter. That's a > defensible position for the WG to take. +1. The only person saying otherwise right now is Tim, and he grants that he is only concerned with a single use case. -- Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, "The Nine Billion Names of God" John Cowan From cowan@ccil.org Wed Jul 3 13:15:28 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 D813F21F9AF1 for ; Wed, 3 Jul 2013 13:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 b4HGxZLuMOgj for ; Wed, 3 Jul 2013 13:15:24 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6D83621F9A87 for ; Wed, 3 Jul 2013 13:15:24 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuTSU-0006vG-Tq; Wed, 03 Jul 2013 16:15:23 -0400 Date: Wed, 3 Jul 2013 16:15:22 -0400 From: John Cowan To: Tatu Saloranta Message-ID: <20130703201522.GM32044@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: Tim Bray , "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 20:15:29 -0000 Tatu Saloranta scripsit: > It has never been a problem for me, nor has there been user requests beyond > schema (and schema validator) implementors who care more. But it is > possible that perhaps this has been a significant problem for others. The trouble is that with sufficiently bad implementations, or chains of implementations, such permissiveness can lead to a security breach, and security being a Yang Worship Word these days, everyone cowers in fear which such things are mentioned. My most recent use case for JSON (to represent the MicroXML data model) doesn't even require parsing it, but I never suppose that for that reason JSON might as well be limited to nothing but arrays in which the first element is always a string and the second element is always an object with string values. -- 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 tsaloranta@gmail.com Wed Jul 3 13:21: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 28DF111E8220 for ; Wed, 3 Jul 2013 13:21:53 -0700 (PDT) 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, 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 m4YbLjLQis-S for ; Wed, 3 Jul 2013 13:21:52 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 581E911E821B for ; Wed, 3 Jul 2013 13:21:52 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so481304wes.40 for ; Wed, 03 Jul 2013 13:21:50 -0700 (PDT) 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=eCjcA0vRHCqq/GIxm3pSnaQ6mqXlYsXfwUdjVx/KNsc=; b=a1GtW7AjGRdSVh+rbE5e3oc4C6DYayIXn+AGkF1jU0X8SXn8x/nuPlYqzCGr1cZtQ8 Jb4RMf4hX/qdDNbmN3Nco3ifGLGGIDyciRd4ApTlXHEpibP86tM/N2q5X5SklYHH+tAS JDu4rd+dFOtPMN/GFjUyPHeDcoJXZ8nltT1+3P9F9RB9HLNtE4yNVyf0UCkLmJaAxIez QDOl/hsG5aKuHPh4CsjEZD1m5taLX7Spt0p1XfyarrxZUdHqcroKrgi1Et3I2m+PrIsq 9XcWztsSiz4q/ZwHJGzhX240jYObQICsut5F5i4p+0JDu+rA0sFllwOjlvcn8LdERaJ4 Yocg== MIME-Version: 1.0 X-Received: by 10.180.188.36 with SMTP id fx4mr18951761wic.55.1372882910583; Wed, 03 Jul 2013 13:21:50 -0700 (PDT) Received: by 10.227.72.74 with HTTP; Wed, 3 Jul 2013 13:21:50 -0700 (PDT) In-Reply-To: <20130703201522.GM32044@mercury.ccil.org> References: <20130703201522.GM32044@mercury.ccil.org> Date: Wed, 3 Jul 2013 13:21:50 -0700 Message-ID: From: Tatu Saloranta To: John Cowan Content-Type: multipart/alternative; boundary=001a11c25cd834224e04e0a1366c Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] JSON for Internet messages 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, 03 Jul 2013 20:21:53 -0000 --001a11c25cd834224e04e0a1366c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 3, 2013 at 1:15 PM, John Cowan wrote: > Tatu Saloranta scripsit: > > > It has never been a problem for me, nor has there been user requests > beyond > > schema (and schema validator) implementors who care more. But it is > > possible that perhaps this has been a significant problem for others. > > The trouble is that with sufficiently bad implementations, or chains > of implementations, such permissiveness can lead to a security breach, > and security being a Yang Worship Word these days, everyone cowers in > fear which such things are mentioned. My most recent use case for > JSON (to represent the MicroXML data model) doesn't even require parsing > it, > but I never suppose that for that reason JSON might as well be limited > to nothing but arrays in which the first element is always a string and > the second element is always an object with string values. > Ok. This makes more sense to me. I hope that security aspect can be emphasized in context of duplicates, if it is the leading reason (which is consistent with earlier discussions I think). I also do not think there is anything wrong in having multiple documents that add layers of requirements: strict handling of duplicates seems best handled at higher level, and not at basic format level. -+ Tatu +- --001a11c25cd834224e04e0a1366c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 1:15 PM, John Cowan <cowan@me= rcury.ccil.org> wrote:
Tatu Saloranta scripsit:

> It has never been a problem for me, nor has there been user requests b= eyond
> schema (and schema validator) implementors who care more. But it is > possible that perhaps this has been a significant problem for others.<= br>
The trouble is that with sufficiently bad implementations, or chains<= br> of implementations, such permissiveness can lead to a security breach,
and security being a Yang Worship Word these days, everyone cowers in
fear which such things are mentioned. =A0My most recent use case for
JSON (to represent the MicroXML data model) doesn't even require parsin= g it,
but I never suppose that for that reason JSON might as well be limited
to nothing but arrays in which the first element is always a string and
the second element is always an object with string values.


Ok. This= makes more sense to me. I hope that security aspect can be emphasized in c= ontext of duplicates, if it is the leading reason (which is consistent with= earlier discussions I think).
I also do not think there is anything wrong in having multiple d= ocuments that add layers of requirements: strict handling of duplicates see= ms best handled at higher level, and not at basic format level.

-+ Tatu +-

=A0
<= /div>
--001a11c25cd834224e04e0a1366c-- From lear@cisco.com Wed Jul 3 13:29: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 DDEFE11E80CC for ; Wed, 3 Jul 2013 13:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.429 X-Spam-Level: X-Spam-Status: No, score=-110.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ufebbCATeSgz for ; Wed, 3 Jul 2013 13:29:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 974E521F994B for ; Wed, 3 Jul 2013 13:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1061; q=dns/txt; s=iport; t=1372883348; x=1374092948; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KYmgBh+SrvODt6JtBkgOhGnyuE4FYRdkR7hhhIU+V1Q=; b=aRVb6NHeWm52Pj97kQqoX007lKRk0GPTRtUyTdkhemD6RKBzHckPA9ti xSo5GlxNR0CWoTzWG6Id9xjBLZJ7Cpbm69E/c4VvjUk/TU1xHSB4G0sIA EzIoGTOHxo1X3ikbXwubW7xMtSClWpAhannjJSXJSekiNkZqEkkz1T/g/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFALSI1FGQ/khL/2dsb2JhbABagwmEA70vgQgWdIIjAQEBAwEjVQEQCw4KAgIFFgsCAgkDAgECASsaBg0BBwEBiAUGqQ2RDoEmjQ6BNweCUYEcA5dJkUWDEzqBLQ X-IronPort-AV: E=Sophos;i="4.87,990,1363132800"; d="scan'208";a="156140708" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2013 20:29:07 +0000 Received: from mctiny.local ([10.61.175.226]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r63KT4JL024504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 20:29:05 GMT Message-ID: <51D48990.7090305@cisco.com> Date: Wed, 03 Jul 2013 22:29:04 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Pete Resnick References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> In-Reply-To: <51D48023.1020008@qti.qualcomm.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Nico Williams , Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 20:29:14 -0000 On 7/3/13 9:48 PM, Pete Resnick wrote: > Speaking strictly as a participant, and just to give guidance, not > insist on an outcome. Same. > > Let's remember the meaning of these capitalized words in IETF > parlance. We use them "where it is actually required for > interoperation or to limit behavior which has potential for causing > harm." So a MUST would mean that not doing so would prevent > interoperation or cause harm. RECOMMENDED (like SHOULD) would also > mean that not doing so would prevent interoperation or cause harm, but > "that there may exist valid reasons in particular circumstances to > ignore a particular item, but the full implications must be understood > and carefully weighed before choosing a different course." I have to say that ambiguity of a language implies an introduction to interoperability problems. But MUST we use MUST in those cases? I would prefer the catch the problem when we have the opportunity. If the WG feels differently, Meh. As Nico said, deal with it at a higher layer. Eliot From tbray@textuality.com Wed Jul 3 13: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 5447221F9A2C for ; Wed, 3 Jul 2013 13:44:44 -0700 (PDT) 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 QmEasI3ArANa for ; Wed, 3 Jul 2013 13:44:39 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 44D0421F9926 for ; Wed, 3 Jul 2013 13:44:38 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 13so595530lba.2 for ; Wed, 03 Jul 2013 13:44:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=h/mgjwC/+64UwBMIbL6YHNRfijImeQu3S/U+pHz/M7U=; b=hztOtehemVYlMuPDbJ69X2fnq9d7fOlyieynaxsZzci8nPHaJowGggbkbj4oeegcc6 fX1ks4NBTT9Kg2gx3cPvcMh/4aIp/QY7TRX6NcvKcNLmMuMTchx84DlFg89vKbVz06UU PRRM9we58eXR+NmSpSCfeFkm81wiMn2YcxGprTbok26pr3XDB20OSVs+CEIzJgUHDJrf Jbhu1jT6+vOZUqSFk5jLCTdEay7TGgG9yp3IswLLqWkpl0vGbkOpnQ1URoNSYn+9MH1A QqCfhcKIk2+Sf3q0apA6IRi9qvWMh0+QFhYq/9IzyBAq75CVGEnfRkak8i2ypI3gPMDJ jyMA== MIME-Version: 1.0 X-Received: by 10.152.8.198 with SMTP id t6mr1322016laa.36.1372884277347; Wed, 03 Jul 2013 13:44:37 -0700 (PDT) Received: by 10.114.71.51 with HTTP; Wed, 3 Jul 2013 13:44:37 -0700 (PDT) X-Originating-IP: [209.121.225.216] In-Reply-To: <20130703201143.GL32044@mercury.ccil.org> References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> Date: Wed, 3 Jul 2013 13:44:37 -0700 Message-ID: From: Tim Bray To: John Cowan Content-Type: multipart/alternative; boundary=089e0153844aab596c04e0a18768 X-Gm-Message-State: ALoCoQk9WT3pH+unmSvqrgCF3cvZrpV/6/rA7ynKyTR40+VjoSWDQ4kucpI1xu3WUoWBSY35OTLH Cc: Nico Williams , Pete Resnick , Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 20:44:44 -0000 --089e0153844aab596c04e0a18768 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm? I=E2=80=99m perfectly OK with a minimal edit leaving most things as th= ey are and just pointing out potential interop gotchas. JSON is what JSON is. For a BCP doc or =E2=80=9CInternet JSON=E2=80=9D profile, it=E2=80=99s a di= fferent story. -T On Wed, Jul 3, 2013 at 1:11 PM, John Cowan wrote: > Pete Resnick scripsit: > > > So I don't think saying RECOMMENDED or SHOULD regarding not > > producing duplicates should be seen as a non-starter. That's a > > defensible position for the WG to take. > > +1. The only person saying otherwise right now is Tim, and he grants > that he is only concerned with a single use case. > > -- > Overhead, without any fuss, the stars were going out. > --Arthur C. Clarke, "The Nine Billion Names of God" > John Cowan > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0153844aab596c04e0a18768 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hm?=C2=A0 I=E2=80=99m perfectly OK with a minimal edit lea= ving most things as they are and just pointing out potential interop gotcha= s.=C2=A0=C2=A0 JSON is what JSON is.=C2=A0 For a BCP doc or =E2=80=9CIntern= et JSON=E2=80=9D profile, it=E2=80=99s a different story.=C2=A0 -T


On Wed, Jul 3= , 2013 at 1:11 PM, John Cowan <cowan@mercury.ccil.org> = wrote:
Pete Resnick scripsit:

> So I don't think saying RECOMMENDED or SHOULD regarding not
> producing duplicates should be seen as a non-starter. That's a
> defensible position for the WG to take.

+1. =C2=A0The only person saying otherwise right now is Tim, and he g= rants
that he is only concerned with a single use case.

--
Overhead, without any fuss, the stars were going out.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --Arthur C. Clarke, "The Nine Billion Name= s of God"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 John Cowan <cowan@ccil.org>
_____________________= __________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0153844aab596c04e0a18768-- From nico@cryptonector.com Wed Jul 3 14:31: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 2490111E8259 for ; Wed, 3 Jul 2013 14:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.027, 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 qlBioZ9VgnYV for ; Wed, 3 Jul 2013 14:31:36 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3648111E80EA for ; Wed, 3 Jul 2013 14:31:36 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 9637D2C806B for ; Wed, 3 Jul 2013 14:31:34 -0700 (PDT) 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=Wdxk/J02ku59h7+pAuiX 6f13igY=; b=uUCiQz6xHmJu7Bis1oTb4WHTp2Poavqe6fw9M6TWDKndTcrb0IL4 6Wp3z8Vpw9rNrfxbxId8tsotC/tz3/DNCDSqZlST46fg1z7J3CqGOo5fIsgPSaCq Xy+dbyIq3TXiDMj4kebN1b0h7lkNql/kE+pRLSCo2UMY9Dbr3PG6er0= 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-a24.g.dreamhost.com (Postfix) with ESMTPSA id 45CB52C806D for ; Wed, 3 Jul 2013 14:31:34 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so539606wev.2 for ; Wed, 03 Jul 2013 14:31:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dl4rIsXkbsGsU6KfgstSTVBAKkALp3QVw/CTk+vvDKE=; b=CHVyAdlvIb6vM/xJr86eV+sAjZWbJTpejygxdHEpmAoIt5j3muwxyd+6a0hP6pH32W UpnLnDLjlb0Ca4Lbnk/mFHPsP/5lNPUdk5UsR3yH6n5dGTMat4dKXYRSb0crIwp6IB6S onSg6V0c0oYmAxbsUGCFGIbP4wheoL+weJ3pZ5u3sravuIu1rZMIb9hQh9uy8Ycbrc2b GEMvIv9/YM6KpMmj+PUISaCXd3NWdIfVPYvfxFnjAzWzXVqgj1KoY+DJVBEpfT6pyCkr FD9f2r7qBozrvEjTEd7/2+GH7Bwu4ha5yKl8VNowNmCxTpezWdO93Nm2xBoayYCeOf87 FlOQ== MIME-Version: 1.0 X-Received: by 10.180.77.74 with SMTP id q10mr19116892wiw.28.1372887092516; Wed, 03 Jul 2013 14:31:32 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 14:31:32 -0700 (PDT) In-Reply-To: <1AB34263-877A-43FC-899E-4681F90BD7B8@tzi.org> References: <1AB34263-877A-43FC-899E-4681F90BD7B8@tzi.org> Date: Wed, 3 Jul 2013 16:31:32 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 03 Jul 2013 21:31:41 -0000 On Wed, Jul 3, 2013 at 2:42 PM, Carsten Bormann wrote: > On Jul 3, 2013, at 18:29, Nico Williams wrote: > >> leave the rest mostly as-is > > That means that every user of JSON has to define their own additional clarifications, as JOSE has started to do. > In effect, each user creates their own little dialect. Why couldn't they reference the BCP? But as I said, I also don't mind us publishing an "Internet JSON". We'd have to grapple with the meaning of the existing MIME type for JSON, but JOSE could normatively reference "Internet JSON" and be done. I guess that's a lot of choices. > A textbook example for how to create soup. > > I'd rather have 2 or 3 flavors of JSON than n, where n is the number of users. > (Or, if it has to be, 2 or 3 on/off pizza toppings each of which can be selected or deselected.) Well, yes, but those N happen to mostly interop. I'm not sure that we've seen claims of non-interoperability for any applications, just differences in JSON implementations which most definitely *can* cause interop problems, but maybe they never happen because users implicitly end up sticking to interoperable subsets of JSON. Not robust, but the world has been working anyways. Nico -- From nico@cryptonector.com Wed Jul 3 14:37: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 B42DE11E8263 for ; Wed, 3 Jul 2013 14:37:44 -0700 (PDT) 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=-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 i-VIvn7Prpo8 for ; Wed, 3 Jul 2013 14:37:39 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C5F4411E80EA for ; Wed, 3 Jul 2013 14:37:39 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id BA56A678069 for ; Wed, 3 Jul 2013 14:37:38 -0700 (PDT) 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=Q3fweBcwX6B9AoA0M4Wh CqCJ+BY=; b=t270mgzAu+agkni7BCuenSourPfR2nXm7EpqBTpF0h9hR4BkxEXk fbKPxjyLOsteeDVzMNEH0Hqjz2JESG4VI7dFMgAX/h5ET7wsxt/aHQxHBTRhcqcI g+TuZ2pUdCJDqkXMEG2Wu88JConZHWNkdtCIboWMJI36FK9YQhUzp/Q= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 68D16678063 for ; Wed, 3 Jul 2013 14:37:38 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so6708774wiw.2 for ; Wed, 03 Jul 2013 14:37:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CSm6lJ2bLgggueBKbrPyD3YuZyJO9NJP9F6E/Guv5yE=; b=CsBWcSDp6Xs+XM4wV2ppco8MQU4sK9ltpKCv9UmHsY26exiA5H0MTTzryhrolgAZoo W2LdmP9OOQflzgC9PErZuuWwu8/RmvNA4gzMr+BnTTZ1Y4MiVf7/Rxliau9FpwKOAUlQ QkwhX3JnwqgqpRp5HCbJZm574PHAwm3SyOoVDrdGWo98G2kQVFjGWTr5VzuaHaeztuT3 I/FKFf1AFZEMm5uwLAooJUdk1z2TS22DqQvSInifk8JHxZKc5I+odcag4KhZw3BR7hAb LuxXfM6YOR+Rn4ZtZ8GDoSFB38f6qu/rjyDH3cqpcMay2F4rBK7Zei6qljmt6jEPEGuq Rl6g== MIME-Version: 1.0 X-Received: by 10.180.73.68 with SMTP id j4mr3185682wiv.10.1372887457112; Wed, 03 Jul 2013 14:37:37 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 14:37:37 -0700 (PDT) In-Reply-To: <51D48990.7090305@cisco.com> References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <51D48990.7090305@cisco.com> Date: Wed, 3 Jul 2013 16:37:37 -0500 Message-ID: From: Nico Williams To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Cc: Pete Resnick , Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 21:37:44 -0000 On Wed, Jul 3, 2013 at 3:29 PM, Eliot Lear wrote: > On 7/3/13 9:48 PM, Pete Resnick wrote: >> Let's remember the meaning of these capitalized words in IETF >> parlance. We use them "where it is actually required for >> interoperation or to limit behavior which has potential for causing >> harm." So a MUST would mean that not doing so would prevent >> interoperation or cause harm. RECOMMENDED (like SHOULD) would also >> mean that not doing so would prevent interoperation or cause harm, but >> "that there may exist valid reasons in particular circumstances to >> ignore a particular item, but the full implications must be understood >> and carefully weighed before choosing a different course." > > I have to say that ambiguity of a language implies an introduction to > interoperability problems. But MUST we use MUST in those cases? I > would prefer the catch the problem when we have the opportunity. If the > WG feels differently, Meh. As Nico said, deal with it at a higher layer. I think we're very likely to get consensus for SHOULD language with an out for streaming generators/parsers pushing the MUST to the application. We could force MUST with an out for streaming generators/parsers pushing the MUST to the application, but it'd leave some implementors on the rough side of consensus and unhappy. I'd be very happy either way. In the case of the application I mentioned object well-formedness is a feature of the underlying DB so there's never a way to end up with duplicate names, so using non-conformant generators/parsers is not a problem: the result would be conformant. As long as that's OK I'll be happy. Nico -- From nico@cryptonector.com Wed Jul 3 14:39: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 C75A911E8219 for ; Wed, 3 Jul 2013 14:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.025, 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 rfgeguuBVMnN for ; Wed, 3 Jul 2013 14:39:54 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id DB53A11E80EE for ; Wed, 3 Jul 2013 14:39:54 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 31E1A27BC05D for ; Wed, 3 Jul 2013 14:39:54 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=rPcqw9nIJbWjdTcg9awwsUfD0iE=; b=KqQfGedy5ib I2mzaZ7JOTeEva9C3OC/rI11bpadzUmf4F15fKmP5KhgiEVsCciFBH3YuZYVe8Zr fnrE1d+oTubNBjsGUoHDvrkpz0cKMYQZw/zta+0bWOs025qUR4hbGOKh3vJ6d947 fUtNWRBCS2k3d4I3gxl89hmeC+ERNOKQ= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (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 D614727BC069 for ; Wed, 3 Jul 2013 14:39:53 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so537182wes.21 for ; Wed, 03 Jul 2013 14:39:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e4XCZT02LDsgSaZ1uxr3PHJJZxflg9xmYs3NPlyn+kg=; b=bkGqkUGXFhJlBnbKArHhtnJ9AHKDb6fxT5n8iozKVwn17jDEjJb0DHNr/OmUjBKYMZ Eax/hj60FrJXG83muFn76juAiV9mVpIW42t6fJ6xix2EV61mNopbQsa22gnG3ekQHvKj /AWN4QIsvFAxImvghm79RTmSKzyX7iXyPB9EUGHyVIm2NdsxRKWJtVOXa4dbY8GjZegr YofHt93Z+DfybM0LxEVmBxdXhEMR+Hi8qUOgfXwm1dnPXLKv/jV6ykHNzGqavwCpcJqY sK44b+AY/2e6V1rDGOf4InQAj3LgDjwGJ7vgZXCwA/mbEnzzWTkasjKAfavAbAZ2q3au kkSQ== MIME-Version: 1.0 X-Received: by 10.194.173.37 with SMTP id bh5mr1831984wjc.30.1372887592471; Wed, 03 Jul 2013 14:39:52 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 14:39:52 -0700 (PDT) In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> Date: Wed, 3 Jul 2013 16:39:52 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Pete Resnick , John Cowan , Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 21:39:59 -0000 On Wed, Jul 3, 2013 at 3:44 PM, Tim Bray wrote: > On Wed, Jul 3, 2013 at 1:11 PM, John Cowan wrote= : >> >> Pete Resnick scripsit: >> >> > So I don't think saying RECOMMENDED or SHOULD regarding not >> > producing duplicates should be seen as a non-starter. That's a >> > defensible position for the WG to take. >> >> +1. The only person saying otherwise right now is Tim, and he grants >> that he is only concerned with a single use case. > Hm? I=E2=80=99m perfectly OK with a minimal edit leaving most things as = they are > and just pointing out potential interop gotchas. JSON is what JSON is. > For a BCP doc or =E2=80=9CInternet JSON=E2=80=9D profile, it=E2=80=99s a = different story. -T I think John thought that you wanted a strict "MUST NOT have dup names" requirement, but if you'd just settle for an out for streaming generators/parsers, pushing the non-dup name responsibility up a layer (or three) then maybe we could just all agree. Nico -- From tbray@textuality.com Wed Jul 3 14:43: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 60C1711E8262 for ; Wed, 3 Jul 2013 14:43:27 -0700 (PDT) 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=[AWL=-0.000, 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 VjpWrnSZ0IlC for ; Wed, 3 Jul 2013 14:43:21 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 058FC11E8261 for ; Wed, 3 Jul 2013 14:43:20 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gw10so619630lab.30 for ; Wed, 03 Jul 2013 14:43:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Kf0lWBA8PACSSxfDi0AFZj3rWr0ngk2mnyTMgfeAw9E=; b=oy31SRo6/Ye/RKDvwSab3eTz5tNOVw2omYf0kBwvRa/oXq45X/1JsO/IZ55NgO0rSE NVpnsReUHFxnge4iqwohtFdfIxc7eCvsFMOtPgypLaHNFwR3//PyckBEj69S99oS8Ccu 3v+HcB+vZVMqDErUh1drW6Ic8/QnvtsRIyiF73reXASRJRziCpv6U9mOR4M7H/i5/0Ms Z2rG4d/aXpuiSi/0jziLfE2JK6es1HTW5FlEc3dWaTpeCz474dnc6qmgnL4VOs3eGRTq uTNxnK5hxPCdfBIHYqR2PQwBJG5YNJksQtULIxQj4rI4p3rDqv1GQg9SQDUoc3aE3qKU dt0g== MIME-Version: 1.0 X-Received: by 10.152.8.198 with SMTP id t6mr1411927laa.36.1372887798465; Wed, 03 Jul 2013 14:43:18 -0700 (PDT) Received: by 10.114.71.51 with HTTP; Wed, 3 Jul 2013 14:43:18 -0700 (PDT) X-Originating-IP: [209.121.225.216] In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> Date: Wed, 3 Jul 2013 14:43:18 -0700 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=089e0153844a8b672b04e0a259fa X-Gm-Message-State: ALoCoQnekrY9B0dm89uyHmg8mQHAlPEkaeb6fKteR49L9Ba6BTNjqridwYcBs959v0yIicNOoFJ4 Cc: Pete Resnick , John Cowan , Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 03 Jul 2013 21:43:27 -0000 --089e0153844a8b672b04e0a259fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There=E2=80=99s no need to mention streaming; to start with, we=E2=80=99d h= ave to define a bunch of terms. Say, as the RFC does, that you SHOULD NOT emit duplicates because it leads to variable results, and also note that there is software in the world that nonetheless does, possibly note that ECMA allows it, and say that receiving software SHOULD do last-dupe-wins. JSON is what JSON is. For =E2=80=9CInternet JSON=E2=80=9D, it=E2=80=99s a different argument. -T On Wed, Jul 3, 2013 at 2:39 PM, Nico Williams wrote= : > On Wed, Jul 3, 2013 at 3:44 PM, Tim Bray wrote: > > On Wed, Jul 3, 2013 at 1:11 PM, John Cowan > wrote: > >> > >> Pete Resnick scripsit: > >> > >> > So I don't think saying RECOMMENDED or SHOULD regarding not > >> > producing duplicates should be seen as a non-starter. That's a > >> > defensible position for the WG to take. > >> > >> +1. The only person saying otherwise right now is Tim, and he grants > >> that he is only concerned with a single use case. > > > Hm? I=E2=80=99m perfectly OK with a minimal edit leaving most things a= s they are > > and just pointing out potential interop gotchas. JSON is what JSON is= . > > For a BCP doc or =E2=80=9CInternet JSON=E2=80=9D profile, it=E2=80=99s = a different story. -T > > I think John thought that you wanted a strict "MUST NOT have dup > names" requirement, but if you'd just settle for an out for streaming > generators/parsers, pushing the non-dup name responsibility up a layer > (or three) then maybe we could just all agree. > > Nico > -- > --089e0153844a8b672b04e0a259fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There=E2=80=99s no need to mention streaming; to start wit= h, we=E2=80=99d have to define a bunch of terms.

Say, as the RFC do= es, that you SHOULD NOT emit duplicates because it leads to variable result= s, and also note that there is software in the world that nonetheless does,= possibly note that ECMA allows it, and say that receiving software SHOULD = do last-dupe-wins.=C2=A0 JSON is what JSON is.

For =E2=80=9CInternet JSON=E2=80=9D, it=E2=80=99s a different argument.= -T


= On Wed, Jul 3, 2013 at 2:39 PM, Nico Williams <nico@cryptonector.com> wrote:
On Wed, Jul 3, 2013 at 3:4= 4 PM, Tim Bray <tbray@textuality= .com> wrote:
> On Wed, Jul 3, 2013 at 1:11 PM, John Cowan <cowan@mercury.ccil.org> wrote:
>>
>> Pete Resnick scripsit:
>>
>> > So I don't think saying RECOMMENDED or SHOULD regarding n= ot
>> > producing duplicates should be seen as a non-starter. That= 9;s a
>> > defensible position for the WG to take.
>>
>> +1. =C2=A0The only person saying otherwise right now is Tim, and h= e grants
>> that he is only concerned with a single use case.

> Hm? =C2=A0I=E2=80=99m perfectly OK with a minimal edit leaving most th= ings as they are
> and just pointing out potential interop gotchas. =C2=A0 JSON is what J= SON is.
> For a BCP doc or =E2=80=9CInternet JSON=E2=80=9D profile, it=E2=80=99s= a different story. =C2=A0-T

I think John thought that you wanted a strict "MUST NOT have dup=
names" requirement, but if you'd just settle for an out for stream= ing
generators/parsers, pushing the non-dup name responsibility up a layer
(or three) then maybe we could just all agree.

Nico
--

--089e0153844a8b672b04e0a259fa-- From presnick@qti.qualcomm.com Wed Jul 3 15:53: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 D4CE111E824A for ; Wed, 3 Jul 2013 15:53:48 -0700 (PDT) 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 C81bs-Wj-MB3 for ; Wed, 3 Jul 2013 15:53:44 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id A61A711E80E0 for ; Wed, 3 Jul 2013 15:53:44 -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=1372892024; x=1404428024; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RKK3chE0Dn4Q4a7G26Nfrhx/9bnS9SZSjepJxWU1fZM=; b=xNj320KfeKereR6i5e9gPIiGY0PU9s4ZSQV8N8CCOlJzhpQQGJgCE5ae sSwJ8lY4h9cNm9/J9K7pkUi0gEjuP3wO4783CWrYE8HCSJSKQOJcloQdA qgEZKtiM88hkT+DaHHIOoM7kSz0ywvKSBdfojSnCLYlp+yT1KrwuzcVDe U=; X-IronPort-AV: E=Sophos;i="4.87,991,1363158000"; d="scan'208";a="46823269" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 03 Jul 2013 15:53:44 -0700 X-IronPort-AV: E=Sophos;i="4.87,991,1363158000"; d="scan'208";a="562798522" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2013 15:53:33 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 3 Jul 2013 15:53:33 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 3 Jul 2013 15:53:32 -0700 Message-ID: <51D4AB6B.50203@qti.qualcomm.com> Date: Wed, 3 Jul 2013 17:53:31 -0500 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: John Cowan References: <51D474BD.7040302@qti.qualcomm.com> <20130703195743.GJ32044@mercury.ccil.org> In-Reply-To: <20130703195743.GJ32044@mercury.ccil.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "json@ietf.org" Subject: Re: [Json] Quick note / People coming to Berlin? 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, 03 Jul 2013 22:53:48 -0000 Speaking again as AD: On 7/3/13 2:57 PM, John Cowan wrote: > Pete Resnick scripsit: > > >> The running discussion over the past 24 hours has been a bit intense >> for me to catch up on. I'm hoping to send a message by EOB today >> with some thoughts. The chairs and I chatted. I think there's quite a bit of "two ships passing in the night" discussion that's going on here on the list, with people thinking they are disagreeing but are simply not speaking the "same language". I'm working on a series of questions that should hopefully clarify where we are on some issues and maybe (just *maybe*) lead to consensus. I'm already seeing some movement on the duplicate names front that I think will result in a good outcome. I doubt I'll get to posting my questions tonight, but I'll try to get that done over the weekend. As the book says, "Don't panic!" >> I do not think all hope is lost on doing what >> this group was chartered to do. >> > Well, one of the chairs has said (albeit while hatless[1]), that the > charter is self-contradictory. While that may not be the voice of the god > "coming to tell of doom in words like beaten bronze"[2], it's certainly > not encouraging. > Your humble AD disagrees with the assessment that the charter is somehow self-contradictory. I think it is quite plausible to believe that we can correct "errors and inconsistencies", but "keep changes to a minimum", even when it comes to the string issue. Even if we have to put in a significant block of explanatory text in order to do that, I don't think we will have violated the dictate of making "minimal changes". And I still think that is a plausible outcome. Stay tuned. Remain calm. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From paul.hoffman@vpnc.org Wed Jul 3 15:56:25 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 4D13511E80E0 for ; Wed, 3 Jul 2013 15:56:25 -0700 (PDT) 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 yaNsqH-POKjJ for ; Wed, 3 Jul 2013 15:56:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 31ABA11E825F for ; Wed, 3 Jul 2013 15:56:23 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r63MuLvL071558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Jul 2013 15:56:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130703195743.GJ32044@mercury.ccil.org> Date: Wed, 3 Jul 2013 15:56:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51D474BD.7040302@qti.qualcomm.com> <20130703195743.GJ32044@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Quick note / People coming to Berlin? 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, 03 Jul 2013 22:56:25 -0000 On Jul 3, 2013, at 12:57 PM, John Cowan wrote: > Pete Resnick scripsit: >=20 >> The running discussion over the past 24 hours has been a bit intense >> for me to catch up on. I'm hoping to send a message by EOB today >> with some thoughts. I do not think all hope is lost on doing what >> this group was chartered to do. >=20 > Well, one of the chairs has said (albeit while hatless[1]), that the > charter is self-contradictory. While that may not be the voice of the = god > "coming to tell of doom in words like beaten bronze"[2], it's = certainly > not encouraging. That seems like a lame excuse to be discouraged. It assumes that people = will never change their mind. Just because some people on this list say = "rejected" and "impossible" and "obvious" and "never" more often than = one might hope, we can always change. In this specific case, I have been convinced that I was wrong since I = wrote that. So you can feel free to now all of a sudden to feel = encouraged again. --Paul Hoffman= From tbray@textuality.com Wed Jul 3 16:46: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 66BE111E811F for ; Wed, 3 Jul 2013 16:46:13 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=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 l8y4-hECUTfR for ; Wed, 3 Jul 2013 16:46:08 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF5421F9BAA for ; Wed, 3 Jul 2013 16:46:07 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id kw10so507646vcb.5 for ; Wed, 03 Jul 2013 16:46:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=pWpJEc++tbTbmmw7HzHU6+Ie5c3oYjaVgZnR8otAMUI=; b=YoEideaT6i0T4JoWf1dB7OFtwXQKGG9c5TyYmka22dADfQeuK8Vx7pOWp9WugKIRgi Gsn/MT9GAFgy5z68cj3ODBUdRE6cr9LP+4qFM/99UYVK1AnOuxq1zIsVsNEjgxFYD6CY 9rDg+KLF6HrsAS1gubJoEZZ45XB/tm/shvvaEagNnfOWvY0mtXJSc0sYlPOiN0lGcQgL b8dTWNUtJaoX2ha5hT5hxqEDU3SFAwpokhR+yy7ibqrqhizaWYWIQQhUM0pQvWCX5E4E aoa+Mq12xFPwbAEhFVDhciW7hFMg/JMljg9TZ7LK5ZC991kKadskKBPcA/38kixMxU6f jaWw== MIME-Version: 1.0 X-Received: by 10.220.197.72 with SMTP id ej8mr1012690vcb.66.1372895164632; Wed, 03 Jul 2013 16:46:04 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Wed, 3 Jul 2013 16:46:04 -0700 (PDT) X-Originating-IP: [209.121.225.216] Date: Wed, 3 Jul 2013 16:46:04 -0700 Message-ID: From: Tim Bray To: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1f08e9a258604e0a41066 X-Gm-Message-State: ALoCoQmOVxfWK5S/YXHLF4eiiauZK8BFIAHm5XCF8kdixeQhSEpeLyVE9CUQLy6HEntTwOX7Lwr+ Subject: [Json] 2-step proposal 4627bis + 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: Wed, 03 Jul 2013 23:46:13 -0000 --001a11c1f08e9a258604e0a41066 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I look forward to hearing what path Pete suggests through the thicket. Here=E2=80=99s one that I think is plausible: 1. Do a 4267bis along the lines of the minimal-work proposals. It describes JSON as she are spoke (wildly successful), changes as little as we possibly can, documents the areas of interoperability breakage (dupes, surrogates, top-level primitives), whacks the regex in the security section, uses SHOULD in the manner that Pete suggested is perfectly kosher. Declare victory! 2. Recharter in a way that will allow us to produce something like a strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html Produce something like that. Second victory! -T --001a11c1f08e9a258604e0a41066 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I look forward to hearing what path Pete su= ggests through the thicket.=C2=A0 Here=E2=80=99s one that I think is plausi= ble:

1. Do a 4267bis along the lines of the minimal-work propo= sals. It describes JSON as she are spoke (wildly successful), changes as li= ttle as we possibly can, documents the areas of interoperability breakage (= dupes, surrogates, top-level primitives), whacks the=C2=A0 regex in the sec= urity section, uses SHOULD in the manner that Pete suggested is perfectly k= osher. Declare victory!

2. Recharter in a way that will allow us to produce something lik= e a strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html=C2=A0 = Produce something like that. Second victory!

=C2=A0-T
--001a11c1f08e9a258604e0a41066-- From mnot@mnot.net Wed Jul 3 16:57: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 45AED11E8108 for ; Wed, 3 Jul 2013 16:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.562 X-Spam-Level: X-Spam-Status: No, score=-105.562 tagged_above=-999 required=5 tests=[AWL=-2.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 IRI5HFCD1F4p for ; Wed, 3 Jul 2013 16:57:19 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id F32FE11E8104 for ; Wed, 3 Jul 2013 16:57:18 -0700 (PDT) Received: from [192.168.1.80] (unknown [118.209.244.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8B78322E1FA; Wed, 3 Jul 2013 19:57:11 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: Date: Thu, 4 Jul 2013 09:57:07 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <7B669A34-7CFC-4B11-8BFB-5417CD9CB11F@mnot.net> References: To: Tim Bray X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org" Subject: Re: [Json] 2-step proposal 4627bis + 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: Wed, 03 Jul 2013 23:57:23 -0000 +1, although I'd strongly suggest that the top-level value NOT be a = boolean, but instead an object; lots of people have talked about a = top-level _"meta" object to hold information like profile identity, and = if we're going to go to the trouble of defining something that intrudes = into content, we might as well just do it once. Cheers, On 04/07/2013, at 9:46 AM, Tim Bray wrote: > I look forward to hearing what path Pete suggests through the thicket. = Here=92s one that I think is plausible: >=20 > 1. Do a 4267bis along the lines of the minimal-work proposals. It = describes JSON as she are spoke (wildly successful), changes as little = as we possibly can, documents the areas of interoperability breakage = (dupes, surrogates, top-level primitives), whacks the regex in the = security section, uses SHOULD in the manner that Pete suggested is = perfectly kosher. Declare victory! >=20 > 2. Recharter in a way that will allow us to produce something like a = strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html = Produce something like that. Second victory! >=20 > -T > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham http://www.mnot.net/ From nico@cryptonector.com Wed Jul 3 17:00: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 8DCC211E8104 for ; Wed, 3 Jul 2013 17:00:43 -0700 (PDT) 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=[AWL=-0.000, 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 HgSAGlBbnIXG for ; Wed, 3 Jul 2013 17:00:39 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD5511E826B for ; Wed, 3 Jul 2013 17:00:34 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id A41F05406F for ; Wed, 3 Jul 2013 17:00:33 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=MGGclFjyBmqHKQckJnslCD/MqOs=; b=mJ+4EiA+K+c Axz/NsPd7zrEcC8Ibo3Sy5Pnsi9ewkJY82Wv/S6WHz0j5qQT1AlaE8dgIZrTyJC+ HnLpRTJz8Y25PIoptWiBKOOXEkG7+PDVyMVobI7tfp7azh7pv011+KVMUQKGMkKG DwYKAk1YGFpY3Fh8Sk0PbgCkDke9yMG8= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 486015405B for ; Wed, 3 Jul 2013 17:00:33 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so679312wiv.5 for ; Wed, 03 Jul 2013 17:00:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/lnS4brH8x5uB2+xwDZMChuv2sdJYz0UipaF5pEwU9U=; b=YO1XTrHfe/rKvQ+MDUqaGBIdkfnVmlTf1ffCqXrIdrulJyQHxTp0710xUc+ZH7Lvl1 KbVo7uH8VQimc/Mktghu5LJs+r+lfRpnM3/mqX6UFYyoF58PNKQT6URyJ+yonC59M0QZ E6IBh1mRJlRfQBXuJ5Uzgrxbl/LjT4iHWGnGDfWR/Q/rOxAUvr2X82endTX2dGNM8mX9 85yifTASfX19PO8x3foLLSgcK5JDmYeX7sm6O5o1uCK84j0Odit/wEjrhPf3pgNMt743 SEoyNl9Xm9OGPlCtlYNwIubuexqYwJxEk0ni21FYWPp4McGHt8jkDvLE1KEklOhScVMX XYPQ== MIME-Version: 1.0 X-Received: by 10.180.107.71 with SMTP id ha7mr1657886wib.28.1372896031563; Wed, 03 Jul 2013 17:00:31 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 17:00:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 19:00:31 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "json@ietf.org" Subject: Re: [Json] 2-step proposal 4627bis + 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: Thu, 04 Jul 2013 00:00:43 -0000 On Wed, Jul 3, 2013 at 6:46 PM, Tim Bray wrote: > I look forward to hearing what path Pete suggests through the thicket. > Here=E2=80=99s one that I think is plausible: > > 1. Do a 4267bis along the lines of the minimal-work proposals. It describ= es > JSON as she are spoke (wildly successful), changes as little as we possib= ly > can, documents the areas of interoperability breakage (dupes, surrogates, > top-level primitives), whacks the regex in the security section, uses > SHOULD in the manner that Pete suggested is perfectly kosher. Declare > victory! > > 2. Recharter in a way that will allow us to produce something like a > strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html Prod= uce > something like that. Second victory! A hearty +1. When I'm done with more pressing I-Ds (i.e., by Monday) I'll propose text for (1). Nico -- From sayrer@gmail.com Wed Jul 3 17:18: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 90AB821F9C26 for ; Wed, 3 Jul 2013 17:18:47 -0700 (PDT) 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, 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 D48I6cVIL73y for ; Wed, 3 Jul 2013 17:18:46 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E365721F9C28 for ; Wed, 3 Jul 2013 17:18:43 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so615004wev.22 for ; Wed, 03 Jul 2013 17:18:43 -0700 (PDT) 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=CJ4uO6U3Jz3Irpc/sCPMc/HCfAtn16KTMWTvumKs7jI=; b=nXND+Xl5GxGCpWXnnBHwZacKAzvAV0DuKTPNqxcH7IXdFpdoChw/NjX3fdm0VY+PTB awPxQoGr7oKcf4YAV3EpXFg6xn4r7sPKakpwoLAqnCGlbNR1+jfgf1VJWmnzyWVRkQsk HKhIZzDYOqpKAgdyHhAI5EAkKtqIV/YxDpw32F9or8XJ3XfEBoLpBgttKtNIE5cFHj2Z xBWOmCorb+Lt20EpgeecHcCqlyhL8QcoixzhtNLemz4KQe0R6i4Ws1uMZE3ic2U5GpEm JiibHBbddDuFxs9DlohMPRkLgGNEShDrPY+uoNu9UywMt1CMd6rVveVJlUsUP0XMYpd0 uUAQ== MIME-Version: 1.0 X-Received: by 10.180.9.242 with SMTP id d18mr19472502wib.18.1372897123068; Wed, 03 Jul 2013 17:18:43 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Wed, 3 Jul 2013 17:18:43 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Wed, 3 Jul 2013 17:18:43 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Jul 2013 17:18:43 -0700 Message-ID: From: R S To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c2228c5571d104e0a485ee Cc: Tim Bray , json@ietf.org Subject: Re: [Json] 2-step proposal 4627bis + 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: Thu, 04 Jul 2013 00:18:47 -0000 --001a11c2228c5571d104e0a485ee Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 On Jul 3, 2013 5:00 PM, "Nico Williams" wrote: > On Wed, Jul 3, 2013 at 6:46 PM, Tim Bray wrote: > > I look forward to hearing what path Pete suggests through the thicket. > > Here=92s one that I think is plausible: > > > > 1. Do a 4267bis along the lines of the minimal-work proposals. It > describes > > JSON as she are spoke (wildly successful), changes as little as we > possibly > > can, documents the areas of interoperability breakage (dupes, surrogate= s, > > top-level primitives), whacks the regex in the security section, uses > > SHOULD in the manner that Pete suggested is perfectly kosher. Declare > > victory! > > > > 2. Recharter in a way that will allow us to produce something like a > > strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html Pro= duce > > something like that. Second victory! > > A hearty +1. > > When I'm done with more pressing I-Ds (i.e., by Monday) I'll propose > text for (1). > > Nico > -- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c2228c5571d104e0a485ee Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

+1

On Jul 3, 2013 5:00 PM, "Nico Williams"= ; <nico@cryptonector.com>= ; wrote:
On Wed, Jul 3, 2013 at 6:46 PM, Tim Bray <tbray@textuality.com> wrote:
> I look forward to hearing what path Pete suggests through the thicket.=
> Here=92s one that I think is plausible:
>
> 1. Do a 4267bis along the lines of the minimal-work proposals. It desc= ribes
> JSON as she are spoke (wildly successful), changes as little as we pos= sibly
> can, documents the areas of interoperability breakage (dupes, surrogat= es,
> top-level primitives), whacks the =A0regex in the security section, us= es
> SHOULD in the manner that Pete suggested is perfectly kosher. Declare<= br> > victory!
>
> 2. Recharter in a way that will allow us to produce something like a > strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html =A0Pr= oduce
> something like that. Second victory!

A hearty +1.

When I'm done with more pressing I-Ds (i.e., by Monday) I'll propos= e
text for (1).

Nico
--
_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--001a11c2228c5571d104e0a485ee-- From cowan@ccil.org Wed Jul 3 17:27: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 7263111E8195 for ; Wed, 3 Jul 2013 17:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 KCvyDfIuVtlb for ; Wed, 3 Jul 2013 17:27:33 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6369E11E80E4 for ; Wed, 3 Jul 2013 17:27:33 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuXOW-0007mH-BG; Wed, 03 Jul 2013 20:27:32 -0400 Date: Wed, 3 Jul 2013 20:27:32 -0400 From: John Cowan To: Tim Bray Message-ID: <20130704002732.GV32044@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: "json@ietf.org" Subject: Re: [Json] 2-step proposal 4627bis + 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: Thu, 04 Jul 2013 00:27:37 -0000 Tim Bray scripsit: > 2. Recharter in a way that will allow us to produce something like a > strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html > Produce something like that. Second victory! This is a fine trial balloon. I have two comments: 1) I do not understand the rationale of Section 2, which amounts to saying that the top-level datum SHOULD NOT be an array. The presence of the string "urn:ietf:i-json" as the first element of the array would serve the same purposes of self-identification, and an array (unlike an object) will be serialized in order by any conformant serializer. As for extensibility, it is obvious that an array can be extended by adding new elements to the end if the elements are semantically heterogeneous, and if they are homogeneous, there is nothing to extend. 2) Stating the precision of numbers does not suffice: you ought also to state explicitly that the valid range is numbers whose absolute value is between 2^-1074 and (1 + (1 - 2^52)) * 2^1023, inclusive. For example, the integer 4503599627370497 is not exactly representable as a double (it is 2^52+1) and ought not to be allowed in I-JSON. So I still prefer my proposal of "is exactly representable as an IEEE 754:2008 64-bit binary floating point number". -- A mosquito cried out in his pain, John Cowan "A chemist has poisoned my brain!" http://www.ccil.org/~cowan The cause of his sorrow cowan@ccil.org Was para-dichloro- Diphenyltrichloroethane. (aka DDT) From James.H.Manger@team.telstra.com Wed Jul 3 18:36:28 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 8B36211E80F1 for ; Wed, 3 Jul 2013 18:36:28 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 6blODYY1ppPw for ; Wed, 3 Jul 2013 18:36:23 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 59AAF11E80D9 for ; Wed, 3 Jul 2013 18:36:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,992,1363093200"; d="scan'208";a="144839365" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 04 Jul 2013 11:36:21 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7125"; a="142140250" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipccvi.tcif.telstra.com.au with ESMTP; 04 Jul 2013 11:36:21 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Thu, 4 Jul 2013 11:36:20 +1000 From: "Manger, James H" To: Tim Bray , "json@ietf.org" Date: Thu, 4 Jul 2013 11:36:19 +1000 Thread-Topic: [Json] 2-step proposal 4627bis + I-JSON Thread-Index: Ac54R4cHyJQecUt+Q2SV2qHKTB/X3gAAMTbw Message-ID: <255B9BB34FB7D647A506DC292726F6E1151C19AD73@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Json] 2-step proposal 4627bis + 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: Thu, 04 Jul 2013 01:36:28 -0000 PiAyLiBSZWNoYXJ0ZXIgaW4gYSB3YXkgdGhhdCB3aWxsIGFsbG93IHVzIHRvIHByb2R1Y2Ugc29t ZXRoaW5nIGxpa2UgYQ0KPiBzdHJhd21hbiBJIGNvb2tlZCB1cCwgSS1KU09OOiBodHRwczovL3d3 dy50YnJheS5vcmcvdG1wL2ktanNvbi5odG1sDQo+IFByb2R1Y2Ugc29tZXRoaW5nIGxpa2UgdGhh dC4gU2Vjb25kIHZpY3RvcnkhDQo+IMKgLVQNCg0KSS1KU09OIGhhcyBzb21lIGdyZWF0IHNlY3Rp b25zLCBidXQuLg0KDQoidXJuOmlldGY6aS1qc29uIjp0cnVlICAtLSBVZ2g/IFdoeT8gSG93IGRv IHlvdSB0aGluayB0aGlzIHdvdWxkIGJlIHVzZWQgYnkgYXBwcyByZWNlaXZpbmcgSlNPTj8gRG8g dGhleSBzd2l0Y2ggYmV0d2VlbiByZWplY3RpbmcgZHVwcyB2cyBhY2NlcHRpbmcgbGFzdCBkdXAg YmFzZWQgb24gdGhlIHByZXNlbmNlIG9mIHRoaXMgZWxlbWVudD8gU291bmRzIHVubGlrZWx5Lg0K DQoid2hpY2ggTVVTVCBiZSB0aGUgZmlyc3QgbWVtYmVyIG9mIHRoZSB0b3AtbGV2ZWwgb2JqZWN0 IiAtLSBwbGVhc2UgZG9uJ3QgaGF2ZSB0aGlzLiBJdCB2aW9sYXRlcyB0aGUgcnVsZSB0aGF0IG9i amVjdCBlbGVtZW50cyBhcmUgKnVub3JkZXJlZCosIHdoaWNoIGp1c3QgZW5jb3VyYWdlcyBtb3Jl IHN1Y2ggdmlvbGF0aW9ucy4NCg0KDQpXZSBjb3VsZCBjbGFpbSB2aWN0b3J5IGlmIHRoaXMgc3Bl YyBlbmNvdXJhZ2VkIG1vc3QgImNvbW1vbiIgSlNPTiBwYXJzZXJzIHRvIGJlIG1vZGlmaWVkIHNv IHRoZXkgY291bGQgc2F5IHRoZXkgYXJlIEktSlNPTi1jb21wbGlhbnQuIFRoYXQgcmVxdWlyZXMg ImNvbW1vbiIgcGFyc2VycyB0byBzd2l0Y2ggdG8gdGhyb3dpbmcgYW4gZXJyb3Igd2hlbiBhIGR1 cCBpcyBkZXRlY3RlZCwgaW5zdGVhZCBvZiBzaWxlbnRseSBhY2NlcHRpbmcgdGhlIGxhc3QgdmFs dWUuIEkgd291bGQgbG92ZSB0byBzZWUgdGhhdCwgYnV0IEkgaGF2ZSBzZWVuIG5vIHNpZ24gdGhh dCB0aGlzIGlzIGxpa2VseS4NCiANCi0tDQpKYW1lcyBNYW5nZXINCg== From cowan@ccil.org Wed Jul 3 20:05: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 2FAAA11E8117 for ; Wed, 3 Jul 2013 20:05:44 -0700 (PDT) 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 fPEuORmFnzhY for ; Wed, 3 Jul 2013 20:05:39 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5E48311E80AD for ; Wed, 3 Jul 2013 20:05:36 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuZrQ-00076o-Er; Wed, 03 Jul 2013 23:05:32 -0400 Date: Wed, 3 Jul 2013 23:05:32 -0400 From: John Cowan To: Tatu Saloranta Message-ID: <20130704030532.GA14538@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: Nico Williams , Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 04 Jul 2013 03:05:44 -0000 Tatu Saloranta scripsit: > On unpaired surrogates: since their potential use has been outlined > multiple times, I am wondering if this has been substantiated by links to > systems that make use of this ability? I assume this potential exists only > on some platforms (and specifically not useful for platforms I typically > work on), but it would good to see links, similar to recent listing of > Streaming JSON processors one can find with bit of googling (happy to see > my SO answer being linked :) ). I would say that the potential is there for any JSON system running on a JVM, CLR, or JavaScript platform, since in all of these a string is a sequence of 16-bit code points. -- John Cowan http://www.ccil.org/~cowan "Any legal document draws most of its meaning from context. A telegram that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in 5-bit Baudot code plus appropriate headers) is as good a legal document as any, even sans digital signature." --me From cowan@ccil.org Wed Jul 3 20:27: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 4339E11E8104 for ; Wed, 3 Jul 2013 20:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 3atW1irUig2G for ; Wed, 3 Jul 2013 20:27:05 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B39D921F99D9 for ; Wed, 3 Jul 2013 20:27:04 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UuaCD-0000ib-7H; Wed, 03 Jul 2013 23:27:01 -0400 Date: Wed, 3 Jul 2013 23:27:01 -0400 From: John Cowan To: Tatu Saloranta Message-ID: <20130704032700.GB14538@mercury.ccil.org> References: <51D3C63C.5030703@cisco.com> <51D3CB52.7040902@cisco.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: Nico Williams , Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 04 Jul 2013 03:27:09 -0000 Tatu Saloranta scripsit: > There is difference between retaining parent path (names of "open" Object > properties), and retaining names of all preceding siblings. Indeed, you need to hold the names not only of preceding siblings, but of preceding siblings of all ancestral objects as well, though only the former are searched for conflicts. > Former is indeed done by parsers that try to give useful error information > with respect to nesting problems and such. No doubt, but nobody is going to *mandate* good error messages: that is QOI, and in some implementations (space constrained) you don't even want them. -- But the next day there came no dawn, John Cowan and the Grey Company passed on into the cowan@ccil.org darkness of the Storm of Mordor and were http://www.ccil.org/~cowan lost to mortal sight; but the Dead followed them. --"The Passing of the Grey Company" From ietf@lindenbergsoftware.com Wed Jul 3 20:47: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 37AEC11E8104 for ; Wed, 3 Jul 2013 20:47:14 -0700 (PDT) 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 Ie9BnV+XQjiy for ; Wed, 3 Jul 2013 20:47:09 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 98B3C11E8126 for ; Wed, 3 Jul 2013 20:47:09 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:51800 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UuaVe-000TxH-DT; Wed, 03 Jul 2013 20:47:06 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Norbert Lindenberg In-Reply-To: <20130704030532.GA14538@mercury.ccil.org> Date: Wed, 3 Jul 2013 20:47:06 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8BA75BB9-5136-47FB-8478-80E4870DA4F9@lindenbergsoftware.com> References: <20130704030532.GA14538@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Tatu Saloranta , Norbert Lindenberg , Paul Hoffman , "json@ietf.org" , Tim Bray , Nico Williams Subject: Re: [Json] What are we trying to do? 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, 04 Jul 2013 03:47:14 -0000 On Jul 3, 2013, at 20:05 , John Cowan wrote: > I would say that the potential is there for any JSON system running on > a JVM, CLR, or JavaScript platform, since in all of these a string is > a sequence of 16-bit code points. You mean 16-bit code units, not code points. http://www.unicode.org/glossary/#code_point http://www.unicode.org/glossary/#code_unit Norbert From duerst@it.aoyama.ac.jp Wed Jul 3 21:07: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 562F521F8D0D for ; Wed, 3 Jul 2013 21:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.457 X-Spam-Level: X-Spam-Status: No, score=-103.457 tagged_above=-999 required=5 tests=[AWL=0.333, 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 n5bsimQG1dRD for ; Wed, 3 Jul 2013 21:07:36 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4A28521F8A85 for ; Wed, 3 Jul 2013 21:07:35 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r6447Wm9027309; Thu, 4 Jul 2013 13:07:32 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6ed9_e29f_401dba74_e45f_11e2_b65e_001e6722eec2; Thu, 04 Jul 2013 13:07:31 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 06E88BF548; Thu, 4 Jul 2013 13:05:56 +0900 (JST) Message-ID: <51D4F4F3.2070305@it.aoyama.ac.jp> Date: Thu, 04 Jul 2013 13:07:15 +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: <20130704002732.GV32044@mercury.ccil.org> In-Reply-To: <20130704002732.GV32044@mercury.ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] 2-step proposal 4627bis + 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: Thu, 04 Jul 2013 04:07:42 -0000 On 2013/07/04 9:27, John Cowan wrote: > Tim Bray scripsit: > >> 2. Recharter in a way that will allow us to produce something like a >> strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html >> Produce something like that. Second victory! > > This is a fine trial balloon. I have two comments: > 2) Stating the precision of numbers does not suffice: you ought also to > state explicitly that the valid range is numbers whose absolute value is > between 2^-1074 and (1 + (1 - 2^52)) * 2^1023, inclusive. For example, > the integer 4503599627370497 is not exactly representable as a double (it > is 2^52+1) and ought not to be allowed in I-JSON. So I still prefer my > proposal of "is exactly representable as an IEEE 754:2008 64-bit binary > floating point number". That doesn't work very well either, because you might need quite a few digits after the decimal point to *exactly* represent a binary fraction in decimal numbers. As an example, try to write something like (2**52+1) / 2.0**200 (** being exponentiation) You'll need something like 50+ digits, but nobody does this. What e.g. Ruby does (since about version 2.0) is to produce a representation that has just as many digits as necessary to unambiguously have a single closest representation in IEEE 754:2008. Regards, Martin. From tbray@textuality.com Wed Jul 3 21:25: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 7136E11E80D1 for ; Wed, 3 Jul 2013 21:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=-0.983, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 Gb3Ibl4cip17 for ; Wed, 3 Jul 2013 21:25:11 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 057DF11E8126 for ; Wed, 3 Jul 2013 21:25:04 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf11so621798vcb.12 for ; Wed, 03 Jul 2013 21:25:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=+8kmVuL3FBnBYhxktIeeAuvIfGW++ZInzEX8Ar2mmGc=; b=awfI7huG6N93dyzHWykW+4WXHjUxrfkuVezesvloEW/+73iH7smcydx+kduE1cqDrZ 5nLmL4kXsLLX5V30BD2jMMFaCjbp41uOcVmaW/4L56o2sHSX+MHWiLocjIkd5CO0qwPe I6dxN5ANfRk/hUvUc9q7UrftDn8nGOQ2Q1yfrdEewiy7inIHJ6/NGtyy3MrnkT3NvRkL Hp3OitUoeWHb9cd01nyNSqbbN0VdGMcqqXU1748zcsom4QFOIys4+HJswT9LZDO30yDv aUyFraujGeGlJQ/7MRmsI0mBcMk5kSaJxRc21gO/h5xrvbykTgIVQjpqtNgNa97erZEV gcgg== MIME-Version: 1.0 X-Received: by 10.52.177.6 with SMTP id cm6mr1382600vdc.0.1372911904385; Wed, 03 Jul 2013 21:25:04 -0700 (PDT) Received: by 10.220.201.200 with HTTP; Wed, 3 Jul 2013 21:25:04 -0700 (PDT) X-Originating-IP: [209.121.225.242] In-Reply-To: <51D4F4F3.2070305@it.aoyama.ac.jp> References: <20130704002732.GV32044@mercury.ccil.org> <51D4F4F3.2070305@it.aoyama.ac.jp> Date: Wed, 3 Jul 2013 21:25:04 -0700 Message-ID: From: Tim Bray To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=20cf3071cc1a5e7f0404e0a7f618 X-Gm-Message-State: ALoCoQlSZww4PGJRYAbuCnMHoShx6DWq4l0XRf9QLaSVxsBIoZ5/aj6B/W2tHPKq5hEAvS+P76c8 Cc: John Cowan , "json@ietf.org" Subject: Re: [Json] 2-step proposal 4627bis + 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: Thu, 04 Jul 2013 04:25:15 -0000 --20cf3071cc1a5e7f0404e0a7f618 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Languages like Ruby and Lisp are pretty well proof against almost any imaginable numeric representation. But programmers in statically typed languages are going to do the equivalent of org.json.JSONObject.getLong() or getDouble(), and the idea in I-JSON is that if something in a JSON body is a number, it should Just Work. So I=E2=80=99m beginning to like John=E2=80=99s idea. Although it m= ight be plausible to also say that if the number has no fractional part, it MUST fall in the 64-bit integer value range. But anyhow, this is premature. Let=E2=80=99s hear some input from our chai= rs & ID as to what the WG should be trying to produce. -T On Wed, Jul 3, 2013 at 9:07 PM, "Martin J. D=C3=BCrst" wrote: > On 2013/07/04 9:27, John Cowan wrote: > >> Tim Bray scripsit: >> >> 2. Recharter in a way that will allow us to produce something like a >>> strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-**json.html >>> Produce something like that. Second victory! >>> >> >> This is a fine trial balloon. I have two comments: >> > > 2) Stating the precision of numbers does not suffice: you ought also to >> state explicitly that the valid range is numbers whose absolute value is >> between 2^-1074 and (1 + (1 - 2^52)) * 2^1023, inclusive. For example, >> the integer 4503599627370497 is not exactly representable as a double (i= t >> is 2^52+1) and ought not to be allowed in I-JSON. So I still prefer my >> proposal of "is exactly representable as an IEEE 754:2008 64-bit binary >> floating point number". >> > > That doesn't work very well either, because you might need quite a few > digits after the decimal point to *exactly* represent a binary fraction i= n > decimal numbers. As an example, try to write something like > (2**52+1) / 2.0**200 (** being exponentiation) > > You'll need something like 50+ digits, but nobody does this. What e.g. > Ruby does (since about version 2.0) is to produce a representation that h= as > just as many digits as necessary to unambiguously have a single closest > representation in IEEE 754:2008. > > Regards, Martin. > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --20cf3071cc1a5e7f0404e0a7f618 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Languages like Ruby and Lisp are pretty well proof ag= ainst almost any imaginable numeric representation.

But programmers = in statically typed languages are going to do the equivalent of org.json.JS= ONObject.getLong() or getDouble(), and the idea in I-JSON is that if someth= ing in a JSON body is a number, it should Just Work.=C2=A0 So I=E2=80=99m b= eginning to like John=E2=80=99s idea.=C2=A0 Although it might be plausible = to also say that if the number has no fractional part, it MUST fall in the = 64-bit integer value range.=C2=A0

But anyhow, this is premature.=C2=A0 Let=E2=80=99s hear some inpu= t from our chairs & ID as to what the WG should be trying to produce. -= T


On= Wed, Jul 3, 2013 at 9:07 PM, "Martin J. D=C3=BCrst" <duers= t@it.aoyama.ac.jp> wrote:
On 2013/07/04 9:27, John C= owan wrote:
Tim Bray scripsit:

2. Recharter in a way that will allow us to produce something like a
strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html
Produce something like that. Second victory!

This is a fine trial balloon. =C2=A0I have two comments:

2) Stating the precision of numbers does not suffice: you ought also to
state explicitly that the valid range is numbers whose absolute value is between 2^-1074 and (1 + (1 - 2^52)) * 2^1023, inclusive. =C2=A0For example= ,
the integer 4503599627370497 is not exactly representable as a double (it is 2^52+1) and ought not to be allowed in I-JSON. =C2=A0So I still prefer m= y
proposal of "is exactly representable as an IEEE 754:2008 64-bit binar= y
floating point number".

That doesn't work very well either, because you might need quite a few = digits after the decimal point to *exactly* represent a binary fraction in = decimal numbers. As an example, try to write something like
(2**52+1) / 2.0**200 (** being exponentiation)

You'll need something like 50+ digits, but nobody does this. What e.g. = Ruby does (since about version 2.0) is to produce a representation that has= just as many digits as necessary to unambiguously have a single closest re= presentation in IEEE 754:2008.

Regards, =C2=A0 Martin.

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

--20cf3071cc1a5e7f0404e0a7f618-- From ietf@lindenbergsoftware.com Wed Jul 3 22:06: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 32CB521F9E85 for ; Wed, 3 Jul 2013 22:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 ufZStjoGM5kj for ; Wed, 3 Jul 2013 22:06:37 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6E00921F9E7F for ; Wed, 3 Jul 2013 22:06:37 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:51969 helo=[192.168.0.5]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uubka-000f1I-4P; Wed, 03 Jul 2013 22:06:36 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Norbert Lindenberg In-Reply-To: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> Date: Wed, 3 Jul 2013 22:06:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <600B717E-2F49-4D5F-835C-C90218396E75@lindenbergsoftware.com> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg Subject: Re: [Json] Proposed minimal change for strings 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, 04 Jul 2013 05:06:42 -0000 On Jul 2, 2013, at 16:27 , Paul Hoffman wrote: > Proposal 1 (allow all code units in their unescaped form): >=20 > In section 1 (Introduction): > Change the sentence about Unicode characters to: > A string is a sequence of zero or more Unicode code units [UNICODE]. This should be "code points", not "code units". If you allow a sequence of code units, you might get UTF-8 code units in = random sequence, or a mix of UTF-8 code units and UTF-16 code units, = which wouldn't make sense at all. Also, JSON documents have to be understood at the level of code points, = because their code unit sequences are often changed in transit - e.g., = from UTF-16 code units in JavaScript to UTF-8 code units over the = network back to UTF-16 code units in Java - with no intended change in = content. See also http://www.unicode.org/glossary/#code_point http://www.unicode.org/glossary/#code_unit > In section 2.2 (Strings): > Leave the production for "unescaped" as-is. > In section 3 (Encoding): > Add "Some strings, notably those that have unescaped surrogate code = units > (value 0xD800 to 0xDFFF), cannot be encoded in UTF-8." As above, "surrogate code units" should be "surrogate code points", = therefore U+D800 to U+DFFF. Also, it's exactly the strings containing = unescaped surrogate code points that cannot be encoded in well-formed = UTF-8, so we can get rid of "some" and "notably those". There are a few additional references to "character" that would have to = be changed to "Unicode code point" to make this proposal complete. See http://www.ietf.org/mail-archive/web/json/current/msg00870.html Norbert= From stefan@drees.name Wed Jul 3 22:38:29 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 AC42821F9EF5 for ; Wed, 3 Jul 2013 22:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 81XS9VU040bi for ; Wed, 3 Jul 2013 22:38:24 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id A8FBB21F9EF0 for ; Wed, 3 Jul 2013 22:38:22 -0700 (PDT) Received: from newyork.local.box ([93.129.68.96]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0LyOuM-1U7vgP3WMw-015uHv; Thu, 04 Jul 2013 07:38:17 +0200 Message-ID: <51D50A46.6000501@drees.name> Date: Thu, 04 Jul 2013 07:38:14 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Cowan References: <51D3C63C.5030703@cisco.com> <51D3DC41.4020808@drees.name> <20130703165810.GF32044@mercury.ccil.org> In-Reply-To: <20130703165810.GF32044@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:vovpNk7jDt3rFQcH1LhLOU0kOBBsPX8wUt100jnhtR2QKaVsfD9 B9fxRAUMTJZN9S3iR0oA2ONm18Zb/gVH5N57m1iR8Tp91b9Jg9ms5NRGWl/v4glI07w3T9a blxcFtlhis6Pl703jcAfdsabZm1ZIWRsOzyA/NpUvErj2YOQuxIIsPM9IJo7XDugnQJXtqX iphD+Kd3sBp1TWPC1oCvQ== Cc: Nico Williams , Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 05:38:29 -0000 On 2013-07-03 18:58 +02:00, John Cowan wrote: > Stefan Drees scripsit: > >> JSON in the role of data interchange format allows at that point the >> multiset use case. Bad behaviour IMO is when misusing this. >> >> The expectation, that the unordered list of names in a single object >> must form a set and not a multiset is questionable. > > Nevertheless, anyone who generates JSON with duplicate names in order to > represent a multimap deserves to lose, because many, many JSON parsers > will simply throw away all but the last as an unintended consequence of > their implementation strategies. "lose" what? If this "anyone" (it) wants a self-describing robust form to interchange data, it will annotate it with metadata accordingly, publish the dictionary, or choose microxml or the like. We might share the view, that many applications exchanging data do also share information that is not inside the data. It may well be a one to one communication, not necessarily a one to many. A say sensor automat observing some features, serializing the extracted info into JSON and pushing this to another collecting automat first finds some name for the subject ("Stefan") than estimates from processing further, that this should be tagged with attribute A ("male"), starts a json object (to wrap it), enters the first member "Stefan":"male", eventualy pushes the json text part upstream, processes next observation B "native German", notes it linked to the same subject as member "Stefan": "native German" and pushes ... Why not leave this possibility open, more human like bots might act this way very conveniently, mixing some serial processing somewhere along the way. Even I sometimes overwrite observations on other people in my personal storage ... > I assume you mean a multimap rather than a multiset: a multiset would be > most naturally represented as a JSON object whose values are integers > representing the number of occurrences of a particular object in the > multiset. By the same token, the natural representation of a multiset > is a JSON object whose values are arrays. whose order is semantically > irrelevant. hm, no, I wanted to focus on the "no-keyspace" not on what is associated with the names. Often a boundary condition enforces wrapping inside an object. It is often natural for me (as a person) to express my thoughts and feelings, but in some situation I better do not do it naturally. >> {"Stefan":"male","Stefan":"native German","could not resist":true} > > { > "given name" : "John", > "gender" : "male", > "citizenship" : {"country" : "US", "source" : "jus soli"}, > "ethnicity" : ["German", "Irish"], > "annotations" : { > "verbose" : true, > "machine-processable" : true > } > } That's very nice, John, thanks. But you gave it some thought, backtracked mayb, edited and it is very deep nested for a record missing the family name ;-) That could be some digested output of the receiving end in my "HumBotTalk" scenario above. My "signature" was adhoc, expecting the JSON "reader" to strip the "last" member. The use case (described in more detail above) is more of the kind: Tag with a variable whatever (sha256 of an image?), associate predefined attributes with this "whatever" and push upstream as the analyzer detects. {"Stefan":{"Greetings":true}} From cowan@ccil.org Wed Jul 3 22:49:06 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 199A721F9EBF for ; Wed, 3 Jul 2013 22:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 RttUoXisv6Y7 for ; Wed, 3 Jul 2013 22:49:01 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id C1F5921F9EC0 for ; Wed, 3 Jul 2013 22:49:01 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UucPa-0006Mm-41; Thu, 04 Jul 2013 01:48:58 -0400 Date: Thu, 4 Jul 2013 01:48:58 -0400 From: John Cowan To: =?iso-8859-1?B?Ik1hcnRpbiBKLiBE/HJzdCI=?= Message-ID: <20130704054855.GB20507@mercury.ccil.org> References: <20130704002732.GV32044@mercury.ccil.org> <51D4F4F3.2070305@it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51D4F4F3.2070305@it.aoyama.ac.jp> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Tim Bray , "json@ietf.org" Subject: Re: [Json] 2-step proposal 4627bis + 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: Thu, 04 Jul 2013 05:49:06 -0000 "Martin J. Dürst" scripsit: > You'll need something like 50+ digits, but nobody does this. What > e.g. Ruby does (since about version 2.0) is to produce a > representation that has just as many digits as necessary to > unambiguously have a single closest representation in IEEE 754:2008. Indeed. The Scheme standard requires read/write invariance (what you write is what you read, down to the last ulp) and the minimum number of digits must be written. -- I don't know half of you half as well John Cowan as I should like, and I like less than half cowan@ccil.org of you half as well as you deserve. http://www.ccil.org/~cowan --Bilbo From cowan@ccil.org Wed Jul 3 22:50:29 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 97E2221F9EE3 for ; Wed, 3 Jul 2013 22:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 1bf3w6RuxoFQ for ; Wed, 3 Jul 2013 22:50:25 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 43FDE21F9ED0 for ; Wed, 3 Jul 2013 22:50:25 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UucQy-0006Tc-Di; Thu, 04 Jul 2013 01:50:24 -0400 Date: Thu, 4 Jul 2013 01:50:24 -0400 From: John Cowan To: Tim Bray Message-ID: <20130704055024.GC20507@mercury.ccil.org> References: <20130704002732.GV32044@mercury.ccil.org> <51D4F4F3.2070305@it.aoyama.ac.jp> 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: Martin =?iso-8859-1?Q?J=2E_D=FCrst?= , "json@ietf.org" Subject: Re: [Json] 2-step proposal 4627bis + 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: Thu, 04 Jul 2013 05:50:29 -0000 Tim Bray scripsit: > But programmers in statically typed languages are going to do the > equivalent of org.json.JSONObject.getLong() or getDouble(), and the idea in > I-JSON is that if something in a JSON body is a number, it should Just > Work. So I’m beginning to like John’s idea. Although it might be > plausible to also say that if the number has no fractional part, it MUST > fall in the 64-bit integer value range. For my taste that deviates too far from JSON's JavaScript roots, where ther are no 64-bit ints, only doubles which are sometimes treated as 32-bit ints. -- "Why yes, I'm ten percent Jewish on my manager's side." John Cowan --Connie Francis http://www.ccil.org/~cowan From petejson@codalogic.com Thu Jul 4 05:09: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 61A3621F934C for ; Thu, 4 Jul 2013 05:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.482 X-Spam-Level: * X-Spam-Status: No, score=1.482 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 oRAT6JvYTwP6 for ; Thu, 4 Jul 2013 05:09:16 -0700 (PDT) Received: from codalogic.com (codalogic.com [94.136.60.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6264121F9FC8 for ; Thu, 4 Jul 2013 05:09:14 -0700 (PDT) Received: (qmail 3657 invoked from network); 4 Jul 2013 13:09:12 +0100 Received: from host86-184-169-224.range86-184.btcentralplus.com (HELO codalogic) (86.184.169.224) by codalogic.com with (RC4-MD5 encrypted) SMTP; 4 Jul 2013 13:09:12 +0100 Message-ID: <994CFCB1858040FA8C81A0A11CC1452D@codalogic> From: "Pete Cordell" To: "Manger, James H" , "Tim Bray" , References: <255B9BB34FB7D647A506DC292726F6E1151C19AD73@WSMSG3153V.srv.dir.telstra.com> X-Unsent: 1 Date: Thu, 4 Jul 2013 13:09:09 +0100 x-vipre-scanned: 008D7F82004B50008D80CF 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 Subject: Re: [Json] 2-step proposal 4627bis + 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: Thu, 04 Jul 2013 12:09:20 -0000 Original Message From: "Manger, James H" > To: "Tim Bray" >> 2. Recharter in a way that will allow us to produce something like a >> strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html >> Produce something like that. Second victory! >> -T +1, while I'm here, but... > "urn:ietf:i-json":true -- Ugh? Why? How do you think this would be used > by apps receiving > JSON? Do they switch between rejecting dups vs accepting last dup based on > the presence > of this element? Sounds unlikely. I too am a bit 'meh' on the self identification part. (Knowing it's I-JSON is not even half way to knowing what you really want to know surely.) Extending it to something like: "urn:ietf:i-json:jose" : true or: "urn:ietf:i-json:com.codalogic:myprotocol:v2" : true has some attraction though. Although I think this would be more in the realms of convention than requirement. Or an alternative syntax of: "urn:ietf:i-json" : "jose" or: "urn:ietf:i-json" : "com.codalogic.myprotocol.v2" Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com From mmorley@mpcm.com Thu Jul 4 12:47: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 5F30211E81B3 for ; Thu, 4 Jul 2013 12:47:50 -0700 (PDT) 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 NQ8an-Zt5FzH for ; Thu, 4 Jul 2013 12:47:45 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B712A11E819D for ; Thu, 4 Jul 2013 12:47:44 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id v20so1499598lbc.17 for ; Thu, 04 Jul 2013 12:47:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=qojZA78cjg4p7zsdpLmHIPH/RwpVeCrPWT/0UG9eC5Y=; b=S/zheF6oKNSIQF3DcSSHnJJq+YSllZgbMjnp6A7zqcIa3Z4xvH0b6ZzMUcn28ZhIWK RllN+XrSXijsUt/7d21aJSYuJJWthxalGftFBbwMR5jZgx7xxUfXUHEimeHsjCto/ht0 gHp/9K9jqU7knhaCd7cJ+oRcw5ptXYRms99Yqnb2vNMWuU8nAjwd1TgS3sL4oKVKUKle elsaUUXgYdSWDeTP1lwDIHBgbPuSix3jmNEc8fqhMh9dSA3X2ATwlfEWx/1jaLmOm+LC WqeqTFC4UNJF9g8v/Y/DlNn9x1N3T6e/D5qrCI58HMRLeUEuHGDzUg3Mzkj0bqHiqWse x1fQ== MIME-Version: 1.0 X-Received: by 10.112.150.231 with SMTP id ul7mr4212598lbb.92.1372967263353; Thu, 04 Jul 2013 12:47:43 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.114.187.113 with HTTP; Thu, 4 Jul 2013 12:47:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Jul 2013 15:47:43 -0400 X-Google-Sender-Auth: 0VXcJQcWeLHmuUdA2uzF52XUzpA Message-ID: From: Matthew Morley To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b3434c2054d8c04e0b4dac8 X-Gm-Message-State: ALoCoQm7z/7RKcaYesTSLGcWjS5NNgWRfJkRXBtxB64sp5sPbA/RrEEXJLIwb6qikQ0LG/rhGyR4 Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 04 Jul 2013 19:47:50 -0000 --047d7b3434c2054d8c04e0b4dac8 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 2, 2013 at 7:25 PM, Paul Hoffman wrote: > > > Do either or both of these proposals work for people in the WG? > > --Matt Miller and Paul Hoffman > > The following are proposed minimal changes to make the JSON spec > interoperable with respect to > objects that have duplicate names. > > Proposal 1: > > In section 2.2 (Grammar -> Objects): > No change > In section 4 (Parsers): > Add: "If a parser encounters an object with duplicate names, the parser > MUST use only the last > name/value pair that has the duplicate name. > In section 5 (Generators): > Add: "The names within an object SHOULD be unique." > > Proposal 2: > > Same as Proposal 1 *except* that a second sentence is added for section 4: > "A parser that streams > its outputs MUST fail to finish parsing if it encounters more than one > name/value pair with the > same name." > #1 I guess. Duplicate keys *SHOULD* fail, IMHO. I feel like I am being disruptive by posting this, but I really think we are going down a path of splitting hairs and missing the broader point of this issue. All the same, I'm posting as a reply to the initial thread post, instead of all along the chain of replies. Perhaps I'm in the minority, but I don't want to see the validation around this split depending on the style of the decoding code. "Use the last value, except if you stream then fail" seems a strange position to hold. Failure should be a correct behavior in general. The meaning of *SHOULD* for unique keys within the specification provides enough of an expectation about the behavior, as well as a warning for those that "weighed" the choice to not follow it. *MUST* would have been better, but the complications we have been discussing are reasonable to expect and predict. Relying on ordered behavior in addition to duplicate keys, within a knowingly unordered structure that *SHOULD* have unique keys is clearly grounds for reasonable interop. errors and issues. "Clever" uses for this small gap in behavior changes do not warrant protection. Are there really legitimate uses of duplicate keys that should be honored, warrant this protection, and the level of effort going into this discussion? As an aside, it seems to me that none of this removes the need for streaming parsers to be aware of duplicate keys and to probably fail upon encountering them within the scope of a not-yet-closed object. If valid json should unique keys, parsers should fail on non-unique keys, stream or otherwise. A similar topic comes up with streaming json-rpc servers writers who are trying this SAX style approach (usually with batch requests), and the reality has always been that it must be valid json first. This means you cannot fully process the data with confidence until you confirm the payload is actually valid json. Doing otherwise is simply betting against fulfillment of the JSON format. If you can isolate the impact of the changes, process away until you can confirm, then merge those changes into the world. Otherwise, you need to be prepared to strike the actions from having an impact. Duplicate keys also prevent the use any meaningful path style strings, that are to be used as an either an reference point or as an identity/location token within and across objects (JSON Pointer for example). If your json object produces more than one value for an identity, that is concerning. Perhaps I'm just in shock that `json` is pondering new wording to handle something that clearly comes with such complications and disagreement in practice. Rather than promoting the behavior that is less complicated conceptually and clearly intended. -- Matthew P. C. Morley --047d7b3434c2054d8c04e0b4dac8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 2, 2013 at 7:25 PM, Paul Hoffman <paul.ho= ffman@vpnc.org> wrote:
<chair hats on>

Do either or both of these proposals work for people in the WG?

--Matt Miller and Paul Hoffman

The following are proposed minimal changes to make the JSON spec interopera= ble with respect to
objects that have duplicate names.

Proposal 1:

In section 2.2 (Grammar -> Objects):
=A0 No change
In section 4 (Parsers):
=A0 Add: "If a parser encounters an object with duplicate names, the p= arser MUST use only the last
=A0 name/value pair that has the duplicate name.
In section 5 (Generators):
=A0 Add: "The names within an object SHOULD be unique."

Proposal 2:

Same as Proposal 1 *except* that a second sentence is added for section 4: = "A parser that streams
=A0 its outputs MUST fail to finish parsing if it encounters more than one = name/value pair with the
=A0 same name."

#1 I guess. Duplicate keys *S= HOULD* fail, IMHO.

I feel like I am being disruptive by p= osting this, but I really think we are going down a path of splitting hairs= and missing the broader point of this issue. All the same, I'm posting= as a reply to the initial thread post, instead of all along the chain of r= eplies.

Perhaps I'm in the minority, but I don't want to see the v= alidation around this split depending on the style of the decoding code. &q= uot;Use the last value, except if you stream then fail" seems a strang= e position to hold. Failure should be a correct behavior in general.

The meaning of *SHOULD* for unique keys within the specification provid= es enough of an expectation about the behavior, as well as a warning for th= ose that "weighed" the choice to not follow it. *MUST* would have= been better, but the complications we have been discussing are reasonable = to expect and predict.

Relying on ordered behavior in addition to duplicate keys, within a kno= wingly unordered structure that *SHOULD* have unique keys is clearly ground= s for reasonable interop. errors and issues. "Clever" uses for th= is small gap in behavior changes do not warrant protection.

Are there really=A0legitimate=A0uses of duplicate keys = that should be honored, warrant this protection, and the level of effort go= ing into this discussion?


As an aside, it = seems to me that none of this removes the need for streaming parsers to be = aware of duplicate keys and to probably fail upon encountering them within = the scope of a not-yet-closed object. If valid json should unique keys, par= sers should fail on non-unique keys, stream or otherwise.

A similar topic comes up with streaming json-rpc = servers=A0writers=A0who are trying this SAX style approach (usually with ba= tch requests), and the reality has always been that it must be valid json f= irst. This means you cannot fully process the data with confidence until yo= u confirm the payload is actually valid json. Doing otherwise is simply bet= ting against=A0fulfillment=A0of the JSON format. If you can isolate the imp= act of the changes, process away until you can confirm, then merge those ch= anges into the world. Otherwise, you need to be prepared to strike the acti= ons from having an impact.


Duplicate keys also prevent the use any meaningful = path style strings, that are to be used as an either an reference point or = as an identity/location token within and across objects (JSON Pointer for e= xample). If your json object produces more than one value for an identity, = that is concerning.

Perhaps I'm just in shock that `json` is pon= dering new wording to handle something that clearly comes with such complic= ations and disagreement in practice. Rather than promoting the behavior tha= t is less complicated conceptually and clearly intended.

--
Matthew P. C. Morley
--047d7b3434c2054d8c04e0b4dac8-- From tsaloranta@gmail.com Thu Jul 4 15:17: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 308E311E80D3 for ; Thu, 4 Jul 2013 15:17:23 -0700 (PDT) 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=[AWL=0.000, 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 1xw28c9iA2-f for ; Thu, 4 Jul 2013 15:17:22 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1F53811E81DD for ; Thu, 4 Jul 2013 15:17:21 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so1465111wgh.4 for ; Thu, 04 Jul 2013 15:17:21 -0700 (PDT) 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=XHR8O0rUBZXrBTceBwX4SO/ZwsGDE4vZsL0havhNMNs=; b=MwExN11WHcswkcH9LxyW+0SI7Ma8JJk48Xr1KunFdVMqMtozcMVZgrFt4EmK9oOHgN FBks48rCl7nFwKFxREQ+j3xSghpYJAMTFhM8rWMg0Or/lNKKq80VOu4z+yjCefI1poQw GGHMp/m6+ISKGxn2TXJ5Z8NWBEfbwcn/57Z17hsMTqEQ4UBUWb1ReF3pPuyolfe05tMZ Uw8IAvF5sFnhN+m9eNLQXEDTJuwzSr1lEIhPrz6lhfljSgt5K/mwkvfbqiTJ9zch95JG bXA2RDC4N++EVK2Rr5k7vIvNfo4wtN0S8LAxXcm2O88ZUjhBHeNs6GdVItl4g11mHxpQ 7Fzg== MIME-Version: 1.0 X-Received: by 10.180.11.146 with SMTP id q18mr3160442wib.50.1372976241239; Thu, 04 Jul 2013 15:17:21 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Thu, 4 Jul 2013 15:17:21 -0700 (PDT) In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <51D48990.7090305@cisco.com> Date: Thu, 4 Jul 2013 15:17:21 -0700 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c24d1624ee3d04e0b6f152 Cc: Pete Resnick , Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 04 Jul 2013 22:17:23 -0000 --001a11c24d1624ee3d04e0b6f152 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 3, 2013 at 2:37 PM, Nico Williams wrote: > On Wed, Jul 3, 2013 at 3:29 PM, Eliot Lear wrote: > > On 7/3/13 9:48 PM, Pete Resnick wrote: > >> Let's remember the meaning of these capitalized words in IETF > >> parlance. We use them "where it is actually required for > >> interoperation or to limit behavior which has potential for causing > >> harm." So a MUST would mean that not doing so would prevent > >> interoperation or cause harm. RECOMMENDED (like SHOULD) would also > >> mean that not doing so would prevent interoperation or cause harm, but > >> "that there may exist valid reasons in particular circumstances to > >> ignore a particular item, but the full implications must be understood > >> and carefully weighed before choosing a different course." > > > > I have to say that ambiguity of a language implies an introduction to > > interoperability problems. But MUST we use MUST in those cases? I > > would prefer the catch the problem when we have the opportunity. If the > > WG feels differently, Meh. As Nico said, deal with it at a higher layer. > > I think we're very likely to get consensus for SHOULD language with an > out for streaming generators/parsers pushing the MUST to the > application. > > We could force MUST with an out for streaming generators/parsers > pushing the MUST to the application, but it'd leave some implementors > on the rough side of consensus and unhappy. > > One problem I have had is assumption that we only have 2 layers (application, parser/generator). While it simplifies language, it makes it difficult to define whether combination of parser and deserializer (as well as serializer and generator) should be considered "parser" (and "generator") in specifications or not. Perhaps "application" here would then refer to serialization library and application code? I would be happy with "SHOULD" at parser/generator level, and even "MUST" for serializer/deserializer level, since those are cases that are easy to support efficiently. At the same time, given such separation of processing layers, nothing prevents applications from doing custom serialization/deserialization, and by-passing strict checks. I don't personally mind that -- as long as ramifications are made clear, it's their responsibility -- but I don't think is universally agreed view. -+ Tatu +- --001a11c24d1624ee3d04e0b6f152 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 2:37 PM, Nico Williams <nico@c= ryptonector.com> wrote:
On Wed, Jul 3, 2013 at 3:2= 9 PM, Eliot Lear <lear@cisco.com&g= t; wrote:
> On 7/3/13 9:48 PM, Pete Resnick wrote:
>> Let's remember the meaning of these ca= pitalized words in IETF
>> parlance. We use them "where it is actually required for
>> interoperation or to limit behavior which has potential for causin= g
>> harm." So a MUST would mean that not doing so would prevent >> interoperation or cause harm. RECOMMENDED (like SHOULD) would also=
>> mean that not doing so would prevent interoperation or cause harm,= but
>> "that there may exist valid reasons in particular circumstanc= es to
>> ignore a particular item, but the full implications must be unders= tood
>> and carefully weighed before choosing a different course." >
> I have to say that ambiguity of a language implies an introduction to<= br> > interoperability problems. =A0But MUST we use MUST in those cases? =A0= I
> would prefer the catch the problem when we have the opportunity. =A0If= the
> WG feels differently, Meh. =A0As Nico said, deal with it at a higher l= ayer.

I think we're very likely to get consensus for SHOULD language wi= th an
out for streaming generators/parsers pushing the MUST to the
application.

We could force MUST with an out for streaming generators/parsers
pushing the MUST to the application, but it'd leave some implementors on the rough side of consensus and unhappy.


One problem I have had is assumption t= hat we only have 2 layers (application, parser/generator). While it simplif= ies language, it makes it difficult to define whether combination of parser= and deserializer (as well as serializer and generator) should be considere= d "parser" (and "generator") in specifications or not.<= br>
Perhaps "application" here would then refer to seriali= zation library and application code?

I would be happy wit= h "SHOULD" at parser/generator level, and even "MUST" f= or serializer/deserializer level, since those are cases that are easy to su= pport efficiently.

At the same time, given such separation of processing layers= , nothing prevents applications from doing custom serialization/deserializa= tion, and by-passing strict checks. I don't personally mind that -- as = long as ramifications are made clear, it's their responsibility -- but = I don't think is universally agreed view.

-+ Tatu +-

--001a11c24d1624ee3d04e0b6f152-- From tsaloranta@gmail.com Thu Jul 4 15:27: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 2517F11E81E9 for ; Thu, 4 Jul 2013 15:27:13 -0700 (PDT) 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=[AWL=0.000, 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 53w0gwYZgRU9 for ; Thu, 4 Jul 2013 15:27:12 -0700 (PDT) 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 4B90911E81AD for ; Thu, 4 Jul 2013 15:27:11 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so6779606wgg.5 for ; Thu, 04 Jul 2013 15:27:10 -0700 (PDT) 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=BiUwUFeevGJoyNMo37g66uqv2E/dGbSjy2fk0OEHbr0=; b=Jqm/YTNc/rvjQwDIbCczHsTaAupvoX35rMH/jAV8QgBrhOsI+PGDqSlRJBGG/a4Xel NrSL0KqsVfJbWUpDM+zqAF0uu/TzzeuMtI7vYPcgWAbuc51Ix4jMG1VqlG4w2Vw9b6vG ixZUuowneVyGvLa3stQ8QeXz/ZRK03Zwrq+Gei2gJvh9f3DeKrBzVGU/v+5PRgyRA5n5 o+/WoF5VEkUzCXaxZoYubfM3bIWSkK2KA42gQZ0PC/9kMLVztVlYygfg1rgFpz0YbXuO dp3Vwe987MDhp1RGSO8KwEJCMi21Tjxwbsk2cVhqtAm3sXb6KLoVJv+glXXMXVF25usL MRdg== MIME-Version: 1.0 X-Received: by 10.180.12.45 with SMTP id v13mr21984214wib.7.1372976830380; Thu, 04 Jul 2013 15:27:10 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Thu, 4 Jul 2013 15:27:10 -0700 (PDT) In-Reply-To: <20130704030532.GA14538@mercury.ccil.org> References: <20130704030532.GA14538@mercury.ccil.org> Date: Thu, 4 Jul 2013 15:27:10 -0700 Message-ID: From: Tatu Saloranta To: John Cowan Content-Type: multipart/alternative; boundary=001a11c22ac0427faf04e0b7142d Cc: Nico Williams , Tim Bray , Paul Hoffman , "json@ietf.org" Subject: Re: [Json] What are we trying to do? 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, 04 Jul 2013 22:27:13 -0000 --001a11c22ac0427faf04e0b7142d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 3, 2013 at 8:05 PM, John Cowan wrote: > Tatu Saloranta scripsit: > > > On unpaired surrogates: since their potential use has been outlined > > multiple times, I am wondering if this has been substantiated by links to > > systems that make use of this ability? I assume this potential exists > only > > on some platforms (and specifically not useful for platforms I typically > > work on), but it would good to see links, similar to recent listing of > > Streaming JSON processors one can find with bit of googling (happy to see > > my SO answer being linked :) ). > > I would say that the potential is there for any JSON system running on > a JVM, CLR, or JavaScript platform, since in all of these a string is > a sequence of 16-bit code points. > Right I am not saying there is not potential -- potential is pretty clear to me. But is that potential used by anyone to substantial degree? Is there existing use that would be hampered? What would break? -+ Tatu +- --001a11c22ac0427faf04e0b7142d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 3, 2013 at 8:05 PM, John Cowan <cowan@me= rcury.ccil.org> wrote:
Tatu Saloranta scripsit:

> On unpaired surrogates: since their potential use has been outlined > multiple times, I am wondering if this has been substantiated by links= to
> systems that make use of this ability? I assume this potential exists = only
> on some platforms (and specifically not useful for platforms I typical= ly
> work on), but it would good to see links, similar to recent listing of=
> Streaming JSON processors one can find with bit of googling (happy to = see
> my SO answer being linked :) ).

I would say that the potential is there for any JSON system running o= n
a JVM, CLR, or JavaScript platform, since in all of these a string is
a sequence of 16-bit code points.

Right I am n= ot saying there is not potential -- potential is pretty clear to me.

But is that potential used by anyone to substantial degree? Is = there existing use that would be hampered? What would break?

-+ Tatu +-
=A0
--001a11c22ac0427faf04e0b7142d-- From nico@cryptonector.com Thu Jul 4 19:52: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 F0A1511E8109 for ; Thu, 4 Jul 2013 19:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.023, 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 FNXJqnEE7eLi for ; Thu, 4 Jul 2013 19:52:09 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id BE92711E821F for ; Thu, 4 Jul 2013 19:52:08 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id B2AB867C06E for ; Thu, 4 Jul 2013 19:52:04 -0700 (PDT) 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=JQD0hCdGd37NnRsDiXBh swXZV4A=; b=OBAZC2fCjJJ7qC8SxU9SgSzAnGro+7uiL5oyDjwPpwL7xKiR68ZR 87lEI+qgDGT5AcvHPEMrWbMZeUrJZpO/yS5IVhCRplchXAfaAGquv4fePmuaVtPA NhqMJetVTuvqeiejlC40YwLP9AX7lv1TXIY8kf7ZW/UDc31fD+H+FRI= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 58EA267C06D for ; Thu, 4 Jul 2013 19:52:04 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so1547225wgh.18 for ; Thu, 04 Jul 2013 19:52:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nyyTAFELgipx2Er+WjRYLW1Igltslhz5eGtxRMipS4g=; b=gXW+ZfA30OQXpV4h0G/qnpBExWtB+lz2iauLBssAjLIAQ6xeZHXhZcQCXBr1iTHY0b m0rgyDDCTprSUFGKYix/VkvQF/+l4FLUS29/jpApJWJsGhowAbL8uWBmCrOnF82qlwgt Kz+7gJJTVdEi+x7yeW0WHjQw3IkLfnPEghi9tnFK1pwg4HEynPBXpG25Eotuvqb5NPnC 8lH3Npo2AuZkQTBK4SH4JRLuzakoGnEp/73i44EEAhOyL/XM34UhCTJON6QEZS0QwyNZ 6MCCJVuHZXdmhDNBy+3QDF3Ddoy32M2fQdFlYsA2V3iI4Mz0pr6zb9xPxvdwbbT2gzVY pOSg== MIME-Version: 1.0 X-Received: by 10.194.173.37 with SMTP id bh5mr5052310wjc.30.1372992722490; Thu, 04 Jul 2013 19:52:02 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Thu, 4 Jul 2013 19:52:02 -0700 (PDT) In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <51D48990.7090305@cisco.com> Date: Thu, 4 Jul 2013 21:52:02 -0500 Message-ID: From: Nico Williams To: Tatu Saloranta Content-Type: text/plain; charset=UTF-8 Cc: Pete Resnick , Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 05 Jul 2013 02:52:14 -0000 On Thu, Jul 4, 2013 at 5:17 PM, Tatu Saloranta wrote: > On Wed, Jul 3, 2013 at 2:37 PM, Nico Williams wrote: >> I think we're very likely to get consensus for SHOULD language with an >> out for streaming generators/parsers pushing the MUST to the >> application. >> >> We could force MUST with an out for streaming generators/parsers >> pushing the MUST to the application, but it'd leave some implementors >> on the rough side of consensus and unhappy. >> > > One problem I have had is assumption that we only have 2 layers > (application, parser/generator). While it simplifies language, it makes it > difficult to define whether combination of parser and deserializer (as well > as serializer and generator) should be considered "parser" (and "generator") > in specifications or not. > Perhaps "application" here would then refer to serialization library and > application code? There can be many layers. One application I work with is a Ruby on Rails app with a DB underneath. In one client I have to read a very large subset of the DB and the run with that and an audit feed from the same DB. A JSON streaming generator and parser that ignored duplicate names would work just fine because schema is enforced on the *write* side and so there can be no duplicate names, and *nothing* but the write side need ever concern itself with duplicate names. There's quite a few moving pieces and layers in this one app, but only one piece that ensures properly-formed data -- outside that piece there is no relevance to duplicate name handling for there can't be duplicate names. I don't think it'd be critical to wordsmith the RFC so that this app can work with streaming generators/parsers that are oblivious to duplicate names, but it'd be nice to. One way to do it is to use the passive voice. Otherwise there might have to be a [what do we call this?] consideration for application deverlopers using streaming encoders/parsers that are duplicate name oblivious. There's a trade-off between writing very generic text (but in a passive voice) and having to cover a number [possibly lots] of specific cases. > I would be happy with "SHOULD" at parser/generator level, and even "MUST" > for serializer/deserializer level, since those are cases that are easy to > support efficiently. That's not really enough for my use case. > At the same time, given such separation of processing layers, nothing > prevents applications from doing custom serialization/deserialization, and > by-passing strict checks. I don't personally mind that -- as long as > ramifications are made clear, it's their responsibility -- but I don't think > is universally agreed view. Right, "strict checks" somewhere. Just not necessarily in the generator nor parser. Nico -- From jhildebr@cisco.com Thu Jul 4 20:09: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 DF3EA21F86D5 for ; Thu, 4 Jul 2013 20:09:22 -0700 (PDT) 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 y0YCcGQcV12v for ; Thu, 4 Jul 2013 20:09:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5436E21F8643 for ; Thu, 4 Jul 2013 20:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1107; q=dns/txt; s=iport; t=1372993757; x=1374203357; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=tfE2aXO658c53wqak0j9QcWu77dY6kWF00rlr0Sisls=; b=lCYpwF4b9MsR+mKmPnWaQQENEVqaUZZxBPJFlcQGyvm+xHBxDQgCWDGE SFNLfm4kH+f/4ooLS7OmFda6/IXFrqkFtun6JcUCvWj1E0qiBiS6auYpa dnhVNw9LtmZvny3fWils/ct9hdb1A6aMIvGkPZAptE6XF/SIcDqTQuS1h Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAPI31lGtJXG+/2dsb2JhbABagwl7wDiBARZ0giMBAQEDATpEDQEIIhRCJQIEARIIiAEGuS2POjiDBGkDqQ6DEYIo X-IronPort-AV: E=Sophos;i="4.87,999,1363132800"; d="scan'208";a="231128087" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 05 Jul 2013 03:09:16 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6539GBL007836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 03:09:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 22:09:15 -0500 From: "Joe Hildebrand (jhildebr)" To: Paul Hoffman , "json@ietf.org WG" Thread-Topic: [Json] Proposed minimal change for strings Thread-Index: AQHOd3uz+zMmutqy8ECJIa9yown6S5lVWk+A Date: Fri, 5 Jul 2013 03:09:15 +0000 Message-ID: In-Reply-To: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.87.230] Content-Type: text/plain; charset="us-ascii" Content-ID: <67DEB9FFE151FA4A9C3BE18775E44BB0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Proposed minimal change for strings 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, 05 Jul 2013 03:09:23 -0000 On 7/2/13 5:27 PM, "Paul Hoffman" wrote: >Proposal 1 (allow all code units in their unescaped form): vehemently -1 >Proposal 2 (prohibit unescaped surrogates): > In section 1 (Introduction): > A string is a sequence of zero or more Unicode scalar values [UNICODE]. > In section 2.2 (Strings): > Change the production for "unescaped" to be: > unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF That works for me. I think that the current text implies this by limiting the valid encodings to UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, and UTF-32LE, none of which can legally encode unescaped surrogates. The ABNF is therefore a spec bug that needs to be cleaned up, and any existing code that emits unescaped values in the range %xD800-%xDFFF when not producing UTF-16, or invalid combinations of those values when producing UTF-16 has a bug that needs to be fixed. Note: I don't care if parsers choose to do something heroic in the face of these buggy implementations instead of rejecting the input (viva Postel!). --=20 Joe Hildebrand From jorge@jorgechamorro.com Fri Jul 5 02:48:01 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 4BCEF11E827D for ; Fri, 5 Jul 2013 02:48:01 -0700 (PDT) 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 PI+e3gochunl for ; Fri, 5 Jul 2013 02:47:55 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE7211E827B for ; Fri, 5 Jul 2013 02:47:54 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so1769456wes.41 for ; Fri, 05 Jul 2013 02:47:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Q+zlXFC3mVL5Ut83CG7gfIvXQ6O7eb4rhnluaJQO93I=; b=QzOjV4Xa0XVPpZovz6J7AsKAd7KO2UWwvcDrm7QZyvel+p6Q6LVENAq/bk5Pc2zVI9 edvvrIGW9kOuIrlWqc3q03F6nomzBOK/GmYnSPenLUyazi1Y4rtJA+Tj4VVy/cUp8U0l dPPt0/OESCA0VcfKM8qE5JRLZb4LLClrkV1YZi6FzNkeYA5hFDgGvfatuv8BPkDNf6bD 3Qw3FcjpFF7X2Cr/U9Ot4aJb57PFDeSIy1/UanmJXfnNaWUYVUvPB79v2Q9dGEdZ+Gxr dTCRtuj7wji2hjQLbI+91bOGxalmZSOl8gh7phzvZuuSwpZvJQiW91a0quQ6VEqg/Hno r9Aw== X-Received: by 10.180.74.197 with SMTP id w5mr23019641wiv.20.1373017673716; Fri, 05 Jul 2013 02:47:53 -0700 (PDT) Received: from [192.168.10.50] (156.Red-79-155-151.dynamicIP.rima-tde.net. [79.155.151.156]) by mx.google.com with ESMTPSA id f8sm39034225wiv.0.2013.07.05.02.47.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 02:47:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge In-Reply-To: Date: Fri, 5 Jul 2013 11:47:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <51D48990.7090305@cisco.com> To: Tatu Saloranta X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmrZPxv05tV/KFqY47W9EXcCx4eBlPmh81MukdwKES+/MHWV63dBxWuZiwlnrcNL0jLGTf9 Cc: Nico Williams , Pete Resnick , Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 05 Jul 2013 09:48:01 -0000 On 05/07/2013, at 00:17, Tatu Saloranta wrote: >=20 > At the same time, given such separation of processing layers, nothing = prevents applications from doing custom serialization/deserialization, = and by-passing strict checks. I don't personally mind that -- as long as = ramifications are made clear, it's their responsibility -- but I don't = think is universally agreed view. I've been using JSON in a server in a language that doesn't have = objects... so for the outgoing JSON texts I've had to write a custom = generator for every kind of payload, manually grabbing the data from a = predefined set of vars, and idem for the incoming JSON texts: = .parse()ing had to fill a different predefined set of vars for each kind = of payload. This is one of those scenarios in which JSON text parsers and generators = have to be ad hoc. --=20 ( Jorge )();= From jorge@jorgechamorro.com Fri Jul 5 03:01: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 DB81621F9F78 for ; Fri, 5 Jul 2013 03:01:13 -0700 (PDT) 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 syrpwTNuTEsL for ; Fri, 5 Jul 2013 03:01:08 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id CF8A021F9F19 for ; Fri, 5 Jul 2013 03:01:07 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so1860667wgh.24 for ; Fri, 05 Jul 2013 03:01:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=NcqzhBFssCXhi57iZCxcJOEwGhZ+r4LQm7BqE8sA38Y=; b=VFhvLLGnupTUwCV5dAxiz7xlEDLcyZzyLmdJPcqnwLM7kLnzjoDEOD06L4x/5Epb90 b+DitFlv3lXP94stq6jNrodeIJ+tdLdAGXwBYM+hSy4RpbAMmv7gf7o/o3ZuLIlnBhwZ m1ofJev9Ct7kPSWHFQCltqTW//PP7vi6yJ/9tjmeLwY16ihbG7avjy8XPD1Z0hY/iXp7 srXlLBw5PuCwjj6JkFe3IsEFvXQJ2l1DpDCIXsJaTfrWBKguzOkdgiZQPmFXQNCqN4Lt Xf76wb+73TMrMDyuK0V+zj+3boT8eKZpIEAtkvw4Vqry+pCM8wp3IYri1jxs2yZufAio voOA== X-Received: by 10.194.80.134 with SMTP id r6mr5654243wjx.88.1373018466739; Fri, 05 Jul 2013 03:01:06 -0700 (PDT) Received: from [192.168.10.50] (156.Red-79-155-151.dynamicIP.rima-tde.net. [79.155.151.156]) by mx.google.com with ESMTPSA id f8sm39112901wiv.0.2013.07.05.03.01.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 03:01:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Jorge In-Reply-To: Date: Fri, 5 Jul 2013 12:01:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmyixdmXW1Unty0gmmtnlat/K2NMs7FBpzzMJmsaTwkQpq+7ffvRQyAi6SXsmhs5MXKRcbZ Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 05 Jul 2013 10:01:14 -0000 On 05/07/2013, at 05:09, Joe Hildebrand (jhildebr) wrote: > On 7/2/13 5:27 PM, "Paul Hoffman" wrote: >=20 >> Proposal 1 (allow all code units in their unescaped form): >=20 > vehemently -1 But, don't the JavaScripts in =98 every browser in the world permit it? --=20 ( Jorge )();= From derhoermi@gmx.net Fri Jul 5 07:11: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 51E4211E80E9 for ; Fri, 5 Jul 2013 07:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, 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 NnMD5Izn604v for ; Fri, 5 Jul 2013 07:11:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id B372021F9F7A for ; Fri, 5 Jul 2013 07:11:34 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lrp0S-1UDUoF28zO-013elD for ; Fri, 05 Jul 2013 16:11:33 +0200 Received: (qmail invoked by alias); 05 Jul 2013 14:11:32 -0000 Received: from p5B233A42.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.58.66] by mail.gmx.net (mp002) with SMTP; 05 Jul 2013 16:11:32 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19q1eQIA8pq1aNFp0Kcaus3zsHjLxRc9ejU9O57Q8 voq+LjXApmiBSN From: Bjoern Hoehrmann To: Matthew Morley Date: Fri, 05 Jul 2013 16:11:31 +0200 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-Y-GMX-Trusted: 0 Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 05 Jul 2013 14:11:39 -0000 * Matthew Morley wrote: >#1 I guess. Duplicate keys *SHOULD* fail, IMHO. > >I feel like I am being disruptive by posting this, but I really think we >are going down a path of splitting hairs and missing the broader point of >this issue. All the same, I'm posting as a reply to the initial thread >post, instead of all along the chain of replies. The broader point here is that the Working Group is supposed to document the JSON format based on running code and rough consensus and changes to what is in RFC 4627 require very strong justification and support. That means duplicate names in objects will be permitted and parsers will not be required to detect and report duplicate names. Relying on duplicated names is a bad practise, and for parsers that report only one of the names, it is a good practise to pick the last in- stance, and of course parsers are always free to reject any content for security reasons as they see fit, this's all largely agreed in the group and people do not care terribly much how the specification conveys this. I for instance would prefer telling people that picking the last value is the logical and typical choice and the behavior of standard APIs like JSON.parse and picking the first one or a random one instead is sure to cause interoperability, security, migration, and other headaches -- over fiddling with RFC 2119 keywords, but in the end it does not really have an effect on how people are going to use and implement JSON in the wild. We know all the open questions, as far as I am concerned we could just write them all down and survey the Working Group; one implied question above, as an example, is JSON parsers that treat objects with duplicate keys as malformed for security reasons should be made non-conforming in JSONbis. I would strongly disagree with that and am quite sure other participants would do the same; in studying the survey results the chairs might find there is indeed a rough consensus JSON parsers should be allowed to re- ject such JSON documents for security reasons, and then task editors or whoever volunteers with implementing that in the specification prose. Same for all the other issues, say Allow Unicode Signature in UTF-8 encoded application/json entities. Allow Strings at the top level. ... Then we would be getting somewhere... -- 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 stedolan@stedolan.net Fri Jul 5 08:50: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 BB9D311E8302 for ; Fri, 5 Jul 2013 08:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 lU86Vrdg7706 for ; Fri, 5 Jul 2013 08:50:34 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id D54AE21F9BDB for ; Fri, 5 Jul 2013 08:50:33 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ec20so2152307lab.41 for ; Fri, 05 Jul 2013 08:50:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=jkQa0MqwN6eB7+IG9PW1xfQZ0hVRfJhqzuNixSct1qI=; b=L1PjkrqFvoYZl+auvCZO7JbdwCdGQfxVeKps6z6ckyCKK7yuOzfOy5iC1YSruRqmIZ lzXUUc81VCY4pTg2LhRMa2U1s7C/cHajKHLJoamZd8Z1ac5oeOjV9HLeEm2jiTYVSFv9 qYVdHCd0XN5CXsFN27lQhnBb6G2uGlrMKXg5J92sjizlPZC1GrXeQF9wSD3vmcmGmVGd TOtqnaCpWCIMLGmEmXn9KIgAIS6C7yChEbHTLXbKj9m7H57oMf7DkCGN1glElvdpriUQ Gcq2+ETHXzToptqpn/btC2O2EBjkzXKtvc+WsO7/ozlVKBMgkuPefxm7JHQ0/0xHeVUO 5S/Q== MIME-Version: 1.0 X-Received: by 10.112.159.169 with SMTP id xd9mr5816511lbb.43.1373039432576; Fri, 05 Jul 2013 08:50:32 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.200.198 with HTTP; Fri, 5 Jul 2013 08:50:32 -0700 (PDT) X-Originating-IP: [128.232.9.157] In-Reply-To: References: Date: Fri, 5 Jul 2013 16:50:32 +0100 X-Google-Sender-Auth: Vb3cwJ8K7NWVOu6MDCGvWOq5E0I Message-ID: From: Stephen Dolan To: Jorge Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnHmFukDL2zIHPy3/GgOwJRFbVqNq3BKmVTjnIJ+0czNmgbqCJgKojIItaQ2s+E6XOojV4P Cc: Paul Hoffman , Joe Hildebrand , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 05 Jul 2013 15:50:44 -0000 On Fri, Jul 5, 2013 at 11:01 AM, Jorge wrote: > But, don't the JavaScripts in =98 every browser in the world permit it? They also permit numbers to be NaN or Inf, objects to contain keys which are not strings, array syntax to include a trailing comma, and so on. "Javascript permits it" does not imply that JSON does or should. Regarding the proposals: +1 for proposal 2, and very much -1 for proposal 1 (both because I disagree that unpaired surrogates should be part of JSON, and because it is badly worded, using the term "code unit" in strange ways). Stephen From derhoermi@gmx.net Fri Jul 5 10:15: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 0E73B21F9A79 for ; Fri, 5 Jul 2013 10:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_83=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 QRnUE3sb5IUp for ; Fri, 5 Jul 2013 10:15:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 635CE21F9A59 for ; Fri, 5 Jul 2013 10:15:53 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.58.66]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0Lx4dh-1UAxtG14rR-016jRU; Fri, 05 Jul 2013 19:15:51 +0200 From: Bjoern Hoehrmann To: Paul Hoffman Date: Fri, 05 Jul 2013 19:15:53 +0200 Message-ID: <00sdt8hmont8gqvams8qbuas6o9c32ap5o@hive.bjoern.hoehrmann.de> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> In-Reply-To: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@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:dNm0qm2mB/nJQMxsNL2wcDOdZPCClbdArPyUCeWo1UGCPfE0+i7 hLs+v70B2MZIKrY7SfF7uO+Ksn9e3B4/wO/1/kURt9vdW5Hf4uMzgNgQZyikJ+bwtW/PMCE W1SowraI0PWB7NxnDwvV7Ufh8bEZxBjcYqHSxThaznVIgNxHjZZ0LvG3jwbBMiKGGJyxyuM 6opHd7l3cZ2fgFcVp7IJA== Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 05 Jul 2013 17:15:58 -0000 * Paul Hoffman wrote: >Proposal 2 (prohibit unescaped surrogates): > >In section 1 (Introduction): > A string is a sequence of zero or more Unicode scalar values [UNICODE]. Section 1 describes the JSON data model and the proposed change would prohibit escaped unpaired surrogates, implying that something like JSON.stringify([ JSON.parse('["..."]')[0].substring(0, 140) ]); occasionally returns a string that is not JSON text, even if the input to `JSON.parse` is proper JSON text, when there is a non-BMP character in just the wrong place (`substring` counts UCS-2 code units). With JSON.stringify this can be avoided using a replace function like JSON.stringify(obj, function(key, value) { if (typeof value == 'string') { return value.replace(/.../g, "\uFFFD"); } return value; }) but then you have dataloss, unnecessarily so because you might just be putting an object into a datastore for later use and ecmascript doesn't mind unpaired surrogates, and the code is slower and harder to read. It seems pretty clear to me that decoders are a better place to deal with unpaired surrogate code points. In environments where they pose no problem you probably want them to roundtrip, in others substituting is a better option, and in yet others you might want to fail hard on them. Prohibiting unpaired surrogate escapes would place the burden to avoid them on senders, and I have not seen in argument why that is a better option, all things considered. -- 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 jorge@jorgechamorro.com Fri Jul 5 13:36: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 D0B8821F9F71 for ; Fri, 5 Jul 2013 13:36:40 -0700 (PDT) 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 Nu0JWhBGenvp for ; Fri, 5 Jul 2013 13:36:35 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id BE73021F9EE8 for ; Fri, 5 Jul 2013 13:36:34 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so2288218wgh.19 for ; Fri, 05 Jul 2013 13:36:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=SYY1Ng4gV9lyaUJNXpf2/rj2y3q8Hj9BLgFT0/6acss=; b=ONscuXROU0lwoYzi+Z0fDkQrh7TSv7u+aB6szE+vQCYdGzK0fE9zWWGtHIXXccKrOY fP8Kao6T/gMiuMoKNYJCas7SPM95CCh2LhhTf8OiYQzGjDBNvOUgBC31JAV8OhdzccVo QgRJcLTG6qYiAuwSzSO6B0P5QTckzf4AymU1jtKQs8UePN/RAaPtxnkWwt3j3juFLBAZ eGEcogTbNs/TBYvD/YsVsS6w86fJouO4JmBMWuK/Ou5+QutQIK6IErGsn3a1/D8nnWLg IVjaO9NvPHRWHdkfx/A2Qq/cwBny/4rTf7kr/Ru+hR9NnfIM9qlJAasT99mFLlg1q6zf s1fw== X-Received: by 10.180.102.37 with SMTP id fl5mr24259795wib.52.1373056593906; Fri, 05 Jul 2013 13:36:33 -0700 (PDT) Received: from [192.168.10.50] (142.Red-79-145-235.dynamicIP.rima-tde.net. [79.145.235.142]) by mx.google.com with ESMTPSA id u9sm11577647wif.6.2013.07.05.13.36.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 13:36:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge In-Reply-To: Date: Fri, 5 Jul 2013 22:36:29 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6B216380-37C5-46FF-8160-C20B356EF32F@jorgechamorro.com> References: To: Stephen Dolan X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnmLSNgn8KX9KAOoiencR4dhzr/ABFyZuCs5fm+UhGkfdN8EqQ1jC1eE2flKOVIecDyd6dQ Cc: Paul Hoffman , Joe Hildebrand , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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, 05 Jul 2013 20:36:40 -0000 On 05/07/2013, at 17:50, Stephen Dolan wrote: > "Javascript permits it" does not imply that JSON does or > should. But the built-in *JSON* in every current browser allows it: JSON.parse(JSON.stringify({a:'_\ud800_'})).a.charCodeAt(1).toString(16) "d800" -- ( Jorge )(); From James.H.Manger@team.telstra.com Sat Jul 6 06:43: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 4EF7D21F9BF9 for ; Sat, 6 Jul 2013 06:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_83=0.6, RELAY_IS_203=0.994] 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 lv-3vH8J22pR for ; Sat, 6 Jul 2013 06:43:41 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 423EF21F9BD8 for ; Sat, 6 Jul 2013 06:43:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,1009,1363093200"; d="scan'208";a="145218697" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 06 Jul 2013 23:43:30 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7127"; a="142699208" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcbvi.tcif.telstra.com.au with ESMTP; 06 Jul 2013 23:43:30 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Sat, 6 Jul 2013 23:43:29 +1000 From: "Manger, James H" To: Bjoern Hoehrmann , Paul Hoffman Date: Sat, 6 Jul 2013 23:43:28 +1000 Thread-Topic: [Json] Proposed minimal change for strings Thread-Index: Ac55o1OfLFkRXVvVSsCi5R/qLaBshQApGl8Q Message-ID: <255B9BB34FB7D647A506DC292726F6E1151C2C71BD@WSMSG3153V.srv.dir.telstra.com> References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> <00sdt8hmont8gqvams8qbuas6o9c32ap5o@hive.bjoern.hoehrmann.de> In-Reply-To: <00sdt8hmont8gqvams8qbuas6o9c32ap5o@hive.bjoern.hoehrmann.de> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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: Sat, 06 Jul 2013 13:43:47 -0000 PiAqIFBhdWwgSG9mZm1hbiB3cm90ZToNCj4gPlByb3Bvc2FsIDIgKHByb2hpYml0IHVuZXNjYXBl ZCBzdXJyb2dhdGVzKToNCj4gPg0KPiA+SW4gc2VjdGlvbiAxIChJbnRyb2R1Y3Rpb24pOg0KPiA+ ICBBIHN0cmluZyBpcyBhIHNlcXVlbmNlIG9mIHplcm8gb3IgbW9yZSBVbmljb2RlIHNjYWxhciB2 YWx1ZXMNCj4gW1VOSUNPREVdLg0KPiANCj4gU2VjdGlvbiAxIGRlc2NyaWJlcyB0aGUgSlNPTiBk YXRhIG1vZGVsIGFuZCB0aGUgcHJvcG9zZWQgY2hhbmdlIHdvdWxkDQo+IHByb2hpYml0IGVzY2Fw ZWQgdW5wYWlyZWQgc3Vycm9nYXRlcywgaW1wbHlpbmcgdGhhdCBzb21ldGhpbmcgbGlrZQ0KPiAN Cj4gICBKU09OLnN0cmluZ2lmeShbIEpTT04ucGFyc2UoJ1siLi4uIl0nKVswXS5zdWJzdHJpbmco MCwgMTQwKSBdKTsNCj4gDQo+IG9jY2FzaW9uYWxseSByZXR1cm5zIGEgc3RyaW5nIHRoYXQgaXMg bm90IEpTT04gdGV4dCwgZXZlbiBpZiB0aGUgaW5wdXQNCj4gdG8gYEpTT04ucGFyc2VgIGlzIHBy b3BlciBKU09OIHRleHQsIHdoZW4gdGhlcmUgaXMgYSBub24tQk1QIGNoYXJhY3Rlcg0KPiBpbiBq dXN0IHRoZSB3cm9uZyBwbGFjZSAoYHN1YnN0cmluZ2AgY291bnRzIFVDUy0yIGNvZGUgdW5pdHMp Lg0KPiANCj4gV2l0aCBKU09OLnN0cmluZ2lmeSB0aGlzIGNhbiBiZSBhdm9pZGVkIHVzaW5nIGEg cmVwbGFjZSBmdW5jdGlvbiBsaWtlDQo+IA0KPiAgIEpTT04uc3RyaW5naWZ5KG9iaiwgZnVuY3Rp b24oa2V5LCB2YWx1ZSkgew0KPiAgICAgaWYgKHR5cGVvZiB2YWx1ZSA9PSAnc3RyaW5nJykgew0K PiAgICAgICByZXR1cm4gdmFsdWUucmVwbGFjZSgvLi4uL2csICJcdUZGRkQiKTsNCj4gICAgIH0N Cj4gICAgIHJldHVybiB2YWx1ZTsNCj4gICB9KQ0KPiANCj4gYnV0IHRoZW4geW91IGhhdmUgZGF0 YWxvc3MsIHVubmVjZXNzYXJpbHkgc28gYmVjYXVzZSB5b3UgbWlnaHQganVzdCBiZQ0KPiBwdXR0 aW5nIGFuIG9iamVjdCBpbnRvIGEgZGF0YXN0b3JlIGZvciBsYXRlciB1c2UgYW5kIGVjbWFzY3Jp cHQgZG9lc24ndA0KPiBtaW5kIHVucGFpcmVkIHN1cnJvZ2F0ZXMsIGFuZCB0aGUgY29kZSBpcyBz bG93ZXIgYW5kIGhhcmRlciB0byByZWFkLg0KDQoNCkl0IGlzIG9ubHkgInVubmVjZXNzYXJ5IGRh dGFsb3NzIiB3aGVuIHlvdSBhcmUgY2VydGFpbiBhIHZhbHVlIHdpbGwgb25seSBiZSBoYW5kbGVk IGJ5IEVDTUFTY3JpcHQgLS0gaW4gd2hpY2ggY2FzZSByZWx5aW5nIG9uIEVDTUFTY3JpcHQncyAo cmVhc29uYWJsZSkgZXh0ZW5zaW9uIGJleW9uZCBKU09OIGlzIG9rLg0KT24gdGhlIG90aGVyIGhh bmQsIHdoYXQgaGFwcGVucyBpZiB0aGUgZGF0YXN0b3JlIHVuZGVyc3RhbmRzIEpTT04gYW5kIHRy aWVzIHRvIHN0b3JlIHRoZSBub24tZGF0YWxvc3MgdmFsdWVzIGFzIFVURi04PyBUaGF0IGlzIGxp a2VseSB0byBmYWlsLiBJbiB0aGlzIGNhc2UgImRhdGFsb3NzIiB0aGF0IHRoZSBhcHAgY29udHJv bHMgKGFuZCBjYW4gYXZvaWQgYnkgbm90IHNwbGl0dGluZyBhIG5vbi1CTVAgY2hhcmFjdGVyKSBp cyBtdWNoIGJldHRlciB0aGF0IHVucHJlZGljdGFibGUgYmVoYXZpb3VyICh3b3JrcyBvciBmYWls cykgZnJvbSBkaWZmZXJlbnQgSlNPTi1jb21wbGlhbnQgZGF0YXN0b3Jlcy4NCg0KDQo+IEl0IHNl ZW1zIHByZXR0eSBjbGVhciB0byBtZSB0aGF0IGRlY29kZXJzIGFyZSBhIGJldHRlciBwbGFjZSB0 byBkZWFsDQo+IHdpdGggdW5wYWlyZWQgc3Vycm9nYXRlIGNvZGUgcG9pbnRzLiBJbiBlbnZpcm9u bWVudHMgd2hlcmUgdGhleSBwb3NlIG5vDQo+IHByb2JsZW0geW91IHByb2JhYmx5IHdhbnQgdGhl bSB0byByb3VuZHRyaXAsIGluIG90aGVycyBzdWJzdGl0dXRpbmcgaXMNCj4gYSBiZXR0ZXIgb3B0 aW9uLCBhbmQgaW4geWV0IG90aGVycyB5b3UgbWlnaHQgd2FudCB0byBmYWlsIGhhcmQgb24gdGhl bS4NCj4gDQo+IFByb2hpYml0aW5nIHVucGFpcmVkIHN1cnJvZ2F0ZSBlc2NhcGVzIHdvdWxkIHBs YWNlIHRoZSBidXJkZW4gdG8gYXZvaWQNCj4gdGhlbSBvbiBzZW5kZXJzLCBhbmQgSSBoYXZlIG5v dCBzZWVuIGluIGFyZ3VtZW50IHdoeSB0aGF0IGlzIGEgYmV0dGVyDQo+IG9wdGlvbiwgYWxsIHRo aW5ncyBjb25zaWRlcmVkLg0KDQpJIHRoaW5rIHlvdXIgcHJldmlvdXMgcGFyYWdyYXBoIHByb3Zp ZGVzIHRoZSBhcmd1bWVudC4gSWYgZGlmZmVyZW50IGRlY29kZXJzIGNhbiBsZWdpdGltYXRlbHkg cm91bmR0cmlwLCBzdWJzdGl0dXRlLCBvciBmYWlsIG9uIHBhcnNpbmcgYW4gdW5wYWlyZWQgc3Vy cm9nYXRlIGVzY2FwZSB0aGFuIHNlbmRlcnMgbmVlZCB0byBiZSB3YXJuZWQgKGluIGJpZyBmbGFz aGluZyBsaWdodHMpIG9mIHRoaXMgbm9uLWludGVyb3BlcmFibGUgYmVoYXZpb3VyLiBUaGUgYmVz dCB3YXkgdG8gZG8gdGhhdCBpcyB0byBleGNsdWRlIHVucGFpcmVkIHN1cnJvZ2F0ZSBlc2NhcGVz IGZyb20gdGhlIHNwZWNpZmljYXRpb24gb2YgSlNPTi4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From derhoermi@gmx.net Sat Jul 6 07: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 5AD4321F9AA4 for ; Sat, 6 Jul 2013 07:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Nh8Di+k7FApr for ; Sat, 6 Jul 2013 07:47:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 45CF521F9BB1 for ; Sat, 6 Jul 2013 07:47:07 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.52.158]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MTSmp-1UodSc3Hc7-00SPdm; Sat, 06 Jul 2013 16:46:59 +0200 From: Bjoern Hoehrmann To: "Manger, James H" Date: Sat, 06 Jul 2013 16:46:55 +0200 Message-ID: References: <9BACB3F2-F9BF-40C7-B4BA-C0C2F33E4278@vpnc.org> <00sdt8hmont8gqvams8qbuas6o9c32ap5o@hive.bjoern.hoehrmann.de> <255B9BB34FB7D647A506DC292726F6E1151C2C71BD@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151C2C71BD@WSMSG3153V.srv.dir.telstra.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:tKiAMifxfYmvGfxqCTO9kIpj8yB2J2Zauc4l51BaFgJBgLXZWEy DP6OrutMRm8d3ZaQV2HXuGqvDogvh9QYG14KuE9GJwZBn7l0XsBztn/V3SnWuIGnFK2XbN/ AusJIR0H/TwaZj4C6eKhp9jozntzruDeDOeyy9Eq3L3abLDn6Y3YfssD14o2EZ+adTF5dqA h2qhBQg6UTfFpd+EQXZ+g== Cc: Paul Hoffman , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for strings 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: Sat, 06 Jul 2013 14:47:19 -0000 * Manger, James H wrote: >It is only "unnecessary dataloss" when you are certain a value will only >be handled by ECMAScript -- in which case relying on ECMAScript's >(reasonable) extension beyond JSON is ok. This is not an ecmascript-specific problem. Environments that can encode unpaired surrogates in the native string type are the norm; Perl can % perl -MJSON -e "print JSON->new->ascii->encode([chr(0xd800)])" ["\ud800"] and as far as I am aware so can Java, C#, C++, Python, and many others, and for many of them it is easy to create lone surrogates by accident. >I think your previous paragraph provides the argument. If different >decoders can legitimately roundtrip, substitute, or fail on parsing an >unpaired surrogate escape than senders need to be warned (in big >flashing lights) of this non-interoperable behaviour. The best way to do >that is to exclude unpaired surrogate escapes from the specification of >JSON. But receivers need to be warned that they will likely have to deal with JSON documents with unpaired surrogate escapes in strings, and the best way to do that is to include them 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 ietf@augustcellars.com Sat Jul 6 16:19: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 C2F6A21F98AC for ; Sat, 6 Jul 2013 16:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 zYNGPyLtcrNu for ; Sat, 6 Jul 2013 16:19:19 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E05C21F965B for ; Sat, 6 Jul 2013 16:19:18 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id AE76F2CA12; Sat, 6 Jul 2013 16:19:16 -0700 (PDT) From: "Jim Schaad" To: "'John Cowan'" , "'Pete Resnick'" References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> In-Reply-To: <20130703201143.GL32044@mercury.ccil.org> Date: Sat, 6 Jul 2013 16:18:17 -0700 Message-ID: <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJvUTXGqIW3iuu0l9rzv3fxldJ4PQL8G24kAqTixrQBjIQJ6gH4Oee+l81ZmFA= Content-Language: en-us Cc: 'Nico Williams' , 'Paul Hoffman' , 'Eliot Lear' , json@ietf.org Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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: Sat, 06 Jul 2013 23:19:23 -0000 And the JOSE working group. > -----Original Message----- > From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of > John Cowan > Sent: Wednesday, July 03, 2013 1:12 PM > To: Pete Resnick > Cc: Nico Williams; Paul Hoffman; Eliot Lear; json@ietf.org WG > Subject: Re: [Json] Proposed minimal change for duplicate names in objects > > Pete Resnick scripsit: > > > So I don't think saying RECOMMENDED or SHOULD regarding not > producing > > duplicates should be seen as a non-starter. That's a defensible > > position for the WG to take. > > +1. The only person saying otherwise right now is Tim, and he grants > that he is only concerned with a single use case. > > -- > Overhead, without any fuss, the stars were going out. > --Arthur C. Clarke, "The Nine Billion Names of God" > John Cowan > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From ietf@augustcellars.com Sat Jul 6 17:14: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 26A3521F9346 for ; Sat, 6 Jul 2013 17:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 UZ+YYEAoBOdB for ; Sat, 6 Jul 2013 17:14:25 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E96621F8BB7 for ; Sat, 6 Jul 2013 17:14:25 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 888C12CA09; Sat, 6 Jul 2013 17:14:22 -0700 (PDT) From: "Jim Schaad" To: "'John Cowan'" , "'Pete Resnick'" References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> In-Reply-To: <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> Date: Sat, 6 Jul 2013 17:13:22 -0700 Message-ID: <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJvUTXGqIW3iuu0l9rzv3fxldJ4PQL8G24kAqTixrQBjIQJ6gH4Oee+ATLeuAaXw+X7wA== Content-Language: en-us Cc: 'Nico Williams' , 'Paul Hoffman' , 'Eliot Lear' , json@ietf.org Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 00:14:30 -0000 Further clarification (on request) Tim is not the only person saying this. The JOSE working group has this as a requirement to be enforced in the documents it is producing. Specification that JOSE objects MUST fail validation if there are duplicate names in an object. > -----Original Message----- > From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of > Jim Schaad > Sent: Saturday, July 06, 2013 4:18 PM > To: 'John Cowan'; 'Pete Resnick' > Cc: 'Nico Williams'; 'Paul Hoffman'; 'Eliot Lear'; json@ietf.org > Subject: Re: [Json] Proposed minimal change for duplicate names in objects > > And the JOSE working group. > > > -----Original Message----- > > From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf > > Of John Cowan > > Sent: Wednesday, July 03, 2013 1:12 PM > > To: Pete Resnick > > Cc: Nico Williams; Paul Hoffman; Eliot Lear; json@ietf.org WG > > Subject: Re: [Json] Proposed minimal change for duplicate names in > > objects > > > > Pete Resnick scripsit: > > > > > So I don't think saying RECOMMENDED or SHOULD regarding not > > producing > > > duplicates should be seen as a non-starter. That's a defensible > > > position for the WG to take. > > > > +1. The only person saying otherwise right now is Tim, and he grants > > that he is only concerned with a single use case. > > > > -- > > Overhead, without any fuss, the stars were going out. > > --Arthur C. Clarke, "The Nine Billion Names of God" > > John Cowan > > _______________________________________________ > > 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 nico@cryptonector.com Sat Jul 6 18:20:28 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 7BE0A21F9A4A for ; Sat, 6 Jul 2013 18:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.021, 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 YNX0v6UxQY+N for ; Sat, 6 Jul 2013 18:20:23 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8B55721F9980 for ; Sat, 6 Jul 2013 18:20:23 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 033341F007C for ; Sat, 6 Jul 2013 18:20:23 -0700 (PDT) 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=ph6UsZXYpsJlpU2kFOue 5fMGvx0=; b=l6Lubt9MVqrABpRo7eJK9r5fS8ejVjPm5MbTtZeyFoZJaZSFvH2/ UWKmCqfDX2fWlVhnW/fNFw79fn1Y2TQXvANI/5P5m9MyiOgBRyfnX9Jqn13Li6OG mPMtYMyp9YH5s2o/ICJvszoS/z2hhIBBuXc3rVbXRabrARZv9QIyXBE= Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 9D2931F0081 for ; Sat, 6 Jul 2013 18:20:22 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so2790272wes.20 for ; Sat, 06 Jul 2013 18:20:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Cv3ofJIz8fp1gruHKWWaclGJMtTKthqCZ3aK/tkN14=; b=ajMFIravGuVgmL/BgnbuHuK0vpq2NpxXY5LwmE7lcjAEdPEBl6m5fI5qC20uQyNoWF Uk3FuEMNXG7JVQ77Ck2KZ0TWSlqrytQ2TK+hQXtMQDXJO3kI7WVSBm6o0MIpZcv5UsXc KrzFRRUKpR+BBoZCllKdBWr4SEM4ot+OUnVOL3XXHTQhGjfiiyzyp/Yl3Q0p/A3HznXk U4blEXB60AcBukRpCLI+PDeqpf7Hwt/uHBbVQsE+YI3ysMMf+vnyDHtABNY8sro4IgIz SfeFs5xwbR9fXSD858Yea43r9HJnafbbvavaY/1faZK0ZN009b0IwKReRF3VD05n44BZ d1hA== MIME-Version: 1.0 X-Received: by 10.180.210.148 with SMTP id mu20mr26072776wic.38.1373160020760; Sat, 06 Jul 2013 18:20:20 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Sat, 6 Jul 2013 18:20:20 -0700 (PDT) In-Reply-To: <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> Date: Sat, 6 Jul 2013 20:20:20 -0500 Message-ID: From: Nico Williams To: json@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: Jim Schaad Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 01:20:28 -0000 On Sat, Jul 6, 2013 at 7:13 PM, Jim Schaad wrote: > Tim is not the only person saying this. The JOSE working group has this as > a requirement to be enforced in the documents it is producing. > Specification that JOSE objects MUST fail validation if there are duplicate > names in an object. But does it follow (did you even mean to say) that since JOSE wants requirement X (no dup names here) JSON should have it itself? One might argue that otherwise JOSE implementations would have to use JSON parsers that implement JOSE's requirement even though JSON doesn't have the same requirement. But then. JOSE implementations also could use streaming JSON parsers and check for dup names themselves. So I don't think JOSE's requirement adds anything new to the discussion. We still need to decide (directly or indirectly) whether to impose dup name checking on all JSON parsers, even minimal-state streaming parsers, whether we want to impose a requirement on the parser and the application (so we need not mention streaming), or on the parser if it's not a streaming parser *and* the application if the parser is streaming. My view (for whatever it counts) is that we don't have consensus [yet] for imposing a requirement on parsers to reject objects with dup names. We've had at least a number of examples of streaming parsers that cannot implement such a requirement -- the whole point of streaming being nullified by state-keeping requirements like this one. So we'd have to explicitly decide that we don't want to allow minimal state streaming parsers. Might as well call for consensus on that. Nico -- From tbray@textuality.com Sat Jul 6 18:44: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 EAA7F21F9D8E for ; Sat, 6 Jul 2013 18:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[AWL=0.109, 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 blZZeh5IZnEU for ; Sat, 6 Jul 2013 18:44:10 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 160BA21F9C4D for ; Sat, 6 Jul 2013 18:44:09 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ha12so2503585vcb.35 for ; Sat, 06 Jul 2013 18:44:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=HpdZ4gDsO3sY9Yd1Q8n0y396xT/1nVEb6fz8A4Wwyk8=; b=mosCwdq0wVi4Ion6Fde3JkoprHB3w9c2zVmKmB9pPK0hxLet6IW7NpnZgBoRKLZa/b qJM8oe6mJr1UskLJnepnMzE9yqjH79+SVowtYInq0a0838BXD6svN3TLhjtDd3AS7bsx BJewtEG6pIJC94LNJbk7QSmE+TVWRUUeiFSEr7LIC1YJs/gwBTU0cbsXu2yNXvvga1zv jmez3+jdLxSrB0Kf6wAc8kz6UcpRJWfSuDZwHrWjZ/739Erietb69/ZlF3pOjOKhyroV bpiyoAVRau9WZDHUtS15wuQ3IQfghWEPHBPmfwdCaFYicpzrOK7zCg1yc26BTNad3T2L 1Tlw== MIME-Version: 1.0 X-Received: by 10.221.64.18 with SMTP id xg18mr11000911vcb.57.1373161448109; Sat, 06 Jul 2013 18:44:08 -0700 (PDT) Received: by 10.220.164.7 with HTTP; Sat, 6 Jul 2013 18:44:07 -0700 (PDT) X-Originating-IP: [209.121.225.191] In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> Date: Sat, 6 Jul 2013 18:44:07 -0700 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=001a11331c08558aab04e0e21021 X-Gm-Message-State: ALoCoQleeLObqECdSewjUR8hx+rojHHafexGKn777dhBjV9mEnLgx+YR/MFQk5hw0tcG8cxMPBHF Cc: Jim Schaad , "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 01:44:15 -0000 --001a11331c08558aab04e0e21021 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This feels like a no-brainer to me, but that=E2=80=99s probably because (as= I=E2=80=99ve said before) I=E2=80=99m an API guy, and the only use for JSON objects in m= y world is to transfer a hash table or database record or whatever from here to there, and there, and in such a situation dupes can never be useful or intended and can only be a symptom of breakage (or, in the JOSE case, a symptom of a malicious attack on my crypto). -Tim On Sat, Jul 6, 2013 at 6:20 PM, Nico Williams wrote= : > On Sat, Jul 6, 2013 at 7:13 PM, Jim Schaad wrote= : > > Tim is not the only person saying this. The JOSE working group has thi= s > as > > a requirement to be enforced in the documents it is producing. > > Specification that JOSE objects MUST fail validation if there are > duplicate > > names in an object. > > But does it follow (did you even mean to say) that since JOSE wants > requirement X (no dup names here) JSON should have it itself? > > One might argue that otherwise JOSE implementations would have to use > JSON parsers that implement JOSE's requirement even though JSON > doesn't have the same requirement. But then. JOSE implementations > also could use streaming JSON parsers and check for dup names > themselves. So I don't think JOSE's requirement adds anything new to > the discussion. > > We still need to decide (directly or indirectly) whether to impose dup > name checking on all JSON parsers, even minimal-state streaming > parsers, whether we want to impose a requirement on the parser and the > application (so we need not mention streaming), or on the parser if > it's not a streaming parser *and* the application if the parser is > streaming. > > My view (for whatever it counts) is that we don't have consensus [yet] > for imposing a requirement on parsers to reject objects with dup > names. We've had at least a number of examples of streaming parsers > that cannot implement such a requirement -- the whole point of > streaming being nullified by state-keeping requirements like this one. > So we'd have to explicitly decide that we don't want to allow minimal > state streaming parsers. Might as well call for consensus on that. > > Nico > -- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11331c08558aab04e0e21021 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This feels like a no-brainer to me, but that=E2=80=99= s probably because (as I=E2=80=99ve said before) I=E2=80=99m an API guy, an= d the only use for JSON objects in my world is to transfer a hash table or = database record or whatever from here to there, and there, and in such a si= tuation dupes can never be useful or intended and can only be a symptom of = breakage (or, in the JOSE case, a symptom of a malicious attack on my crypt= o).

-Tim


On Sat, Jul 6, 2013 at 6:20 PM, Nico Williams <n= ico@cryptonector.com> wrote:
On Sat, Jul 6, 2013 at 7:1= 3 PM, Jim Schaad <ietf@augustc= ellars.com> wrote:
> Tim is not the only person saying this. =C2=A0The JOSE working group h= as this as
> a requirement to be enforced in the documents it is producing.
> Specification that JOSE objects MUST fail validation if there are dupl= icate
> names in an object.

But does it follow (did you even mean to say) that since JOSE wants requirement X (no dup names here) JSON should have it itself?

One might argue that otherwise JOSE implementations would have to use
JSON parsers that implement JOSE's requirement even though JSON
doesn't have the same requirement. =C2=A0But then. JOSE implementations=
also could use streaming JSON parsers and check for dup names
themselves. =C2=A0So I don't think JOSE's requirement adds anything= new to
the discussion.

We still need to decide (directly or indirectly) whether to impose dup
name checking on all JSON parsers, even minimal-state streaming
parsers, whether we want to impose a requirement on the parser and the
application (so we need not mention streaming), or on the parser if
it's not a streaming parser *and* the application if the parser is
streaming.

My view (for whatever it counts) is that we don't have consensus [yet]<= br> for imposing a requirement on parsers to reject objects with dup
names. =C2=A0We've had at least a number of examples of streaming parse= rs
that cannot implement such a requirement -- the whole point of
streaming being nullified by state-keeping requirements like this one.
=C2=A0So we'd have to explicitly decide that we don't want to allow= minimal
state streaming parsers. =C2=A0Might as well call for consensus on that.
Nico
--
___________________________________= ____________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11331c08558aab04e0e21021-- From nico@cryptonector.com Sat Jul 6 19:57: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 50ADE21F9DF0 for ; Sat, 6 Jul 2013 19:57:59 -0700 (PDT) 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=[AWL=-0.000, 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 WzMsIPE4b2AB for ; Sat, 6 Jul 2013 19:57:54 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4D421F9DCC for ; Sat, 6 Jul 2013 19:57:54 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id E7903678058 for ; Sat, 6 Jul 2013 19:57:53 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=BHlVcdw5zrJg6d12j3Jnw8Qd6Sw=; b=lI9lH2eiohw CH1onGA9fVVInRx7MeVwd3th1JhebqM2quXXVe32vLtfSJCQ0ujBQ/+5PZnOxC9W JSOC/tPFL3touTq0CG6nXrjhlTxIWul8I3Ix1FWpluNrMsBUa3tkXgpOJ4pG2j09 acbCbz1L7xt3errBG6ty+FUosom1n1rs= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 9E26D678057 for ; Sat, 6 Jul 2013 19:57:53 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so3046809wiv.11 for ; Sat, 06 Jul 2013 19:57:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=p+ZZCUFwMuSDeiNRMHtp5rbw11VVH6lxWqIM0nflyAY=; b=I+sC1ock9pPdN934pym8axZM0fmqs/KPpQNsyQSaPdwEiuylyafwTQciqNu5DSdcNQ hlpn9hEx9ZYRZ11Dug5aNCp/6e15CyxBoRLW8XPHeanLVBdo/ahLlqz3V6ELJiz4shEG UxDGqiul9qKHtib/rnwwev/GvMqNRY/EM9alOHrpemmpvJg+MPQFvqBN/kEd4VRBeuyw 55zMXoWgRznbS8RvbjTV5IkykQnzfeCS2vK7q7M21n6bavfRj4iBYppfiJxaXbTn2W0j LhDYSmHHyAFN4PjBniW84OpIJ0zGR7CPNq7T0LFYhGDda7vLr/tZQmvNrhE1HszjMPfW yw8Q== MIME-Version: 1.0 X-Received: by 10.194.7.137 with SMTP id j9mr9481429wja.11.1373165872139; Sat, 06 Jul 2013 19:57:52 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Sat, 6 Jul 2013 19:57:52 -0700 (PDT) In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> Date: Sat, 6 Jul 2013 21:57:52 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jim Schaad , "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 02:57:59 -0000 On Sat, Jul 6, 2013 at 8:44 PM, Tim Bray wrote: > This feels like a no-brainer to me, but that=E2=80=99s probably because (= as I=E2=80=99ve > said before) I=E2=80=99m an API guy, and the only use for JSON objects in= my world > is to transfer a hash table or database record or whatever from here to > there, and there, and in such a situation dupes can never be useful or > intended and can only be a symptom of breakage (or, in the JOSE case, a > symptom of a malicious attack on my crypto). I agree. As a security guy I would prefer if one way or another we end up with no dup names, but as an "API guy" myself I think of the streaming parsers (they offer an API after all). Just say the magic words: "to hell with minimal state streaming parsers" or perhaps something to the effect that *some* component of a layered application MUST reject objects with dup names. It's either or. Let's choose. I'm happy with "some component of a layered application MUST reject objects with duplicate names" -- I prefer this to the "no minimal state streaming parsers" alternative. I will assume that in general objects rarely have lots of names, so that parsers need not keep that much state in order to check for dups. Requiring parsers to reject objects with dup names is my second choice. Nico -- From tsaloranta@gmail.com Sat Jul 6 21:37: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 6E64021F9CE8 for ; Sat, 6 Jul 2013 21:37:21 -0700 (PDT) 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, 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 ZZ4gMcu8J2jI for ; Sat, 6 Jul 2013 21:37:20 -0700 (PDT) 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 3B56821F9D4B for ; Sat, 6 Jul 2013 21:37:20 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so8155443wib.0 for ; Sat, 06 Jul 2013 21:37:19 -0700 (PDT) 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=mfqiKCFR+GiMzeu8Plk1WGZI21Qq9huDKX+lUZPvu4Q=; b=ksbN1tq8XLNQpyakn3cxhAzri2yzmzvWgBQp4TMDxxCLGSE1vrCzabiebdUyIRk5eC oEhrRsGqEpZk6NnrmF80q5LzxPgONjPOyymuYv8cpLo9ZlvFX93knKWuBMsu9nIUV01p zBiZGz6pcjxDm9aRtDfwXddcsjhaulpl+wMhEGjEXfssU2to4M/xe6191+bEwXnf7Yeu HBGh+3fRYAslP1VvOtU7fxx9qsHthfdlMbI17l6SFD1Zw7hXjin8DlRr3QWkgRgnSkfO VFIn2RNLJnoLiTEm6H/JzfBqMZ4e1e9kp3sE7RWJ5t96Ly8LHIGN+hgsYO1b0TV463bn tHRw== MIME-Version: 1.0 X-Received: by 10.194.179.129 with SMTP id dg1mr9619496wjc.38.1373171839392; Sat, 06 Jul 2013 21:37:19 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Sat, 6 Jul 2013 21:37:19 -0700 (PDT) In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> Date: Sat, 6 Jul 2013 21:37:19 -0700 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=089e013d194eb3e1a204e0e47bad Cc: Jim Schaad , Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 04:37:21 -0000 --089e013d194eb3e1a204e0e47bad Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sat, Jul 6, 2013 at 7:57 PM, Nico Williams wrote= : > On Sat, Jul 6, 2013 at 8:44 PM, Tim Bray wrote: > > This feels like a no-brainer to me, but that=92s probably because (as I= =92ve > > said before) I=92m an API guy, and the only use for JSON objects in my > world > > is to transfer a hash table or database record or whatever from here to > > there, and there, and in such a situation dupes can never be useful or > > intended and can only be a symptom of breakage (or, in the JOSE case, a > > symptom of a malicious attack on my crypto). > > I agree. As a security guy I would prefer if one way or another we > end up with no dup names, but as an "API guy" myself I think of the > streaming parsers (they offer an API after all). Just say the magic > words: "to hell with minimal state streaming parsers" or perhaps > something to the effect that *some* component of a layered application > MUST reject objects with dup names. It's either or. Let's choose. > > I'm happy with "some component of a layered application MUST reject > objects with duplicate names" -- I prefer this to the "no minimal > state streaming parsers" alternative. > > I will assume that in general objects rarely have lots of names, so > that parsers need not keep that much state in order to check for dups. > Requiring parsers to reject objects with dup names is my second > choice. > Just to make sure: I also do not have any use for duplicates, and consider them flaws in processing. I have never used duplicates for anything, nor find that interesting approach. The only concern really is that of mandating (or not) detection and/or prevention at lowest level components of commonly used processing stacks (low-level push/pull parser, higher-level library or app code that builds full representations), since this is significant cost, based on extensive profiling I have done at this level. Case of application code directly using streaming parser/generators is not nearly as common as that of frameworks using them to produce higher level abstractions. These higher level abstraction (JSON tree representation, binding to native objects) do either report errors such as duplicates, and at very least can detect it and use consistent handling. They can do it much more efficiently than low-level components since they have to build representations that then serve as data structures for detecting/preventing duplicates. Specific concern for me is this: if specification mandates detection and/or prevention for parser, generators, without any mention that 'parser' and 'generator' are logical concepts (thing that reads JSON, thing that writes JSON), I will have lots of users who promptly demand low-level components to force checks. And then I get to spend lots of time discussing why such checks can (and IMO should) still be pushed to higher level of processing. It is amazing how much FUD can be generated based on cursory reading of specifications. This concern extends to suggested "Internet JSON messages" specification. I would like simple suggestion that some component of the processing should/must detect and report duplicates; and prevent producing of same; or, lengthier explanation of what "parser" and "generator" mean (parser is such a horrible misnomer -- there is very very little parsing involved, it's just a lexer, and optional object builder -- but I digress). -+ Tatu +- --089e013d194eb3e1a204e0e47bad Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 6, 2013 at 7:57 PM, Nico Williams <nico@c= ryptonector.com> wrote:
On Sat,= Jul 6, 2013 at 8:44 PM, Tim Bray <tbray@textuality.com> wrote:
> This feels like a no-brainer to me, but that=92s probably because (as = I=92ve
> said before) I=92m an API guy, and the only use for JSON objects in my= world
> is to transfer a hash table or database record or whatever from here t= o
> there, and there, and in such a situation dupes can never be useful or=
> intended and can only be a symptom of breakage (or, in the JOSE case, = a
> symptom of a malicious attack on my crypto).

I agree. =A0As a security guy I would prefer if one way or another we=
end up with no dup names, but as an "API guy" myself I think of t= he
streaming parsers (they offer an API after all). =A0Just say the magic
words: "to hell with minimal state streaming parsers" or perhaps<= br> something to the effect that *some* component of a layered application
MUST reject objects with dup names. =A0It's either or. =A0Let's cho= ose.

I'm happy with "some component of a layered application MUST rejec= t
objects with duplicate names" -- I prefer this to the "no minimal=
state streaming parsers" alternative.

I will assume that in general objects rarely have lots of names, so
that parsers need not keep that much state in order to check for dups.
=A0Requiring parsers to reject objects with dup names is my second
choice.

Just to make sure: I also do no= t have any use for duplicates, and consider them flaws in processing. I hav= e never used duplicates for anything, nor find that interesting approach.
The only concern really is that of mandating (or not) detection = and/or prevention at lowest level components of commonly used processing st= acks (low-level push/pull parser, higher-level library or app code that bui= lds full representations), since this is significant cost, based on extensi= ve profiling I have done at this level.

Case of application code directly using streaming parser/gen= erators is not nearly as common as that of frameworks using them to produce= higher level abstractions.
These higher level abstraction (J= SON tree representation, binding to native objects) do either report errors= such as duplicates, and at very least can detect it and use consistent han= dling. They can do it much more efficiently than low-level components since= they have to build representations that then serve as data structures for = detecting/preventing duplicates.

Specific concern for me is this: if specification mandates detect= ion and/or prevention for parser, generators, without any mention that '= ;parser' and 'generator' are logical concepts (thing that reads= JSON, thing that writes JSON), I will have lots of users who promptly dema= nd low-level components to force checks.
And then I get to spend lots of time discussing why such checks can (= and IMO should) still be pushed to higher level of processing. It is amazin= g how much FUD can be generated based on cursory reading of specifications.=

This concern extends to suggested &quo= t;Internet JSON messages" specification.

I would like simple suggestion = that some component of the processing should/must detect and report duplica= tes; and prevent producing of same; or, lengthier explanation of what "= ;parser" and "generator" mean (parser is such a horrible mis= nomer -- there is very very little parsing involved, it's just a lexer,= and optional object builder -- but I digress).

-+ Tatu +-

--089e013d194eb3e1a204e0e47bad-- From tbray@textuality.com Sat Jul 6 21:58: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 BB84621F9DB6 for ; Sat, 6 Jul 2013 21:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.878 X-Spam-Level: X-Spam-Status: No, score=-2.878 tagged_above=-999 required=5 tests=[AWL=0.098, 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 K9AwIarYP84i for ; Sat, 6 Jul 2013 21:58:25 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id ACEC421F9D90 for ; Sat, 6 Jul 2013 21:58:25 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id ox1so2683380veb.41 for ; Sat, 06 Jul 2013 21:58:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=1WAsLWLm4p340eVe/bAEG4u8RCB1+3NkGy03+3j9ND8=; b=lrwVKVvRGAK7Z0Cnc4nyQzj0w5uTzRX2XUGaxY/gmbJkukpPY/vb4pTJZZtLbOjgRs zL2bJasBQsi08wI2Z0dLFPZ+SvzHoTQ7ZQDRMKY//Ug4aehYp12nNH+cnuyxfl/bmGGA tp3iX1qCGNRF2G/DQPM/mS5sSNk2fTEvIya9INp0Su6Lwn8kNc+ju70g7Drd6qU85xOD V8CKdQwbjnNQYYFAqGfqCeGH3KUB4EUoxBSnq6BLeJpV1q6WNI2tywVE7vPfxdBByTek ef9KmnvwUQUsUwRBGpn+42qNpNfCrYXWFecA76v5myCevxJ/QhD/vpXcjHDbcOs3Ad08 nwog== MIME-Version: 1.0 X-Received: by 10.52.90.115 with SMTP id bv19mr9234647vdb.108.1373173104769; Sat, 06 Jul 2013 21:58:24 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Sat, 6 Jul 2013 21:58:24 -0700 (PDT) X-Originating-IP: [209.121.225.191] In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> Date: Sat, 6 Jul 2013 21:58:24 -0700 Message-ID: From: Tim Bray To: Tatu Saloranta Content-Type: multipart/alternative; boundary=20cf307f38de200ff404e0e4c7cc X-Gm-Message-State: ALoCoQk1UPCcfYtJa7OxUC79R2ycAzs9JbdhPgUxhMC/xj73RpFLLgfU94eUiKa425ga76zRAl5n Cc: Nico Williams , Jim Schaad , "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 04:58:31 -0000 --20cf307f38de200ff404e0e4c7cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99ll assume you=E2=80=99re right when you say dupe detection has be= en measured as expensive at run time, but I=E2=80=99m thinking that if I were writing a re= ader I'd implement a hash table with a test-and-set method, so I admit I'm surprised by the finding. I think I=E2=80=99d need to see a little more research bef= ore I=E2=80=99d accept that as a given. -T On Sat, Jul 6, 2013 at 9:37 PM, Tatu Saloranta wrote= : > On Sat, Jul 6, 2013 at 7:57 PM, Nico Williams wrot= e: > >> On Sat, Jul 6, 2013 at 8:44 PM, Tim Bray wrote: >> > This feels like a no-brainer to me, but that=E2=80=99s probably becaus= e (as I=E2=80=99ve >> > said before) I=E2=80=99m an API guy, and the only use for JSON objects= in my >> world >> > is to transfer a hash table or database record or whatever from here t= o >> > there, and there, and in such a situation dupes can never be useful or >> > intended and can only be a symptom of breakage (or, in the JOSE case, = a >> > symptom of a malicious attack on my crypto). >> >> I agree. As a security guy I would prefer if one way or another we >> end up with no dup names, but as an "API guy" myself I think of the >> streaming parsers (they offer an API after all). Just say the magic >> words: "to hell with minimal state streaming parsers" or perhaps >> something to the effect that *some* component of a layered application >> MUST reject objects with dup names. It's either or. Let's choose. >> >> I'm happy with "some component of a layered application MUST reject >> objects with duplicate names" -- I prefer this to the "no minimal >> state streaming parsers" alternative. >> >> I will assume that in general objects rarely have lots of names, so >> that parsers need not keep that much state in order to check for dups. >> Requiring parsers to reject objects with dup names is my second >> choice. >> > > Just to make sure: I also do not have any use for duplicates, and conside= r > them flaws in processing. I have never used duplicates for anything, nor > find that interesting approach. > The only concern really is that of mandating (or not) detection and/or > prevention at lowest level components of commonly used processing stacks > (low-level push/pull parser, higher-level library or app code that builds > full representations), since this is significant cost, based on extensive > profiling I have done at this level. > > Case of application code directly using streaming parser/generators is no= t > nearly as common as that of frameworks using them to produce higher level > abstractions. > These higher level abstraction (JSON tree representation, binding to > native objects) do either report errors such as duplicates, and at very > least can detect it and use consistent handling. They can do it much more > efficiently than low-level components since they have to build > representations that then serve as data structures for detecting/preventi= ng > duplicates. > > Specific concern for me is this: if specification mandates detection > and/or prevention for parser, generators, without any mention that 'parse= r' > and 'generator' are logical concepts (thing that reads JSON, thing that > writes JSON), I will have lots of users who promptly demand low-level > components to force checks. > And then I get to spend lots of time discussing why such checks can (and > IMO should) still be pushed to higher level of processing. It is amazing > how much FUD can be generated based on cursory reading of specifications. > > This concern extends to suggested "Internet JSON messages" specification. > > I would like simple suggestion that some component of the processing > should/must detect and report duplicates; and prevent producing of same; > or, lengthier explanation of what "parser" and "generator" mean (parser i= s > such a horrible misnomer -- there is very very little parsing involved, > it's just a lexer, and optional object builder -- but I digress). > > -+ Tatu +- > > --20cf307f38de200ff404e0e4c7cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99ll assume you=E2=80=99re right when you say dupe= detection has been measured as expensive at run time, but I=E2=80=99m thin= king that if I were writing a reader I'd implement a hash table with a = test-and-set method, so I admit I'm surprised by the finding.=C2=A0 I t= hink I=E2=80=99d need to see a little more research before I=E2=80=99d acce= pt that as a given.=C2=A0 -T


On Sat,= Jul 6, 2013 at 9:37 PM, Tatu Saloranta <tsaloranta@gmail.com> wrote:
On S= at, Jul 6, 2013 at 7:57 PM, Nico Williams <nico@cryptonector.com&g= t; wrote:
On Sat, Jul 6, 2013 = at 8:44 PM, Tim Bray <tbray@textuality.com> wrote:
> This feels like a no-brainer to me, but that=E2=80=99s probably becaus= e (as I=E2=80=99ve
> said before) I=E2=80=99m an API guy, and the only use for JSON objects= in my world
> is to transfer a hash table or database record or whatever from here t= o
> there, and there, and in such a situation dupes can never be useful or=
> intended and can only be a symptom of breakage (or, in the JOSE case, = a
> symptom of a malicious attack on my crypto).

I agree. =C2=A0As a security guy I would prefer if one way or another= we
end up with no dup names, but as an "API guy" myself I think of t= he
streaming parsers (they offer an API after all). =C2=A0Just say the magic words: "to hell with minimal state streaming parsers" or perhaps<= br> something to the effect that *some* component of a layered application
MUST reject objects with dup names. =C2=A0It's either or. =C2=A0Let'= ;s choose.

I'm happy with "some component of a layered application MUST rejec= t
objects with duplicate names" -- I prefer this to the "no minimal=
state streaming parsers" alternative.

I will assume that in general objects rarely have lots of names, so
that parsers need not keep that much state in order to check for dups.
=C2=A0Requiring parsers to reject objects with dup names is my second
choice.

Just to make sure: = I also do not have any use for duplicates, and consider them flaws in proce= ssing. I have never used duplicates for anything, nor find that interesting= approach.
The only concern really is that of mandating (or not) detection = and/or prevention at lowest level components of commonly used processing st= acks (low-level push/pull parser, higher-level library or app code that bui= lds full representations), since this is significant cost, based on extensi= ve profiling I have done at this level.

Case of application code directly using streaming parser/gen= erators is not nearly as common as that of frameworks using them to produce= higher level abstractions.
These higher level abstraction (J= SON tree representation, binding to native objects) do either report errors= such as duplicates, and at very least can detect it and use consistent han= dling. They can do it much more efficiently than low-level components since= they have to build representations that then serve as data structures for = detecting/preventing duplicates.

Specific concern for me is this: if specification mandates detect= ion and/or prevention for parser, generators, without any mention that '= ;parser' and 'generator' are logical concepts (thing that reads= JSON, thing that writes JSON), I will have lots of users who promptly dema= nd low-level components to force checks.
And then I get to spend lots of time discussing why such checks can (= and IMO should) still be pushed to higher level of processing. It is amazin= g how much FUD can be generated based on cursory reading of specifications.=

This concern extends to suggested &quo= t;Internet JSON messages" specification.

I would like simple suggestion = that some component of the processing should/must detect and report duplica= tes; and prevent producing of same; or, lengthier explanation of what "= ;parser" and "generator" mean (parser is such a horrible mis= nomer -- there is very very little parsing involved, it's just a lexer,= and optional object builder -- but I digress).

-+ Tatu +-


--20cf307f38de200ff404e0e4c7cc-- From ietf@augustcellars.com Sat Jul 6 22:45: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 960E421F9AAC for ; Sat, 6 Jul 2013 22:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 Iwca7vD5VZ1L for ; Sat, 6 Jul 2013 22:45:09 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id B815621F9A23 for ; Sat, 6 Jul 2013 22:45:09 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 112A438EF1; Sat, 6 Jul 2013 22:45:07 -0700 (PDT) From: "Jim Schaad" To: "'Nico Williams'" , References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> In-Reply-To: Date: Sat, 6 Jul 2013 22:44:08 -0700 Message-ID: <00e401ce7ad5$00991c20$01cb5460$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJvUTXGqIW3iuu0l9rzv3fxldJ4PQL8G24kAqTixrQBjIQJ6gH4Oee+ATLeuAYCdtMjrQKGcuyml5xXbxA= Content-Language: en-us Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 05:45:15 -0000 To be perfectly honest, I would personally argue that this is a = requirement that parsers need to enforce. The JOSE group is going to = need some interesting text about what happens if it is using a parser = that does not enforce this mechanism. And an even more interesting = question of how this would ever be determined if the parser is not part = of the application itself. That is how does a JOSE application know = that the built in (assuming there is one) parser for the FOO = language/environment it is operating in will correctly do the detection = for it and not use the rule of grab the last value. I would also be open to the argument that a streaming parser is not = really an entire parser and the thing that consumes the output of a = streaming parser could be the entity that enforces the uniqueness = requirement. =20 Jim > -----Original Message----- > From: Nico Williams [mailto:nico@cryptonector.com] > Sent: Saturday, July 06, 2013 6:20 PM > To: json@ietf.org > Cc: Jim Schaad > Subject: Re: [Json] Proposed minimal change for duplicate names in = objects >=20 > On Sat, Jul 6, 2013 at 7:13 PM, Jim Schaad = wrote: > > Tim is not the only person saying this. The JOSE working group has > > this as a requirement to be enforced in the documents it is = producing. > > Specification that JOSE objects MUST fail validation if there are > > duplicate names in an object. >=20 > But does it follow (did you even mean to say) that since JOSE wants > requirement X (no dup names here) JSON should have it itself? >=20 > One might argue that otherwise JOSE implementations would have to use > JSON parsers that implement JOSE's requirement even though JSON = doesn't > have the same requirement. But then. JOSE implementations also could = use > streaming JSON parsers and check for dup names themselves. So I don't > think JOSE's requirement adds anything new to the discussion. >=20 > We still need to decide (directly or indirectly) whether to impose dup = name > checking on all JSON parsers, even minimal-state streaming parsers, > whether we want to impose a requirement on the parser and the = application > (so we need not mention streaming), or on the parser if it's not a = streaming > parser *and* the application if the parser is streaming. >=20 > My view (for whatever it counts) is that we don't have consensus [yet] = for > imposing a requirement on parsers to reject objects with dup names. = We've > had at least a number of examples of streaming parsers that cannot > implement such a requirement -- the whole point of streaming being > nullified by state-keeping requirements like this one. > So we'd have to explicitly decide that we don't want to allow minimal = state > streaming parsers. Might as well call for consensus on that. >=20 > Nico > -- From cowan@ccil.org Sat Jul 6 22:53: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 8042521F9E3E for ; Sat, 6 Jul 2013 22:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 wrL9xsfnImEl for ; Sat, 6 Jul 2013 22:53:54 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 82BD321F9E3A for ; Sat, 6 Jul 2013 22:53:41 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Uvhuk-0007r5-Rl; Sun, 07 Jul 2013 01:53:38 -0400 Date: Sun, 7 Jul 2013 01:53:38 -0400 From: John Cowan To: Jim Schaad Message-ID: <20130707055338.GB2947@mercury.ccil.org> References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <00e401ce7ad5$00991c20$01cb5460$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e401ce7ad5$00991c20$01cb5460$@augustcellars.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: 'Nico Williams' , json@ietf.org Subject: [Json] Duplicate names: are they erroneous or not? 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, 07 Jul 2013 05:53:58 -0000 What I wish to avoid is a specification that says that having two fields of the same name in an object is a perfectly okay thing to do. In other words, such documents for my purposes have to be erroneous, rather than a legitimate way of encoding multimaps. Is there anyone who can't live with that restriction? If there isn't anyone, then we can talk about whether this is an error that generators and/or parsers MUST or SHOULD detect. But if we can't even get consensus on that much, it's futile to discuss parser or generator behavior. -- Do I contradict myself? John Cowan Very well then, I contradict myself. cowan@ccil.org I am large, I contain multitudes. http://www.ccil.org/~cowan --Walt Whitman, Leaves of Grass From nico@cryptonector.com Sat Jul 6 23:25:38 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 C265221F9E35 for ; Sat, 6 Jul 2013 23:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.020, 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 vXURZPsy7piD for ; Sat, 6 Jul 2013 23:25:33 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1352021F9DCD for ; Sat, 6 Jul 2013 23:25:33 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 5472C1E071 for ; Sat, 6 Jul 2013 23:25:32 -0700 (PDT) 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=y5Mq0nt7/zdZON55m1Bx p6OAEeg=; b=i4Ay8/nS7QHhJudDj6tLWSV/Sm6AGB3IEbbYywIMxY51d+AzcGqY SUHNuOxUcEvo6yBvH97mgN/pZACK83iLxUOUhkGzUGb8EPLIxSA3MHLL2CyJGDyj IgY1UciC2g9mAMlIJjM6cIuw38CkXMvBMdbcpKEqoI/rtUUM/NSw6NE= Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (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 E96211E064 for ; Sat, 6 Jul 2013 23:25:31 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so2809671wes.23 for ; Sat, 06 Jul 2013 23:25:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wc3i+rlwtaiy1OlBRp0uhZ3z77KXPi1gIXzhHg+ta0U=; b=cIEbULdGZ8tsFeM5i4QpwcbYuvh/7S83IYfZ+vJSwA0ExxrC646dJ7uUP8nNkHwuoX 6NGKSX7tsSVICWgZD1kt/ZbIFnzWCBKJ0MfIMRg9AZZcJhmw9Q4TERfMrqTh1ON5f79X ENJ4byH/dEZAxF+0yggRudWq3rNjxQgw135D9d8M6LRIc2FinJMqSN41jubPz2OuPgNf ntzoGtq5vKgyOiOPc19t3H9rg7zKZXFQZwnzL3kQzFXm+a9oYPDW8eO6tmO4C1YdYxVw SIZqtmNBcTNmX04C86lxVqY+6N7mSFW2uEJ25COkKEj6QtcMRPC0ct8WXYnwiZeDVykw 8MKg== MIME-Version: 1.0 X-Received: by 10.194.20.97 with SMTP id m1mr9427752wje.31.1373178330506; Sat, 06 Jul 2013 23:25:30 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Sat, 6 Jul 2013 23:25:30 -0700 (PDT) In-Reply-To: <00e401ce7ad5$00991c20$01cb5460$@augustcellars.com> References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <00e401ce7ad5$00991c20$01cb5460$@augustcellars.com> Date: Sun, 7 Jul 2013 01:25:30 -0500 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Cc: json@ietf.org Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 06:25:40 -0000 On Sun, Jul 7, 2013 at 12:44 AM, Jim Schaad wrote: > To be perfectly honest, I would personally argue that this is a > requirement that parsers need to enforce. The JOSE group is going to > need some interesting text about what happens if it is using a parser > that does not enforce this mechanism. And an even more interesting JOSE was going to need that anyways. If we manage to reach the consensus you want then JOSE won't need to, but will JOSE wait for JSON? > question of how this would ever be determined if the parser is not > part of the application itself. That is how does a JOSE application > know that the built in (assuming there is one) parser for the FOO > language/environment it is operating in will correctly do the > detection for it and not use the rule of grab the last value. I'd say... "read the docs" and "test the parser" :) (you'd have to no matter what; what if you got a YAML-based parser that had remote code execution vulnerabilities? surely you'd want to avoid that...) > I would also be open to the argument that a streaming parser is not > really an entire parser and the thing that consumes the output of a > streaming parser could be the entity that enforces the uniqueness > requirement. Right, that was my proposal. There's little appetite for describing parser types in the RFC though. I'm ambivalent, but willing to go with requiring rejection of objects with dup names. Nico -- From nico@cryptonector.com Sat Jul 6 23:25: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 EDA5821F9DCD for ; Sat, 6 Jul 2013 23:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.019, 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 85cRC7VSIjcn for ; Sat, 6 Jul 2013 23:25:46 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7A39621F9E3C for ; Sat, 6 Jul 2013 23:25:46 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 2C85E9405C for ; Sat, 6 Jul 2013 23:25:46 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=G/jsqUAJB2hJnuhUVBTclYD6nbM=; b=sarlgyGCP/K YjiQriJwzPTwsCvluTq8dqv+vfCOa+rV6AU/Qlt432JZLEg1HhMUOnncFJmnDUZE RY6IeqSlgY0dEpYidpThb17eWKdKjU/hZgh1Mgn3kxym0N/wXyhgr6hWX40/CUmG 6vAmAkVd8ImkIPjR3LMloYdVZhotTFts= Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id D051294059 for ; Sat, 6 Jul 2013 23:25:45 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so2891136wgg.8 for ; Sat, 06 Jul 2013 23:25:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=b6I1SX1LxeC//TPavw55ZjfOcdmml7I2IZzzF41lvCo=; b=ZDC/vzYqylkH6Yz8OH8ysV/1p8+2vFWtj990UcaadIYUdkAtXmBBHgfZdDp1gm27Im 8Ip4/12ZHOJPncxlvw1QzDQCLMqLxZ+KL2cF2lxlithTGojW1HMfSlX5gmV7qSBUb9E8 4RKfI8w67uwhXwRnspxPNNU/9a5AK3yskqU79K6/hB/ukdqRLpcJZdTlfsb6h6QKdJ3c a6VrQuzm3gEzUHbJqugRdMNufgxhfwrQsrKp8QTVxmp+CtySwygPTcGWqxBEJa9QqMDG 1Ke88SuE/idyBihywxmuYu1t3xOHIhEInjuWcGOKZq7CRdVPaJuoSCEdpT5rTdwqk1Fw WGSA== MIME-Version: 1.0 X-Received: by 10.180.107.71 with SMTP id ha7mr8684399wib.28.1373178344404; Sat, 06 Jul 2013 23:25:44 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Sat, 6 Jul 2013 23:25:44 -0700 (PDT) In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> Date: Sun, 7 Jul 2013 01:25:44 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jim Schaad , Tatu Saloranta , "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 06:25:52 -0000 On Sat, Jul 6, 2013 at 11:58 PM, Tim Bray wrote: > I=E2=80=99ll assume you=E2=80=99re right when you say dupe detection has = been measured as > expensive at run time, but I=E2=80=99m thinking that if I were writing a = reader I'd > implement a hash table with a test-and-set method, so I admit I'm surpris= ed > by the finding. I think I=E2=80=99d need to see a little more research b= efore I=E2=80=99d > accept that as a given. -T Dunno about Tatu, but I think the vast majority of JSON usage must be coupled either with generic hash tables (objects/dicts/maps/whatever) or structs (with associated schema). For the latter dup detection may well be more expensive than not, but probably not that much more expensive. For the former dup detection is essentially free. For other use cases, like Stephen Dolan's "launch missiles" example, dup detection might well be expensive, but maybe JSON is the wrong tool for those use cases. The CPU cost of dup detection doesn't concern me. It's the architectural implication that does: minimal state streaming parsers are out. I have to ask myself: are there use cases where I would want a minimal state streaming parser? and do I mind losing the ability to have such a thing? My personal, tentative answers: "yes" and "probably not, maybe in such a case I should not use JSON". Others will no doubt have different answers, which brings us to... ...more retreading. I still think the best thing to do is note the divergent interpretations and publish Internet JSON. Nico -- From stefan@drees.name Sun Jul 7 03:23: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 38AB421F9EE0 for ; Sun, 7 Jul 2013 03:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 AMFN4OzX+-vn for ; Sun, 7 Jul 2013 03:23:05 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 32DB721F9EDC for ; Sun, 7 Jul 2013 03:23:04 -0700 (PDT) Received: from newyork.local.box ([93.129.185.138]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0LuMER-1UFGFw2D7H-011msJ; Sun, 07 Jul 2013 12:23:00 +0200 Message-ID: <51D94182.6010208@drees.name> Date: Sun, 07 Jul 2013 12:22:58 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Cowan References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <00e401ce7ad5$00991c20$01cb5460$@augustcellars.com> <20130707055338.GB2947@mercury.ccil.org> In-Reply-To: <20130707055338.GB2947@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0mnC9ST4e41ciBa/5B5HLFRSEDih1plRD5HwW9xxrCdb50oGxvK DjJRrRknw18NIUNsqQRBRE9M7VyJIvg1gH9ZWSymev4Bl9Z9s/8+S1f3doFmYsxgYwO1ANY iHm/LIqtnCpuCWFi4mLTjJxJ8uHcjwFIbitQdJnSIqMhBldq6sMb7yB5/BwH54TYHIqhPCH ZPxJ/LqTksA9wKjjjifOQ== Cc: 'Nico Williams' , Jim Schaad , json@ietf.org Subject: Re: [Json] Duplicate names: are they erroneous or not? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 10:23:11 -0000 On 2013-07-07 07:53 +02:00, John Cowan wrote: > What I wish to avoid is a specification that says that having two > fields of the same name in an object is a perfectly okay thing to do. > In other words, such documents for my purposes have to be erroneous, > rather than a legitimate way of encoding multimaps. Is there anyone > who can't live with that restriction? If the above question is equivalent to: Does someone speak up, that MUST encode multimaps through members in an object, where the names are not pairwise distinct? I for myself will **not** speeak up. But that is neither necessary nor sufficient for this important pre condition of going further as described i your second paragraph below. Maybe it might good to request, that the chairs at this point - or not too far in the future - start such a consensus preparing call? > If there isn't anyone, then we can talk about whether this is an error > that generators and/or parsers MUST or SHOULD detect. But if we can't > even get consensus on that much, it's futile to discuss parser or > generator behavior. I need not consider any mandate - like the WG - only the rules for participating in these discussions, and I am willing to evolve the JSON into a versatile future proof data interchange format, as long as it doesn't mutate into the serialization format of just another specific language culture. {"Scene":[{"Me":"All"},{"Dog":"(wags his tail)"},{"Me":"the Best."}]} From derhoermi@gmx.net Sun Jul 7 06:35: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 6BEC521F9EED for ; Sun, 7 Jul 2013 06:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 WaQHVZXafYG0 for ; Sun, 7 Jul 2013 06:35:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id CF79E21F9E2E for ; Sun, 7 Jul 2013 06:35:17 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.20.89]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0M3vCA-1U5dxp0QDq-00rYvw; Sun, 07 Jul 2013 15:34:46 +0200 From: Bjoern Hoehrmann To: John Cowan Date: Sun, 07 Jul 2013 15:34:46 +0200 Message-ID: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <00e401ce7ad5$00991c20$01cb5460$@augustcellars.com> <20130707055338.GB2947@mercury.ccil.org> In-Reply-To: <20130707055338.GB2947@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:ZLFuzQ4BgXXhcwjlr7oEbyC89MK2uEEe0bnOeQhUxbCQd2bipTj YQQehFB3jEJXvVQEtJF0MKh/NaWTsLZ6JGHF9lZ3vB7yugsw5QSlMLWZ2BaUDTNkfTR6qKG BFNI2t1Z7/+zu17iUt69zUKlLBrMhK4H/W86+3jv/QJtvKJcHhmAws8ljhg1rC8T7qRpXEI 3XSgUABj6ap2jghuN7yOA== Cc: 'Nico Williams' , Jim Schaad , json@ietf.org Subject: Re: [Json] Duplicate names: are they erroneous or not? 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, 07 Jul 2013 13:35:22 -0000 * John Cowan wrote: >What I wish to avoid is a specification that says that having two >fields of the same name in an object is a perfectly okay thing to do. >In other words, such documents for my purposes have to be erroneous, >rather than a legitimate way of encoding multimaps. Is there anyone >who can't live with that restriction? The current text is "The names within an object SHOULD be unique". That makes it clear that you might encounter duplicate names in the wild and that your parser might not report it when it finds repeated names. That is the running code situation and so I would oppose making it a "MUST". >If there isn't anyone, then we can talk about whether this is an error >that generators and/or parsers MUST or SHOULD detect. But if we can't >even get consensus on that much, it's futile to discuss parser or >generator behavior. People who would like JSON parsers to detect repeated names in objects are welcome to implement and deploy and evangelise them; and when other parsers have become the exception, then it might be useful to capture that reality in an updated specification. Right now parsers usually do not detect repeated names and so it would be incorrect to tell people they can expect parsers to detect repeated names. -- 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 Sun Jul 7 06:38: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 7929A21F9F0E for ; Sun, 7 Jul 2013 06:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 chBIZrZPZqg2 for ; Sun, 7 Jul 2013 06:38:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id C9C0A21F9F0D for ; Sun, 7 Jul 2013 06:38:30 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.20.89]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0LjLwB-1ULvJX3dnj-00dVX7; Sun, 07 Jul 2013 15:38:03 +0200 From: Bjoern Hoehrmann To: Tim Bray Date: Sun, 07 Jul 2013 15:38:04 +0200 Message-ID: <8krit8hfboqbl6ipni5ef7l4dtl3dnuqnv@hive.bjoern.hoehrmann.de> References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:sLKOqeoATtc9653JDwI0xPHg36oeRLWcileokXmnifA6/gLMlmD vjfOzPjKvmMDVZ8kxNHOcWWcuMXXWyekrX0soEsKmjPnXqKFUMerW9MQQDZF0P3jiRhzpXZ hv069PbwU44VwSHP3ZbJvexmeoGWMVkNhUFxKkSY+D+LJ1DXJEawjfThUFeMIViSgLp1lTw /nHByrU0+CcT0xcSKmD7w== Cc: Nico Williams , Jim Schaad , "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 13:38:35 -0000 * Tim Bray wrote: >This feels like a no-brainer to me, but that’s probably because (as I’ve >said before) I’m an API guy, and the only use for JSON objects in my world >is to transfer a hash table or database record or whatever from here to >there, and there, and in such a situation dupes can never be useful or >intended and can only be a symptom of breakage (or, in the JOSE case, a >symptom of a malicious attack on my crypto). Designs like http://wiki.apache.org/solr/UpdateJSON#Solr_3.1_Example are not uncommon. -- 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 cabo@tzi.org Sun Jul 7 07:02: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 86BF921F9F1F for ; Sun, 7 Jul 2013 07:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 4DkpBZK5uQpG for ; Sun, 7 Jul 2013 07:02:16 -0700 (PDT) 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 6DF4C21F9F11 for ; Sun, 7 Jul 2013 07:02:16 -0700 (PDT) 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 r67E2CcO001709; Sun, 7 Jul 2013 16:02:12 +0200 (CEST) Received: from [192.168.217.105] (p54890C27.dip0.t-ipconnect.de [84.137.12.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C77EF3692; Sun, 7 Jul 2013 16:02:11 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <8krit8hfboqbl6ipni5ef7l4dtl3dnuqnv@hive.bjoern.hoehrmann.de> Date: Sun, 7 Jul 2013 16:02:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <71B60D6F-ED2B-4F33-914B-3BADBB66E4A6@tzi.org> References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <8krit8hfboqbl6ipni5ef7l4dtl3dnuqnv@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 14:02:22 -0000 On Jul 7, 2013, at 15:38, Bjoern Hoehrmann wrote: > http://wiki.apache.org/solr/UpdateJSON#Solr_3.1_Example Well, fixing that misconception is one of the points of this discussion. After JSON get standardized, people should no longer be able to claim = "It is legal in JSON to have duplicate names." with a straight face. =20 (It never was, but the requirement was stated with sufficiently soft = language that people have simply re-interpreted what was said as = something else that happened to be convenient at the time.) Gr=FC=DFe, Carsten From tsaloranta@gmail.com Sun Jul 7 10:57:52 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 2606821F9A35 for ; Sun, 7 Jul 2013 10:57:52 -0700 (PDT) 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, 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 r49hglEHuKWk for ; Sun, 7 Jul 2013 10:57:50 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB3621F9A2A for ; Sun, 7 Jul 2013 10:57:50 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so3148680wgh.14 for ; Sun, 07 Jul 2013 10:57:49 -0700 (PDT) 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=sFfNV4iAr1DqQpDZMTlEauPhbht94noOwiluq1CofLk=; b=zXHxe+Pe4R8R1iSzn3zhiyWAib5GARqDCrT9kr5IeKuH4VXmBCpzeObqjdzLHhE4Tp rZnfVSPjagR4MUoKKNk4qUKctKmTaaoK5jerAMk8CYMn9CCxv5h8/tJZ1SoESiagU6ej BFQZka9CROfNZE2gnRDQ2GG7J16E8HjesR/k3nhzmrfm+H6q4k6u9aInJpTcENhSMJ0E v6UFU3Ouk7+BL3+g5fk6L3azO/jzgDfPuuxv3Ub5BGzfYsdaexJ5E16jKz8YDW2Fg9mi y26Pp0bgKcNSADkgun24C8WeMPlFyGrY7vqcbg6n8Xy1bftR+Z2JeMTC7ptGxO/yEovz xj9g== MIME-Version: 1.0 X-Received: by 10.180.208.17 with SMTP id ma17mr9866811wic.7.1373219868251; Sun, 07 Jul 2013 10:57:48 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Sun, 7 Jul 2013 10:57:47 -0700 (PDT) In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> Date: Sun, 7 Jul 2013 10:57:47 -0700 Message-ID: From: Tatu Saloranta To: Tim Bray Content-Type: multipart/alternative; boundary=001a11c3808e721f9504e0efaaa4 Cc: Nico Williams , Jim Schaad , "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 17:57:52 -0000 --001a11c3808e721f9504e0efaaa4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sat, Jul 6, 2013 at 9:58 PM, Tim Bray wrote: > I=92ll assume you=92re right when you say dupe detection has been measure= d as > expensive at run time, but I=92m thinking that if I were writing a reader= I'd > implement a hash table with a test-and-set method, so I admit I'm surpris= ed > by the finding. I think I=92d need to see a little more research before = I=92d > accept that as a given. -T > > Point is that no hash table need be created at all. All one has is simple tokenizer (lexer). No tree is built, just parent stack with information to match close markers, report error locations. And bit of state information to validate well-formedness wrt separators. I agree that if a per-document symbol table/map is maintained, extra cost would probably be negligible and not worth worrying too much about. Hash table will typically be used at higher level, if building an object representation, such as tree model, or native objects: either as structure to build (tree), or mapping to object fields (name to method/field). At this level catching duplicates is easier and more efficient to handle, and I would not be worried about mandating such handling. So why separation to layers like this? While writing a naive tokenizer is an easy task, it takes much more effort to create an efficient one. But there are not many variations there, so once an efficient one exists, it is easy to use that as a building block, save time and have some confidence that simple encoding/decoding works correctly and efficiently. Conversely, higher level components vary a lot regarding functionality. This is similar to division between low-level SAX or Stax APIs, and higher-level DOM (tree) and JAXB (data binding) for XML on Java. I think C#/dotnet has similar separation between pull-parsing and higher-level abstractions, but it seems absent from most scripting languages. As to research, I don't know if this -- https://github.com/eishay/jvm-serializers/wiki -- helps, but contrasting these two entries: create ser deser total size +dfl json/jackson/manual 62 1137 1519 2656 468 253 json/jackson/tree 63 2045 2650 4695 485 259 gives difference between manually written data-binding (streaming parser, hand-written code to match names to fields), and building a HashMap-based simple tree model (built on streaming parser) as 2-to-1 performance difference (2656 nsec vs 4695 nsec). Part of this is with overhead of Maps vs. plain java objects, but not all. I could prototype with actual detection too (in fact, there is an RFE for streaming parser to do just that -- and I consider it a legitimate thing to do as optional settings) and see how much actual overhead a highly-tuned minimal-state parser will have on Java platform. -+ Tatu +- > > On Sat, Jul 6, 2013 at 9:37 PM, Tatu Saloranta wrot= e: > >> On Sat, Jul 6, 2013 at 7:57 PM, Nico Williams wro= te: >> >>> On Sat, Jul 6, 2013 at 8:44 PM, Tim Bray wrote: >>> > This feels like a no-brainer to me, but that=92s probably because (as >>> I=92ve >>> > said before) I=92m an API guy, and the only use for JSON objects in m= y >>> world >>> > is to transfer a hash table or database record or whatever from here = to >>> > there, and there, and in such a situation dupes can never be useful o= r >>> > intended and can only be a symptom of breakage (or, in the JOSE case,= a >>> > symptom of a malicious attack on my crypto). >>> >>> I agree. As a security guy I would prefer if one way or another we >>> end up with no dup names, but as an "API guy" myself I think of the >>> streaming parsers (they offer an API after all). Just say the magic >>> words: "to hell with minimal state streaming parsers" or perhaps >>> something to the effect that *some* component of a layered application >>> MUST reject objects with dup names. It's either or. Let's choose. >>> >>> I'm happy with "some component of a layered application MUST reject >>> objects with duplicate names" -- I prefer this to the "no minimal >>> state streaming parsers" alternative. >>> >>> I will assume that in general objects rarely have lots of names, so >>> that parsers need not keep that much state in order to check for dups. >>> Requiring parsers to reject objects with dup names is my second >>> choice. >>> >> >> Just to make sure: I also do not have any use for duplicates, and >> consider them flaws in processing. I have never used duplicates for >> anything, nor find that interesting approach. >> The only concern really is that of mandating (or not) detection and/or >> prevention at lowest level components of commonly used processing stacks >> (low-level push/pull parser, higher-level library or app code that build= s >> full representations), since this is significant cost, based on extensiv= e >> profiling I have done at this level. >> >> Case of application code directly using streaming parser/generators is >> not nearly as common as that of frameworks using them to produce higher >> level abstractions. >> These higher level abstraction (JSON tree representation, binding to >> native objects) do either report errors such as duplicates, and at very >> least can detect it and use consistent handling. They can do it much mor= e >> efficiently than low-level components since they have to build >> representations that then serve as data structures for detecting/prevent= ing >> duplicates. >> >> Specific concern for me is this: if specification mandates detection >> and/or prevention for parser, generators, without any mention that 'pars= er' >> and 'generator' are logical concepts (thing that reads JSON, thing that >> writes JSON), I will have lots of users who promptly demand low-level >> components to force checks. >> And then I get to spend lots of time discussing why such checks can (and >> IMO should) still be pushed to higher level of processing. It is amazing >> how much FUD can be generated based on cursory reading of specifications= . >> >> This concern extends to suggested "Internet JSON messages" specification= . >> >> I would like simple suggestion that some component of the processing >> should/must detect and report duplicates; and prevent producing of same; >> or, lengthier explanation of what "parser" and "generator" mean (parser = is >> such a horrible misnomer -- there is very very little parsing involved, >> it's just a lexer, and optional object builder -- but I digress). >> >> -+ Tatu +- >> >> > --001a11c3808e721f9504e0efaaa4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 6, 2013 at 9:58 PM, Tim Bray <tbray@textua= lity.com> wrote:
I=92ll a= ssume you=92re right when you say dupe detection has been measured as expen= sive at run time, but I=92m thinking that if I were writing a reader I'= d implement a hash table with a test-and-set method, so I admit I'm sur= prised by the finding.=A0 I think I=92d need to see a little more research = before I=92d accept that as a given.=A0 -T


Point is that no hash table = need be created at all. All one has is simple tokenizer (lexer). No tree is= built, just parent stack with information to match close markers, report e= rror locations. And bit of state information to validate well-formedness wr= t separators.
I agree that if a per-document symbol table/map is maintained, extra cost w= ould probably be negligible and not worth worrying too much about.

Hash table will typically be used at higher level, if buildi= ng an=20 object representation, such as tree model, or native objects: either as str= ucture to build (tree), or mapping to object fields (name to method/field).= At this=20 level catching duplicates is easier and more efficient to handle, and I wou= ld not be worried about mandating such handling.

So why separation to layers like this? While writing a naive tokenizer is an = easy=20 task, it takes much more effort to create an efficient one. But there are n= ot many variations there, so once an efficient one exists, it is easy to us= e that as a building block, save time and have some confidence that simple = encoding/decoding works correctly and efficiently.
Conversely, higher level components vary a lot regarding functionality. Thi= s is similar to division between low-level SAX or Stax APIs, and higher-lev= el DOM (tree) and JAXB (data binding) for XML on Java. I think C#/dotnet ha= s similar separation between pull-parsing and higher-level abstractions, bu= t it seems absent from most scripting languages.

As to research, I don't know if this -- https://github.com/eishay/jvm-seriali= zers/wiki -- helps, but contrasting these two entries:
        =
                   create     ser   deser   total   size  +dfl
  json/jackson/manual           62    1137    1519  2656    468   253
  json/jackson/tree             63    2045    2650  4695    485   259
=
gives difference between manually written data-binding (streamin= g parser, hand-written code to match names to fields), and building a HashM= ap-based simple tree model (built on streaming parser) as 2-to-1 performanc= e difference (2656 nsec vs 4695 nsec).
Part of this is with overhead of Maps vs. plain java objects, bu= t not all.

I could prototype with actual detection too (in fact, the= re is an RFE for streaming parser to do just that -- and I consider it a le= gitimate thing to do as optional settings) and see how much actual overhead= a highly-tuned minimal-state parser will have on Java platform.

-+ Tatu +-
=A0

On Sat, Jul 6, 2013 at 9:37 PM, Tatu Saloranta <= span dir=3D"ltr"><tsaloranta@gmail.com> wrote:
On Sat, Jul 6, 2013 at 7:57 PM, Nico Williams <nico@cryptonector.com= > wrote:
On Sat, Jul 6, 2013 = at 8:44 PM, Tim Bray <tbray@textuality.com> wrote:
> This feels like a no-brainer to me, but that=92s probably because (as = I=92ve
> said before) I=92m an API guy, and the only use for JSON objects in my= world
> is to transfer a hash table or database record or whatever from here t= o
> there, and there, and in such a situation dupes can never be useful or=
> intended and can only be a symptom of breakage (or, in the JOSE case, = a
> symptom of a malicious attack on my crypto).

I agree. =A0As a security guy I would prefer if one way or another we=
end up with no dup names, but as an "API guy" myself I think of t= he
streaming parsers (they offer an API after all). =A0Just say the magic
words: "to hell with minimal state streaming parsers" or perhaps<= br> something to the effect that *some* component of a layered application
MUST reject objects with dup names. =A0It's either or. =A0Let's cho= ose.

I'm happy with "some component of a layered application MUST rejec= t
objects with duplicate names" -- I prefer this to the "no minimal=
state streaming parsers" alternative.

I will assume that in general objects rarely have lots of names, so
that parsers need not keep that much state in order to check for dups.
=A0Requiring parsers to reject objects with dup names is my second
choice.

Just to make sure: = I also do not have any use for duplicates, and consider them flaws in proce= ssing. I have never used duplicates for anything, nor find that interesting= approach.
The only concern really is that of mandating (or not) detection = and/or prevention at lowest level components of commonly used processing st= acks (low-level push/pull parser, higher-level library or app code that bui= lds full representations), since this is significant cost, based on extensi= ve profiling I have done at this level.

Case of application code directly using streaming parser/gen= erators is not nearly as common as that of frameworks using them to produce= higher level abstractions.
These higher level abstraction (J= SON tree representation, binding to native objects) do either report errors= such as duplicates, and at very least can detect it and use consistent han= dling. They can do it much more efficiently than low-level components since= they have to build representations that then serve as data structures for = detecting/preventing duplicates.

Specific concern for me is this: if specification mandates detect= ion and/or prevention for parser, generators, without any mention that '= ;parser' and 'generator' are logical concepts (thing that reads= JSON, thing that writes JSON), I will have lots of users who promptly dema= nd low-level components to force checks.
And then I get to spend lots of time discussing why such checks can (= and IMO should) still be pushed to higher level of processing. It is amazin= g how much FUD can be generated based on cursory reading of specifications.=

This concern extends to suggested &quo= t;Internet JSON messages" specification.

I would like simple suggestion = that some component of the processing should/must detect and report duplica= tes; and prevent producing of same; or, lengthier explanation of what "= ;parser" and "generator" mean (parser is such a horrible mis= nomer -- there is very very little parsing involved, it's just a lexer,= and optional object builder -- but I digress).

-+ T= atu +-



--001a11c3808e721f9504e0efaaa4-- From tsaloranta@gmail.com Sun Jul 7 11:07: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 C16DA11E80F3 for ; Sun, 7 Jul 2013 11:07:55 -0700 (PDT) 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=[AWL=0.000, 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 zZS7zkwZz1KZ for ; Sun, 7 Jul 2013 11:07:54 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 676C711E80EE for ; Sun, 7 Jul 2013 11:07:54 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so3184768wgh.16 for ; Sun, 07 Jul 2013 11:07:53 -0700 (PDT) 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=BwbssAqOogAf4Ky+4jrIXA8ApP4h87lnQcjlw4SzaAw=; b=SfbJktAVTuncPpATYkx90deHFqBh+wxGFbfH0FxQuI3ehYXULppAbAuqK9A5wqcMQQ D4hWjLUmk/x8xKeo44mfNJ2xoAZXDwojm8GPdErSeTHCIDoNCu4UPTlN87Iqz3/bICNw TpLMefZnHxtU86cv59BLkjbStF1GSdB1VgGQeEmM/0nYagPavxi4xB14l6iFK8GoELE9 5ZgJ7XElMMcyNOyOVW0h5vlxeGisFzvu4RxDro8a4qOLJT0rfMwVBa/G/1CGzA2nCX7R NYuVmswhFRippRWZqG/WLFsqHJJzrgI8YXkRKEcdD+cEYDMGi/FOCHxzC5X0WCJQGNSJ NL0A== MIME-Version: 1.0 X-Received: by 10.180.208.17 with SMTP id ma17mr9879099wic.7.1373220473429; Sun, 07 Jul 2013 11:07:53 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Sun, 7 Jul 2013 11:07:53 -0700 (PDT) In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> Date: Sun, 7 Jul 2013 11:07:53 -0700 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c3808e84689204e0efcecc Cc: Jim Schaad , Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 18:07:55 -0000 --001a11c3808e84689204e0efcecc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sat, Jul 6, 2013 at 11:25 PM, Nico Williams wrote= : > On Sat, Jul 6, 2013 at 11:58 PM, Tim Bray wrote: > > I=92ll assume you=92re right when you say dupe detection has been measu= red as > > expensive at run time, but I=92m thinking that if I were writing a read= er > I'd > > implement a hash table with a test-and-set method, so I admit I'm > surprised > > by the finding. I think I=92d need to see a little more research befor= e > I=92d > > accept that as a given. -T > > Dunno about Tatu, but I think the vast majority of JSON usage must be > coupled either with generic hash tables (objects/dicts/maps/whatever) > or structs (with associated schema). For the latter dup detection may > well be more expensive than not, but probably not that much more > expensive. For the former dup detection is essentially free. > Yes (for second case, schema typically coming from Java class definitions, implicitly). I did not imply that overhead here would be significant. > For other use cases, like Stephen Dolan's "launch missiles" example, > dup detection might well be expensive, but maybe JSON is the wrong > tool for those use cases. > > The CPU cost of dup detection doesn't concern me. It's the > architectural implication that does: minimal state streaming parsers > are out. > > I have to ask myself: are there use cases where I would want a minimal > state streaming parser? and do I mind losing the ability to have such > a thing? My personal, tentative answers: "yes" and "probably not, > maybe in such a case I should not use JSON". Others will no doubt > have different answers, which brings us to... > > I would just note that at this point JSON is very competive, performance-wise, exceeding performance of other textual formats, and competing well with binary formats as well. In fact, I rarely see compelling reason to even consider binary formats, unless payload size is significant factor. If this aspect was lost due to clarification for solving a problem that has more to do with concerns for _possible_ security issues, that would be sad. End users rarely have real need for minimal-state parsing. It is framework-builders -- such as, say Solr, Elastic Search, Hadoop, JAX-RS implementations (these for Java, similar for other platforms) -- that care as performance implications there have more effect. And they are the ones that have legitimate use for minimal-state components. I assume all of above is understood by now, so apologies if I sound like a broken record here. > ...more retreading. > > I still think the best thing to do is note the divergent > interpretations and publish Internet JSON. > > I agree. -+ Tatu +- --001a11c3808e84689204e0efcecc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 6, 2013 at 11:25 PM, Nico Williams <nic= o@cryptonector.com> wrote:
On Sat, Jul 6, 2013 at 11:= 58 PM, Tim Bray <tbray@textualit= y.com> wrote:
> I=92ll assume you=92re right when you say dupe detection has been meas= ured as
> expensive at run time, but I=92m thinking that if I were writing a rea= der I'd
> implement a hash table with a test-and-set method, so I admit I'm = surprised
> by the finding. =A0I think I=92d need to see a little more research be= fore I=92d
> accept that as a given. =A0-T

Dunno about Tatu, but I think the vast majority of JSON usage must be=
coupled either with generic hash tables (objects/dicts/maps/whatever)
or structs (with associated schema). =A0For the latter dup detection may well be more expensive than not, but probably not that much more
expensive. =A0For the former dup detection is essentially free.

Yes (for second case, schema typically coming from= Java class definitions, implicitly).
I did not imply that ov= erhead here would be significant.


For other use cases, like Stephen Dolan's "launch missiles" e= xample,
dup detection might well be expensive, but maybe JSON is the wrong
tool for those use cases.

The CPU cost of dup detection doesn't concern me. =A0It's the
architectural implication that does: minimal state streaming parsers
are out.

I have to ask myself: are there use cases where I would want a minimal
state streaming parser? =A0and do I mind losing the ability to have such a thing? =A0My personal, tentative answers: "yes" and "proba= bly not,
maybe in such a case I should not use JSON". =A0Others will no doubt have different answers, which brings us to...


I would just note that at this point J= SON is very competive, performance-wise, exceeding performance of other tex= tual formats, and competing well with binary formats as well. In fact, I ra= rely see compelling reason to even consider binary formats, unless payload = size is significant factor.
If this aspect was lost due to clarification for solving a problem that has= more to do with concerns for _possible_ security issues, that would be sad= .

End users rarely have real need for minimal-= state parsing. It is framework-builders -- such as, say Solr, Elastic Searc= h, Hadoop, JAX-RS implementations (these for Java, similar for other platfo= rms) -- that care as performance implications there have more effect. And t= hey are the ones that have legitimate use for minimal-state components.

I assume all of above is understood by now, so ap= ologies if I sound like a broken record here.
=A0
...more retreading.

I still think the best thing to do is note the divergent
interpretations and publish Internet JSON.


I agree.

-+ Tatu +-<= br>
=A0
--001a11c3808e84689204e0efcecc-- From sgbeal@googlemail.com Sun Jul 7 11:09:38 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 D6F6221F9446 for ; Sun, 7 Jul 2013 11:09:38 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622, 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 aeBgoTnLPlA9 for ; Sun, 7 Jul 2013 11:09:38 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 977DE21F91CE for ; Sun, 7 Jul 2013 11:09:37 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so8397640wiw.11 for ; Sun, 07 Jul 2013 11:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=IXDJYONJAPHpP4SgqYnQ6FapfViQCQz2LGvhP2Qod1I=; b=RVRpII7A4mDd3Qg9avhMAwXHmv203fi6ulYq/IBvjxuCLh9MgN0xQ5qDYeP49SfZst WaE/XaUD43jskJzWWtUF2jr1MIjBzEW3qceYcbCqYCwNEfSUHk/wTC0grVvlDUGdkDf5 JOhJzhKf5bk+kv9n9qWMV+1ZRezcBagzEXthW+NqETc3GUGpvKUykehxilrgoJLBld+U rC28NML1o3Hd2B3aD7lK9ZiEb4aQBEtUri/AgUTV91h56iYuLhe/0460dUmlCrFRD/ya /Xmh8KFSXqYQe30pCgJmYfPe9q5FJdReuQfE6suk1JQBTwzyTm2t8Ew045rXMO53cHR+ R45Q== MIME-Version: 1.0 X-Received: by 10.180.82.196 with SMTP id k4mr12198427wiy.0.1373220576707; Sun, 07 Jul 2013 11:09:36 -0700 (PDT) Received: by 10.194.1.241 with HTTP; Sun, 7 Jul 2013 11:09:36 -0700 (PDT) In-Reply-To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> Date: Sun, 7 Jul 2013 20:09:36 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=f46d044281ceac4e5804e0efd4e0 Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 18:09:38 -0000 --f46d044281ceac4e5804e0efd4e0 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 7, 2013 at 3:20 AM, Nico Williams wrote: > We still need to decide (directly or indirectly) whether to impose dup > name checking on all JSON parsers, even minimal-state streaming > parsers, whether we want to impose a requirement on the parser and the > application (so we need not mention streaming), or on the parser if > it's not a streaming parser *and* the application if the parser is > streaming. > FWIW, as a JSON library implementor, i can say that a MUST on the whole duplicate keys issue is not going to be enforced in any of my impls. Having to check for an existing key on every insert turns O(N) operations in to catastrophically poor operation if the property store is not fast (and JSON has no business specifying performance characteristics). e.g. my JSON libraries tend to use simple key/value pair _lists_, not maps, because the nature of JSON is (for most apps) such that it's spit out and slurped in, but not manipulated as the basic data structure (at least not in C, where i'm working). Streaming or not, enforcing the implied level of infrastructure and potential performance hits which MUST implies is not something i plan on doing, even if it means not being fully compliant. "Duplicate keys lead to unspecified behaviour," end of story. names. We've had at least a number of examples of streaming parsers > that cannot implement such a requirement -- the whole point of > streaming being nullified by state-keeping requirements like this one. > So we'd have to explicitly decide that we don't want to allow minimal > state streaming parsers. Might as well call for consensus on that. > i'm for not splitting them into categories, as this document really has no business (IMO) specifying that level of implementation detail. Specify the duplicate keys as poor practice leading to unspecified/implementation-defined behaviour, and be done it. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --f46d044281ceac4e5804e0efd4e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 7, 2013 at 3:20 AM, Nico Williams <nico@c= ryptonector.com> wrote:
We still need to decide (directly or indirectly) whether to impos= e dup
name checking on all JSON parsers, even minimal-state streaming
parsers, whether we want to impose a requirement on the parser and the
application (so we need not mention streaming), or on the parser if
it's not a streaming parser *and* the application if the parser is
streaming.

FWIW, as a JSON library impl= ementor, i can say that a MUST on the whole duplicate keys issue is not goi= ng to be enforced in any of my impls. Having to check for an existing key o= n every insert turns O(N) operations in to catastrophically poor operation = if the property store is not fast (and JSON has no business specifying perf= ormance characteristics). e.g. my JSON libraries tend to use simple key/val= ue pair _lists_, not maps, because the nature of JSON is (for most apps) su= ch that it's spit out and slurped in, but not manipulated as the basic = data structure (at least not in C, where i'm working). Streaming or not= , enforcing the implied level of infrastructure and potential performance h= its which MUST =A0implies is not something i plan on doing, even if it mean= s not being fully compliant. "Duplicate keys lead to unspecified behav= iour," end of story.

names. =A0We've had at le= ast a number of examples of streaming parsers
that cannot implement such a requirement -- the whole point of
streaming being nullified by state-keeping requirements like this one.
=A0So we'd have to explicitly decide that we don't want to allow mi= nimal
state streaming parsers. =A0Might as well call for consensus on that.

i'm for not splitting them into categori= es, as this document really has no business (IMO) specifying that level of = implementation detail. Specify the duplicate keys as poor practice leading = to unspecified/implementation-defined behaviour, and be done it.

--
----- stephan beal
http://wanderinghorse.net/home= /stephan/
--f46d044281ceac4e5804e0efd4e0-- From cowan@ccil.org Sun Jul 7 11:10:10 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 5ACDC21F9446 for ; Sun, 7 Jul 2013 11:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 Qqcg9dqFWc8I for ; Sun, 7 Jul 2013 11:09:58 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B35BE11E80F2 for ; Sun, 7 Jul 2013 11:09:58 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UvtPH-0003B6-F7; Sun, 07 Jul 2013 14:09:55 -0400 Date: Sun, 7 Jul 2013 14:09:55 -0400 From: John Cowan To: Tatu Saloranta Message-ID: <20130707180955.GA11346@mercury.ccil.org> References: <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.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: Nico Williams , Jim Schaad , Tim Bray , "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 18:10:10 -0000 Tatu Saloranta scripsit: > Part of this is with overhead of Maps vs. plain java objects, but not all. I'm wondering if the parser interns object names. That would be a big win for a manually built system (you can use == comparison to figure out which field to set, rather than String.equals), but no advantage at all to a Map-based tree (unless indeed it used IdentityMaps). -- Income tax, if I may be pardoned for saying so, John Cowan is a tax on income. --Lord Macnaghten (1901) cowan@ccil.org From cowan@ccil.org Sun Jul 7 11:11: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 6C42921F9ADD for ; Sun, 7 Jul 2013 11:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 DrB3iDxRZNV4 for ; Sun, 7 Jul 2013 11:11:22 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE6421F9A4A for ; Sun, 7 Jul 2013 11:11:22 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UvtQf-0003Jy-4U; Sun, 07 Jul 2013 14:11:21 -0400 Date: Sun, 7 Jul 2013 14:11:21 -0400 From: John Cowan To: Stephan Beal Message-ID: <20130707181121.GB11346@mercury.ccil.org> References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.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: "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 18:11:26 -0000 Stephan Beal scripsit: > i'm for not splitting them into categories, as this document really has no > business (IMO) specifying that level of implementation detail. Specify the > duplicate keys as poor practice leading to > unspecified/implementation-defined behaviour, and be done it. +1 to that. "Unspecified behavior" is another way of saying "is an error". -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Uneasy lies the head that wears the Editor's hat! --Eddie Foirbeis Climo From cabo@tzi.org Sun Jul 7 11:39: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 E224821F9991 for ; Sun, 7 Jul 2013 11:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.129 X-Spam-Level: X-Spam-Status: No, score=-106.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 mSaONL19PoIX for ; Sun, 7 Jul 2013 11:39:28 -0700 (PDT) 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 CDA8221F8F09 for ; Sun, 7 Jul 2013 11:39:22 -0700 (PDT) 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 r67IdHmu003800; Sun, 7 Jul 2013 20:39:17 +0200 (CEST) Received: from [192.168.217.105] (p54890C27.dip0.t-ipconnect.de [84.137.12.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8862A36F4; Sun, 7 Jul 2013 20:39:17 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130707180955.GA11346@mercury.ccil.org> Date: Sun, 7 Jul 2013 20:39:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18CB0DCA-36FA-4900-9A56-43ECECF2A21A@tzi.org> References: <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <20130707180955.GA11346@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 18:39:34 -0000 On Jul 7, 2013, at 20:09, John Cowan wrote: > I'm wondering if the parser interns object names.=20 The problem with that may be that it leads to an easy DoS (interned = strings are never released). In many JSON designs, the receiver knows the full set of keys ahead of = time. In this case, you are better off with conditionally interning it = (i.e., if I already have the symbol, return it, otherwise keep the = string around, now we know that it didn't map to a known key). Gr=FC=DFe, Carsten From cowan@ccil.org Sun Jul 7 11:43: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 ED6A721F9E46 for ; Sun, 7 Jul 2013 11:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Iv6GLrhTEoi0 for ; Sun, 7 Jul 2013 11:43:27 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8B21C21F9DB0 for ; Sun, 7 Jul 2013 11:43:27 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Uvtve-0006KH-OB; Sun, 07 Jul 2013 14:43:22 -0400 Date: Sun, 7 Jul 2013 14:43:22 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20130707184322.GA16880@mercury.ccil.org> References: <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <20130707180955.GA11346@mercury.ccil.org> <18CB0DCA-36FA-4900-9A56-43ECECF2A21A@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18CB0DCA-36FA-4900-9A56-43ECECF2A21A@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 18:43:32 -0000 Carsten Bormann scripsit: > In many JSON designs, the receiver knows the full set of keys ahead > of time. In this case, you are better off with conditionally interning > it (i.e., if I already have the symbol, return it, otherwise keep the > string around, now we know that it didn't map to a known key). I don't know any way to do that in Java, because there seems to be no way to ask if a string is interned except by interning it. -- John Cowan cowan@ccil.org http://ccil.org/~cowan I come from under the hill, and under the hills and over the hills my paths led. And through the air. I am he that walks unseen. I am the clue-finder, the web-cutter, the stinging fly. I was chosen for the lucky number. --Bilbo From derhoermi@gmx.net Sun Jul 7 11:57: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 1D7DD11E80FF for ; Sun, 7 Jul 2013 11:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 jfKWwWws8BKx for ; Sun, 7 Jul 2013 11:57:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id B8B1211E80EE for ; Sun, 7 Jul 2013 11:57:38 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.43.58]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MXDo1-1UjYMw1nuf-00WJ9y; Sun, 07 Jul 2013 20:57:35 +0200 From: Bjoern Hoehrmann To: Tatu Saloranta Date: Sun, 07 Jul 2013 20:57:34 +0200 Message-ID: <7adjt8hkf0lrirnloid2nnvg3ad2i7070k@hive.bjoern.hoehrmann.de> 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:Ky/PiU48/21esQcaWKTXCIe8EI/RdlY8gJjsljWsSbOX4Ss2uRC zAf0xi07SdC580hu/lt4Kj3X8U8707Cib5XLRUCGZ4S19vuRnGV3KnIhOaG9zhorSJdmAXC tkd2Jmui3G+q1+Hy5THlx05CVkH8ITayf451cNnFp/chNDQUwgR5iHwtVpKXDwc+kdKoaaa AjFZgPZOILY4+2ZimU+mA== Cc: "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 18:57:43 -0000 * Tatu Saloranta wrote: >If this aspect was lost due to clarification for solving a problem that has >more to do with concerns for _possible_ security issues, that would be sad. > >End users rarely have real need for minimal-state parsing. It is >framework-builders -- such as, say Solr, Elastic Search, Hadoop, JAX-RS >implementations (these for Java, similar for other platforms) -- that care >as performance implications there have more effect. And they are the ones >that have legitimate use for minimal-state components. Note that the performance implications can easily become security impli- cations. A naive implementation of checking for duplicates may well be vulnerable to algorithmic complexity attacks causing denial of service (by using maliciously crafted input that exhibits worst-case behavior). http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html for in- stance surprisingly showed that many common environments had failed to pay attention when the problem was addressed in Perl eight years prior. -- 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 cabo@tzi.org Sun Jul 7 12:03: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 B1F4411E80EE for ; Sun, 7 Jul 2013 12:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Edlgt0daz1nP for ; Sun, 7 Jul 2013 12:03:18 -0700 (PDT) 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 9BED421F9AA2 for ; Sun, 7 Jul 2013 12:03:18 -0700 (PDT) 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 r67J3D1e016000; Sun, 7 Jul 2013 21:03:13 +0200 (CEST) Received: from [192.168.217.105] (p54890C27.dip0.t-ipconnect.de [84.137.12.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5C25036F9; Sun, 7 Jul 2013 21:03:13 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130707184322.GA16880@mercury.ccil.org> Date: Sun, 7 Jul 2013 21:03:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9CD89FF5-59DF-454E-BFCF-C0EE99933457@tzi.org> References: <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <20130707180955.GA11346@mercury.ccil.org> <18CB0DCA-36FA-4900-9A56-43ECECF2A21A@tzi.org> <20130707184322.GA16880@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 07 Jul 2013 19:03:24 -0000 On Jul 7, 2013, at 20:43, John Cowan wrote: > Carsten Bormann scripsit: >=20 >> In many JSON designs, the receiver knows the full set of keys ahead >> of time. In this case, you are better off with conditionally = interning >> it (i.e., if I already have the symbol, return it, otherwise keep the >> string around, now we know that it didn't map to a known key). >=20 > I don't know any way to do that in Java, because there seems to be no > way to ask if a string is interned except by interning it. No idea about Java, but same problem at the language level in Ruby. However, at the C API level, there is a conditional intern = (rb_check_id()). Too bad that this isn't exported to the Ruby level. Gr=FC=DFe, Carsten From jhildebr@cisco.com Sun Jul 7 23:35: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 0DF4311E819A for ; Sun, 7 Jul 2013 23:35:14 -0700 (PDT) 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 l0NctQE5xbXJ for ; Sun, 7 Jul 2013 23:35:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D1C3421F9A57 for ; Sun, 7 Jul 2013 23:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=535; q=dns/txt; s=iport; t=1373265307; x=1374474907; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=i0YsTyqttOBQTuPTgMkgme7b7VfEB1YWHFcgxxz0TO8=; b=k9zErTBx8jLxN7b8XjWUHBxosPBgtUEPxGgfMYBRMd3nGvvoRfiS5xEC 8LnQ2EGnPQUPCDZlmODEp60u4ksiLmmjfqSY/mISQxlLjsdDZFbEBcCih NoYkl/nr+xeF4nYfdlK7PQnAhXBz7Qk85RsiNq3YgkU6hDWieEsI0lZLE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFAINc2lGtJV2Z/2dsb2JhbABZgwl/gkG+H4ENFnSCJQEEOlEBCA4UFEIlAgQBEgiHdQMPr0oNiFGNAII6OIMHaQOpG4MRgig X-IronPort-AV: E=Sophos;i="4.87,1016,1363132800"; d="scan'208";a="231933191" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 08 Jul 2013 06:35:07 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r686Z794027324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jul 2013 06:35:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 01:35:07 -0500 From: "Joe Hildebrand (jhildebr)" To: Stephan Beal , "json@ietf.org" Thread-Topic: [Json] Proposed minimal change for duplicate names in objects Thread-Index: AQJvUTXGqIW3iuu0l9rzv3fxldJ4PQL8G24kAqTixrQBjIQJ6gH4Oee+l81ZmFCAAHeBAIAAErYAgAEZ/QCAAGtUgA== Date: Mon, 8 Jul 2013 06:35:06 +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.5.130515 x-originating-ip: [10.21.124.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <5E148D4623E96540B064723B48E5022A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 08 Jul 2013 06:35:14 -0000 On 7/7/13 12:09 PM, "Stephan Beal" wrote: >Specify the duplicate keys as poor practice leading to >unspecified/implementation-defined behaviour, and be done it. I went in to this conversation really wanting to move to MUST. I've now been convinced that strong language about how awful duplicates are is the best we can do, so +1. I don't want people to be able to read the text and argue with a straight face that their protocol is "legal" when it's just poorly designed. --=20 Joe Hildebrand From jsontest@yahoo.com Mon Jul 8 00:16: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 2FE9D21F9DB6 for ; Mon, 8 Jul 2013 00:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_QP_LONG_LINE=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 qDsgdVTCmRkY for ; Mon, 8 Jul 2013 00:16:44 -0700 (PDT) Received: from nm19-vm4.bullet.mail.ne1.yahoo.com (nm19-vm4.bullet.mail.ne1.yahoo.com [98.138.91.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC9621F99D9 for ; Mon, 8 Jul 2013 00:16:44 -0700 (PDT) Received: from [98.138.90.48] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jul 2013 07:16:42 -0000 Received: from [98.138.84.45] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jul 2013 07:16:42 -0000 Received: from [127.0.0.1] by smtp113.mail.ne1.yahoo.com with NNFMP; 08 Jul 2013 07:16:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1373267802; bh=/lEHcIaT6UqX5BJ+JKFWkOatwro55aj6ViEzedA9hVc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=vmNzVpUGGePeMMTuvXVQDlka3D2P6Ud375QlkdBoFWWLxbewx5ruX2KS8Tg336FhKPn9OUr58YRJoJG0AFKzFokVDhRjvSvzmRf9woiiLa7rKFiIOBApqwPIDqkp6ghKOy2IHYOOKcQVK6pp1kW7p5ICeAK7ZsM1TrbwE5YZI6s= X-Yahoo-Newman-Id: 621541.91266.bm@smtp113.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6BN2GIkVM1lNix9voIMTTQTj63slSZs1PKx3uhLFIlQDfdy kkRq9jTyUjtMGxjyxMJUobimeqVDXH38Wc8gDYvo35FnEZ.i49rnAF0fxGNH 1FrpwX0hWUJ70SW71dk6_zkzQTIRpDziLBcmqz0sYLQ1WWbYaN0BIXs9Rfyj se6WrnmVsZhmrlN_5o0GrX1Y64SwRBjJnVmrAITvrlsj14A2Dx04hDC8YqST 4WdX7eUy7u6yfy2s93QJDRlBjt1iOnk7O1y2hFB9nvruetObM4xHNJpuUIsK UcmFHSRNHfUX9NWyMF8YapE2klJi_3wNrBbjhG1yW4Hprrl7gOiesQJDwYDD Pv6adZf0bHYWMC_ob4BzbEuoVZ6_bTY.Y4BiQ9kdQTSoA2Urrl0jsv8oKls5 hRNiXanisOOxce32yvZ3Rkm8V7MH9OYfJmAPbQfQNw9BQX.eJzk4QHGE.UOq .UDAVvxbhULCX43cX3jwuzoIooBryQaUidxDnIetNyOjfnK2n1QpAqc.yiPU RcCuzuRFZ9UkUj_5y7vRS7HRp0hyMI0_eBLqRJIwYnsAaPUfiqq4TMu.WMbQ 1eP.GreNAvThVkqF1w5YvIpdPmGkr X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T X-Rocket-Received: from [192.168.0.102] (jsontest@76.29.100.42 with ) by smtp113.mail.ne1.yahoo.com with SMTP; 08 Jul 2013 00:16:42 -0700 PDT References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-815B28AE-536A-4049-8201-A6E3B7928F63 Content-Transfer-Encoding: 7bit Message-Id: <72BA0BFC-1C4D-4537-8B39-8B32F38D63E3@yahoo.com> X-Mailer: iPod Mail (9B206) From: Vinny A Date: Mon, 8 Jul 2013 02:16:39 -0500 To: Stephan Beal Cc: "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 08 Jul 2013 07:16:50 -0000 --Apple-Mail-815B28AE-536A-4049-8201-A6E3B7928F63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 7, 2013, at 1:09 PM, Stephan Beal wrote: > Streaming or not, enforcing the implied level of infrastructure and poten= tial performance hits which MUST implies is not something i plan on doing, e= ven if it means not being fully compliant. "Duplicate keys lead to unspecifi= ed behaviour," end of story. >=20 The TL;DR of this discussion seems to be that MUST is too restrictive for so= me (streaming parsers, overhead, etc) yet SHOULD leaves too much space for a= mbiguity (as it does in the current RFC 4627). I'd like to point this list's attention to a post Eliot made a while ago, wh= ere he suggested wording that 1) expresses heavy disapproval on an implement= ation, 2) still allows for an alternative implementation if (1) is not accep= table, 3) is relatively minimal wording (which seems to be a priority given l= ast week's discussions), and 4) has been used in previous RFCs. Here's the r= elevant comment: On Jun 5, 2013, at 3:08 PM, Eliot Lear wrote: > Demonstrating my age, an old trick we've done that goes back to RFC-1123 > is to say MUST NOT send, and then implementations MAY NOT process, and > if they do MUST process thusly... Could people come to a consensus on this if the proposed wording was similar= to the above? I.e "Implementations MUST NOT send duplicate names; if receiv= ed, parsers MAY NOT process the JSON, instead issuing an error. If implement= ations insist on supporting duplicated names, they MUST process in the follo= wing manner (insert boilerplate warnings about undesirable behavior)."=20 ----------------- Vinny www.jsontest.com --Apple-Mail-815B28AE-536A-4049-8201-A6E3B7928F63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

O= n Jul 7, 2013, at 1:09 PM, Stephan Beal <sgbeal@googlemail.com> wrote:

 Streaming or not, enforcing the implied level= of infrastructure and potential performance hits which MUST  implies i= s not something i plan on doing, even if it means not being fully compliant.= "Duplicate keys lead to unspecified behaviour," end of story.


The TL;DR of th= is discussion seems to be that MUST is too restrictive for some (streaming p= arsers, overhead, etc) yet SHOULD leaves too much space for ambiguity (as it= does in the current  RFC 4627).

I'd like to p= oint this list's attention to a post Eliot made a while ago, where he sugges= ted wording that 1) expresses heavy disapproval on an implementation, 2) sti= ll allows for an alternative implementation if (1) is not acceptable, 3) is r= elatively minimal wording (which seems to be a priority given last week's di= scussions), and 4) has been used in previous RFCs. Here's the relevant comme= nt:

On Jun 5, 2013, at 3:08 PM, Eliot Lear <lear@cisco.com> wrote:
= Demonstrating my age, an old trick we've done that goes back to RFC-1123
is to say MUST NOT send, and then implementations MAY NOT proce= ss, and
if they do MUST process thusly...

Could people come to a consensus on this if the p= roposed wording was similar to the above? I.e "Implementations MUST NOT send= duplicate names; if received, parsers MAY NOT process the JSON, instead iss= uing an error. If implementations insist on supporting duplicated names, the= y MUST process in the following manner (insert boilerplate warnings about un= desirable behavior)." 

-----------------
Vinny
=


= --Apple-Mail-815B28AE-536A-4049-8201-A6E3B7928F63-- From lear@cisco.com Mon Jul 8 00:32: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 3D0E011E81A3 for ; Mon, 8 Jul 2013 00:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.459 X-Spam-Level: X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 jB3vrYDehPk4 for ; Mon, 8 Jul 2013 00:32:10 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 90AE711E81B0 for ; Mon, 8 Jul 2013 00:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=936; q=dns/txt; s=iport; t=1373268727; x=1374478327; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=t5FjVk28QVBCYZGf0+eIlugjQbWIdFSMlZO+Rk0xksU=; b=imc3HQAG6S1mie+apVy+89vAVka0U+WmU1ZeVOfbHBdh+meqIbPjrjT5 QDpAdTv7+fOv5fX1+tof5pMs/NRfVpiaCbKc/kx+zStpgh7aatbuhhSDA JI8RKe/8sBqTrNqbY/3o9FKJH07X4QB9bPNBzz2oKQzNQHfFld3e0XqzU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAN5o2lGQ/khL/2dsb2JhbABagwmEB71ZgQ4WdIIjAQEBBCNVARALGAICBRYLAgIJAwIBAgErGgYNAQcBAYgLp1CQToEmjkUHglSBHAOXU5FIgxM6 X-IronPort-AV: E=Sophos;i="4.87,1018,1363132800"; d="scan'208";a="14956807" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 08 Jul 2013 07:32:04 +0000 Received: from mctiny.local ([10.61.160.194]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r687W2dK010285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jul 2013 07:32:02 GMT Message-ID: <51DA6AF2.8050205@cisco.com> Date: Mon, 08 Jul 2013 09:32:02 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Cowan References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <20130707181121.GB11346@mercury.ccil.org> In-Reply-To: <20130707181121.GB11346@mercury.ccil.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Stephan Beal , "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 08 Jul 2013 07:32:15 -0000 And this is where we simply can't code ourselves out of a paper bag. The reason one generally doesn't hardcode rules at the lower layer is that you don't have visibility as to what the poor practice is. Here we do. ALSO, I'll go one farther. The generator itself needn't always keep state. It simply needs to be told to keep state or not. If it is told not to, then the upper layer is assumed to be doing so, but at that point it is not a matter for the wire protocol, which is where we are. Eliot On 7/7/13 8:11 PM, John Cowan wrote: > Stephan Beal scripsit: > >> i'm for not splitting them into categories, as this document really has no >> business (IMO) specifying that level of implementation detail. Specify the >> duplicate keys as poor practice leading to >> unspecified/implementation-defined behaviour, and be done it. > +1 to that. "Unspecified behavior" is another way of saying "is an error". > From markus.lanthaler@gmx.net Mon Jul 8 01:32: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 AAF6E11E819D for ; Mon, 8 Jul 2013 01:32:08 -0700 (PDT) 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 ODG+rVVWJVOq for ; Mon, 8 Jul 2013 01:32:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 9A66221F8447 for ; Mon, 8 Jul 2013 01:29:45 -0700 (PDT) Received: from Vostro3500 ([77.117.246.63]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MUYiV-1UmvzZ0gFP-00RJWV for ; Mon, 08 Jul 2013 10:29:34 +0200 From: "Markus Lanthaler" To: References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <72BA0BFC-1C4D-4537-8B39-8B32F38D63E3@yahoo.com> In-Reply-To: <72BA0BFC-1C4D-4537-8B39-8B32F38D63E3@yahoo.com> Date: Mon, 8 Jul 2013 10:29:27 +0200 Message-ID: <009601ce7bb5$46045870$d20d0950$@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: Ac57qyDJcJOw8ZkGSpyqab6OudLz6gACZD5Q Content-Language: de X-Provags-ID: V03:K0:TuTggNNrC+g8vDI0Ufaekz8+wsmJEYrM/GUf8tGG5zvo9x3YC/Z U8nZKwb0cvL9iYg7/gMnH3+4H2q8BiMACytRFP7sL2Txc59HkJnOpCM05M1hyvsUNozhz+b e4gEddSNXkwGIOmlMohqbvLXh7+VNngkVQAtNSy779xCuarZzYptVxkzcikgo0HNacf/QsF FBKLMqM7+cVOi2WLibh5g== Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 08 Jul 2013 08:32:49 -0000 On Monday, July 08, 2013 9:17 AM, Vinny A wrote: > On Jun 5, 2013, at 3:08 PM, Eliot Lear wrote: >> Demonstrating my age, an old trick we've done that goes back to = RFC-1123 >> is to say MUST NOT send, and then implementations MAY NOT process, = and >> if they do MUST process thusly... >=20 > Could people come to a consensus on this if the proposed wording was > similar to the above? I.e "Implementations MUST NOT send duplicate = names; > if received, parsers MAY NOT process the JSON, instead issuing an = error. > If implementations insist on supporting duplicated names, they MUST > process in the following manner (insert boilerplate warnings about > undesirable behavior)."=20 I personally could certainly live with something like this but the "MUST = NOT send" is problematic as such data exists and we shouldn't invalidate = it. Changing that to SHOULD NOT would probably be something more people = would be equally (un)happy with. -- Markus Lanthaler @markuslanthaler From sgbeal@googlemail.com Mon Jul 8 01:49: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 A9F5F11E81B8 for ; Mon, 8 Jul 2013 01:49:16 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622, 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 bQXamNIY0eKA for ; Mon, 8 Jul 2013 01:49:14 -0700 (PDT) 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 E0F8411E81AB for ; Mon, 8 Jul 2013 01:47:30 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so8688477wgg.5 for ; Mon, 08 Jul 2013 01:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Il8X8K9pLsH4AEm5P4XjT0A6MQhZLdBtB+Vw3amalyE=; b=DeW3nSo5XCojQy3bIKnDhJ1/ok/ZlCV25QkFYDUb9rg5ianoQ4dVUTTn4KUJijL+Ts Emqt9kptkj5CvmENgWZghmVN+XBoBBzH6Tsis7T4L+eIwsI+pjPaPz+Q8YyAvTKDaEmj zrh7XmQ9Q13/Ne1TAHeSYhEHPPydB1BIRxd5kHeE/iSHbghxlKt3+gFH9IspI/YUj1JL 7Nqfbe+Bv6f+wjOi+gC9AiLgbYqHOC+9LjQsdgICe5botopND9KO9N2r09T28DezNQWk aQcTgMv+PHey0qXm8cyawuuIT5rD7JTGtyrJeOHcoxAh0yoNwoTg/l+XEpqiuq1AerzU 5HfA== MIME-Version: 1.0 X-Received: by 10.180.185.148 with SMTP id fc20mr11258083wic.0.1373273204386; Mon, 08 Jul 2013 01:46:44 -0700 (PDT) Received: by 10.194.1.241 with HTTP; Mon, 8 Jul 2013 01:46:44 -0700 (PDT) In-Reply-To: <51da79b4.84e9440a.45eb.ffffaadeSMTPIN_ADDED_BROKEN@mx.google.com> References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <72BA0BFC-1C4D-4537-8B39-8B32F38D63E3@yahoo.com> <51da79b4.84e9440a.45eb.ffffaadeSMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 8 Jul 2013 10:46:44 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a11c23f3686f27d04e0fc1564 Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 08 Jul 2013 08:49:20 -0000 --001a11c23f3686f27d04e0fc1564 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 8, 2013 at 10:29 AM, Markus Lanthaler wrote: > On Monday, July 08, 2013 9:17 AM, Vinny A wrote: > > Could people come to a consensus on this if the proposed wording was > > similar to the above? I.e "Implementations MUST NOT send duplicate names; > > if received, parsers MAY NOT process the JSON, instead issuing an error. > > If implementations insist on supporting duplicated names, they MUST > > process in the following manner (insert boilerplate warnings about > > undesirable behavior)." > > I personally could certainly live with something like this but the "MUST > NOT send" is problematic as such data exists and we shouldn't invalidate > it. Changing that to SHOULD NOT would probably be something more people > would be equally (un)happy with. > >From me, certainly. i don't see "MUST NOT SEND" as being too helpful because the receivers need to be able to recognize the existence of dupes in that case. i.e. it implies a MUST on the consumers, and the "must" on the consumers is what i find most prickly in this particular topic. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --001a11c23f3686f27d04e0fc1564 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 8, 2013 at 10:29 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
On Monday, July 08, 2013 9= :17 AM, Vinny A wrote:
> Could people come to a consensus on this if = the proposed wording was
> similar to the above? I.e "Implementations MUST NOT send duplicat= e names;
> if received, parsers MAY NOT process the JSON, instead issuing an erro= r.
> If implementations insist on supporting duplicated names, they MUST > process in the following manner (insert boilerplate warnings about
> =A0undesirable behavior)."

I personally could certainly live with something like this but the &q= uot;MUST NOT send" is problematic as such data exists and we shouldn&#= 39;t invalidate it. Changing that to SHOULD NOT would probably be something= more people would be equally (un)happy with.

From me, certainly. i don't see "= MUST NOT SEND" as being too helpful because the receivers need to be a= ble to recognize the existence of dupes in that case. i.e. it implies a MUS= T on the consumers, and the "must" on the consumers is what i fin= d most prickly in this particular topic.

--
----- stephan beal
http://wanderinghorse.net/home= /stephan/
--001a11c23f3686f27d04e0fc1564-- From lear@cisco.com Mon Jul 8 02:06: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 12FF621F9A6C for ; Mon, 8 Jul 2013 02:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.463 X-Spam-Level: X-Spam-Status: No, score=-110.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 vt5D92Z+M37i for ; Mon, 8 Jul 2013 02:05:45 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA6E21F84B6 for ; Mon, 8 Jul 2013 02:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=591; q=dns/txt; s=iport; t=1373274323; x=1374483923; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mja6zBGf8M+RNwhpYXCGJ/P17gaX9LKC8MPhi82vmFc=; b=MWHghU4wIIfuhjFpZ0CBdOLJwS1BMPNMT3e6PbQWQ7V+8rMIsXgbWdGI NMFnnyqSsVjqHm4Cd0o8ISa3/eomevfQcofyTcHU2O56FxhBqIBqmIMJA m5WRVWcO7b5zHGkXVZgDbijWR3TX9Uj7hfzdC2nXpmGyh2aDw+mUv+M5Z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAG9/2lGQ/khR/2dsb2JhbABagwmEB71ZgRAWdIIjAQEBAwEjVQEQCw4MAgUWCwICCQMCAQIBKxoGDQEHAQGIBQanM5BagSaORQeCVIEcA5dTkUiDEzo X-IronPort-AV: E=Sophos;i="4.87,1019,1363132800"; d="scan'208";a="14959545" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 08 Jul 2013 09:05:05 +0000 Received: from mctiny.local ([10.61.211.183]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r68952i6029437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jul 2013 09:05:02 GMT Message-ID: <51DA80BE.8000902@cisco.com> Date: Mon, 08 Jul 2013 11:05:02 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephan Beal References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <72BA0BFC-1C4D-4537-8B39-8B32F38D63E3@yahoo.com> <51da79b4.84e9440a.45eb.ffffaadeSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 08 Jul 2013 09:06:02 -0000 On 7/8/13 10:46 AM, Stephan Beal wrote: > > > From me, certainly. i don't see "MUST NOT SEND" as being too helpful > because the receivers need to be able to recognize the existence of > dupes in that case. i.e. it implies a MUST on the consumers, and the > "must" on the consumers is what i find most prickly in this particular > topic. > No such implication exists. Often we say "MUST NOT" to the sender and then prescribe "MAY or SHOULD" some behavior (like an error) the receiver. There are many reasons for this, but a good one is security or resource processing. From cowan@ccil.org Mon Jul 8 04:55: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 88AB121F924A for ; Mon, 8 Jul 2013 04:55:09 -0700 (PDT) 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 UhVt7V0iil9y for ; Mon, 8 Jul 2013 04:55:05 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7AC21F91A5 for ; Mon, 8 Jul 2013 04:55:04 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UwA21-0006Wa-VG; Mon, 08 Jul 2013 07:55:02 -0400 Date: Mon, 8 Jul 2013 07:55:01 -0400 From: John Cowan To: Vinny A Message-ID: <20130708115501.GB27795@mercury.ccil.org> References: <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <72BA0BFC-1C4D-4537-8B39-8B32F38D63E3@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72BA0BFC-1C4D-4537-8B39-8B32F38D63E3@yahoo.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Stephan Beal , "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 08 Jul 2013 11:55:09 -0000 Vinny A scripsit: > Could people come to a consensus on this if the proposed wording was > similar to the above? I.e "Implementations MUST NOT send duplicate > names; if received, parsers MAY NOT process the JSON, instead issuing > an error. If implementations insist on supporting duplicated names, > they MUST process in the following manner (insert boilerplate warnings > about undesirable behavior)." "MAY NOT" is not RFC 2119 language, and for good reason: it's ambiguous between "must not" (as in "You may not leave the room") and "may" ("We may not go, I don't know yet", which is synonymous with "We may go, I don't know yet"). -- Some people open all the Windows; John Cowan wise wives welcome the spring cowan@ccil.org by moving the Unix. http://www.ccil.org/~cowan --ad for Unix Book Units (U.K.) (see http://cm.bell-labs.com/cm/cs/who/dmr/unix3image.gif) From cabo@tzi.org Mon Jul 8 05:17: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 4DE7921F9EE1 for ; Mon, 8 Jul 2013 05:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.163 X-Spam-Level: X-Spam-Status: No, score=-106.163 tagged_above=-999 required=5 tests=[AWL=0.086, 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 XKRjSE9uD1Z2 for ; Mon, 8 Jul 2013 05:17:15 -0700 (PDT) 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 33AE721F89EB for ; Mon, 8 Jul 2013 05:17:14 -0700 (PDT) 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 r68CHClX026114 for ; Mon, 8 Jul 2013 14:17:12 +0200 (CEST) Received: from [192.168.217.105] (p54894869.dip0.t-ipconnect.de [84.137.72.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 023A43A73; Mon, 8 Jul 2013 14:17:11 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Jul 2013 14:17:10 +0200 To: "json@ietf.org WG" Message-Id: <9326419D-73C0-4098-91F0-0E83A7FEA67A@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [Json] I-JSON vs. JSON-S 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, 08 Jul 2013 12:17:21 -0000 We'll have to bite the bullet at some point and acknowledge there there are two levels of interoperability in the JSON ecosystem: I-JSON and JSON-S. I-JSON is the syntax adapted from JavaScript plus the data model. Maps are maps, and strings are (Unicode character) strings. I-JSON is highly interoperable between different JSON implementations. (I-JSON stands for "interoperable JSON" or Tim Bray's "Internet JSON".) JSON-S is just the syntax. The data model being used may be related to that of JSON, but ultimately is application specific. So, Solr can have their repeated keys, the "array of general 16-bit values" faction can have their unpaired surrogates, etc. When people talk about "not breaking things", it is just not clear whether they mean "carry along all usages of JSON-S" or "make sure all I-JSON implementations stil interoperate flawlessly". That's why the current charter may have less of a defined meaning than it appears. Unless the two levels of interoperability are clearly identified, it is not possible to break neither. Gr=FC=DFe, Carsten From derhoermi@gmx.net Mon Jul 8 08:25: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 3964D21F9A57 for ; Mon, 8 Jul 2013 08:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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-JwMV1Op8cf for ; Mon, 8 Jul 2013 08:25:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 14A1921F8F38 for ; Mon, 8 Jul 2013 08:25:30 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.54.144]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0LrIPo-1UCwJe1ZYi-0137JL; Mon, 08 Jul 2013 17:25:28 +0200 From: Bjoern Hoehrmann To: Carsten Bormann Date: Mon, 08 Jul 2013 17:25:25 +0200 Message-ID: <6milt8df307ep0rtfo2pp6ghgsiea25djb@hive.bjoern.hoehrmann.de> References: <9326419D-73C0-4098-91F0-0E83A7FEA67A@tzi.org> In-Reply-To: <9326419D-73C0-4098-91F0-0E83A7FEA67A@tzi.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:xu4PM8phKZx31+GSJgy7m3CdjGQGaHzmEXgzqj9vTvbT4pGybqD ezsaxZW5ZO2enyJdjInaWuTIwv9tjR6DfaXgw1hFA0y5UaFyV+DUXwquZS3muIt0xRr619n EkKf3vhKQawSPl+6iAdZ7gJrJ/wtmmlnyW1VUjqXJCEAanWZIxie+gT1r28ubqpp6uYg9Ds i+e+CPA4Nh7zbxTckQZmg== Cc: "json@ietf.org WG" Subject: Re: [Json] I-JSON vs. JSON-S 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, 08 Jul 2013 15:25:35 -0000 * Carsten Bormann wrote: >When people talk about "not breaking things", it is just not clear >whether they mean "carry along all usages of JSON-S" or "make sure all >I-JSON implementations stil interoperate flawlessly". That's why the >current charter may have less of a defined meaning than it appears. >Unless the two levels of interoperability are clearly identified, it >is not possible to break neither. http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/ proposes that the XMLHttpRequest implementations parse JSON HTTP responses by way of JSON.parse(decode_utf8_with_bom_and_error_recovery(bytes)) That extends and subsets what is defined in RFC 4627. If this is imple- mented as proposed, and my parser does something else, I may eventually have to deal with bug reports telling me "but it works with XHR". And I might have to adapt my parser. Same for many other implementations. http://www.w3.org/TR/2012/WD-xslt-30-20120710/#func-parse-json proposes a `parse-json` function that takes option parameters like "RFC4627" and "ECMA-262" to select among JSON profiles. People seeing this might ask that my parser also has such options. We could take RFC4627-JSON, remove unpaired surrogate escapes and dupli- cate keys and call it RFC7xxx-JSON, but that would make ECMA-JSON and RFC-JSON more different. RFC4627-JSON with all values at the top level allowed would make them more similar. It would improve our understanding of what is JSON. -- 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 Mon Jul 8 09:35:10 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 6482D21F842E for ; Mon, 8 Jul 2013 09:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 ta5N8zd+Gh3h for ; Mon, 8 Jul 2013 09:35:05 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3C421F8C40 for ; Mon, 8 Jul 2013 09:35:05 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 2B5C967407B for ; Mon, 8 Jul 2013 09:35:05 -0700 (PDT) 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=GyJJ2Qin55yUW7igQKp0 GyQpMsM=; b=SaaG5ndWkEYTyPFjnd98b0jM4m3lTmiHsK6bLoKEABYVbEiUJw7L vqT1f5FFOx++DrQRnLCu/GZYIbW5GuUfs8UzmZC3JviKybRkpxicWnJDsxIQIIU4 THI2VanLEiXst0tWxdEknyieGQeF/5X5X+c/ohuhgx0bPqIzchsrQGY= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 27BBE674089 for ; Mon, 8 Jul 2013 09:35:03 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so9237941wiv.13 for ; Mon, 08 Jul 2013 09:35:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xpGE9v+fE7vIDiQhno6x80NNFJi2nuBm3S7l2IX6BCQ=; b=D54Lz8pcByOLSfxN3dtsAwHQq/to8DrJpCAizuBMPg1guild/3+xn6+HSwYQm2qUvO mztNpEmW9dyM8wR+I1939cTUD1loFbR74YxevwS6MAaIAvPHmDKaZ5oN3LtGBT8V/aup bXa9eKNgI4Qt4VTBEGDWW1ApYFh/u+Hq/jkiNAhoX82jlfCaNpRM7j4vCzc4n2Uemrdm dppEqLoPQflwf/9dCsGOhrpwsr1w+VUM8uKXrQTRb0KpRghzrveOJALeQeE1DInEVFg6 z3m/u/ivNzJukD7LhTB0pIPuih9ssLMvoHLEaYKeHEhSpiTiCWbLpcBZqWN4Mn1DKf8a I80A== MIME-Version: 1.0 X-Received: by 10.180.210.148 with SMTP id mu20mr29404494wic.38.1373301301273; Mon, 08 Jul 2013 09:35:01 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Mon, 8 Jul 2013 09:35:01 -0700 (PDT) In-Reply-To: <9326419D-73C0-4098-91F0-0E83A7FEA67A@tzi.org> References: <9326419D-73C0-4098-91F0-0E83A7FEA67A@tzi.org> Date: Mon, 8 Jul 2013 11:35:01 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org WG" Subject: Re: [Json] I-JSON vs. JSON-S 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, 08 Jul 2013 16:35:10 -0000 On Mon, Jul 8, 2013 at 7:17 AM, Carsten Bormann wrote: > JSON-S is just the syntax. The data model being used may be related > to that of JSON, but ultimately is application specific. So, Solr can > have their repeated keys, the "array of general 16-bit values" > faction can have their unpaired surrogates, etc. I think even for JSON-S we should leave the duplicate name text that's in RFC4627. Solr can still have their dup names, and strings would be arrays of 16-bit code units. > When people talk about "not breaking things", it is just not clear > whether they mean "carry along all usages of JSON-S" or "make sure all > I-JSON implementations stil interoperate flawlessly". That's why the > current charter may have less of a defined meaning than it appears. I think "don't break me" mostly means: allow my non-I-JSON usage. I-JSON is about guaranteeing interop because we [will] have a standard with sufficiently normative language. So, mostly agreed. > Unless the two levels of interoperability are clearly identified, it > is not possible to break neither. Interop will require specifying which JSON you're using, or actually sticking to a subset of JSON that happens to interop (which will be very close to I-JSON, if not exactly I-JSON). Seems fine to me, given that we have no other way forward. Nico -- From nico@cryptonector.com Mon Jul 8 09:38: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 4312421F9D61 for ; Mon, 8 Jul 2013 09:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=-0.571, 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 cC84XdQK--yB for ; Mon, 8 Jul 2013 09:38:38 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6734A21F9D53 for ; Mon, 8 Jul 2013 09:38:38 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 3CB0A50808D for ; Mon, 8 Jul 2013 09:38:38 -0700 (PDT) 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=81Yth1TpHNNvN4mp5xbP wn6GJaY=; b=XSCwD+D3XXLEfdiZzqMXBihUeHYK4u5l/EhNqDUp2Uz6KSqILDkC PPfzbw7+QfGvi3jsk1ArDirSCPWwiFqcL+LMAcDws/FuUVjSgNFBhpv0cvbyMMZs YZkhkGPskQfl7RSMV/E2VInPW/4exIdwY62CKx54yp8e9iClhKeqYM4= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id DCB9B508064 for ; Mon, 8 Jul 2013 09:38:37 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ey16so4165461wid.4 for ; Mon, 08 Jul 2013 09:38:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w+MGLFnT1cXNpsu07az403FYHmMlVIUy2h4imx3FxwQ=; b=RA0vqtgmdklCJhYbBckjEKMTCsg39I1j5G+V16exMaf1LU92S47RTxD0hT/1XmG63L aL2++VtnPXne1eAxDeS+mOeHmVrjDs9C0ydR2+7mIbOV28jMJbN/B/fB8cjTsMbuMwfq NWMilFXOyc/Y2LJRkrpfQiTXCXOYPigkFqrrQF++im++xg+6buQn1ViTLcd4Y1s8rdFo fi1J26AjmZAzjQGvWQApJylQh27jro29UDL0OIRJsE3Qj2EqOU32FwynjWxZOoWRZm5q MmKD7Qrc4hgLzqL1o7bjfxuMrOYFSkPVhEC5zmUJbkTdiQt4h7xce1VTUk6zIqQ1SB3w yCog== MIME-Version: 1.0 X-Received: by 10.194.173.37 with SMTP id bh5mr13055049wjc.30.1373301516396; Mon, 08 Jul 2013 09:38:36 -0700 (PDT) Received: by 10.216.152.73 with HTTP; Mon, 8 Jul 2013 09:38:36 -0700 (PDT) In-Reply-To: <6milt8df307ep0rtfo2pp6ghgsiea25djb@hive.bjoern.hoehrmann.de> References: <9326419D-73C0-4098-91F0-0E83A7FEA67A@tzi.org> <6milt8df307ep0rtfo2pp6ghgsiea25djb@hive.bjoern.hoehrmann.de> Date: Mon, 8 Jul 2013 11:38:36 -0500 Message-ID: From: Nico Williams To: Bjoern Hoehrmann Content-Type: text/plain; charset=UTF-8 Cc: Carsten Bormann , "json@ietf.org WG" Subject: Re: [Json] I-JSON vs. JSON-S 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, 08 Jul 2013 16:38:43 -0000 On Mon, Jul 8, 2013 at 10:25 AM, Bjoern Hoehrmann wrote: > http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/ proposes that the > XMLHttpRequest implementations parse JSON HTTP responses by way of > > JSON.parse(decode_utf8_with_bom_and_error_recovery(bytes)) > > That extends and subsets what is defined in RFC 4627. If this is imple- > mented as proposed, and my parser does something else, I may eventually > have to deal with bug reports telling me "but it works with XHR". And I > might have to adapt my parser. Same for many other implementations. Every parser (and generator) I've seen takes options arguments. For all our debates over this I think we'll probably just end up with most implementations supporting both JSON forms. > http://www.w3.org/TR/2012/WD-xslt-30-20120710/#func-parse-json proposes > a `parse-json` function that takes option parameters like "RFC4627" and > "ECMA-262" to select among JSON profiles. People seeing this might ask > that my parser also has such options. No doubt they will. > We could take RFC4627-JSON, remove unpaired surrogate escapes and dupli- > cate keys and call it RFC7xxx-JSON, but that would make ECMA-JSON and > RFC-JSON more different. RFC4627-JSON with all values at the top level > allowed would make them more similar. It would improve our understanding > of what is JSON. I agree that allowing any types at the top-level seems like a no-brainer, but others disagree vehemently, and I don't think I care that much about that. Nico -- From tsaloranta@gmail.com Mon Jul 8 16:18: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 41AB421F9AD1 for ; Mon, 8 Jul 2013 16:18:11 -0700 (PDT) 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=[AWL=0.000, 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 jVdCeBUZwmwj for ; Mon, 8 Jul 2013 16:18:10 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7806A21F9546 for ; Mon, 8 Jul 2013 16:18:10 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so9551128wib.16 for ; Mon, 08 Jul 2013 16:18:09 -0700 (PDT) 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=kBb5gmGrZdtzbuKxYIIbwBWl2s704KsrdZN5YgEvN+s=; b=PzwI7S01d+g/qTlbh/4D+Yw/ikttQKf76/7IT5eit+CGNXhgBbw1Z7Jf+2sAzqh3R0 o5Odhvpu8LUTTD71jUb1OXtPm7m+vH9bhARIstLvqdhOI+Fo+TiqddpYFQVmkcrDtKnZ 5vxTDTwA/HSZ7mKUVZ4yi4QVEvZMWp8Mev4k3mtdoggsDmGaSPRzG2HUZjFnnyj68yIf +4EtyMKFOVYKRQlxkm7kH0WROu+5Aayke1QWI2fwbrdzZk06EZy2oNXJGHdOVcUo5Tzd /iccI6nRpF2gPhoaZNXDsn7hfqAMepBUALHSKaWo7a6lys/F58JWYz7R0NbrYHTmKEos qlzw== MIME-Version: 1.0 X-Received: by 10.180.11.146 with SMTP id q18mr11652522wib.50.1373325489457; Mon, 08 Jul 2013 16:18:09 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Mon, 8 Jul 2013 16:18:09 -0700 (PDT) In-Reply-To: <20130707184322.GA16880@mercury.ccil.org> References: <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <20130707180955.GA11346@mercury.ccil.org> <18CB0DCA-36FA-4900-9A56-43ECECF2A21A@tzi.org> <20130707184322.GA16880@mercury.ccil.org> Date: Mon, 8 Jul 2013 16:18:09 -0700 Message-ID: From: Tatu Saloranta To: John Cowan Content-Type: multipart/alternative; boundary=001a11c24d16f5d27404e1084146 Cc: Carsten Bormann , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 08 Jul 2013 23:18:11 -0000 --001a11c24d16f5d27404e1084146 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 7, 2013 at 11:43 AM, John Cowan wrote: > Carsten Bormann scripsit: > > > In many JSON designs, the receiver knows the full set of keys ahead > > of time. In this case, you are better off with conditionally interning > > it (i.e., if I already have the symbol, return it, otherwise keep the > > string around, now we know that it didn't map to a known key). > > I don't know any way to do that in Java, because there seems to be no > way to ask if a string is interned except by interning it. > This can be done if caller has a way to indicate set of expected possible names, which may be the case for data-binding. This also means that actual intern()ing can be done ahead of time, and potentially decode straight from byte sequences to intern()ed Strings. Jackson does something similar, although it goes via general symbol table as reuse coupled with multi-level, varying vocabularies becomes rather hairy thing to manage (multi-level symbol tables). Anyway... this works for subset of cases; and many users use dynamically generated names, open-ended domain. -+ Tatu +- --001a11c24d16f5d27404e1084146 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 7, 2013 at 11:43 AM, John Cowan <cowan@m= ercury.ccil.org> wrote:
Carsten Bormann scripsit:

> In many JSON designs, the receiver knows the full set of keys ahead > of time. =A0In this case, you are better off with conditionally intern= ing
> it (i.e., if I already have the symbol, return it, otherwise keep the<= br> > string around, now we know that it didn't map to a known key).

I don't know any way to do that in Java, because there seems to b= e no
way to ask if a string is interned except by interning it.

This can be = done if caller has a way to indicate set of expected possible names, which = may be the case for data-binding. This also means that actual intern()ing c= an be done ahead of time, and potentially decode straight from byte sequenc= es to intern()ed Strings. Jackson does something similar, although it goes = via general symbol table as reuse coupled with multi-level, varying vocabul= aries becomes rather hairy thing to manage (multi-level symbol tables).

Anyway... this works for subset of cases; and many users use dynamicall= y generated names, open-ended domain.

-+ Tatu +-

<= /div>

=A0
--001a11c24d16f5d27404e1084146-- From tsaloranta@gmail.com Mon Jul 8 16:24: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 326EA11E80AE for ; Mon, 8 Jul 2013 16:24:51 -0700 (PDT) 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=[AWL=0.000, 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 rPiZ6sSr4muj for ; Mon, 8 Jul 2013 16:24:50 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E2F7911E80D9 for ; Mon, 8 Jul 2013 16:24:49 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so4224798wes.12 for ; Mon, 08 Jul 2013 16:24:48 -0700 (PDT) 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=Fb/JRwDt6yvUIauHfZKzGn60Jfys691XXpKBOy7103k=; b=sPe+VziHo+6shM7FLP8SW/TpaPqHy5Ql+AkJC6BBVMqD7qwDIzZDT6NDsjQcPsF7jK 1FK0dD8r5ED0H99EJ+UvM+g0JfESYSNlo8Kf2xzc87/SQO2gJBQ4cNeJNXZWABUQ2riE i7+vlGGM6JRxMnuy+cI5HG4IjqSj412xOOaSlZ83MhOz4Pb9xnK42gB+srOaAv+ZkqbS KEeXvbfZyMrXOzfJWEumCKklg0axYZAKJF7ksqnTcqY5TtI3fRlWaQXYIxqypBzOdXON cpf8x6jMuGu2U+vGMTax+lvQVOzaNJXFYWuiMtaEkKIdEdKrYbG+ANQY1NhJG30r3W0x UP8Q== MIME-Version: 1.0 X-Received: by 10.194.179.129 with SMTP id dg1mr13857151wjc.38.1373325888845; Mon, 08 Jul 2013 16:24:48 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Mon, 8 Jul 2013 16:24:48 -0700 (PDT) In-Reply-To: <7adjt8hkf0lrirnloid2nnvg3ad2i7070k@hive.bjoern.hoehrmann.de> References: <7adjt8hkf0lrirnloid2nnvg3ad2i7070k@hive.bjoern.hoehrmann.de> Date: Mon, 8 Jul 2013 16:24:48 -0700 Message-ID: From: Tatu Saloranta To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=089e013d194ec400d404e108592a Cc: "json@ietf.org" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 08 Jul 2013 23:24:51 -0000 --089e013d194ec400d404e108592a Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 7, 2013 at 11:57 AM, Bjoern Hoehrmann wrote: > * Tatu Saloranta wrote: > >If this aspect was lost due to clarification for solving a problem that > has > >more to do with concerns for _possible_ security issues, that would be > sad. > > > >End users rarely have real need for minimal-state parsing. It is > >framework-builders -- such as, say Solr, Elastic Search, Hadoop, JAX-RS > >implementations (these for Java, similar for other platforms) -- that care > >as performance implications there have more effect. And they are the ones > >that have legitimate use for minimal-state components. > > Note that the performance implications can easily become security impli- > cations. A naive implementation of checking for duplicates may well be > vulnerable to algorithmic complexity attacks causing denial of service > (by using maliciously crafted input that exhibits worst-case behavior). > > http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html for in- > stance surprisingly showed that many common environments had failed to > pay attention when the problem was addressed in Perl eight years prior. > > Yes, good point. -+ Tatu +- --089e013d194ec400d404e108592a Content-Type: text/html; charset=ISO-8859-1
On Sun, Jul 7, 2013 at 11:57 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
* Tatu Saloranta wrote:
>If this aspect was lost due to clarification for solving a problem that has
>more to do with concerns for _possible_ security issues, that would be sad.
>
>End users rarely have real need for minimal-state parsing. It is
>framework-builders -- such as, say Solr, Elastic Search, Hadoop, JAX-RS
>implementations (these for Java, similar for other platforms) -- that care
>as performance implications there have more effect. And they are the ones
>that have legitimate use for minimal-state components.

Note that the performance implications can easily become security impli-
cations. A naive implementation of checking for duplicates may well be
vulnerable to algorithmic complexity attacks causing denial of service
(by using maliciously crafted input that exhibits worst-case behavior).

http://events.ccc.de/congress/2011/Fahrplan/events/4680.en.html for in-
stance surprisingly showed that many common environments had failed to
pay attention when the problem was addressed in Perl eight years prior.


Yes, good point.

-+ Tatu +-

--089e013d194ec400d404e108592a-- From pfpschneider@gmail.com Tue Jul 9 06:26: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 4132411E812A for ; Tue, 9 Jul 2013 06:26:50 -0700 (PDT) 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 XfpGMLY3yQeS for ; Tue, 9 Jul 2013 06:26:49 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 482D811E8128 for ; Tue, 9 Jul 2013 06:26:49 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j6so8034401oag.29 for ; Tue, 09 Jul 2013 06:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=uMQNhwPrnFLdDS/3cpbhThrW4KbRSzerSDk238Q2WWE=; b=VDbU+Q+tfUT51qO3xtdnci/h3rCv1d+rAOR/itW80TkrWeyObpqnykWvVwi4d05dLt tjvfg3Q1ecPfVBt13nR4cjVVV3DixPyN5Iuzu4A5k6aZCtxjsrTjKM2UXnssa+NZSRxx ooRR5OpNFaxdkJkT9Atqgzz7uXk002V2aJRH1VgsTp9ocmEQh5uknw4+WnR79JuG1hxs WiPU/V+3pyz0r6z1t4eqsbEi+/vlrZR2AUGubqD2K1jCW8UWlF2/zfqHWo5/ZtnF7Alp m+en/RQqOeFVbIMR+qq1jNvNVOn8KgROMQ3hPOSKIpjD0n8CxQlbVwHLGfxXYRWl16LF JzdA== X-Received: by 10.182.196.1 with SMTP id ii1mr23779599obc.93.1373376407778; Tue, 09 Jul 2013 06:26:47 -0700 (PDT) Received: from [192.168.1.102] (out-on-148.wireless.telus.com. [207.219.69.148]) by mx.google.com with ESMTPSA id kz3sm38054410obb.6.2013.07.09.06.26.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 06:26:47 -0700 (PDT) Message-ID: <51DC0F95.7010407@gmail.com> Date: Tue, 09 Jul 2013 06:26:45 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: json@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 14:07:06 -0000 [I'm picking up this discussion rather late, but the issue has come up in JSON-LD, so I'm putting my oar in.] My informed understanding of JSON, from reading all the relevant documents, was (and again is) also that JSON numbers are ECMAScript numbers are IEEE floating point doubles (minus some odd bits). I was astonished to find out that some people disagree, apparently to the point that they believe that 0 is different from .0 Not being clear on the primitive data types in JSON is a very bad thing, in my opinion. Peter F. Patel-Schneider From: Jacob Davies To: "json at ietf.org" Date: Wed, 5 Jun 2013 10:51:58 -0700 On Tue, Jun 4, 2013 at 9:05 PM, Nico Williams wrote: It might be nice to be able to specify some ranges that MUST be supported by decoders, but in practice I think we can't (and probably shouldn't try to) even do that. My past reading of the number section and the many references to _javascript_ in the spec led me to believe that the number type was _javascript_'s number type, and that compliance required you to accept & emit numbers only in that range (i.e. IEEE 754 64-bit numbers minus NaN and infinities). Implementation limits on the length of strings or size of arrays or objects were not specified either, but those are large enough in most languages that you're unlikely to run into them unexpectedly; if you are thinking of sending a terabyte of text in string or an object with a trillion keys it has probably occurred to you that some special interoperability concerns will apply. But just sending large 64-bit integers as numbers in a JSON string will cause you interoperability problems with _javascript_ and a lot of other JSON parsers, and my experience & some quick searches indicate this has been a common bug (or misunderstanding, perhaps) in implementations. I wouldn't say a size restriction should be specified either. But I think it might be worth noting this particular interoperability concern in the specification rather than just as a best practice. From sgbeal@googlemail.com Tue Jul 9 07:33:52 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 E35C921F9F36 for ; Tue, 9 Jul 2013 07:33:52 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622, 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 Z18Dw2nEaVPe for ; Tue, 9 Jul 2013 07:33:51 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E311D21F9EDF for ; Tue, 9 Jul 2013 07:33:50 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so10257065wiv.7 for ; Tue, 09 Jul 2013 07:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HGw9U6KOpbeBN3lqT7mwWvTmuL+GF4Sn4Nki4MmLHLY=; b=FJUOrPAiesl2lbUrq9yvpKwIRi3W7ccLoW33amZjTS6fVNs5hS4wvRCzbfzzO7QqsE Ho2gNDMwyj/e7xPKD1J+sP+AOSS3sAdA7kscZg4iuZygZyX102hzZU0V8g2jeKjqqcvi AFCVH2oIOn/7fNZn1U9/gd8aPYjasjK2ZmrnqndesKgbGbYErhSnC3TkQGWiRD2raUgx uQJ2/enRkUwq1OllaSlK24KATXgqeePX7ETEmo7SwwI5D/uFqTzs0zLku2Few367Ntvw /2O9UPC8byzI1HM54F6iGUtg+L6BzLEWdLCnA2MqydgWnVybbSwpOsBjH1H3ZElFwxFK 3BJg== MIME-Version: 1.0 X-Received: by 10.194.249.231 with SMTP id yx7mr15540445wjc.13.1373380429983; Tue, 09 Jul 2013 07:33:49 -0700 (PDT) Received: by 10.194.1.241 with HTTP; Tue, 9 Jul 2013 07:33:49 -0700 (PDT) In-Reply-To: <51DC0F95.7010407@gmail.com> References: <51DC0F95.7010407@gmail.com> Date: Tue, 9 Jul 2013 16:33:49 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a11c29cc4abb99504e1150c2b Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 14:33:53 -0000 --001a11c29cc4abb99504e1150c2b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 3:26 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > My informed understanding of JSON, from reading all the relevant > documents, was (and again is) also that JSON numbers are ECMAScript numbers > are IEEE floating point doubles (minus some odd bits). I was astonished to > find out that some people disagree, apparently to the point that they > believe that 0 is different from .0 > My (also informed) interpretation differs significantly ;). My last reading of the RFC didn't reveal any mention of numeric precision. i.e. an implementation which supports 5-bit precision is, from my reading of the RFC, completely legal (it only has to be able to read a number with the digits 0-9). Not being clear on the primitive data types in JSON is a very bad thing, in > my opinion. > It is impossible to require a specific precision because not all platforms/environments can guaranty a specific precision. > From: Jacob Davies > To: "json at ietf.org" > Date: Wed, 5 Jun 2013 10:51:58 -0700 > > On Tue, Jun 4, 2013 at 9:05 PM, Nico Williams > wrote: > .,,Implementation limits on the length of strings or size of arrays or > objects were not specified either > Which implies (to me) that a 5-bit-precision implementation is perfectly legal (though obviously not very useful). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --001a11c29cc4abb99504e1150c2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2013 at 3:26 PM, Peter F. Patel-Schneider <= span dir=3D"ltr"><pfpschneider@gmail.com> wrote:
My informed understanding of JSON, from read= ing all the relevant documents, was (and again is) also that JSON numbers a= re ECMAScript numbers are IEEE floating point doubles (minus some odd bits)= . =A0I was astonished to find out that some people disagree, apparently to = the point that they believe that 0 is different from .0

My (also informed) interpretation differs = significantly ;). My last reading of the RFC didn't reveal any mention = of numeric precision. i.e. an implementation which supports 5-bit precision= is, from my reading of the RFC, completely legal (it only has to be able t= o read a number with the digits 0-9).


Not being clea= r on the primitive data types in JSON is a very bad thing, in my opinion.

It is impossible to require a specific pre= cision because not all platforms/environments can guaranty a specific preci= sion.
=A0
From: Jacob Davies <jacob at well.com>
To: "json at ietf.org" <json at ietf.org<= /a>>
Date: Wed, 5 Jun 2013 10:51:58 -0700

On Tue, Jun 4, 2013 at 9:05 PM, Nico Williams <nico at cryptonector.com> wrote:
.,,= Implementation limits on the length of strings or size of arrays or objects= were not specified either


Which implies (to me) that = a 5-bit-precision implementation is perfectly legal (though obviously not v= ery useful).

--
----- stephan beal
http://wande= ringhorse.net/home/stephan/
--001a11c29cc4abb99504e1150c2b-- From cabo@tzi.org Tue Jul 9 07:42: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 7ED9821F9C6E for ; Tue, 9 Jul 2013 07:42:00 -0700 (PDT) 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 xeBialh9whLX for ; Tue, 9 Jul 2013 07:41:55 -0700 (PDT) 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 5579121F9EC4 for ; Tue, 9 Jul 2013 07:41:54 -0700 (PDT) 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 r69Efmj9006242; Tue, 9 Jul 2013 16:41:48 +0200 (CEST) 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 A74E035B1; Tue, 9 Jul 2013 16:41:48 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <51DC0F95.7010407@gmail.com> Date: Tue, 9 Jul 2013 16:41:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51DC0F95.7010407@gmail.com> To: "Peter F. Patel-Schneider" X-Mailer: Apple Mail (2.1508) Cc: json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 14:42:00 -0000 > JSON numbers are ECMAScript numbers That's a common misconception. JSON numbers are what they are (see the production "number" in RFC = 4627). JSON numbers obviously are decimal, ECMAScript numbers are binary. The text then goes on to say "The representation of numbers is similar = to that used in most programming languages."; most programming languages = distinguish 0 and 0.0 very heavily, and almost all modern ones have more = than 53 bits of precision in numbers, but most programming languages = also use binary numbers for the semantics of that decimal = representation. When generating JSON for high levels of interoperability, you wouldn't = want to rely on the recipient distinguishing 0 from 0.0, or more = generally on distinguishing two numbers that differ but map to the same = IEEE 754 double precision number. Some user communities have done the = latter*) and I know a lot of parsers that do the former. > ECMAScript numbers are IEEE floating point doubles (minus some odd = bits). =20 Indeed. > I was astonished to find out that some people disagree, apparently to = the point that they believe that 0 is different from .0 .0 is not a JSON number, but 0.0 is. Whether that is different from 0 is up to the data model (RFC 4627 is = mute about that, and I have reason to believe that is intentional); in = interoperable JSON, it would be foolish to rely on them being different = (but it is less clear to me how foolish it would be to rely on them not = being different), in JSON syntax, they clearly are different. Gr=FC=DFe, Carsten *) https://dev.twitter.com/docs/twitter-ids-json-and-snowflake From tbray@textuality.com Tue Jul 9 08:28:06 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 5462721F9E9E for ; Tue, 9 Jul 2013 08:28:06 -0700 (PDT) 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 Tr2UQJ7kp671 for ; Tue, 9 Jul 2013 08:28:02 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id C2E7921F9EB6 for ; Tue, 9 Jul 2013 08:28:01 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id c13so4776617vea.35 for ; Tue, 09 Jul 2013 08:28:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=rYB1VIcoA3LcEtHUEwOdUb04bpKLRdYK7esF5k7SKuY=; b=fOTPiqQdQ8Rop4NL2XJpfWBIJtK6L1zRRvIqG7XOzHZmJWreEYjrKPjZBG1LTzVRnb IG5CI6l+UA9M64hs3JE9Qp0RzAewk4GhQ8BicrJrtb0/zCkJ7TV3zEv4PKwMqEx79BLa KAwZ8lYYbC8X+7XnHO979zhH6kz+siy3LbqcRA5jM9tP/i///nTbyfQOrkPL/s6KDFyd 6Q47Bbn/aiFm/wkBbmJXsEgLe1zp285Lrh0pNG5fLM/hWfutNKRhEYjgT1W2cqAhu9Um sx5xFGZHEHcEm4g/7rk52n4oYM+xAULPnnmrSNdeLTIP32ZaX/q3ue26jWL3A1HvFGxL te9w== MIME-Version: 1.0 X-Received: by 10.52.90.115 with SMTP id bv19mr13888655vdb.108.1373383680178; Tue, 09 Jul 2013 08:28:00 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Tue, 9 Jul 2013 08:27:59 -0700 (PDT) X-Originating-IP: [12.232.193.126] In-Reply-To: References: <51DC0F95.7010407@gmail.com> Date: Tue, 9 Jul 2013 08:27:59 -0700 Message-ID: From: Tim Bray To: Carsten Bormann Content-Type: multipart/alternative; boundary=20cf307f38de65cf1804e115cee3 X-Gm-Message-State: ALoCoQkrq919gpMfc5Ahabc4o9MnfU09onLY6w4ILfVwAu7SY8JYRnwdjwKaJ4xeeaawe698AwmP Cc: "Peter F. Patel-Schneider" , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 15:28:06 -0000 --20cf307f38de65cf1804e115cee3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, we can=E2=80=99t retroactively change the 4627 production for number,= nor, in the -bis, say very much useful aside from a caution that implementations are all over the map. When we move on to the BCP or Internet JSON or whatever, I think the single most interesting discussion will be how to constrain numeric values for maximum interoperability. -T On Tue, Jul 9, 2013 at 7:41 AM, Carsten Bormann wrote: > > JSON numbers are ECMAScript numbers > > That's a common misconception. > > JSON numbers are what they are (see the production "number" in RFC 4627). > JSON numbers obviously are decimal, ECMAScript numbers are binary. > > The text then goes on to say "The representation of numbers is similar to > that used in most programming languages."; most programming languages > distinguish 0 and 0.0 very heavily, and almost all modern ones have more > than 53 bits of precision in numbers, but most programming languages also > use binary numbers for the semantics of that decimal representation. > > When generating JSON for high levels of interoperability, you wouldn't > want to rely on the recipient distinguishing 0 from 0.0, or more generall= y > on distinguishing two numbers that differ but map to the same IEEE 754 > double precision number. Some user communities have done the latter*) an= d > I know a lot of parsers that do the former. > > > ECMAScript numbers are IEEE floating point doubles (minus some odd bits= ). > > Indeed. > > > I was astonished to find out that some people disagree, apparently to > the point that they believe that 0 is different from .0 > > .0 is not a JSON number, but 0.0 is. > Whether that is different from 0 is up to the data model (RFC 4627 is mut= e > about that, and I have reason to believe that is intentional); in > interoperable JSON, it would be foolish to rely on them being different > (but it is less clear to me how foolish it would be to rely on them not > being different), in JSON syntax, they clearly are different. > > Gr=C3=BC=C3=9Fe, Carsten > > *) https://dev.twitter.com/docs/twitter-ids-json-and-snowflake > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --20cf307f38de65cf1804e115cee3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, we can=E2=80=99t retroactively change the 4627 = production for number, nor, in the -bis, say very much useful aside from a = caution that implementations are all over the map.=C2=A0 When we move on to= the BCP or Internet JSON or whatever, I think the single most interesting = discussion will be how to constrain numeric values for maximum interoperabi= lity.

-T


On Tue, Jul 9, 2013 at 7:41 AM, Carsten Bormann = <cabo@tzi.org><= /span> wrote:
> =C2=A0JSON numbers ar= e ECMAScript numbers

That's a common misconception.

JSON numbers are what they are (see the production "number" in RF= C 4627).
JSON numbers obviously are decimal, ECMAScript numbers are binary.

The text then goes on to say "The representation of numbers is similar= to that used in most programming languages."; most programming langua= ges distinguish 0 and 0.0 very heavily, and almost all modern ones have mor= e than 53 bits of precision in numbers, but most programming languages also= use binary numbers for the semantics of that decimal representation.

When generating JSON for high levels of interoperability, you wouldn't = want to rely on the recipient distinguishing 0 from 0.0, or more generally = on distinguishing two numbers that differ but map to the same IEEE 754 doub= le precision number. =C2=A0Some user communities have done the latter*) and= I know a lot of parsers that do the former.

> ECMAScript numbers are IEEE floating point doubles (minus some odd bit= s).

Indeed.

> I was astonished to find out that some people disagree, apparently to = the point that they believe that 0 is different from .0

.0 is not a JSON number, but 0.0 is.
Whether that is different from 0 is up to the data model (RFC 4627 is mute = about that, and I have reason to believe that is intentional); in interoper= able JSON, it would be foolish to rely on them being different (but it is l= ess clear to me how foolish it would be to rely on them not being different= ), in JSON syntax, they clearly are different.

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

*) https://dev.twitter.com/docs/twitter-ids-json-and-snowfla= ke

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

--20cf307f38de65cf1804e115cee3-- From derhoermi@gmx.net Tue Jul 9 09:23: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 5291E21F9CA4 for ; Tue, 9 Jul 2013 09:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 UXVUmOA0gtgN for ; Tue, 9 Jul 2013 09:23:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id CCB5F21F9CB1 for ; Tue, 9 Jul 2013 09:23:33 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.39.121]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MgKoE-1Ua6J43zlO-00Nl38; Tue, 09 Jul 2013 18:23:32 +0200 From: Bjoern Hoehrmann To: "Peter F. Patel-Schneider" Date: Tue, 09 Jul 2013 18:23:28 +0200 Message-ID: References: <51DC0F95.7010407@gmail.com> In-Reply-To: <51DC0F95.7010407@gmail.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:hoChWIw904rupxVcDZe8hxwSlaZXRZdkqpfvmXv+uw8m0y6viWi r8S+gEmhvawFqjulgC69SkX6TU//g8fuE1aOBb9EQSK7sMrzB4i2/6EYsTYN2m32fz4r7mp CCWz9gAsozSDS+a8Ykqxo9CBjJT3UWgLn/WG/HJZ+5HEjLKv7mIcBvCz798neqk43FKqgsF kkzhjuEH/zn+6d3YJhVgA== Cc: json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 16:23:41 -0000 * Peter F. Patel-Schneider wrote: >My informed understanding of JSON, from reading all the relevant documents, >was (and again is) also that JSON numbers are ECMAScript numbers are IEEE >floating point doubles (minus some odd bits). I was astonished to find out >that some people disagree, apparently to the point that they believe that 0 is >different from .0 RFC 4627 does not define this, but it notes among other things: Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted. If JSON used ecmascript semantics then `1e309` would be Infinity, `-1E-324` would be another way to write `-0.0`. Certain values like `0.12345678901234567` do have interoperability problems in practise, consider for instance that 0.12345678901234568 - 0.12345678901234566 != 0 (ecmascript and Perl) 0.12345678901234567 - 0.12345678901234566 == 0 (ecmascript) 0.12345678901234567 - 0.12345678901234568 == 0 (Perl) and libraries are known round on serialisation; while in ecmascript % es -e "JSON.stringify(JSON.parse('[0.12345678901234567]')))" "[0.12345678901234566]" in Perl % perl -MJSON -e "print JSON->new->encode(JSON->new ->decode('[0.12345678901234567]'))" [0.123456789012346] I think it is well-understood that if you need particularily small, big, precise or otherwise unusual numbers in JSON then it's best to encode them as strings so you can do the string-to-number conversion at a higher level than whatever JSON library you might be using today. -- 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 Jul 9 09:38:04 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 3345921F9E18 for ; Tue, 9 Jul 2013 09:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 GfMuiA8M2HSy for ; Tue, 9 Jul 2013 09:37:59 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC1921F9E96 for ; Tue, 9 Jul 2013 09:37:59 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 088B8350084 for ; Tue, 9 Jul 2013 09:37:52 -0700 (PDT) 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=ZCUBlr3TXZ93/FsZ3ewI Uz7N0KY=; b=puM5livWAQKOpKv2K2vmH4KBGy2ikC1BnzGhYFIG6zEgW8sVFLTI kqtFo/qkrHbkKhU13gi1CIdiQ6PETzW+YO2erO+JCRYcFy2Gp8DjFGIfNhZMMol4 WQQwVeCd8toLnwrTMDy5WDp/eRoRI3DFV3Bc3jOpR0WqU8XHktahb4E= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 9FF7E350079 for ; Tue, 9 Jul 2013 09:37:51 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so10413640wiv.1 for ; Tue, 09 Jul 2013 09:37:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LfZhQjD2vAAa/WZ5/ercXZKMmrQYPpeJ+KukqcYD9ms=; b=h/ouMk0OB9HNJuuEntVLB4o22OgjjGLVTnzmxXX6b7/nNRmwOUf0djn2gnJlgzgXlg 9t5ATChFkFNEZeBpSCpGd8k7oAE9WX6/yCxviSPbTk1ViRRtb1ZF6cRx8BEN5t6F7L7J 44QOvvbSxk5tRKHIyVh0mh9yug/Hqu9sQc4cW3yVZCJolWxv7tztPxmGyvDBcdK18kW+ fVPn1ZQc1R9h6t0aFM6WKWpv/9yPy/8B2cXfHybyF5KoPqKZ07aDUUo6v/e1MkXQzjpK NCQUc+S1LSO3Oce8cQKJKnjTdhGsnM4y11ZXeaTQLHeJsIbWcCv/e9rewALySkmIjNn7 0ivA== MIME-Version: 1.0 X-Received: by 10.194.240.169 with SMTP id wb9mr15038219wjc.90.1373387869747; Tue, 09 Jul 2013 09:37:49 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Tue, 9 Jul 2013 09:37:49 -0700 (PDT) In-Reply-To: References: <51DC0F95.7010407@gmail.com> Date: Tue, 9 Jul 2013 11:37:49 -0500 Message-ID: From: Nico Williams To: Bjoern Hoehrmann Content-Type: text/plain; charset=UTF-8 Cc: "Peter F. Patel-Schneider" , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 16:38:04 -0000 On Tue, Jul 9, 2013 at 11:23 AM, Bjoern Hoehrmann wrote: > I think it is well-understood that if you need particularily small, > big, precise or otherwise unusual numbers in JSON then it's best to > encode them as strings so you can do the string-to-number conversion > at a higher level than whatever JSON library you might be using today. If that's what we should always do then why can't parsers do it automatically? From markus.lanthaler@gmx.net Tue Jul 9 11:12:01 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 7C53621F9CA4 for ; Tue, 9 Jul 2013 11:12:01 -0700 (PDT) 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 XlRL3YOTM8aV for ; Tue, 9 Jul 2013 11:11:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 739ED21F9B18 for ; Tue, 9 Jul 2013 11:11:55 -0700 (PDT) Received: from Vostro3500 ([178.115.250.27]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lu2F0-1UEB0G0m8s-011SEd for ; Tue, 09 Jul 2013 20:11:54 +0200 From: "Markus Lanthaler" To: References: <51DC0F95.7010407@gmail.com> In-Reply-To: Date: Tue, 9 Jul 2013 20:11:49 +0200 Message-ID: <020801ce7ccf$c97c8ae0$5c75a0a0$@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: Ac58wrFGwtDhRHQeTpOc3VZ5PZAxxwADJ+Ig X-Provags-ID: V03:K0:ikoab/MBM+bFRdEN8ZY9BIPHWzSm8o4v42v4DbUHCmAkczxGrzT Nq9xxK1Zw+MP2PXqwxl7f1rpCiB1DVtG0AmX/hfeTdDRVzlbqlw05PUK07A1VeS75jrGCuL dUtHLSFHZYqMuzMDAbTOKhw+XibNR/PJHzLhzjOn2FWwhMEsm3ZAQEdkT72nojXwG7Cixsy qsC9N9EJ5m5xxFM41a0jA== Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 18:12:01 -0000 > On Tuesday, July 09, 2013 6:38 PM, Nico Williams wrote: > On Tue, Jul 9, 2013 at 11:23 AM, Bjoern Hoehrmann > wrote: > > I think it is well-understood that if you need particularily small, > > big, precise or otherwise unusual numbers in JSON then it's best to > > encode them as strings so you can do the string-to-number conversion > > at a higher level than whatever JSON library you might be using > today. > > > If that's what we should always do then why can't parsers do it > automatically? > Some parsers have options to support that. PHP, e.g. has a JSON_BIGINT_AS_STRING flag. -- Markus Lanthaler @markuslanthaler From nico@cryptonector.com Tue Jul 9 12:55: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 64A0B21F9CA7 for ; Tue, 9 Jul 2013 12:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 UfXw0yDSxU7j for ; Tue, 9 Jul 2013 12:55:42 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8433D21F9964 for ; Tue, 9 Jul 2013 12:55:42 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 0D34D67432C for ; Tue, 9 Jul 2013 12:55:42 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=q/8MVpSyb9vzlMUALC0FJh54Bms=; b=rqO3udRG4BR BpW7SQ/7n0BdBZ6x4LVBrpERRzoo5sMp+drEtdg0RgdMhmNQtIqqyz9+38fpRH+k juWb9zvJfAOG3i93u4FltjQrCJWr+wTTCtbiKhtbAGFjVx7ftgXmP5OLl5JM9iQP 3DRB/f3NJzzfR1hT9BRx0653k8voxrvI= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 39204674546 for ; Tue, 9 Jul 2013 08:38:03 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so4705836wev.8 for ; Tue, 09 Jul 2013 08:38:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Z3a0CfT3Itj/Dq5tqketsBoFeWf/boYmzjVblqpxawQ=; b=WYCvZBEn9pxC//cLNKYFiiYsNtsZ0yXYXugfx1oe3Gz5Mw2jaUe+gAhOMcD6kz13Rh 2JB3WdaIstBOIkKA8n0BAFXEyOQy8GsNJ/Uq1zoxtGnlzonTeiJimLEICTqKbBGRYOPu 1in/cDRDXQPN/B/73tDcnv4CbBBCpedR/1pCo+GYUn3cBDG4oT9IoAIOAGbh9yLqeRkh vRJ00WzIFsU48U233npDYd0zWEVeTsfeiMEtMYk6VcKlAgMeT9KIFMgPJgmdLeFvCuZ+ s8e00nK4ha7EIAoecG6PrMnLb+DCB9jksBs03w6Sm26RDhmdCRIhYiZNPDdoEZebbwDf knHg== MIME-Version: 1.0 X-Received: by 10.180.74.197 with SMTP id w5mr32351937wiv.20.1373384282263; Tue, 09 Jul 2013 08:38:02 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Tue, 9 Jul 2013 08:38:02 -0700 (PDT) In-Reply-To: References: <51DC0F95.7010407@gmail.com> Date: Tue, 9 Jul 2013 10:38:02 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Carsten Bormann , "Peter F. Patel-Schneider" , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 19:55:47 -0000 On Tue, Jul 9, 2013 at 10:27 AM, Tim Bray wrote: > Yeah, we can=E2=80=99t retroactively change the 4627 production for numbe= r, nor, in > the -bis, say very much useful aside from a caution that implementations = are > all over the map. When we move on to the BCP or Internet JSON or whateve= r, > I think the single most interesting discussion will be how to constrain > numeric values for maximum interoperability. I would like to do two things here though: 1) give advice as to what numeric ranges and precisions are generally supported (e.g., 32-bit signed integers); 2) what a parser SHOULD do when it parsers a number that it cannot represen= t. Nico -- From tsaloranta@gmail.com Tue Jul 9 13:12: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 A326C21F8C38 for ; Tue, 9 Jul 2013 13:12:26 -0700 (PDT) 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=[AWL=0.000, 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 pWEFuXm6bTO4 for ; Tue, 9 Jul 2013 13:12:26 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id E0E7711E8158 for ; Tue, 9 Jul 2013 13:12:25 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so10262495wgg.2 for ; Tue, 09 Jul 2013 13:12:24 -0700 (PDT) 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=+9K9FNuJC5GR6XgREAG/C0rctUtJzvwI9Gj5entRJHY=; b=vJFukl00Z7bZ8HLctqVUg5wW4nr1uQGzURwQiZjc/ObXCywMM3Rm656idEG8Gi2k76 u8Q9WYcNjgbTU8ks/vP9+GjqOo+WouGZH5zOoBaguf6/a5YRxa5cHpgllx7ZJJFZxC6W GtMxUOBQE8R5D1BGudfmqXdXKQAnShAr5JesN/JRLXsJ7mhyMi1z2RFRwUrqw9s7DIZv u/Rxy54OzR7Fy0lBcsRWwWvsfFPx1LURZ8aKEIJq5G/PszNSpxhU1Lf+SYtbs1NAc+w1 xxnz8mYx1h4IAJbkM4bEAWoy8KXKZTrshz946+BocY8/TJEsc91KZZixLlUke+uk3UI9 GE8Q== MIME-Version: 1.0 X-Received: by 10.180.9.212 with SMTP id c20mr14977774wib.55.1373400744776; Tue, 09 Jul 2013 13:12:24 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Tue, 9 Jul 2013 13:12:24 -0700 (PDT) In-Reply-To: <51dc5295.0548420a.0e8f.ffffb53bSMTPIN_ADDED_BROKEN@mx.google.com> References: <51DC0F95.7010407@gmail.com> <51dc5295.0548420a.0e8f.ffffb53bSMTPIN_ADDED_BROKEN@mx.google.com> Date: Tue, 9 Jul 2013 13:12:24 -0700 Message-ID: From: Tatu Saloranta To: Markus Lanthaler Content-Type: multipart/alternative; boundary=001a11c1879c86db3304e119c7cf Cc: "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 20:12:26 -0000 --001a11c1879c86db3304e119c7cf Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 11:11 AM, Markus Lanthaler wrote: > > On Tuesday, July 09, 2013 6:38 PM, Nico Williams wrote: > > On Tue, Jul 9, 2013 at 11:23 AM, Bjoern Hoehrmann > > wrote: > > > I think it is well-understood that if you need particularily small, > > > big, precise or otherwise unusual numbers in JSON then it's best to > > > encode them as strings so you can do the string-to-number conversion > > > at a higher level than whatever JSON library you might be using > > today. > > > > > > If that's what we should always do then why can't parsers do it > > automatically? > > > > Some parsers have options to support that. PHP, e.g. has a > JSON_BIGINT_AS_STRING flag > Ditto for Java: usually coercion from JSON String to number is supported; and ability to force output of all or some numeric types as Strings as well. Additional settings to enable (or not) use of unlimited-length numeric types. Things are actually bit easier with data-binding, because expected target type is the metadata that informs whether to truncate this (or error out), or to keep full fidelity. -+ Tatu +- --001a11c1879c86db3304e119c7cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 9, 2013 at 11:11 AM, Markus Lanthaler = <markus.lanthaler@gmx.net> wrote:
> On Tuesday, July 09, 2013 6:38 PM, Nico Williams wrote:
> On Tue, Jul 9, 2013 at 11:23 AM, Bjoern Hoehrmann <derhoermi@gmx.net>
> wrote:
> > I think it is well-understood that if you need particularily smal= l,
> > big, precise or otherwise unusual numbers in JSON then it's b= est to
> > encode them as strings so you can do the string-to-number convers= ion
> > at a higher level than whatever JSON library you might be using > today.
>
> <semifacetious>
> If that's what we should always do then why can't parsers do i= t
> automatically?
> </semifacetious>

Some parsers have options to support that. PHP, e.g. has a
JSON_BIGINT_AS_STRING flag


Ditto fo= r Java: usually coercion from JSON String to number is supported; and abili= ty to force output of all or some numeric types as Strings as well.
Additional settings to enable (or not) use of unlimited-length n= umeric types.

Things are actually bit easier with data-binding, beca= use expected target type is the metadata that informs whether to truncate t= his (or error out), or to keep full fidelity.

-+ Tatu +-

--001a11c1879c86db3304e119c7cf-- From tsaloranta@gmail.com Tue Jul 9 13:13: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 D554A21F9E28 for ; Tue, 9 Jul 2013 13:13:49 -0700 (PDT) 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=[AWL=0.000, 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 eJAlnheguyvJ for ; Tue, 9 Jul 2013 13:13:49 -0700 (PDT) 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 EA0D721F9DF8 for ; Tue, 9 Jul 2013 13:13:48 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so10626578wid.9 for ; Tue, 09 Jul 2013 13:13:48 -0700 (PDT) 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=j/GASpFq5LYTtq/zFXmKUSsNSMcvPEInXhC2lQQjCDU=; b=HF1MVjwprT7f051Tf9jxSwuPzWJSPYLoUjpuIudp94Yif3ATbVN92ftadqtaK0WrTn ffwwFFgg6gaGZGJm5H6nx5LoREMtKYLlJ396K+fFHff5iTs2awRuessQfi9Epjk8t53q KsMdRKrzLPS40wXgG8pT4eghkqdVB1mQK9E20hJ4OYVT06WsbKChh3sW3tZBBFxKUHnN X+9h6PeJZycRY8QGm4w5t64VTHA9dKD5wWmFET6qSk6SvZ4II1D4yQ3XqT9TTYw7jTZO VKxMaji6h94ooGlMsp3Z7lYBwPTrF6jBe0keHdZX7IBi2u/80oByI+lIR+dRayZZ8/bB FLvA== MIME-Version: 1.0 X-Received: by 10.194.90.244 with SMTP id bz20mr16570616wjb.69.1373400827963; Tue, 09 Jul 2013 13:13:47 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Tue, 9 Jul 2013 13:13:47 -0700 (PDT) In-Reply-To: References: <51DC0F95.7010407@gmail.com> Date: Tue, 9 Jul 2013 13:13:47 -0700 Message-ID: From: Tatu Saloranta To: Nico Williams Content-Type: multipart/alternative; boundary=047d7bfd090a7c323104e119cc22 Cc: "Peter F. Patel-Schneider" , Carsten Bormann , Tim Bray , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 20:13:50 -0000 --047d7bfd090a7c323104e119cc22 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jul 9, 2013 at 8:38 AM, Nico Williams wrote= : > On Tue, Jul 9, 2013 at 10:27 AM, Tim Bray wrote: > > Yeah, we can=92t retroactively change the 4627 production for number, n= or, > in > > the -bis, say very much useful aside from a caution that implementation= s > are > > all over the map. When we move on to the BCP or Internet JSON or > whatever, > > I think the single most interesting discussion will be how to constrain > > numeric values for maximum interoperability. > > I would like to do two things here though: > > 1) give advice as to what numeric ranges and precisions are generally > supported (e.g., 32-bit signed integers); > > 2) what a parser SHOULD do when it parsers a number that it cannot > represent. > This would be useful. One challenge is that of precision for floating-point types: figuring out whether loss occurs is rather costly. For integer types this is easier. -+ Tatu +- --047d7bfd090a7c323104e119cc22 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2013 at 8:38 AM, Nico Williams <nico@c= ryptonector.com> wrote:
On Tue, Jul 9, 2013 at 10:= 27 AM, Tim Bray <tbray@textualit= y.com> wrote:
> Yeah, we can=92t retroactively change the 4627 production for number, = nor, in
> the -bis, say very much useful aside from a caution that implementatio= ns are
> all over the map. =A0When we move on to the BCP or Internet JSON or wh= atever,
> I think the single most interesting discussion will be how to constrai= n
> numeric values for maximum interoperability.

I would like to do two things here though:

1) give advice as to what numeric ranges and precisions are generally
supported (e.g., 32-bit signed integers);

2) what a parser SHOULD do when it parsers a number that it cannot represen= t.

This would be useful. One challenge = is that of precision for floating-point types: figuring out whether loss oc= curs is rather costly. For integer types this is easier.

-+ Tatu +-
=A0
--047d7bfd090a7c323104e119cc22-- From pfpschneider@gmail.com Tue Jul 9 14:24:28 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 B935821F9D3B for ; Tue, 9 Jul 2013 14:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 Dn0EgmVFBkP2 for ; Tue, 9 Jul 2013 14:24:28 -0700 (PDT) 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 2793C21F99BB for ; Tue, 9 Jul 2013 14:24:28 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wo10so7450679obc.17 for ; Tue, 09 Jul 2013 14:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8QJ2lgnF7fU3mDQyxWj31Ro5YpUejgntPkZvH3TWMXg=; b=btflXhr4OgCEWvlw4y3ZsrhhIkN1bNSelvBL5ZapCQJv4zZ0m6Oxe48ThjxvW0XofE FG+MqtHBgt6idzHqSMbKvpCkhFpqjRycLAfd4YSpPKEaGAOS/xHdF7aRcn92qXGsPVLn a5Au0GgRbPPiHHbIO96kJ7TSaxPPHRnWofT95EDLjTtF5dUHWk/GSGDTQU3M9Fg2qND7 tjYVVTCaOVG+vkF1JRo85mHvzyfudsnO81I+f3k1Z1EA1ZKM1qNPcKWqpXRnjNBwHOu1 n3nOrQshWTYx7g2wc6tgupPJXKqlFXtFxNTx8a6B5uAwnMq05mny809lo9JA54yE61y7 8aPg== X-Received: by 10.60.45.138 with SMTP id n10mr25429316oem.101.1373405067703; Tue, 09 Jul 2013 14:24:27 -0700 (PDT) Received: from [192.168.1.102] (out-on-158.wireless.telus.com. [207.219.69.158]) by mx.google.com with ESMTPSA id qa4sm40911879oeb.5.2013.07.09.14.24.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 14:24:25 -0700 (PDT) Message-ID: <51DC7F87.6060503@gmail.com> Date: Tue, 09 Jul 2013 14:24:23 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nico Williams References: <51DC0F95.7010407@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 21:24:28 -0000 [Somewhat less facetious.] Where does this end? Do I have to worry about whether, for example, 0.0 is different from 0.00? (Some people, e.g., numerical analysts, would argue that they are different - the first is 0+-0.05 and the second is 0+-0.005.) Do I have to worry about whether 0.1 is different from 1E-1? (Some people, e.g., XML-philes, might argue that the first is a decimal and the second is a float or double.) Do I have to worry about whether 0 is different from 0.? (Some people, e.g., C programmers, might argue that 0 is an int and 0. is a float.) Searching for answers to these questions lead me various bits of RFC 4627. I looked at "The representation of numbers is similar to that used in most programming languages." However, the only programming language that I was acquainted with that had a single number type encompassing scientific notation was LISP. Most other languages that I could recall, e.g., C, C++, and ML, had at least a distinction between integers and floats. Java sort of splits the difference. So this really didn't provide me with any guidance. This lead me to the beginning of the document and the "is derived from the ECMAScript Programming Language Standard" and the "JSON defines a small set of formatting rules for the portable representation of structured data." Finally, some guidance! Hopefully ECMAScript will tell me how numbers in JSON can be portably interpreted as data. So I read the ECMAScript document. Success! The ECMAScript document tells me, in gory detail, how to interpret something that looks like JSON numbers and, moreover, provides a datatype for these numbers, namely IEEE floating point double. So that is how I came up with JSON numbers being IEEE floating point double. Imagine my surprise when I was told that my reasoning was not correct. Peter F. Patel-Schneider On 07/09/2013 09:37 AM, Nico Williams wrote: > On Tue, Jul 9, 2013 at 11:23 AM, Bjoern Hoehrmann wrote: >> I think it is well-understood that if you need particularily small, >> big, precise or otherwise unusual numbers in JSON then it's best to >> encode them as strings so you can do the string-to-number conversion >> at a higher level than whatever JSON library you might be using today. > > If that's what we should always do then why can't parsers do it automatically? > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From tsaloranta@gmail.com Tue Jul 9 14:34: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 77CEB11E816D for ; Tue, 9 Jul 2013 14:34:14 -0700 (PDT) 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, 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 eSoOkL9zFpgh for ; Tue, 9 Jul 2013 14:34:13 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 49C5511E8156 for ; Tue, 9 Jul 2013 14:34:13 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so5622123wib.2 for ; Tue, 09 Jul 2013 14:34:12 -0700 (PDT) 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=roM69oBTl5XerSJuVj9djgV8T5vAxVfnv38gOQ3MSjE=; b=pZpg3bmwoewdmhVO8hGQrXJ8FVZ1Rb38oHx5et4S/OTkfs6URNUuHdhZupWZOeDfZa ApW/zuohU7bwivQt+qi+pegETNT6Vf6rBB3KZv0dmGmZDUxbVocVVM2anV+4C4Pi1RXj qHOL/xDEZEL9cJpqzxcOKln1z2+evgvum+1+7CN12L+ztbxbyWwiG0bhMcBvN50y+UCB fdVVxidvTSk/Sv/rgXQfNzvNKgyp/SAMQkkJK5eZU2UTa/B5uA3OQlr1CzxgmcxnBqHn qpPtrq+8kkQFQBpNdtXNyPy7C4WF/hdupUw69qW+VfwLito7fJkl9O4uk/419HYfvlQ2 mVFg== MIME-Version: 1.0 X-Received: by 10.180.206.70 with SMTP id lm6mr33189331wic.50.1373405652300; Tue, 09 Jul 2013 14:34:12 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Tue, 9 Jul 2013 14:34:12 -0700 (PDT) In-Reply-To: <51DC7F87.6060503@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> Date: Tue, 9 Jul 2013 14:34:12 -0700 Message-ID: From: Tatu Saloranta To: "Peter F. Patel-Schneider" Content-Type: multipart/alternative; boundary=001a11c265be09ba5704e11aec99 Cc: Nico Williams , Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 21:34:14 -0000 --001a11c265be09ba5704e11aec99 Content-Type: text/plain; charset=ISO-8859-1 I am surprised you came to this conclusion, since I assumed we were finally getting rid of misconception that JSON is closely tied to Javascript. This is not to say that the way JSON (under-)defines numbers is optimal; but at this point forcing castrated version of numbers -- which would lead to practical problems like preventing use of 64-bit longs for timestamps -- would be counter-productive and to me a non-starter. -+ Tatu +- On Tue, Jul 9, 2013 at 2:24 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > [Somewhat less facetious.] > > Where does this end? Do I have to worry about whether, for example, 0.0 > is different from 0.00? (Some people, e.g., numerical analysts, would > argue that they are different - the first is 0+-0.05 and the second is > 0+-0.005.) Do I have to worry about whether 0.1 is different from 1E-1? > (Some people, e.g., XML-philes, might argue that the first is a decimal > and the second is a float or double.) Do I have to worry about whether 0 is > different from 0.? (Some people, e.g., C programmers, might argue that 0 > is an int and 0. is a float.) > > Searching for answers to these questions lead me various bits of RFC 4627. > > I looked at "The representation of numbers is similar to that used in most > programming languages." However, the only programming language that I was > acquainted with that had a single number type encompassing scientific > notation was LISP. Most other languages that I could recall, e.g., C, > C++, and ML, had at least a distinction between integers and floats. Java > sort of splits the difference. So this really didn't provide me with any > guidance. > > This lead me to the beginning of the document and the "is derived from the > ECMAScript Programming Language Standard" and the "JSON defines a small set > of formatting rules for the portable representation of structured data." > > Finally, some guidance! Hopefully ECMAScript will tell me how numbers in > JSON can be portably interpreted as data. So I read the ECMAScript > document. Success! The ECMAScript document tells me, in gory detail, how > to interpret something that looks like JSON numbers and, moreover, provides > a datatype for these numbers, namely IEEE floating point double. > > So that is how I came up with JSON numbers being IEEE floating point > double. > > Imagine my surprise when I was told that my reasoning was not correct. > > Peter F. Patel-Schneider > > > > On 07/09/2013 09:37 AM, Nico Williams wrote: > >> On Tue, Jul 9, 2013 at 11:23 AM, Bjoern Hoehrmann >> wrote: >> >>> I think it is well-understood that if you need particularily small, >>> big, precise or otherwise unusual numbers in JSON then it's best to >>> encode them as strings so you can do the string-to-number conversion >>> at a higher level than whatever JSON library you might be using today. >>> >> >> If that's what we should always do then why can't parsers do it >> automatically? >> >> ______________________________**_________________ >> 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 > --001a11c265be09ba5704e11aec99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am surprised you came to this conclusion, sinc= e I assumed we were finally getting rid of misconception that JSON is close= ly tied to Javascript.

This is not to say that the way JS= ON (under-)defines numbers is optimal; but at this point forcing castrated = version of numbers -- which would lead to practical problems like preventin= g use of 64-bit longs for timestamps -- would be counter-productive and to = me a non-starter.

-+ Tatu +-



On Tue, Jul 9, 2013 at 2:24 PM, Peter= F. Patel-Schneider <pfpschneider@gmail.com> wrote:
[Somewhat less facetious.]

Where does this end? =A0 Do I have to worry about whether, for example, 0.0= is different from 0.00? =A0 (Some people, e.g., numerical analysts, would = argue that they are different - the first is 0+-0.05 and the second is 0+-0= .005.) =A0Do I have to worry about whether 0.1 is different from 1E-1? =A0(= Some people, e.g., XML-philes, might argue that the first is a decimal and = the second is a float or double.) Do I have to worry about whether 0 is dif= ferent from 0.? =A0(Some people, e.g., C programmers, might argue that 0 is= an int and 0. is a float.)

Searching for answers to these questions lead me various bits of RFC 4627.<= br>
I looked at "The representation of numbers is similar to that used in = most programming languages." =A0However, the only programming language= that I was acquainted with that had a single number type encompassing scie= ntific notation was LISP. =A0 Most other languages that I could recall, e.g= ., C, C++, and ML, had at least a distinction between integers and floats. = =A0 Java sort of splits the difference. =A0 So this really didn't provi= de me with any guidance.

This lead me to the beginning of the document and the "is derived from= the ECMAScript Programming Language Standard" and the "JSON defi= nes a small set of formatting rules for the portable representation of stru= ctured data."

Finally, some guidance! =A0Hopefully ECMAScript will tell me how numbers in= JSON can be portably interpreted as data. =A0 So I read the ECMAScript doc= ument. =A0Success! =A0The ECMAScript document tells me, in gory detail, how= to interpret something that looks like JSON numbers and, moreover, provide= s a datatype for these numbers, namely IEEE floating point double.

So that is how I came up with JSON numbers being IEEE floating point double= .

Imagine my surprise when I was told that my reasoning was not correct.

Peter F. Patel-Schneider



On 07/09/2013 09:37 AM, Nico Williams wrote:
On Tue, Jul 9, 2013 at 11:23 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
I think it is well-understood that if you need particularily small,
big, precise or otherwise unusual numbers in JSON then it's best to
encode them as strings so you can do the string-to-number conversion
at a higher level than whatever JSON library you might be using today.
<semifacetious>
If that's what we should always do then why can't parsers do it aut= omatically?
</semifacetious>
_______________________________________________
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

--001a11c265be09ba5704e11aec99-- From pfpschneider@gmail.com Tue Jul 9 14:34: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 3F9C211E816D for ; Tue, 9 Jul 2013 14:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 73IBmZDxKhKQ for ; Tue, 9 Jul 2013 14:34:14 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id B005611E8156 for ; Tue, 9 Jul 2013 14:34:14 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id g12so8499601oah.39 for ; Tue, 09 Jul 2013 14:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=G6s/72CkDsyUFDI3zY4ieANGSf1tO8xNykcKC1tLgxY=; b=l3lYc5pWwX7l6fJyTSqqdUa8UV5oqEQqFVfZ8/rsZTG9XmG1VKbSpQlfLbF+Zx/MlC CNEInITKmIE2hl5+lBgAdrDRCKFJ4oHRMcfjk8ahWOczmJfKqWlWxfR39+Lvdrldpjzs vbzk2CnzP4MMh/kwLpxZD0rWdq1F3YwCwbhqOmtm4uCQW1FtVxD/5evZviQms8MGVzub hn5GJmHpxOPY2/9FWVol5MMFuad2vs13BKmdWpnk3nAvzIsFsNP7jxS0qfXjPQ2iilyB ltXEGe7PbXosJRP90gq8VVJ4IM0uxhnlTbGqHm6jbJbrrpWY5OtSpM1vXb0Qeb6LyIXM YxzQ== X-Received: by 10.182.16.137 with SMTP id g9mr26008650obd.17.1373405654306; Tue, 09 Jul 2013 14:34:14 -0700 (PDT) Received: from [192.168.1.102] (out-on-158.wireless.telus.com. [207.219.69.158]) by mx.google.com with ESMTPSA id q4sm40282539obl.1.2013.07.09.14.34.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 14:34:13 -0700 (PDT) Message-ID: <51DC81CD.9070904@gmail.com> Date: Tue, 09 Jul 2013 14:34:05 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: json@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Json] a candidate for the minimal change target 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, 09 Jul 2013 21:34:15 -0000 This may be somewhat on the spec-lawyerly side, but Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted. is counter to the grammar for numbers. For example, under any sane reading of what numbers mean this would disallow the rational number 1/10. (Yes, I'm counting unusual number bases as an insanity.) Peter F. Patel-Schneider From jorge@jorgechamorro.com Tue Jul 9 15:20:08 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 DE48521F9799 for ; Tue, 9 Jul 2013 15:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=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 RsmHYOGICmg1 for ; Tue, 9 Jul 2013 15:20:03 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id BDE2F11E816F for ; Tue, 9 Jul 2013 15:20:02 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so5228103wev.16 for ; Tue, 09 Jul 2013 15:20:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=3qnbLnRUHjN4gY86FMH2qDQXygYDRYaRgIWwFPJvd9k=; b=iZRfkW+8iIfLYMzK/HqlL53Yy+GeUgUPbDnMNhrpoySxVuUehddC4b6sOoYH5UHvdA ztQYtxkNzkswJpti7XuTiBnlzzp2HrxOmbLRdFIYCXp1ZQ9azwv1bUcU46hWmQZH/wPx LLpNHozFhFySnUT+u13OeqRp/C6WWTboHaKkc8ZIqw5KNCCT/jskdqMPd5IQTOO2Eohn tUxOy5mOVHCU8xIybgbGfTQuG81cIp1TV1BY+YgzWrBjPKnb8yu6T5bUzoWZz0321uo1 VUdBqBRTjeGTCf8Vl0lttV5MNNXEgIiVTYbx5PyA9O88zHJwOJImys9vE+IRfokdg35x gDUA== X-Received: by 10.180.38.45 with SMTP id d13mr15411841wik.62.1373408401417; Tue, 09 Jul 2013 15:20:01 -0700 (PDT) Received: from [192.168.10.50] (11.Red-88-0-221.dynamicIP.rima-tde.net. [88.0.221.11]) by mx.google.com with ESMTPSA id fb2sm63803080wic.4.2013.07.09.15.20.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 15:20:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: <51DC7F87.6060503@gmail.com> Date: Wed, 10 Jul 2013 00:19:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> To: "Peter F. Patel-Schneider" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnF9//B5RX9hY6GB/2mM7SxHMSdOy91qPCFcyPf9kxe29YXrtOP9FWpOUU6RBPo4A/miRMY Cc: Nico Williams , Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 22:20:09 -0000 On 09/07/2013, at 23:24, Peter F. Patel-Schneider wrote: >=20 > Imagine my surprise when I was told that my reasoning was not correct. A "JSON number" is a *text* not a number: number =3D [ minus ] int [ frac ] [ exp ] decimal-point =3D %x2E ; . digit1-9 =3D %x31-39 ; 1-9 e =3D %x65 / %x45 ; e E exp =3D e [ minus / plus ] 1*DIGIT frac =3D decimal-point 1*DIGIT int =3D zero / ( digit1-9 *DIGIT ) minus =3D %x2D ; - plus =3D %x2B ; + zero =3D %x30 ; 0 A character representation of a number that follows the rules in the RFC = 4627 that -unlike ECMAScript- doesn't say a thing about its precision, = integer-ness, floating-point-ness, allowable ranges or the likes. To say that a "JSON number" (which is a text) is =3D=3D=3D IEEE-754 = double doesn't make too much sense. JSON.stringify(number:number) -> text:JSON_number JSON.parse(text:JSON_number) -> number:number --=20 ( Jorge )();= From nico@cryptonector.com Tue Jul 9 15:22: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 34BEF21E805D for ; Tue, 9 Jul 2013 15:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=-0.168, 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 Ri7Wod2g2JCd for ; Tue, 9 Jul 2013 15:22:21 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id DD67B21E8051 for ; Tue, 9 Jul 2013 15:22:19 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 58CFB3B8069 for ; Tue, 9 Jul 2013 15:22:19 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id E5F9E3B8072 for ; Tue, 9 Jul 2013 15:22:18 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so5288874wgh.19 for ; Tue, 09 Jul 2013 15:22:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oHnmoAHqXOl7WGMY+sATBqRO2DOhr2eYzJXFvA7milc=; b=nwosnX/cC57QkzEQAkwho99a2j+zzFbsIC2WgPR7XOfFJUWfJr2Vnm1rgnCvTwmMNu XCsy/4sjaeMrwMwfFZben16GraV3keZROFTVJeKdvnYsNJ7aUhrU+8EaHO3cuMM24y2c RsIKcJLZvadeWs34wRit9i2CoCutYZCzQZHgAxu0yHt8wnsKCFk0O8hs9MLQsEfThcoW R/SAdU9Dwlvk9PoRZgia/sWXuQwmdX9684CiwHxbFDSCf1vqA/L/kfyiMtKDElmZ/h2D mHSoEWZDt2Al96J5auTR+hreNK4nfpHbMDqNC5JiJEmyXNlFlQIedyL+CFM06y/TTztI o0/w== MIME-Version: 1.0 X-Received: by 10.194.240.169 with SMTP id wb9mr15738886wjc.90.1373408536023; Tue, 09 Jul 2013 15:22:16 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Tue, 9 Jul 2013 15:22:15 -0700 (PDT) In-Reply-To: <51DC7F87.6060503@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> Date: Tue, 9 Jul 2013 17:22:15 -0500 Message-ID: From: Nico Williams To: "Peter F. Patel-Schneider" Content-Type: text/plain; charset=UTF-8 Cc: Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 22:22:27 -0000 On Tue, Jul 9, 2013 at 4:24 PM, Peter F. Patel-Schneider wrote: > So that is how I came up with JSON numbers being IEEE floating point double. > > Imagine my surprise when I was told that my reasoning was not correct. A great many participants on this list (since its very recent inception) have been surprised, myself included, by many oddities. It should no longer surprise any of us that others are surprised by these things :) Nico -- From johnl@iecc.com Tue Jul 9 15:26: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 EA6BA11E817A for ; Tue, 9 Jul 2013 15:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.656 X-Spam-Level: X-Spam-Status: No, score=-110.656 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 fmftterBlNq9 for ; Tue, 9 Jul 2013 15:26:29 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 38A9421F9CDC for ; Tue, 9 Jul 2013 15:26:25 -0700 (PDT) Received: (qmail 14553 invoked from network); 9 Jul 2013 22:26:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Jul 2013 22:26:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51dc8e11.xn--30v786c.k1307; i=johnl@user.iecc.com; bh=jIyL/0poCAGrGwHzHhgLKUYe7HLK+0CdEM2NM5/gIOA=; b=MeVJbJG5qciVw7IOY1jvsXwKbFO+O9bBFed6BjK8GTd8Uectn1WBG/OSQOykKzhNMuVNKM/mQwaSvdPSR2Deh4RtcIiL/WIL07IRSAv3N9UfMeUxtKLzIAH+1uknYjx4uy1PscLmUNZFOlbkkzfD3BD5IrLLsh5ydtBjPXS3Sdt2UEKJkG54nv8RfSRut8mvtiOgYFNiptMid8b3AkLzPzH0PHLGs9YBAaQwf070PUBt9ppxC0aO/F6DExDc5Rkv DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51dc8e11.xn--30v786c.k1307; olt=johnl@user.iecc.com; bh=jIyL/0poCAGrGwHzHhgLKUYe7HLK+0CdEM2NM5/gIOA=; b=X4MZsbpGFeUCE/GO10E4MUzyXR6JbNvrRep+vxmVvoDBqszO3WOb3MMERuK+oqrdJWjLL+XERK0GFphZo9ypSQv2fj2rAPXPEn9WcmWupsSXcEo7IxNQLkHoSB31aV4oqAd/3B0EvtHzUy6lHLwUw0XfaJe6G3ZngPRqJMLVMLVhUkaYElpBdLJOSf1iyvgzeHMxKviJZRKmPfeV42BC/7HnVnx+Bi6T/e6+wNYgI9CFNaPOAYrkCZWYCvkppnAt Date: 9 Jul 2013 22:26:01 -0000 Message-ID: <20130709222601.32831.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: nico@cryptonector.com Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 22:26:46 -0000 >1) give advice as to what numeric ranges and precisions are generally >supported (e.g., 32-bit signed integers); Do we actually know? Or is it just whatever number format a library's underlying language happens to provide? From nico@cryptonector.com Tue Jul 9 15:31: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 2796611E8181 for ; Tue, 9 Jul 2013 15:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.444, 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 1iq7ZxxkUYMu for ; Tue, 9 Jul 2013 15:31:11 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 6380911E817A for ; Tue, 9 Jul 2013 15:31:11 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 6BC643B806C for ; Tue, 9 Jul 2013 15:31:04 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 11FB53B8059 for ; Tue, 9 Jul 2013 15:31:03 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so10736615wib.16 for ; Tue, 09 Jul 2013 15:31:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N4tqH95q3bLG2VWiGHcjgZRp4BkOgfmX7vFSlQRexio=; b=mro6RqofP+z8r9ZFXfoW6WJVOSuq9II9I42cNCmFqVINFEdnDDXq5jBPwDGgIAgHHX gn6g2hDaSPFN8RUSPQ0Nb0sbozY2pQ/PsZtRP5HsXfWQBktHzRC2vtvZm8AZPAow3866 /bednnwU6NJgzdikut1pj4IelDyfXyjr4sRa6ZXegt/1b7uA2dWCrkgcPTa+bMG9UHZA sHRsnh/7vkoD9ddMUBF8ugUcL/kg2YeQPyds0aEnyeWd5m/aCl+xrVUb4Xugp8ruwkN5 mRnC1+ZSxC+igYcl3sFHqksrZJJMXWySaU5QnA5aG0nsm8sLIoSFN2oXKZjQPB8DNO5Y sR1A== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr16597377wjn.23.1373409062548; Tue, 09 Jul 2013 15:31:02 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Tue, 9 Jul 2013 15:31:02 -0700 (PDT) In-Reply-To: <20130709222601.32831.qmail@joyce.lan> References: <20130709222601.32831.qmail@joyce.lan> Date: Tue, 9 Jul 2013 17:31:02 -0500 Message-ID: From: Nico Williams To: John Levine Content-Type: text/plain; charset=UTF-8 Cc: json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 22:31:17 -0000 On Tue, Jul 9, 2013 at 5:26 PM, John Levine wrote: >>1) give advice as to what numeric ranges and precisions are generally >>supported (e.g., 32-bit signed integers); > > Do we actually know? Or is it just whatever number format a library's > underlying language happens to provide? I've contributed to one JSON implementation that doesn't do better than 32-bit signed integers. I've contributed to one that uses C doubles. I doubt there's any that support only 0-bit numbers (heh). And I doubt there are any that only support 16-bit integers (or that we'd care about them, but who knows). I *suspect* 32-bit signed, or perhaps 31-bit unsigned integers is the minimum that all implementations we'd care about support. We might want to do a survey. From nico@cryptonector.com Tue Jul 9 15:45: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 05B0B21F9021 for ; Tue, 9 Jul 2013 15:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=-1.244, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 K9XSJBPJoGvj for ; Tue, 9 Jul 2013 15:45:29 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0559121F8FF8 for ; Tue, 9 Jul 2013 15:45:28 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 8EB34360075 for ; Tue, 9 Jul 2013 15:45:28 -0700 (PDT) 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=tLGqcMOFHok/6Ilxh/hq tia75jQ=; b=nb8qVKLxjxNNaa+DerHbyrWNx0j2wry8zz1xLK71i4UELLnE+9XR ttLtcnoW2ng8dByK+fuoqNi+wiXiq4WIa9Utui8gMFcVdHVTftJJYpJAGcQYvst/ Ierk3bQ7YGZfABxUn6ssIveqNMUhtEDV291lFpyENpnHmTlQKrdopKc= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 3A0F536006D for ; Tue, 9 Jul 2013 15:45:28 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so5215070wgh.2 for ; Tue, 09 Jul 2013 15:45:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BXAf4hmhEL6zfHmn1GZXlMD8pXQ18dv10e8o7qxrGcA=; b=VbKrc/urL0VirPPypJ8a7FQ3eHYpp4cjvSpvNPyFndnnEF35BlBXm7p6j9+CQZCCVM SxC7P0cyTyizLpXKJFP7yH/5nL7fgGvWYSQIsh5chNau/FPViyJILkb0gPgR/ZQzTedk i/Onnicvftbth4lz9LmBhZz3tYSjeIocNb9mxfmLyB4iJDxsnhPCiaGFP7tsAgKIcftK WYjeUJ7YM8lxVVrHtGdg26dc4SOG/mqFXtW+fZU6m36e9RT/P3QUDdgSRGlMrH4xVo9G cUcEMoKPfHyNjYzMP29Ml9cV5QSXHPVX2yrVWIJqkhz4ZHnQJ+p7RkPM/QF4aTHixI5P ME7w== MIME-Version: 1.0 X-Received: by 10.194.22.1 with SMTP id z1mr16749376wje.14.1373409926699; Tue, 09 Jul 2013 15:45:26 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Tue, 9 Jul 2013 15:45:26 -0700 (PDT) In-Reply-To: <51DC7F87.6060503@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> Date: Tue, 9 Jul 2013 17:45:26 -0500 Message-ID: From: Nico Williams To: "Peter F. Patel-Schneider" Content-Type: text/plain; charset=UTF-8 Cc: Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 22:45:34 -0000 On Tue, Jul 9, 2013 at 4:24 PM, Peter F. Patel-Schneider wrote: > [Somewhat less facetious.] I was surprised that needn't have been at all facetious. JSON surprises me all the time. Since so many parsers have optional behaviours, let's explore this path. > Where does this end? Do I have to worry about whether, for example, 0.0 is > different from 0.00? (Some people, e.g., numerical analysts, would argue > that they are different - the first is 0+-0.05 and the second is 0+-0.005.) > Do I have to worry about whether 0.1 is different from 1E-1? (Some people, > e.g., XML-philes, might argue that the first is a decimal and the second is > a float or double.) Do I have to worry about whether 0 is different from 0.? > (Some people, e.g., C programmers, might argue that 0 is an int and 0. is a > float.) I think unnecessary leading or trailing zeros, or even zero decimal fraction, are fair game to lose. Such things bear no information if all we care about is numbers. (.0 in some languages implies floating point, as opposed to integer, but that's not relevant here.) Ditto negative zero. Otherwise the tolerance level for information loss in numbers should be specified by the application. We can probably agree on some common options that implementations *might* provide. Here's all the options that I think we should consider, but I'm probably missing some: - IEEE 754 {32, 64}-bit double with unspecified loss tolerance-- any value that can be represented as such no matter what lossage, will be accepted - IEEE 754 {32, 64}-bit double with no loss in exponent and with N digits of precision, with some specified rounding - IEEE 754 {32, 64}-bit double with no loss (e.g., 0.1 can't be parsed as a double exactly) - take the floor of the number as an integer of {32, 64, 128} bits - take the floor of the number as bigint (whatever that means for the parser / host language) (subject to some arbitrary max size constraint) - bignum with no loss (subject to some arbitrary max size constraint) From pfpschneider@gmail.com Tue Jul 9 15:46: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 9CC3E11E817A for ; Tue, 9 Jul 2013 15:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_66=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 ZljYVDqB-K80 for ; Tue, 9 Jul 2013 15:46:15 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 290F421F9C69 for ; Tue, 9 Jul 2013 15:46:15 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so7545833obc.20 for ; Tue, 09 Jul 2013 15:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=N9LYxfDZrM5QXsQ2WyFUDMGB5kJ+SOzHXuCoTyts5O8=; b=k0uS8aODw8SEO6bP1BVCEtw5yoigITqFDdax/lDhlF7Q580wQbV08lOjqrPjIDVGPk /Iu8h81HWqSOAvHstqunOZEvyR4HbBVahJNX6w4cWD0Nvdb+KTkj0xOJSdfcoL0kYxie yHI+4gvWGF7n02durwwjAY64UooVBFB2TrCAMk/B3Bsp50VaSWwrJS/sJ+CjqfKRRP6I E1hMK/8RstvEDRcXPT/dpDLjTuabCK5HIoc9aGd2HvPXX65xYxOAZQ7SjH0QO00VZuCG r5Jed+OSDsx6KJPeS8ZT8A4iSuHSz4/BAkW0nKP+K+0NaJbBHb3im2zhkop7dURb1bZr XBxg== X-Received: by 10.182.205.138 with SMTP id lg10mr25836047obc.6.1373409973632; Tue, 09 Jul 2013 15:46:13 -0700 (PDT) Received: from [192.168.1.102] (out-on-158.wireless.telus.com. [207.219.69.158]) by mx.google.com with ESMTPSA id q4sm40616927obl.1.2013.07.09.15.46.11 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 15:46:12 -0700 (PDT) Message-ID: <51DC92B1.7000908@gmail.com> Date: Tue, 09 Jul 2013 15:46:09 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jorge Chamorro References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nico Williams , Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 22:46:15 -0000 On 07/09/2013 03:19 PM, Jorge Chamorro wrote: > On 09/07/2013, at 23:24, Peter F. Patel-Schneider wrote: >> Imagine my surprise when I was told that my reasoning was not correct. > A "JSON number" is a *text* not a number: OK, OK. A JSON number represents a number. I'm guilty of not being appropriately pedantic. But everything that I've read about JSON indicates that JSON is supposed to be used for (portably) interchanging data. If all there is to JSON is the grammar then what's the point of JSON? > > number = [ minus ] int [ frac ] [ exp ] > > decimal-point = %x2E ; . > > digit1-9 = %x31-39 ; 1-9 > > e = %x65 / %x45 ; e E > > exp = e [ minus / plus ] 1*DIGIT > > frac = decimal-point 1*DIGIT > > int = zero / ( digit1-9 *DIGIT ) > > minus = %x2D ; - > > plus = %x2B ; + > > zero = %x30 ; 0 > > A character representation of a number that follows the rules in the RFC 4627 that -unlike ECMAScript- doesn't say a thing about its precision, integer-ness, floating-point-ness, allowable ranges or the likes. And neither does the BNF for numeric types in most programming languages, including ECMAScript. The BNF syntax for numbers in ECMAScript permits arbitrarily long sequences of digits. As far as I can recall C, C++, and ML all have the same characteristic. What is (surprisingly) missing in JSON is a firm notion of the data being represented by the syntax. A pale shadow of this issue for strings appears to have been consuming this working for quite some time. > > > To say that a "JSON number" (which is a text) is === IEEE-754 double doesn't make too much sense. OK, then, what I inferred was that a JSON number represents an IEEE floating point double and I was very surprised to find out that this was not the case. Peter F. Patel-Schneider > > > JSON.stringify(number:number) -> text:JSON_number > JSON.parse(text:JSON_number) -> number:number From pfpschneider@gmail.com Tue Jul 9 15:59:10 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 9F17321F9CD7 for ; Tue, 9 Jul 2013 15:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 NjFD6hSbwVIo for ; Tue, 9 Jul 2013 15:59:10 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BEF7221F9CCC for ; Tue, 9 Jul 2013 15:59:09 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j6so8846402oag.15 for ; Tue, 09 Jul 2013 15:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TqnuDkH9WyOwtAM4L3axMuGOc/KZDlOLkNqgdxieBl4=; b=AsfaRE1rumNKATY9A4p8qJlhF1kRqH+c9JrsZHWgaY15oGN3BnGDwIsbOot/l4C75y xMJDbc/m5zlJfNheNuxWconjTNw1LiSSxsjxsKPU0SNc8iKn9zXFd2rIOuxVRs/LlVAY oR8csYDc8c5hqSo8SlgWWi0NIL6Cr/7+24rIRUdDVOoCuzttK1nbN3jxUR6c0wb2vKIH YXbsNIEre+zDDh7Aeyvtl8euX26RWTfPyDbMOMtRsB3mnqCyRTDygnDh+78fUi5Qim6K Nu3WiLAfPKM6KqmHmOnUFVnrKL33OUtLsMwnxMOjHB+vpEX32rg7AWQAjYseIiCrXvfy Nv3Q== X-Received: by 10.60.96.170 with SMTP id dt10mr25779479oeb.81.1373410749387; Tue, 09 Jul 2013 15:59:09 -0700 (PDT) Received: from [192.168.1.102] (out-on-158.wireless.telus.com. [207.219.69.158]) by mx.google.com with ESMTPSA id m11sm41364814oer.4.2013.07.09.15.59.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 15:59:08 -0700 (PDT) Message-ID: <51DC95B2.8080801@gmail.com> Date: Tue, 09 Jul 2013 15:58:58 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tatu Saloranta References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nico Williams , Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 22:59:10 -0000 Where then am I supposed to go to find out what a JSON number represents? There are many possibilities (float only, rational only, separate integer and float, separate rational and float, variable-precision decimal only, separate integer and variable-precision decimal, variable precision float only, ...). And then there are the various range possibilities. The only suitable guidance provided in RFC4627 is via ECMAScript and ECMAScript is firmly IEEE floating point double only. So why are you surprised that I came up with this conclusion? peter On 07/09/2013 02:34 PM, Tatu Saloranta wrote: > I am surprised you came to this conclusion, since I assumed we were finally > getting rid of misconception that JSON is closely tied to Javascript. > > This is not to say that the way JSON (under-)defines numbers is optimal; but > at this point forcing castrated version of numbers -- which would lead to > practical problems like preventing use of 64-bit longs for timestamps -- > would be counter-productive and to me a non-starter. > > -+ Tatu +- > > From nico@cryptonector.com Tue Jul 9 16:01: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 B213B11E8197 for ; Tue, 9 Jul 2013 16:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.109, 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 hE6SSbb+mXnd for ; Tue, 9 Jul 2013 16:00:55 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id B241311E8195 for ; Tue, 9 Jul 2013 16:00:55 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 45A192AC073 for ; Tue, 9 Jul 2013 16:00:55 -0700 (PDT) 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=t2MhviirgZZt3OtFkyS3 XAJmo4A=; b=xH0/VAAnCfukeV1HJJwS/y0r2VUwq0fbcm7XxzBS4Rh+sK8Guwhe UqcQ+Kyq1lEQoYod7GcyT/UekdWk8Htw23gD8C4gtn43SWUImZZN4wh1fOULZdDy vgJ076hcChcyxPAe+ZxiUfIVXBbVagjAE3BOivfKvW5CfobB+BiX9Eo= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (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 EA9722AC072 for ; Tue, 9 Jul 2013 16:00:54 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so5285863wgh.0 for ; Tue, 09 Jul 2013 16:00:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BNj7QQ7w8nVF2V8tI0NJRKafiHguoV5tWNRSriAWXas=; b=Gk+eFk0tc5dY5bY2QH4Bs1npXunJTuUgZkWR5zFnODAyrGkb/ROp1645eoMp9eF1YZ OpAjxTiIxYOUdlBtukpE/zQECJedDnT8zkkQxQI8BBI9zzPHXy69kPx+UikyESxZ4iKK hSo914LjywU5+writu5WJ6voj1Po6cT9spMixdboJq4Q+s0gCuauuw0/Kh4F9cDkFU9n uVwX0S6HSD86PF1WZvpvRESu9HZGzqaDLJnw3NshFB2e+J263QRnI/vWqCmFIY+oDL5M 22ox1tW/jcpypERtxSgraOaR5B8EJQxgUmPdzsW38axgWWWa4BgANpwa9rkOczxvB44m +YLg== MIME-Version: 1.0 X-Received: by 10.180.185.176 with SMTP id fd16mr8314605wic.20.1373410853388; Tue, 09 Jul 2013 16:00:53 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Tue, 9 Jul 2013 16:00:53 -0700 (PDT) In-Reply-To: <51DC92B1.7000908@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> Date: Tue, 9 Jul 2013 18:00:53 -0500 Message-ID: From: Nico Williams To: "Peter F. Patel-Schneider" Content-Type: text/plain; charset=UTF-8 Cc: Jorge Chamorro , Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 23:01:00 -0000 On Tue, Jul 9, 2013 at 5:46 PM, Peter F. Patel-Schneider wrote: > But everything that I've read about JSON indicates that JSON is supposed to > be used for (portably) interchanging data. If all there is to JSON is the > grammar then what's the point of JSON? +1. In practice agreeing on a subset of typing results in interop, at least for implementations of specific applications. Sometimes, when straying past that subset, there's loss of information, and that mostly works out. Sometimes parsers reject inputs, this results in implementors figuring out what happened and how to improve interop, or else the user doesn't bother reporting the problem. We can definitely identify a subset of JSON that is extremely likely to interop successfully: - strings being Unicode character strings, possibly with paired surrogates (there are still some implementations, no doubt, that can't handle code points outside the BMP) - top-level is an array or object (though many parsers have options to allow other top-level types, so I don't think this is too important) - no dup names (parsers might or might not reject, or deconflict) - numbers as 32-bit signed integers, or maybe even numbers as IEEE 754 64-bit doubles -- TBD from a survey we might never do Note that the proposed I-JSON need not be that subset of JSON most likely to interop, just the subset we want for Internet protocols. And we might be happy enough with I-JSON that we never define any other subsets of JSON. RFC4627's underspecification, coupled with host languages with widely varying attributes led to JSON being a superset than most implementations of it. ECMAScript JSON is also a subset of RFC4627, and is neither a subset nor superset of the proposed I-JSON. > What is (surprisingly) missing in JSON is a firm notion of the data being > represented by the syntax. A pale shadow of this issue for strings appears > to have been consuming this working for quite some time. Yes. Nico -- From pfpschneider@gmail.com Tue Jul 9 16:10: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 E3CDA11E8196 for ; Tue, 9 Jul 2013 16:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 t5eB3Fy2jhFV for ; Tue, 9 Jul 2013 16:10:00 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0EC11E8193 for ; Tue, 9 Jul 2013 16:10:00 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id up14so7776246obb.14 for ; Tue, 09 Jul 2013 16:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=g2f806kJ9QNF1Ixb3pJAb/KgXyeS+Zb8CnPjnU0qT38=; b=s2IY0gEzZCzK0diaTWp5I6LzbFGeHBLEjkNobhQX27DhTSOi17SvusdhNMGsD6YCE9 pUX8pYKb1QZW9b9ioqv63NxGZoyzFVCGZTQj890TtJYRNHS4DsKon7u8mVCGxFpTPJZt MzffVehjVNZlidT0bf4f+rGbrho3io57AC88qPmL1+p3N9CjnlVs3+iJgsNatuTckZcH jP3DtUNlRXgcqNtwx2SNgPFMrpgDqSHW+3oPuRWr+09nkwghB1+V1tJu+g2IyG2Q8Iu6 t2Zx12VyP9qQ87mh6CLdboAU2OnxSuOUh8oNZcI0lPTgtdCHHUORSO6Zcttvz7uq8N/O GE9g== X-Received: by 10.182.219.166 with SMTP id pp6mr25973265obc.34.1373411399829; Tue, 09 Jul 2013 16:09:59 -0700 (PDT) Received: from [192.168.1.102] (out-on-158.wireless.telus.com. [207.219.69.158]) by mx.google.com with ESMTPSA id el16sm41442697oeb.2.2013.07.09.16.09.58 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 16:09:59 -0700 (PDT) Message-ID: <51DC9841.9020000@gmail.com> Date: Tue, 09 Jul 2013 16:09:53 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nico Williams References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 23:10:01 -0000 Each of your options provides a single type for what is represented by JSON numbers. However, this doesn't include multiple types, such as - 64 bit integers plus IEEE 754 64-bit double (for some loss tolerance) I think that the biggest surprise that I have had with respect to JSON numbers was that this multiple typing for JSON numbers was allowed (and maybe even common). This lead to my comments on whether the JSON numbers 1, 1.0, and 1.0E0 represent the same thing or not. Peter F. Patel-Schneider On 07/09/2013 03:45 PM, Nico Williams wrote: > On Tue, Jul 9, 2013 at 4:24 PM, Peter F. Patel-Schneider > wrote: >> [Somewhat less facetious.] > I was surprised that needn't have been at all facetious. JSON > surprises me all the time. Since so many parsers have optional > behaviours, let's explore this path. > >> Where does this end? Do I have to worry about whether, for example, 0.0 is >> different from 0.00? (Some people, e.g., numerical analysts, would argue >> that they are different - the first is 0+-0.05 and the second is 0+-0.005.) >> Do I have to worry about whether 0.1 is different from 1E-1? (Some people, >> e.g., XML-philes, might argue that the first is a decimal and the second is >> a float or double.) Do I have to worry about whether 0 is different from 0.? >> (Some people, e.g., C programmers, might argue that 0 is an int and 0. is a >> float.) > I think unnecessary leading or trailing zeros, or even zero decimal > fraction, are fair game to lose. Such things bear no information if > all we care about is numbers. (.0 in some languages implies floating > point, as opposed to integer, but that's not relevant here.) Ditto > negative zero. > > Otherwise the tolerance level for information loss in numbers should > be specified by the application. We can probably agree on some common > options that implementations *might* provide. Here's all the options > that I think we should consider, but I'm probably missing some: > > - IEEE 754 {32, 64}-bit double with unspecified loss tolerance-- any > value that can be represented as such no matter what lossage, will be > accepted > > - IEEE 754 {32, 64}-bit double with no loss in exponent and with N > digits of precision, with some specified rounding > > - IEEE 754 {32, 64}-bit double with no loss (e.g., 0.1 can't be > parsed as a double exactly) > > - take the floor of the number as an integer of {32, 64, 128} bits > > - take the floor of the number as bigint (whatever that means for the > parser / host language) (subject to some arbitrary max size > constraint) > > - bignum with no loss (subject to some arbitrary max size constraint) From jorge@jorgechamorro.com Tue Jul 9 16: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 7B8CD11E80D1 for ; Tue, 9 Jul 2013 16:24:24 -0700 (PDT) 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 syrRFbM9fVfJ for ; Tue, 9 Jul 2013 16:24:17 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 6327311E8193 for ; Tue, 9 Jul 2013 16:24:09 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so5699303wiw.1 for ; Tue, 09 Jul 2013 16:24:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=QDpKJWwgOmX4N0MvEtcTqdLukfme1xYCvMWanIPWfZ8=; b=ePj3ipB6fiiSe1zxKvOUqLGprMkwk7r0FhhElus74x6GeWEuNZrsQYruBcnZlE1FR7 ilruELZ+ZBYZGetTwsbsunpj3NBNsiI+jG7BOd5nFGOERpVKZu0gs8PzGK3mxgH488CO FNqOCpjpF1Zdu7/U/EjcbvmZyh8gh5v45w36A7DxW7jDBqpkTyNo0bOiAMBVCxrEfn/Y uHhiOTefqcRdt9sUSKEm/9wV3cXhf3qTt8gv3gCue29F+Tuw+/iS9jlyRBb7fba4BQJ9 zPflSaE6t6Ny28HdF7pX0esRNNcl53kRLhiBJwcmXps2WaclZ1IoKfauqJzbuzsoj/ft 2Kag== X-Received: by 10.180.188.97 with SMTP id fz1mr15597814wic.34.1373412246900; Tue, 09 Jul 2013 16:24:06 -0700 (PDT) Received: from [192.168.10.50] (189.Red-79-155-151.dynamicIP.rima-tde.net. [79.155.151.189]) by mx.google.com with ESMTPSA id em10sm54629643wid.1.2013.07.09.16.24.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 16:24:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: <51DC92B1.7000908@gmail.com> Date: Wed, 10 Jul 2013 01:24:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> To: Peter F. Patel-Schneider X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQm+cpinzcje4iFznz44Y7CMOtSNUrqtNimZNXBytXbifK0YAx8J06fSYpcoHfZsiccfM9ht Cc: Nico Williams , Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 23:24:38 -0000 On 10/07/2013, at 00:46, Peter F. Patel-Schneider wrote: >=20 >=20 > OK, then, what I inferred was that a JSON number represents an IEEE = floating point double and I was very surprised to find out that this was = not the case. And given the super-simple rules in the RFC *any* number can be properly = represented which is -it seems to me- exactly what Crockford had in = mind: that JSON (the data interchange format) does not impose the = limits. That the platforms, languages, libraries, and stringify()er and parse()r = implementations may have numeric data type limitations, isn't JSON's = (the data interchange format) business. --=20 ( Jorge )();= From pfpschneider@gmail.com Tue Jul 9 16:44:06 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 5E25E21F9C84 for ; Tue, 9 Jul 2013 16:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 R9Zn+AsjgwLm for ; Tue, 9 Jul 2013 16:44:05 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id C1F7021F9BF9 for ; Tue, 9 Jul 2013 16:44:05 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o6so8807991oag.13 for ; Tue, 09 Jul 2013 16:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mHCK5yYHe/zGV43wgSG5GEaH8x+DczJl0fPkQ2XUqnY=; b=KYCWyveCl50gn+khGtXaT5qbNJt9mFZHp0/hSmbXQZz6lBhJCQ8PrV12N7VDkL1iNo YYDOCQWEuATDHI5b24rQht2WZALIB5op1aJrfsbC0jN3HBbsW0hz4I6jjXFxVZmLDmqr rVadgJO72GvM6zbRXzdzfIgvzAWIJG2sIS+kTku8wZWmgFe/Y+8avg4vHT11h/dWSGt8 8mUBZgCpOBNGQMhb2XpiobBSgf35T5rrheH0zDACuPT36pCP7GbsRh8pOQi8ZFvxjw2q rNKBGExk30FKPYOz3TEyqZY7yImEcYlbYA9gsH6WeqnHbu5QD7x9V3emBvKgqvNtlvTl Ht7A== X-Received: by 10.60.95.198 with SMTP id dm6mr25989183oeb.44.1373413445236; Tue, 09 Jul 2013 16:44:05 -0700 (PDT) Received: from [192.168.1.102] (out-on-158.wireless.telus.com. [207.219.69.158]) by mx.google.com with ESMTPSA id mt3sm41615045oeb.1.2013.07.09.16.44.03 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 16:44:04 -0700 (PDT) Message-ID: <51DCA042.4000303@gmail.com> Date: Tue, 09 Jul 2013 16:44:02 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nico Williams References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> In-Reply-To: <20130709231139.GC8043@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bjoern Hoehrmann , Tatu Saloranta , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 23:44:06 -0000 On 07/09/2013 04:11 PM, Nico Williams wrote: > On Tue, Jul 09, 2013 at 03:58:58PM -0700, Peter F. Patel-Schneider wrote: >> Where then am I supposed to go to find out what a JSON number >> represents? There are many possibilities (float only, rational >> [...] > Today there is no specification to tell you that. We're working on it. > Here. Right now. With your input :) > > We seem to be concluding that there's no way to unify JSON. So it may > be that in the end you'll find two or more sets of guidance and you'll > have to select one (or all, deferring the choice to run-time). That's a very unhappy situation. My interest in JSON is to consume data in JSON documents (mostly to use as input into representation systems that also use the W3C semantic web languages RDF and OWL). If JSON is ambiguous (e.g., as to whether 0.0 and 0 encode/stand for/represent the same thing) then JSON isn't very suitable for transmitting data, at least for me. > >> The only suitable guidance provided in RFC4627 is via ECMAScript and >> ECMAScript is firmly IEEE floating point double only. > It's not the only possible guidance. You read RFC4627, you realize it's > underspecified and look for guidance. There's none from the IETF. > There's search engines and if you look at enough JSON implementations > (probably just two, at least of which must not be part of an ECMAScript > implementation) you should note the divergent interpretations of the > spec. > > Your [reasonable] mistake is to assume that because RFC4627 was inspired > by ECMAScript notation then when ECMAScript adds a specification for > JSON the latter must be authoritative. Aah, but that's not what I did. I didn't look at (the new-ish) section 15.12 of ECMAScription version 5.1 at all. Instead I looked at sections 7.8.3 (numeric literals) and 8.5 (numbers) of ECMAScript version 3, which is referenced from, and pre-dates, RFC 4627. I found indications that JSON numbers were derived from ECMAScript numeric literals, so I made the easy conclusion that the values represented by JSON numbers were supposed to be ECMAScript numbers, i.e., IEEE floating point double. > But standards development > organizations don't usually recognize invasions into each others' turfs > without prior agreements, and so... here we are. I had no need, or even desire, to look at a subsequent non-IETF work. > > Now, why should anyone trying to implement JSON need to know about SDO > politics? Well, because there's no way to reconcile all the different > JSONs now -- the ships have sailed. Sooner or later anyone dealing with > JSON will notice this, and then the question of who "owns" JSON comes > up, and then one discovers this whole mess. (Then one weeps. Lather, > rinse, repeat.) > >> So why are you surprised that I came up with this conclusion? > I'm not now, but once would have been. > > Nico Peter F. Patel-Schneider From cromis@gmail.com Tue Jul 9 16:49: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 37C5C11E80D3 for ; Tue, 9 Jul 2013 16:49:46 -0700 (PDT) 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 bNXKDd+T8zZo for ; Tue, 9 Jul 2013 16:49:45 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA8D21F9CAE for ; Tue, 9 Jul 2013 16:49:45 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id a1so3341491qcx.39 for ; Tue, 09 Jul 2013 16:49:45 -0700 (PDT) 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 :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=9AIwXaJL9cmx/xut70++tbbV4BNfKc/bMpLVoJZZcek=; b=IcvR0wQQwuv+32oUNe1RHZIJN3V79omhyGHFuQ5vqzzbMmZDxAlTv19C4ZYodWuBWi Ux0msjduonsCAu1if48q7A8O5e5FJsV4K31G7hxL/z82OVdcoXk57pUZZ/U44wBDkY11 oCAyaaMz4s5XHqecqmFmmmr5yC0X4ww4MDA2cHT1DAe+bT3zWaWBgEX2B2e1U/xAFbSd 9a6EWpXtX1kY4ktZFe/cHqXE1h7sov+vJ/AzE+vsnwyD2AM5I0nSuCKrBKgmdCm0Oe3x Bl6i/72MDVvnCylwIIGQR/IMph6GoboB4FwOfkJjWJV7wYEfaPEnVOGK91bv7C9CU5mH rHVg== X-Received: by 10.224.128.2 with SMTP id i2mr26170713qas.11.1373413785130; Tue, 09 Jul 2013 16:49:45 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.76.42 with HTTP; Tue, 9 Jul 2013 16:49:25 -0700 (PDT) In-Reply-To: <51DC95B2.8080801@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> From: Jacob Davies Date: Tue, 9 Jul 2013 16:49:25 -0700 X-Google-Sender-Auth: iZqPTxHNkx52zuoqMLCJ1_NFG80 Message-ID: To: "Peter F. Patel-Schneider" Content-Type: text/plain; charset=ISO-8859-1 Cc: Nico Williams , Bjoern Hoehrmann , Tatu Saloranta , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 09 Jul 2013 23:49:46 -0000 On Tue, Jul 9, 2013 at 3:58 PM, Peter F. Patel-Schneider wrote: > The only suitable guidance provided in RFC4627 is via ECMAScript and > ECMAScript is firmly IEEE floating point double only. > > So why are you surprised that I came up with this conclusion? What I found surprising was that there appeared to be lots of people willing to say that the strings in the JSON data model (not the format) are Unicode, or that the keys in the objects must be unique according to one particular method of string normalization, but not that the numbers in JSON are derived from Javascript and that interoperability in the most important use of JSON (sending data to browsers) absolutely requires you to stay within the size limit of Javascript numbers (and failure to do so has led to some notable bugs that require backwards-incompatible API changes, i.e. going from number -> string for some field). My take prior to this discussion was that the mild annoyance of not being able to send 9223372036854775807 as a number in JSON was the reasonable price you paid for having an interoperable number range in the format. It seemed like most people here disagreed with my impression, which is fair enough, and it sounded like Douglas Crockford's intent was not to restrict them in such a way, but I would be surprised if many people actually - intentionally at least! - use numbers from outside the Javascript range in JSON, given the problems it causes for Javascript. As for numbers smaller than that range, the RFC says implementations may reject numbers they don't like, so an implementation without floating point numbers is OK, just not capable of general interoperability. From pfpschneider@gmail.com Tue Jul 9 17:16: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 F240011E80D3 for ; Tue, 9 Jul 2013 17:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 BQ8XVqxe1Fok for ; Tue, 9 Jul 2013 17:16:41 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id ED80911E8140 for ; Tue, 9 Jul 2013 17:16:39 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so7658449obb.36 for ; Tue, 09 Jul 2013 17:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=huQz9oQLNs8nv6pE2URcyxGN1PygJZPwvjVJR9DkvOY=; b=Ky+EihmssE3hwdHGm1lH1kEaNy5O+aJi87sImIIluiCjHgmCwZdbhsL/PO4LJfhVoV r2BSycQ7h/FLrQ6fsL9AeDbehSM3MZ8IONHMcyMfs1aLXZdjsIcPsouRl6OEJGXwqaoU gcU8TZDulT21cdCxUwJ0Lu1/rDUZIom5EVAIxWEsbQqHYkj7Kxf6Zd6VM3xGIEVCSOou lHyi8zzVDykDhZF1z2NKY4mDUaFiuuNHv8qhgH/9I8/fyWlm7N4McupKkybXGGW134b6 NUwp8b8YN6vPwRp2+GXXUw5H82JHtics6HjarsXJv6PghCPn6Soi6iDacLj+SFTfcT4T N34w== X-Received: by 10.60.45.229 with SMTP id q5mr26002749oem.79.1373415399356; Tue, 09 Jul 2013 17:16:39 -0700 (PDT) Received: from [192.168.1.102] (out-on-158.wireless.telus.com. [207.219.69.158]) by mx.google.com with ESMTPSA id df11sm41772456oec.0.2013.07.09.17.16.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 17:16:38 -0700 (PDT) Message-ID: <51DCA7DD.8060807@gmail.com> Date: Tue, 09 Jul 2013 17:16:29 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jorge Chamorro References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nico Williams , Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 00:16:43 -0000 *Any* number? Not so! Assuming sane rules, JSON numbers are inadequate for representing all rationals, and the same holds, of course, for any superset of the rationals, including reals and complex. (Yes, yes, no usable data format can represent all the reals or complex numbers.) JSON numbers are unlike the numeric type system of any programming language that I had been familiar with, even LISP. That JSON numbers are so close to ECMAScript numeric literals is, to me, a very strong indication that JSON numbers are supposed to represent ECMAScript numbers. I do agree that implementations may be range-restricted, and that a data interchange format shouldn't always nail the ranges down exactly. However, floats (being rather unusual numbers) are one place where it can be fruitful to nail things completely down. Peter F. Patel-Schneider On 07/09/2013 04:24 PM, Jorge Chamorro wrote: > On 10/07/2013, at 00:46, Peter F. Patel-Schneider wrote: >> >> OK, then, what I inferred was that a JSON number represents an IEEE floating point double and I was very surprised to find out that this was not the case. > And given the super-simple rules in the RFC *any* number can be properly represented which is -it seems to me- exactly what Crockford had in mind: that JSON (the data interchange format) does not impose the limits. > > That the platforms, languages, libraries, and stringify()er and parse()r implementations may have numeric data type limitations, isn't JSON's (the data interchange format) business. From jorge@jorgechamorro.com Tue Jul 9 17:19: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 B1EDA11E80D3 for ; Tue, 9 Jul 2013 17:19:49 -0700 (PDT) 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 HJec2GOpzIRl for ; Tue, 9 Jul 2013 17:19:43 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78E1311E8199 for ; Tue, 9 Jul 2013 17:19:43 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so10799388wiw.17 for ; Tue, 09 Jul 2013 17:19:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mX0XvViGr5YhytlgCndjrfoBa6rzmQ0/Q3mvxjXg+V4=; b=WrxOBzlgJSIQ9fX8BdP29LxCFN6gGWyiuM9DwjAJzJYrXouzRTZUNrm2dZcVyMsY+S hxxcQrRqLOBX2ryNY7XoB3EXGGjrVVTKAuArM/C6PX+nNEZGYYgh8Vsoc4cobUVMwOmQ Qn1hs79EBxCxJ04OExkUgJgKYj5R8hr0fsz0cstG8na8uX83UAUTfmjKALE2v2TvjSYO Vu09IXqLs8IXdUbfsQNrI/ku+AWkOCRJwHPqNF7PDjyxFyyRwYv0Y3O5XoFo4qw9swzp ticGyuIT6A+Gm5bN3hoVT33YOt/1hDrNNmLdRHHVSeCPB1S8xCh8VpoT7pcrU3eLhLgx f7oQ== X-Received: by 10.194.48.116 with SMTP id k20mr16759930wjn.23.1373415582220; Tue, 09 Jul 2013 17:19:42 -0700 (PDT) Received: from [192.168.10.50] (189.Red-79-155-151.dynamicIP.rima-tde.net. [79.155.151.189]) by mx.google.com with ESMTPSA id p1sm64081630wix.9.2013.07.09.17.19.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 17:19:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: Date: Wed, 10 Jul 2013 02:19:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <88456E47-3DC1-4EE9-B827-B3705FAB93D6@jorgechamorro.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> To: Jacob Davies X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkQytenIjoez+9ZpQqv0bwETD/4IpKR5joSXs+TBg2zb9KEYv2FYfI6vmTGnw8Pv1PuGCki Cc: Nico Williams , Bjoern Hoehrmann , "Peter F. Patel-Schneider" , Tatu Saloranta , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 00:19:50 -0000 On 10/07/2013, at 01:49, Jacob Davies wrote: >=20 > My take prior to this discussion was that the mild annoyance of not > being able to send 9223372036854775807 as a number in JSON was the > reasonable price you paid for having an interoperable number range in > the format. It seemed like most people here disagreed with my > impression, which is fair enough, and it sounded like Douglas > Crockford's intent was not to restrict them in such a way, but I would > be surprised if many people actually - intentionally at least! - use > numbers from outside the Javascript range in JSON, given the problems > it causes for Javascript. Right, the implementations set the limits, and JavaScript = implementations in particular have to watch out for interoperability = problems in the presence of 64 bit ints. --=20 ( Jorge )();= From tsaloranta@gmail.com Tue Jul 9 18:09:10 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 906CC21F9AC1 for ; Tue, 9 Jul 2013 18:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 SnfFLerb4+8M for ; Tue, 9 Jul 2013 18:09:10 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 238AD21F9ACD for ; Tue, 9 Jul 2013 18:09:03 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so5407457wes.32 for ; Tue, 09 Jul 2013 18:09:03 -0700 (PDT) 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=p/7ICDujihguOZXd3zwPCrYkyqKO+xwmeiweefdUXQQ=; b=rgzweFQLvNE4dtTSWBypfHolCCf84U2ApL8i9mhpEaVP9nDhQCUFcegGKiG2JcviMS 0P6kG91Pe/axJ8V31aeL6TjCsdVCYQOFHS2kF1N2lUTInt9dYwL+qFdFGgnfrq9FeDVt +G+nxfKRF+nJJgOfRQxNXZJGZZsyO8rzF3l5RD4GZ+LG7IKZNz9qqIvfoxANhBai6LwW zKofKbKp99t8YHoSbI29ppjRvmKnfSGGnIt3u2/z5PRRNJcCFirhpYOojaD2k5uaYax3 06FTBTliJj85D3quydJS0Bj1jAWTcc7UeBFXARiFqtiPFrUiH1hxgeKx1ba6aGcFAAWn wlXQ== MIME-Version: 1.0 X-Received: by 10.180.11.146 with SMTP id q18mr14567704wib.50.1373418542841; Tue, 09 Jul 2013 18:09:02 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Tue, 9 Jul 2013 18:09:02 -0700 (PDT) In-Reply-To: <51DC92B1.7000908@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> Date: Tue, 9 Jul 2013 18:09:02 -0700 Message-ID: From: Tatu Saloranta To: "Peter F. Patel-Schneider" Content-Type: multipart/alternative; boundary=001a11c24d165fc63904e11dec14 Cc: Nico Williams , Jorge Chamorro , Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 01:09:10 -0000 --001a11c24d165fc63904e11dec14 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 3:46 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > > On 07/09/2013 03:19 PM, Jorge Chamorro wrote: > >> On 09/07/2013, at 23:24, Peter F. Patel-Schneider wrote: >> >>> Imagine my surprise when I was told that my reasoning was not correct. >>> >> A "JSON number" is a *text* not a number: >> > > OK, OK. A JSON number represents a number. I'm guilty of not being > appropriately pedantic. > > But everything that I've read about JSON indicates that JSON is supposed > to be used for (portably) interchanging data. If all there is to JSON is > the grammar then what's the point of JSON? > > Proof is in pudding. JSON has been used successfully for years now for interchanging data. I can't recall a case where number precision had actually been reported as a problem; even though it is obvious that something could go wrong somewhere. So while JSON is under-specified, it turns out that actual systems have been successfully built and Just Work. All alarmism aside it is easy to get tangled in the web of _potential_ issues. Same is true with many discussed aspects, including mortal danger of duplicate names. For some reasons it has not registered as a reported issue for library implementors (as far as I know). -+ Tatu +- --001a11c24d165fc63904e11dec14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2013 at 3:46 PM, Peter F. Patel-Schneider <= span dir=3D"ltr"><pfpschneider@gmail.com> wrote:

On 07/09/2013 03:19 PM, Jorge Chamorro wrote:
On 09/07/2013, at 23:24, Peter F. Patel-Schneider wrote:
Imagine my surprise when I was told that my reasoning was not correct.
A "JSON number" is a *text* not a number:

OK, OK. =A0A JSON number represents a number. =A0 I'm guilty of not bei= ng appropriately pedantic.

But everything that I've read about JSON indicates that JSON is suppose= d to be used for (portably) interchanging data. =A0If all there is to JSON = is the grammar then what's the point of JSON?


Proof is in pudding. JSON has been used su= ccessfully for years now for interchanging data.
I can't = recall a case where number precision had actually been reported as a proble= m; even though it is obvious that something could go wrong somewhere.
So while JSON is under-specified, it turns out that actual syste= ms have been successfully built and Just Work.

All alarmi= sm aside it is easy to get tangled in the web of _potential_ issues. Same i= s true with many discussed aspects, including mortal danger of duplicate na= mes. For some reasons it has not registered as a reported issue for library= implementors (as far as I know).

-+ Tatu +-

--001a11c24d165fc63904e11dec14-- From tsaloranta@gmail.com Tue Jul 9 18:12:10 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 A4CA021F9B08 for ; Tue, 9 Jul 2013 18:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=-1.031, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 iXLqMChGa3xk for ; Tue, 9 Jul 2013 18:12:08 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0976C21F9A96 for ; Tue, 9 Jul 2013 18:12:07 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w56so5230050wes.25 for ; Tue, 09 Jul 2013 18:12:07 -0700 (PDT) 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=gpXXhg5GsknxtXNZIPH2DcLUFQfGEF+KZevtQEhhAM4=; b=DH15yAzXJSuHLuDkv9eABmZK9ztdvF1PvuD94z37wZG8IbvTVFyFNsJlrcTZhYBnh4 fQIKOzZ/Dw3FogEC2MrQyKhEkZfm0uiHwGweI6wkxpodvIBce3BNHwR0SNj1HM8qPZA1 FEQiq4UKs3H84DORmYm2J9PG6sT//0zNrpV+9CtqlPNqwEGDAklUKp2COF9dBubIOuYc ftUFRM0zIpm0ZDFDBsn5V7DPl2fcj/M6LbM1FXUrrC7Z6YnHTNGjw3XIS6zt29lOrDJK FlfD6iFrvEtTMHIPmGc/zxvNvbr7g2615uIeGwDklSvjaeKnxE8C+QQjklfqSzlbDos2 pCEg== MIME-Version: 1.0 X-Received: by 10.180.188.36 with SMTP id fx4mr32924960wic.55.1373418727179; Tue, 09 Jul 2013 18:12:07 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Tue, 9 Jul 2013 18:12:07 -0700 (PDT) In-Reply-To: <51DC95B2.8080801@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> Date: Tue, 9 Jul 2013 18:12:07 -0700 Message-ID: From: Tatu Saloranta To: "Peter F. Patel-Schneider" Content-Type: multipart/alternative; boundary=001a11c25cd85c8faa04e11df72a Cc: Nico Williams , Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 01:12:10 -0000 --001a11c25cd85c8faa04e11df72a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 3:58 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > Where then am I supposed to go to find out what a JSON number represents? > There are many possibilities (float only, rational only, separate integer > and float, separate rational and float, variable-precision decimal only, > separate integer and variable-precision decimal, variable precision float > only, ...). And then there are the various range possibilities. > > The only suitable guidance provided in RFC4627 is via ECMAScript and > ECMAScript is firmly IEEE floating point double only. > > So why are you surprised that I came up with this conclusion? > > So your proof is of the form "I was trying to find answer to X; and the only answer I found was Y; thereby it MUST BE the right answer"? That is a logical fallacy of some kind. But you are right in that perhaps I should not be surprised. Different people reach different conclusions all the time, even if given same information. -+ Tatu +- > peter > > > > > On 07/09/2013 02:34 PM, Tatu Saloranta wrote: > >> I am surprised you came to this conclusion, since I assumed we were >> finally getting rid of misconception that JSON is closely tied to >> Javascript. >> >> This is not to say that the way JSON (under-)defines numbers is optimal; >> but at this point forcing castrated version of numbers -- which would lead >> to practical problems like preventing use of 64-bit longs for timestamps -- >> would be counter-productive and to me a non-starter. >> >> -+ Tatu +- >> >> >> > --001a11c25cd85c8faa04e11df72a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2013 at 3:58 PM, Peter F. Patel-Schneider <= span dir=3D"ltr"><pfpschneider@gmail.com> wrote:
Where then am I supposed to go to find out w= hat a JSON number represents? =A0 There are many possibilities (float only,= rational only, separate integer and float, separate rational and float, va= riable-precision decimal only, separate integer and variable-precision deci= mal, variable precision float only, ...). And then there are the various ra= nge possibilities.
=A0
The only suitable guidance provided in RFC4627 is via ECMAScript and ECMASc= ript is firmly IEEE floating point double only.
=A0
So why are you surprised that I came up with this conclusion?


So your proof is of the = form "I was trying to find answer to X; and the only answer I found wa= s Y; thereby it MUST BE the right answer"? That is a logical fallacy o= f some kind.

But you are right in that perhaps I should not be surprised.= Different people reach different conclusions all the time, even if given s= ame information.

-+ Tatu +-

=A0
peter




On 07/09/2013 02:34 PM, Tatu Saloranta wrote:
I am surprised you came to this conclusion, since I assumed we were finally= getting rid of misconception that JSON is closely tied to Javascript.

This is not to say that the way JSON (under-)defines numbers is optimal; bu= t at this point forcing castrated version of numbers -- which would lead to= practical problems like preventing use of 64-bit longs for timestamps -- w= ould be counter-productive and to me a non-starter.

-+ Tatu +-




--001a11c25cd85c8faa04e11df72a-- From cowan@ccil.org Tue Jul 9 18:26: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 09EF811E813A for ; Tue, 9 Jul 2013 18:26:21 -0700 (PDT) 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_12=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 ADAJ3bu+tqkQ for ; Tue, 9 Jul 2013 18:26:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B136111E80BA for ; Tue, 9 Jul 2013 18:26:16 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UwjAV-0006GE-29; Tue, 09 Jul 2013 21:26:07 -0400 Date: Tue, 9 Jul 2013 21:26:07 -0400 From: John Cowan To: John Levine Message-ID: <20130710012606.GM9153@mercury.ccil.org> References: <20130709222601.32831.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130709222601.32831.qmail@joyce.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: nico@cryptonector.com, json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 01:26:21 -0000 John Levine scripsit: > Do we actually know? Or is it just whatever number format a library's > underlying language happens to provide? I would be very surprised if existing libraries did *not* handle the entire range of IEEE doubles (other than Inf, -Inf, NaN, and -0.0) at the very least. -- weirdo: When is R7RS coming out? John Cowan Riastradh: As soon as the top is a beautiful cowan@ccil.org golden brown and if you stick a toothpick in it, the toothpick comes out dry. www.ccil.org/~cowan From pfpschneider@gmail.com Tue Jul 9 18:37:01 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 0F8E121F9A23 for ; Tue, 9 Jul 2013 18:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.936, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 7G9LuVPaz5+4 for ; Tue, 9 Jul 2013 18:37:00 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 49E4621F9A18 for ; Tue, 9 Jul 2013 18:36:51 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so7815373obc.13 for ; Tue, 09 Jul 2013 18:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mZmtufgozQQwDyoqWZ8BFcVW/Jzu3C24Res8pXVDzgc=; b=prZWzgfE7BhUrj1pJ5L9OYNAWP90O+Cgf/gp0f7WMrKxUUEMh8TYmdORmOnunTLRex 0Rh39k27txQ1GUqn44Sdt7Q3PvXy2j/txBFZTKPscEY9u9D5WBET1QJeMJqwkt03LW/K 7KvcBNBByl1BDU6Su4IFEiQ+7/lPpiJmy4EA40fmzjXWgki5i7iz2tuQ7Keud6gXvfcS GHNatYFeXkQ7EeDBdl9BlyqOUW353phvCtjJpHPImNSXDIaxqZ4F0b9uHGhI3LwlF4xF LujtOIt7ReW4DOmRnzF0pE+JCllAxMIiD6dQASezhROve7xmkYXKPX2coxU2YX3taBLW Ln6A== X-Received: by 10.182.231.131 with SMTP id tg3mr5192616obc.44.1373420210737; Tue, 09 Jul 2013 18:36:50 -0700 (PDT) Received: from [192.168.1.102] (out-on-158.wireless.telus.com. [207.219.69.158]) by mx.google.com with ESMTPSA id o8sm6190298obx.11.2013.07.09.18.36.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 18:36:49 -0700 (PDT) Message-ID: <51DCBAAF.20200@gmail.com> Date: Tue, 09 Jul 2013 18:36:47 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tatu Saloranta References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nico Williams , Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 01:37:01 -0000 My reasoning is more like: I was trying to find the answer to Y about X in the defining document for X and the only thing related to Y there (or related to Y in anything pointed to from there) was Z so Z should be the answer. Yes, this isn't quite the situation, but it's close. Yes, this isn't the way things should work in a defining document, but that's the situation with respect to this defining document. Peter F. Patel-Schneider On 07/09/2013 06:12 PM, Tatu Saloranta wrote: > On Tue, Jul 9, 2013 at 3:58 PM, Peter F. Patel-Schneider > > wrote: > > Where then am I supposed to go to find out what a JSON number > represents? There are many possibilities (float only, rational only, > separate integer and float, separate rational and float, > variable-precision decimal only, separate integer and variable-precision > decimal, variable precision float only, ...). And then there are the > various range possibilities. > > The only suitable guidance provided in RFC4627 is via ECMAScript and > ECMAScript is firmly IEEE floating point double only. > > So why are you surprised that I came up with this conclusion? > > > So your proof is of the form "I was trying to find answer to X; and the only > answer I found was Y; thereby it MUST BE the right answer"? That is a > logical fallacy of some kind. > > But you are right in that perhaps I should not be surprised. Different > people reach different conclusions all the time, even if given same information. > > -+ Tatu +- > > peter > > > > > On 07/09/2013 02:34 PM, Tatu Saloranta wrote: > > I am surprised you came to this conclusion, since I assumed we were > finally getting rid of misconception that JSON is closely tied to > Javascript. > > This is not to say that the way JSON (under-)defines numbers is > optimal; but at this point forcing castrated version of numbers -- > which would lead to practical problems like preventing use of 64-bit > longs for timestamps -- would be counter-productive and to me a > non-starter. > > -+ Tatu +- > > > > From pfpschneider@gmail.com Tue Jul 9 18:47: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 7FC0811E80F4 for ; Tue, 9 Jul 2013 18:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 AF9+nqs10vMW for ; Tue, 9 Jul 2013 18:47:22 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id DDB0511E80EC for ; Tue, 9 Jul 2013 18:47:21 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id n10so9022272oag.14 for ; Tue, 09 Jul 2013 18:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=y9v3MGFnN/tF8KxY2Yo44s5kZRCl5hl/s3JvAVinZpA=; b=OXwRq+4w/7S7lLh2EEQnjDnbX1K12Li2NHGTL2Ul0XOeVuKsjHVUcZhi3YpveuDTXv NslTQWDFOPZjTrOsdlufgtYpXbvkvafpJnAeJoWDLmb/JWt7VVBi9cSCT1vp+ANv0JMd EkOZs3UQLv9QnGb1//5I5jiXVwwS53GCCPhSVggOrL+ZpZSC/5rrxDJ8L529dkvNvTE2 aEqq5eiDbp50nuaxxUaJHk9gfYHUUlxUUWM9yOXJ1TAK5uZyjTxFU4g2koyOlSYpl1ZW 6TKf2pUESSAvcmXnupM/tew4vj/x0XJMSN50fwgwlhVUcAPoaXUuj5k5X/ToNMGFmI82 SYcg== X-Received: by 10.182.34.166 with SMTP id a6mr19308009obj.102.1373420841048; Tue, 09 Jul 2013 18:47:21 -0700 (PDT) Received: from [192.168.1.102] (out-on-158.wireless.telus.com. [207.219.69.158]) by mx.google.com with ESMTPSA id q4sm41421915obl.1.2013.07.09.18.47.15 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 18:47:20 -0700 (PDT) Message-ID: <51DCBD22.3060000@gmail.com> Date: Tue, 09 Jul 2013 18:47:14 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tatu Saloranta References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nico Williams , Jorge Chamorro , Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 01:47:22 -0000 On 07/09/2013 06:09 PM, Tatu Saloranta wrote: > On Tue, Jul 9, 2013 at 3:46 PM, Peter F. Patel-Schneider > > wrote: > > > On 07/09/2013 03:19 PM, Jorge Chamorro wrote: > > On 09/07/2013, at 23:24, Peter F. Patel-Schneider wrote: > > Imagine my surprise when I was told that my reasoning was not > correct. > > A "JSON number" is a *text* not a number: > > > OK, OK. A JSON number represents a number. I'm guilty of not being > appropriately pedantic. > > But everything that I've read about JSON indicates that JSON is supposed > to be used for (portably) interchanging data. If all there is to JSON > is the grammar then what's the point of JSON? > > > Proof is in pudding. JSON has been used successfully for years now for > interchanging data. > I can't recall a case where number precision had actually been reported as a > problem; even though it is obvious that something could go wrong somewhere. > So while JSON is under-specified, it turns out that actual systems have been > successfully built and Just Work. > > All alarmism aside it is easy to get tangled in the web of _potential_ > issues. Same is true with many discussed aspects, including mortal danger of > duplicate names. For some reasons it has not registered as a reported issue > for library implementors (as far as I know). > > -+ Tatu +- > So there is more to JSON than the grammar. But what is this more? I've heard quite divergent views on what this more is, both in the working group and, even more, outside it. If you want to sent certain kinds of data (non-C0 ASCII strings, nothing that could be considered to be duplicate names in objects, 32-bit signed integers, ...) around using JSON, then things work well, but what are the limits? What happens when these limits are exceeded? For example, the systems that I build need to know whether 0 and 0.0 represent the same thing because they count up the number of distinct values. Peter F. Patel-Schneider From cowan@ccil.org Tue Jul 9 19:39:10 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 B6DC111E80FD for ; Tue, 9 Jul 2013 19:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 EqiOlmDoSb-j for ; Tue, 9 Jul 2013 19:38:59 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id E700E11E80BA for ; Tue, 9 Jul 2013 19:38:58 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UwkIv-0004wQ-Di; Tue, 09 Jul 2013 22:38:53 -0400 Date: Tue, 9 Jul 2013 22:38:53 -0400 From: John Cowan To: "Peter F. Patel-Schneider" Message-ID: <20130710023853.GN9153@mercury.ccil.org> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> <51DCA7DD.8060807@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51DCA7DD.8060807@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Nico Williams , Jorge Chamorro , Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 02:39:10 -0000 Peter F. Patel-Schneider scripsit: > JSON numbers are unlike the numeric type system of any programming > language that I had been familiar with, even LISP. Basic and Perl are both flonum-only, at least unless you set appropriate options. -- Is a chair finely made tragic or comic? Is the John Cowan portrait of Mona Lisa good if I desire to see cowan@ccil.org it? Is the bust of Sir Philip Crampton lyrical, http://ccil.org/~cowan epical or dramatic? If a man hacking in fury at a block of wood make there an image of a cow, is that image a work of art? If not, why not? --Stephen Dedalus From cowan@ccil.org Tue Jul 9 19:42: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 5552811E8199 for ; Tue, 9 Jul 2013 19:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 lXP9baDHr+zY for ; Tue, 9 Jul 2013 19:42:17 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id ED07611E80FC for ; Tue, 9 Jul 2013 19:42:16 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UwkMB-0005Pb-JQ; Tue, 09 Jul 2013 22:42:15 -0400 Date: Tue, 9 Jul 2013 22:42:15 -0400 From: John Cowan To: Tatu Saloranta Message-ID: <20130710024215.GO9153@mercury.ccil.org> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.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: Nico Williams , Bjoern Hoehrmann , "Peter F. Patel-Schneider" , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 02:42:21 -0000 Tatu Saloranta scripsit: > This is not to say that the way JSON (under-)defines numbers is optimal; > but at this point forcing castrated version of numbers -- which would lead > to practical problems like preventing use of 64-bit longs for timestamps -- > would be counter-productive and to me a non-starter. Apparently, there are already practical problems with interchanging 64-bit longs: google for [json large numbers bugs] for lots of reports. While there are apparently int32-only systems out there, it's clearly understood that they are unusually restricted: such is not the case for JavaScript-hosted implementations. -- By Elbereth and Luthien the Fair, you shall cowan@ccil.org have neither the Ring nor me! --Frodo http://www.ccil.org/~cowan From cabo@tzi.org Tue Jul 9 20:16:25 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 6806211E80FF for ; Tue, 9 Jul 2013 20:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.206 X-Spam-Level: X-Spam-Status: No, score=-106.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 AWDoGrB8kvvG for ; Tue, 9 Jul 2013 20:16:19 -0700 (PDT) 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 460FB11E80E8 for ; Tue, 9 Jul 2013 20:16:18 -0700 (PDT) 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 r6A3GGlA005935; Wed, 10 Jul 2013 05:16:16 +0200 (CEST) Received: from [192.168.217.105] (p548949D5.dip0.t-ipconnect.de [84.137.73.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3CC7D37C0; Wed, 10 Jul 2013 05:16:16 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130710024215.GO9153@mercury.ccil.org> Date: Wed, 10 Jul 2013 05:16:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60109A8A-548F-4C60-8865-1C0AF5D09064@tzi.org> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <20130710024215.GO9153@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 03:16:25 -0000 On Jul 10, 2013, at 04:42, John Cowan wrote: > google for [json large numbers bugs] Next up: google for =BBnumber overflow bugs=AB. Somehow, it seems that handling large numbers is not entirely a problem = specific to JSON. Any interchange format that exchanges numbers between ecosystems with = different number formats will run into this. That is not a valid = argument for saying JSON should be a single-ecosystem format. Gr=FC=DFe, Carsten From nico@cryptonector.com Tue Jul 9 21:13: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 CC8CE11E810A for ; Tue, 9 Jul 2013 21:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=-0.105, 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 DmwNBEvzeA4A for ; Tue, 9 Jul 2013 21:13:26 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id E952721F9B89 for ; Tue, 9 Jul 2013 21:13:25 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 5202F1F0086 for ; Tue, 9 Jul 2013 21:13:25 -0700 (PDT) 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=/tK78wUpt5PFJf/nO/vC kMaIcgM=; b=IfMvplxpRxuVzFDKRVbpnnSE6eZ9FnrM5/oU804a27hsEzlMazo9 7ZnmHvIPunOsi7E7NxP8tBZxAPm2JOjFCa1bEK6eC5JBqr4admzmb2VTuGxbtqkP /D+ma8SKJK7wJoXF/EkJDLmXAaZb6lFG6jAnIK6587wtFj1YUL9VTb8= Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id E25BE1F0085 for ; Tue, 9 Jul 2013 21:13:24 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so5448023wes.37 for ; Tue, 09 Jul 2013 21:13:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OXNZQuiGJ8IqWjWig0xw+3rE3meRpJEADb2D9n5sT4U=; b=fDNOvLeFP7tmlqOaxQj3PcSef6hX+hKoZGFd/7muX/5j3Wi0Zr8FatPkjWvlVcpOsV 4Sa8rhzuGUHtRbdHZqMTGArugLLguzoGh/5CLcm0bfY5lep6sMcyJr+dnDph6Lxhe8Ty RYlsCxwYCZn34tTz6Q7G7Guxw9Ktz3Lbb4+t24vn1tqpdfQQ8l+lGRS5gGG8UIfhqnDi vUHpj3q6qbsCc79b1C7TgD5tVq7qrVfrhtpawnHWa2KBXWnqf0bmhfFyCukJoXle1LTR xxSPiQbj/d9upmK9Jzjnw+SJ+TpfXbstZHvBdLujXWA5vRsPmYjpTzmzmAGDfHbrdpfC Ibug== MIME-Version: 1.0 X-Received: by 10.180.74.162 with SMTP id u2mr4552517wiv.36.1373429603164; Tue, 09 Jul 2013 21:13:23 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Tue, 9 Jul 2013 21:13:23 -0700 (PDT) In-Reply-To: <20130710024215.GO9153@mercury.ccil.org> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <20130710024215.GO9153@mercury.ccil.org> Date: Tue, 9 Jul 2013 23:13:23 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Cc: "Peter F. Patel-Schneider" , Bjoern Hoehrmann , Tatu Saloranta , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 04:13:31 -0000 On Tue, Jul 9, 2013 at 9:42 PM, John Cowan wrote: > Apparently, there are already practical problems with interchanging > 64-bit longs: google for [json large numbers bugs] for lots of reports. > While there are apparently int32-only systems out there, it's clearly > understood that they are unusually restricted: such is not the case > for JavaScript-hosted implementations. So let's survey implementations. ECMAScript, Perl, Python, libjv, Jansson, json-c -- all have doubles. Heimdal's not-really-intended-for-external-use-(not-yet) JSON implementation only does 32-bit integers. This one doesn't count, and it'd be easy to add double support to it if it mattered. Are there any C JSON libraries that do NaN coding? Those are the ones I know, use, and/or contribute to. Nico -- From cowan@ccil.org Tue Jul 9 21:41: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 3C4E521F99DE for ; Tue, 9 Jul 2013 21:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 O8DYQsuUs4m9 for ; Tue, 9 Jul 2013 21:41:42 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBA021F99CE for ; Tue, 9 Jul 2013 21:41:42 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UwmDj-00006z-Ju; Wed, 10 Jul 2013 00:41:39 -0400 Date: Wed, 10 Jul 2013 00:41:39 -0400 From: John Cowan To: Nico Williams Message-ID: <20130710044139.GQ9153@mercury.ccil.org> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <20130710024215.GO9153@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: "Peter F. Patel-Schneider" , Bjoern Hoehrmann , Tatu Saloranta , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 04:41:47 -0000 Nico Williams scripsit: > ECMAScript, Perl, Python, libjv, Jansson, json-c -- all have doubles. My own implementation in Scheme will interpret a number with a decimal point or an exponent as an IEEE double, except on the few Schemes that don't support inexact numbers. An integer will be interpreted as an exact integer up to the system limit, which varies from 24-bit to limited only by memory size. -- Being understandable rather than obscurantist poses certain risks, in that one's opinions are clear and therefore | John Cowan falsifiable in the light of new data, but it has the | cowan@ccil.org advantage of encouraging feedback from others. --James A. Matisoff From sgbeal@googlemail.com Wed Jul 10 02:48:01 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 6F8EA21F9F75 for ; Wed, 10 Jul 2013 02:48:01 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 W90qFJi69sh5 for ; Wed, 10 Jul 2013 02:48:00 -0700 (PDT) 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 860C321F9F6D for ; Wed, 10 Jul 2013 02:48:00 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so6533529pbb.34 for ; Wed, 10 Jul 2013 02:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=mJ+A/NsJ/17UQzk18zE6Wh0XQaxUi5G4p6zKp2LuK3Q=; b=GhApHlOwt99AJgMb6hZPC0J59W+gv6XFC8E/xuN8EkEVXGnq+cwY7/ddsXiAv4bLOT MDGwdQZ2YzGYtBGLhE2HX24CydixkLEVH1/R5AdbENyQr13M72gNAG6tS4aEKZcOQmkC EVXsoLNyZuqYb3gpz4QdoeRcPUnta7vHS1EiDlSY8YQ0F18m/qVZrxP/LW2actHn0SLg tuQuEifX5RIR7yTfD776/Tr6yU5PofRLlIK6aIE0Wbs9Q8iUahlnz+Dv8s2aDeYUB9qW J024oJA+iXs9oimZAwKRf0UvRuoGzPnebrLjHbZlT2FYf5owJjZg8TSaTNZD4EF9i7wM IFsA== MIME-Version: 1.0 X-Received: by 10.66.121.170 with SMTP id ll10mr31786445pab.126.1373449679540; Wed, 10 Jul 2013 02:47:59 -0700 (PDT) Received: by 10.68.156.35 with HTTP; Wed, 10 Jul 2013 02:47:59 -0700 (PDT) In-Reply-To: <51DCA042.4000303@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> <51DCA042.4000303@gmail.com> Date: Wed, 10 Jul 2013 11:47:59 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b41bb0e441f2e04e1252cde Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 09:48:01 -0000 --047d7b41bb0e441f2e04e1252cde Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 10, 2013 at 1:44 AM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > That's a very unhappy situation. My interest in JSON is to consume data > in JSON documents (mostly to use as input into representation systems that > also use the W3C semantic web languages RDF and OWL). If JSON is ambiguous > (e.g., as to whether 0.0 and 0 encode/stand for/represent the same thing) > then JSON isn't very suitable for transmitting data, at least for me. > While i think we will all agree that, at a technically pedantic level, you're absolutely right, JSON has been in heavy use for about 10(?) years now with _relatively_ few instances of this causing a problem. Implementors tend to use whatever default limits the platform provides (e.g. 32-bit on 32-bit platforms and 64 on 64-bit, and 6-digit precision in doubles seems to be conventional in C libraries). People using high-precision/very large/very small numbers are certainly aware of the limitations/portability problems, and will (possibly after falling on their face with JSON) pick a different format. That's all fine and good - i haven't seen anyone here argue that JSON needs to be _the_ data format. It needs to be a _useful_ format for a wide range of applications, and it is that even if it's hard-coded to be limited to 31-bit integer ranges. In my implementations i have had to be very aware of system-level precision limits, but i simply document them, add build options to use, e.g. 64-bit integers if available, and leave it at that. Those details fall comfortably into the normal range of "implementation defined" details, IMO, and do _not_ (IMO) fall into JSON's realm of authority (JSON just needs to tell me the BNF for reading a number, though one could argue that the BNF should/does also imply certain limits). It would be impossible to enforce that arbitrary implementations must support arbitrarily long numbers, just as it would be silly to arbitrarily limit JSON to, say, 20-bit precision. Using your case of 0 vs 0.0. The vast, vast majority of JSON consumers are JavaScript, and JS doesn't differentiate between doubles and integers, so 0 is, in effect equivalent to 0.0. In fact, there are few real-world applications using JSON where the two are _not_ equivalent (barring scientific, high-precision, math-centric apps, of course, and those should probably be looking for a different format which guarantees them their desired ranges/limits). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --047d7b41bb0e441f2e04e1252cde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 10, 2013 at 1:44 AM, Peter F. Patel-Schneider = <pfpschneider@gmail.com> wrote:
That's a very= unhappy situation. =A0 My interest in JSON is to consume data in JSON docu= ments (mostly to use as input into representation systems that also use the= W3C semantic web languages RDF and OWL). If JSON is ambiguous (e.g., as to= whether 0.0 and 0 encode/stand for/represent the same thing) then JSON isn= 't very suitable for transmitting data, at least for me.

While i think we will all agree that, at a= technically pedantic level, you're absolutely right, JSON has been in = heavy use for about 10(?) years now with _relatively_ few instances of this= causing a problem. Implementors tend to use whatever default limits the pl= atform provides (e.g. 32-bit on 32-bit platforms and 64 on 64-bit, and 6-di= git precision in doubles seems to be conventional in C libraries). People u= sing high-precision/very large/very small numbers are certainly aware of th= e limitations/portability problems, and will (possibly after falling on the= ir face with JSON) pick a different format. That's all fine and good - = i haven't seen anyone here argue that JSON needs to be _the_ data forma= t. It needs to be a _useful_ format for a wide range of applications, and i= t is that even if it's hard-coded to be limited to 31-bit integer range= s. In my implementations i have had to be very aware of system-level precis= ion limits, but i simply document them, add build options to use, e.g. 64-b= it integers if available, and leave it at that. Those details fall comforta= bly into the normal range of "implementation defined" details, IM= O, and do _not_ (IMO) fall into JSON's realm of authority (JSON just ne= eds to tell me the BNF for reading a number, though one could argue that th= e BNF should/does also imply certain limits). It would be impossible to enf= orce that arbitrary implementations must support arbitrarily long numbers, = just as it would be silly to arbitrarily limit JSON to, say, 20-bit precisi= on.

Using your case of 0 vs 0.0. The vast, vast majority of= JSON consumers are JavaScript, and JS doesn't differentiate between do= ubles and integers, so 0 is, in effect equivalent to 0.0. In fact, there ar= e few real-world applications using JSON where the two are _not_ equivalent= (barring scientific, high-precision, math-centric apps, of course, and tho= se should probably be looking for a different format which guarantees them = their desired ranges/limits).


--
----- stephan beal
http://wande= ringhorse.net/home/stephan/
--047d7b41bb0e441f2e04e1252cde-- From pfpschneider@gmail.com Wed Jul 10 03:07:08 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 3CE8321E8053 for ; Wed, 10 Jul 2013 03:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 tPk2hOKLRniq for ; Wed, 10 Jul 2013 03:07:07 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 28FC221E804E for ; Wed, 10 Jul 2013 03:07:07 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j6so9464740oag.29 for ; Wed, 10 Jul 2013 03:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=faHDJ4j4IZKtN44nrAIEc71k0Zhe/zJ1v6gd+QvAZXk=; b=aSibNmXzvO+4tUbjzTj8CHrsVqgud5ioaYM5oMjJZCXA4AmLxzKwATNxdJJnhRldzV 5hqh3ry9b8mdnVguDHPfFOKb3HV4b1g3ATAvW7TiR7aDnakZ3kWkRrwbrX/euw300JUW 0KHB//JsVKN+CpWnB+R3Ibf0J+YhzZODvtXvdXNkNvNNCEcTFVYVzC34vHf6vDRuSHRL wIm0vsfYlARIftqcFsbL7LAfv7Z6MOFd6Ay0GoHjgGaAOINIcFICQjz/VofoY1sx6F05 boeA9DnoSypIhzM199ZqeU5PHsG+Wr0p7ZDVqOuCxh0vg6FjaQ5SF+HI5ykpCxkkClTE GlcA== X-Received: by 10.182.165.232 with SMTP id zb8mr27387591obb.101.1373450826657; Wed, 10 Jul 2013 03:07:06 -0700 (PDT) Received: from [192.168.1.101] (out-on-181.wireless.telus.com. [207.219.69.181]) by mx.google.com with ESMTPSA id tv3sm42922340obb.8.2013.07.10.03.07.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 03:07:06 -0700 (PDT) Message-ID: <51DD3248.3020008@gmail.com> Date: Wed, 10 Jul 2013 03:07:04 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephan Beal References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> <51DCA042.4000303@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 10:07:08 -0000 On 07/10/2013 02:47 AM, Stephan Beal wrote: > On Wed, Jul 10, 2013 at 1:44 AM, Peter F. Patel-Schneider > > wrote: > > That's a very unhappy situation. My interest in JSON is to consume > data in JSON documents (mostly to use as input into representation > systems that also use the W3C semantic web languages RDF and OWL). If > JSON is ambiguous (e.g., as to whether 0.0 and 0 encode/stand > for/represent the same thing) then JSON isn't very suitable for > transmitting data, at least for me. > > > While i think we will all agree that, at a technically pedantic level, > you're absolutely right, JSON has been in heavy use for about 10(?) years > now with _relatively_ few instances of this causing a problem. Relatively is one of these weasel words that we all use. I certainly agree that JSON is useful for transmitting certain kinds of data. However, the working group mailing archives contain evidence that there are indeed significant problems when using JSON to portably interchange data, particularly binary data. > Implementors tend to use whatever default limits the platform provides (e.g. > 32-bit on 32-bit platforms and 64 on 64-bit, and 6-digit precision in > doubles seems to be conventional in C libraries). > People using high-precision/very large/very small numbers are certainly > aware of the limitations/portability problems, and will (possibly after > falling on their face with JSON) pick a different format. Are they really aware of all the potential problems? And just what counts as high-precision/very large/very small? Does 0. belong to any of these categories? > That's all fine and good - i haven't seen anyone here argue that JSON needs > to be _the_ data format. It needs to be a _useful_ format for a wide range > of applications, and it is that even if it's hard-coded to be limited to > 31-bit integer ranges. In my implementations i have had to be very aware of > system-level precision limits, but i simply document them, add build options > to use, e.g. 64-bit integers if available, and leave it at that. Those > details fall comfortably into the normal range of "implementation defined" > details, IMO, and do _not_ (IMO) fall into JSON's realm of authority (JSON > just needs to tell me the BNF for reading a number, though one could argue > that the BNF should/does also imply certain limits). It would be impossible > to enforce that arbitrary implementations must support arbitrarily long > numbers, just as it would be silly to arbitrarily limit JSON to, say, 20-bit > precision. > > Using your case of 0 vs 0.0. The vast, vast majority of JSON consumers are > JavaScript, and JS doesn't differentiate between doubles and integers, so 0 > is, in effect equivalent to 0.0. In fact, there are few real-world > applications using JSON where the two are _not_ equivalent (barring > scientific, high-precision, math-centric apps, of course, and those should > probably be looking for a different format which guarantees them their > desired ranges/limits). I would appreciate some evidence to back up the claim that the vast, vast majority of JSON is handled in an environment where the JSON numbers 0 and 0.0 do indeed represent the same thing. The RDF W3C workiing group is in the last stages of putting its stamp of approval on JSON-LD, which presents the JSON numbers 0 and 0.0 to RDF as being different. > > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > > > ___________________ Peter F. Patel-Schneider From sgbeal@googlemail.com Wed Jul 10 03:15: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 1129121F894E for ; Wed, 10 Jul 2013 03:15:24 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 vCydc2qWVvzB for ; Wed, 10 Jul 2013 03:15:23 -0700 (PDT) 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 2926F21F8526 for ; Wed, 10 Jul 2013 03:15:23 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj3so6586723pad.0 for ; Wed, 10 Jul 2013 03:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Kckh47A68Bzi1fglGnM731/kv/Jonu/VeqQau8zUayE=; b=r7pqXUA6bqRQ2T+nPwv7830wUTT6K+CZBUb6vld2mTprxAuuQVHaLtSS48f3NT2qTS DZLIx1Oh0BJaKhsjysFk2inJ3c34YFbTYWRbZJPotVg4Ej5xlNkJrpQI4GyXCaSGj0mX ojoe+e/fLTi7OQ/lVhg3OsAvUy2HWXyrRwa3aaWZb5+xLhiZJNoaXhdpnBE3oLKsvZsB 4m2hclet4OQKwqAwZuHicOxqEUO0K0VdFRIoFEj64ucJHie2JuHu6hYigAzR+hfcduqv NAx1Lnf0wD9rorC7WlXOASLAicDPUhY4rWDiO7IXMt6sxHbNMLOVCnVY/Kol1dwnlHoD h4Cw== MIME-Version: 1.0 X-Received: by 10.68.36.230 with SMTP id t6mr31079855pbj.15.1373451322516; Wed, 10 Jul 2013 03:15:22 -0700 (PDT) Received: by 10.68.156.35 with HTTP; Wed, 10 Jul 2013 03:15:22 -0700 (PDT) In-Reply-To: <51DD3248.3020008@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> <51DCA042.4000303@gmail.com> <51DD3248.3020008@gmail.com> Date: Wed, 10 Jul 2013 12:15:22 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=bcaec520f2db31f6f504e1258e5b Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 10:15:24 -0000 --bcaec520f2db31f6f504e1258e5b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 10, 2013 at 12:07 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > Relatively is one of these weasel words that we all use. Agreed. > > However, the working group mailing archives contain evidence that there > are indeed significant problems when using JSON to portably interchange > data, particularly binary data. Such cases are their own fault: JSON never, every claimed to be able to support binary data. Wrong tool for the job, period. > Implementors tend to use whatever default limits the platform provides > (e.g. 32-bit on 32-bit platforms and 64 on 64-bit, and 6-digit precision in > doubles seems to be conventional in C libraries). > >> People using high-precision/very large/very small numbers are certainly >> aware of the limitations/portability problems, and will (possibly after >> falling on their face with JSON) pick a different format. >> > > Are they really aware of all the potential problems? And just what > counts as high-precision/very large/very small? Does 0. belong to any of > these categories? Excellent point - no, they are most certainly not aware of all potential problems, and that's why they rely on the system-level defaults - because they know that very smart people have spent time implementing them and making sure they are reasonable for a wide variety of use cases. Least common denominator. It would be impossible to expect every JSON parser implementor to understand the intricacies of binary encodings of floating point values. (i've implement 3 or 4 JSON parsers in C and C++ and have never read any of the relevant IEEE docs - i rely on the system to define my legal ranges). >> Using your case of 0 vs 0.0. The vast, vast majority of JSON consumers >> are JavaScript, and JS doesn't differentiate between doubles and integers, >> so 0 is, in effect equivalent to 0.0. In fact, there are few real-world >> applications using JSON where the two are _not_ equivalent (barring >> scientific, high-precision, math-centric apps, of course, and those should >> probably be looking for a different format which guarantees them their >> desired ranges/limits). >> > > I would appreciate some evidence to back up the claim that the vast, vast > majority of JSON is handled in an environment where the JSON numbers 0 and > 0.0 do indeed represent the same thing. You're right, and i'll see if i can find some properly collected statistics. My "evidence" is purely anecdotal - 90+% of the applications i work with which use JSON are www-based or www-bound. The RDF W3C workiing group is in the last stages of putting its stamp of > approval on JSON-LD, which presents the JSON numbers 0 and 0.0 to RDF as > being different. > Different standard - doesn't interest me ;). i don't have a single application where the difference between 0 and 0.0 is relevant to the outcome of a calculation (with the minor exception of maybe output formatting). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --bcaec520f2db31f6f504e1258e5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 10, 2013 at 12:= 07 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
Relatively is one= of these weasel words that we all use.

Agr= eed.=A0

=A0

However, the working group mailing archives contain evidence that there are= indeed significant problems when using JSON to portably interchange data, = particularly =A0binary data.

Such cases are= their own fault: JSON never, every claimed to be able to support binary da= ta. Wrong tool for the job, period.
=A0
Implementors= tend to use whatever default limits the platform provides (e.g. 32-bit on = 32-bit platforms and 64 on 64-bit, and 6-digit precision in doubles seems t= o be conventional in C libraries).
People using high-precision/very large/very small numbers are certainly awa= re of the limitations/portability problems, and will (possibly after fallin= g on their face with JSON) pick a different format.

Are they really aware of all the potential problems? =A0 And just what coun= ts as high-precision/very large/very small? =A0Does 0. belong to any of the= se categories?

Excellent point - no, they a= re most certainly not aware of all potential problems, and that's why t= hey rely on the system-level defaults - because they know that very smart p= eople have spent time implementing them and making sure they are reasonable= for a wide variety of use cases. Least common denominator. It would be imp= ossible to expect every JSON parser implementor to understand the intricaci= es of binary encodings of floating point values. (i've implement 3 or 4= JSON parsers in C and C++ and have never read any of the relevant IEEE doc= s - i rely on the system to define my legal ranges).


Using your case of 0 vs 0.0. The vast, vast majority of JSON consumers are = JavaScript, and JS doesn't differentiate between doubles and integers, = so 0 is, in effect equivalent to 0.0. In fact, there are few real-world app= lications using JSON where the two are _not_ equivalent (barring scientific= , high-precision, math-centric apps, of course, and those should probably b= e looking for a different format which guarantees them their desired ranges= /limits).

I would appreciate some evidence to back up the claim that the vast, vast m= ajority of JSON is handled in an environment where the JSON numbers 0 and 0= .0 do indeed represent the same thing.

You're right, and i'll see if i can find some properly collected st= atistics. My "evidence" is purely anecdotal - 90+% of the applica= tions i work with which use JSON are www-based or www-bound.=A0

The RDF W3C workiing group is in = the last stages of putting its stamp of approval on JSON-LD, which presents= the JSON numbers 0 and 0.0 to RDF as being different.

Different standard - doesn't interest = me ;). i don't have a single application where the difference between 0= and 0.0 is relevant to the outcome of a calculation (with the minor except= ion of maybe output formatting).

--
----- stephan beal
http://wanderinghorse.net/home= /stephan/
--bcaec520f2db31f6f504e1258e5b-- From sgbeal@googlemail.com Wed Jul 10 03:24: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 01CF521F9F43 for ; Wed, 10 Jul 2013 03:24:41 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622, 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 hEmJmHMyz2v6 for ; Wed, 10 Jul 2013 03:24:41 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE7A21F9CF7 for ; Wed, 10 Jul 2013 03:24:41 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id ld11so6519822pab.36 for ; Wed, 10 Jul 2013 03:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dpryv9jYDYnsF7929OpM55ICssGiZRdCe3I/9EHDtOE=; b=Bt8MY67Wrl2oOKIy4SkJwEnXCT9uryhcMGJkJ9NgZ5K6Sln1wHRa59dGu56taSK7Cy n75sBhc7sG8n+VzDh5Afa9e1GBQqth4QG0p2/knkKo61UH87bF7lT5sFw57s/bvTOEQ4 ucNWpCy6TtI7GtnaQV58W7vbxIYWiE0UlxWbjmsblG7tqp2KIB6gcaxHYlhAmSv2eymO r8Ui1AA8zoQNlXg9DbquiGixzFf7pgUujmzcRwPZse8xBaRFemgGmBN0Z6UAtyNCwxYj ilPig34ahY98HO9u50E3tzVhH2IevULYhteUqEjsFVnVriG4mLM9VB0esTyw2eyUbr8t nkPQ== MIME-Version: 1.0 X-Received: by 10.68.219.130 with SMTP id po2mr30670529pbc.54.1373451871867; Wed, 10 Jul 2013 03:24:31 -0700 (PDT) Received: by 10.68.156.35 with HTTP; Wed, 10 Jul 2013 03:24:31 -0700 (PDT) In-Reply-To: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> <51DCA042.4000303@gmail.com> <51DD3248.3020008@gmail.com> Date: Wed, 10 Jul 2013 12:24:31 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ff24881f05d3304e125ae1c Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 10:24:42 -0000 --e89a8ff24881f05d3304e125ae1c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 10, 2013 at 12:15 PM, Stephan Beal wrote: > You're right, and i'll see if i can find some properly collected > statistics. My "evidence" is purely anecdotal - 90+% of the applications i > work with which use JSON are www-based or www-bound. > While this doesn't count as evidence, it might help support the anecdote: http://en.wikipedia.org/wiki/JSON "It [JSON] is used primarily to transmit data between a server and web application, serving as an alternative to XML." -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --e89a8ff24881f05d3304e125ae1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 10, 2013 at 12:15 PM, Stephan Beal <sgb= eal@googlemail.com> wrote:
You're right, and i'll see if i c= an find some properly collected statistics. My "evidence" is pure= ly anecdotal - 90+% of the applications i work with which use JSON are www-= based or www-bound.=A0

While this doesn't count as evid= ence, it might help support the anecdote:



----- stephan beal
http:= //wanderinghorse.net/home/stephan/
--e89a8ff24881f05d3304e125ae1c-- From pfpschneider@gmail.com Wed Jul 10 04:26:25 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 9F39321F9FF7 for ; Wed, 10 Jul 2013 04:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 Fl-tif-oMdhl for ; Wed, 10 Jul 2013 04:26:24 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 699A821F9FF2 for ; Wed, 10 Jul 2013 04:26:24 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so9460871oag.32 for ; Wed, 10 Jul 2013 04:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MGGcj60VHUbNNpaOHc+ukf+Eefi2rR+JW4zfjyR3BvM=; b=CeXIw2k95bVrOoHIEtiGgSghoiuElNLgkHQSehOR5o9PQRgIveCDr6eyCem3rPz6yN 9KmXQBQwKo16wLZUBkYdEQA/0RTwgCCRlYCasz6B5ge+kukL5bdNUPMe82u5h2z/9VuG fIcXsA3SOMbCCY4Blsh01867zJgfyhnSti2lFqq29LrUxobgMwxJ8QQnVu2XwpHIdHbf Jt0W2LURuNpw4/2JZWK/6G2SmPdAOxMx0MrTLxSG05zjknol54JCHSbyH8gSzYQZMrhB NV25mATgC2nMZ0OnZIKaqNbF5goVrrBgX/FzfBZ2sgzxZ4tNE6v81UgvWWVYHJjQ/p6w WeFQ== X-Received: by 10.60.140.168 with SMTP id rh8mr27545982oeb.17.1373455583606; Wed, 10 Jul 2013 04:26:23 -0700 (PDT) Received: from [192.168.1.101] (out-on-181.wireless.telus.com. [207.219.69.181]) by mx.google.com with ESMTPSA id q4sm43233121obl.1.2013.07.10.04.26.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 04:26:22 -0700 (PDT) Message-ID: <51DD44DC.1080300@gmail.com> Date: Wed, 10 Jul 2013 04:26:20 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephan Beal References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> <51DCA042.4000303@gmail.com> <51DD3248.3020008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 11:26:25 -0000 On 07/10/2013 03:24 AM, Stephan Beal wrote: > On Wed, Jul 10, 2013 at 12:15 PM, Stephan Beal > wrote: > > You're right, and i'll see if i can find some properly collected > statistics. My "evidence" is purely anecdotal - 90+% of the applications > i work with which use JSON are www-based or www-bound. > > > While this doesn't count as evidence, it might help support the anecdote: > > http://en.wikipedia.org/wiki/JSON > > "It [JSON] is used primarily to transmit data between a server and web > application, serving as an alternative to XML." > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > > If it is in Wikipedia, it must be true. :-) So that means that I can also count on the infobox information that JSON is "Extended from JavaScript", right? peter From markus.lanthaler@gmx.net Wed Jul 10 05: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 E9F3921F9E85 for ; Wed, 10 Jul 2013 05:18:56 -0700 (PDT) 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 HIaukRz4ZAt1 for ; Wed, 10 Jul 2013 05:18:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id D74AA21F9F7C for ; Wed, 10 Jul 2013 05:18:50 -0700 (PDT) Received: from Vostro3500 ([77.117.247.54]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MU0pN-1UnmYF0MXB-00Qjam for ; Wed, 10 Jul 2013 14:18:42 +0200 From: "Markus Lanthaler" To: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> <51DCA042.4000303@gmail.com> <51DD3248.3020008@gmail.com> In-Reply-To: <51DD3248.3020008@gmail.com> Date: Wed, 10 Jul 2013 14:18:37 +0200 Message-ID: <003c01ce7d67$9bf0b4f0$d3d21ed0$@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: Ac59VT7SKn3YFxBCRaGsyhUsqAYupAAEgHKA Content-Language: de X-Provags-ID: V03:K0:2z9NqAMIoUYo97uA6dkasPnwnAQQ00qydZDnxD0MA0H/Dtg19W+ O2Tf8Xb4fplXdIzXcur93bCWXvJCUhcF36GQnrVsvG2rdcach2LBJZKZqu8kgy+MDV9wMJ2 PhUOK95ept1MSC7iJh/7GjXXfdNwPkccm/qOOphKwfVhVPiegwfRnwgw0sIYndMfrVB/Ey4 RmBa2uxI0CMbm7ofG1ENw== Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 12:18:57 -0000 On Wednesday, July 10, 2013 12:07 PM, Peter F. Patel-Schneider wrote: > I would appreciate some evidence to back up the claim that the vast, vast > majority of JSON is handled in an environment where the JSON numbers 0 and 0.0 > do indeed represent the same thing. The RDF W3C workiing group is in the last > stages of putting its stamp of approval on JSON-LD, which presents the JSON > numbers 0 and 0.0 to RDF as being different. That's just wrong. When converting JSON-LD to RDF both 0 and 0.0 will result in a "0"^^xsd:integer. -- Markus Lanthaler @markuslanthaler From pfpschneider@gmail.com Wed Jul 10 05:29: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 0BBC411E8155 for ; Wed, 10 Jul 2013 05:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 vRWNppKa-1EZ for ; Wed, 10 Jul 2013 05:29:44 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8ED11E814D for ; Wed, 10 Jul 2013 05:29:44 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id fb19so8464378obc.9 for ; Wed, 10 Jul 2013 05:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bwpzFccziqHCKEDlt3cvLGbsvv2GwSTmZ8uuqxh4PBE=; b=eEQaMay78GWkuQ02SZydqpQl/gSxk7OEt2rwILwzgrBHsFDNYiiQCtm722RpEOT7K+ 2j7JVwijrC4tnNAnUZ6h98ihNeskMMs315ViGXhdREARtCHgiIlrnVpZE8mNpvas7Z2n A40934JHn72lNCWt/cnV00vxx2KTNTqyOj7hEf6mqJ1eHzG7qk3RGHHqyUOwyiiydgLA 1fVuzF+iqq73zjsDhoEcGZfscAiT1HYFJNFRvziEO0kn1Twr7/GovWCA22B8MWFuQCjU FPWJ2TlwNgO8JtEkL9aVc1mV79lgtsw0SaaNo0aO8zFKbGp/PCBlxsfa/qBWX/r4RmgM I6pg== X-Received: by 10.182.130.228 with SMTP id oh4mr27997816obb.38.1373459384204; Wed, 10 Jul 2013 05:29:44 -0700 (PDT) Received: from [192.168.1.101] (out-on-181.wireless.telus.com. [207.219.69.181]) by mx.google.com with ESMTPSA id fk3sm43417986obb.2.2013.07.10.05.29.42 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 05:29:43 -0700 (PDT) Message-ID: <51DD53B4.6030207@gmail.com> Date: Wed, 10 Jul 2013 05:29:40 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephan Beal References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> <51DCA042.4000303@gmail.com> <51DD3248.3020008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 12:29:47 -0000 On 07/10/2013 03:15 AM, Stephan Beal wrote: > > On Wed, Jul 10, 2013 at 12:07 PM, Peter F. Patel-Schneider > > wrote: [...] > > > However, the working group mailing archives contain evidence that there > are indeed significant problems when using JSON to portably interchange > data, particularly binary data. > > > Such cases are their own fault: JSON never, every claimed to be able to > support binary data. Wrong tool for the job, period. That's one opinion (which I agree with, by the way), but there appears to be significant support for a different opinion. [...] > Excellent point - no, they [users] are most certainly not aware of all > potential problems, and that's why they rely on the system-level defaults - > because they know that very smart people [the IETF JSON working group?] have > spent time implementing them and making sure they are reasonable for a wide > variety of use cases. Least common denominator. But what is this least common denominator? There was a (probably not serious) post that suggested that 5-bit JSON numbers would be viable. There were serious posts suggesting that one should not count on anything more than 32-bit (signed) integers, i.e., that 0.1 or even 0.0 might be rejected by some JSON implementations. [...] > > The RDF W3C workiing group is in the last stages of putting its stamp of > approval on JSON-LD, which presents the JSON numbers 0 and 0.0 to RDF as > being different. > > > Different standard - doesn't interest me ;). i don't have a single > application where the difference between 0 and 0.0 is relevant to the > outcome of a calculation (with the minor exception of maybe output formatting). I find this particular attitude very troubling, even spoken in jest. You may not care whether the JSON numbers 0 and 0.0 represent different things, but others do, and are about to push an answer into a W3C recommendation. In my opinion, it should be the goal of any standard (or quasi-standard) setting body to try to cover all the reasonable cases (without, of course, getting bogged down on things like how many Unicode surrogate characters can dance on the head of a JSON string). > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > > Peter F. Patel-Schneider From sgbeal@googlemail.com Wed Jul 10 05:49: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 37B1C11E8167 for ; Wed, 10 Jul 2013 05:49:27 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 vqW-0vMq-umW for ; Wed, 10 Jul 2013 05:49:26 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 40D8311E8121 for ; Wed, 10 Jul 2013 05:49:25 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rl6so6698317pac.15 for ; Wed, 10 Jul 2013 05:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nXXXkCHKYUewbT8TLHxa8Hj9Q9fzUScoFdIWABKuJcs=; b=xSZ6dsfunCC7bTE1EraeWhzAH7UXEPBUFlspJP68niJANK/y/dx/uXZy7+svexG1jv tVYgalti88rCj7GoZLzFmZgBsHwUcz3xyPokAqb2fv60Kq5RfEpvfJBupxrxmvk3ifxu YfUDVB4d+VSlDAyoVYJfyAJcpycXPHwtmW88X6cd8RWcwoorMUNZdVO9/q5yWdt26LVf floNxcg3aAB1TyHSnck16TBDwtXNTVAUkKFmp4IWG9c0uNZCf8tM/vJWlVrQRRp9/85W svgbYh0Suhp+Euxvc/DXESFIi+wzPblMOEDB3cMt7PLpTvxFQN9GM3Vv80OYIGPpf8rp AEvw== MIME-Version: 1.0 X-Received: by 10.68.52.10 with SMTP id p10mr31685370pbo.92.1373460565667; Wed, 10 Jul 2013 05:49:25 -0700 (PDT) Received: by 10.68.156.35 with HTTP; Wed, 10 Jul 2013 05:49:25 -0700 (PDT) In-Reply-To: <51DD53B4.6030207@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> <51DCA042.4000303@gmail.com> <51DD3248.3020008@gmail.com> <51DD53B4.6030207@gmail.com> Date: Wed, 10 Jul 2013 14:49:25 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=bcaec54307a02139c404e127b566 Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 12:49:27 -0000 --bcaec54307a02139c404e127b566 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 10, 2013 at 2:29 PM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > > On 07/10/2013 03:15 AM, Stephan Beal wrote: > >> Such cases are their own fault: JSON never, every claimed to be able to >> support binary data. Wrong tool for the job, period. >> > > That's one opinion (which I agree with, by the way), but there appears to > be significant support for a different opinion. > That's the beauty of it - in the context of the JSON RFC it's not an opinion - it's a technical fact. Unless the WG wants to extend JSON in incompatible ways (which they are prohibited from doing, from what i understand) there is zero chance of this revision of it supporting JSON. > > [...] > >> Excellent point - no, they [users] are most certainly not aware of all >> potential problems, and that's why they rely on the system-level defaults - >> because they know that very smart people [the IETF JSON working group?] >> have spent time implementing them and making sure they are reasonable for a >> wide variety of use cases. Least common denominator. >> > > But what is this least common denominator? There was a (probably not > serious) post that suggested that 5-bit JSON numbers would be viable. > There were serious posts suggesting that one should not count on anything > more than 32-bit (signed) integers, i.e., that 0.1 or even 0.0 might be > rejected by some JSON implementations. > As long as JSON does not specify a numeric precision (and IMO it "MUST NOT" ;) then any precision which can be represented per the grammar is legal. i.e. any precision for which we can represent digits 0 to 9 (which rules out the 0-bit precision someone suggested ;). > Different standard - doesn't interest me ;). i don't have a single >> application where the difference between 0 and 0.0 is relevant to the >> outcome of a calculation (with the minor exception of maybe output >> formatting). >> > > I find this particular attitude very troubling, even spoken in jest. It was not intended as a jest. The ONLY JSON documents which interest me are the original RFC and the one being drafted now. i have ZERO applications for which there is a semantic difference between 0 and 0.0, -0, +0, and all the other zeroes. They are the proverbial "noisy minority," for which much of the fuss has been raised regarding numbers, but which have zero impact on "the majority" of applications (==none i've ever worked on in nearly 30 years of programming). > You may not care whether the JSON numbers 0 and 0.0 represent different > things, but others do, and are about to push an answer into a W3C > recommendation. And the current RFC does not distinguish, so what's the problem if it continues not to? JSON, as it is now, is NOT a format for high-precision numerics because the RFC _clearly_ and _unambiguously_ does _not_ cover the details important to such cases (e.g. 0!==0.0 and a myriad of others which have been mentioned in recent weeks). If JSON had been designed for that then i'm quite certain that Doug would have covered those topics. In my opinion, it should be the goal of any standard (or quasi-standard) > setting body to try to cover all the reasonable cases (without, of course, > getting bogged down on things like how many Unicode surrogate characters > can dance on the head of a JSON string) One of the charters of the WG is to NOT break JSON compatibility, so their hands are tied in this regard. They only way to introduce that level of detail is if one "breaks" JSON vis-a-vis many of the existing implementations, or otherwise breaks them in the sense of, "they worked yesterday but are no longer compliant under the new definition" (kinda like what happened to poor old Pluto - it's big enough to have more moons than Earth but is no longer considered a planet). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --bcaec54307a02139c404e127b566 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 10, 2013 at 2:29 PM, Peter F. Patel-Schneider = <pfpschneider@gmail.com> wrote:

On 07/10/2013 03:15 AM, Stephan Beal wrote:
Such cases are their own fault: JSON never, every claimed to be able to sup= port binary data. Wrong tool for the job, period.

That's one opinion (which I agree with, by the way), but there appears = to be significant support for a different opinion.
That's the beauty of it - in the context of the JSON RFC it= 's not an opinion - it's a technical fact. Unless the WG wants to e= xtend JSON in incompatible ways (which they are prohibited from doing, from= what i understand) there is zero chance of this revision of it supporting = JSON.
=A0

[...]
Excellent point - no, they [users] are most certainly not aware of all pote= ntial problems, and that's why they rely on the system-level defaults -= because they know that very smart people [the IETF JSON working group?] ha= ve spent time implementing them and making sure they are reasonable for a w= ide variety of use cases. Least common denominator.

But what is this least common denominator? =A0There was a (probably not ser= ious) post that suggested that 5-bit JSON numbers would be viable. =A0There= were serious posts suggesting that one should not count on anything more t= han 32-bit (signed) integers, i.e., that 0.1 or even 0.0 might be rejected = by some JSON implementations.

As long as JSON does not specify a numeric= precision (and IMO it "MUST NOT" ;) then any precision which can= be represented per the grammar is legal. i.e. any precision for which we c= an represent digits 0 to 9 (which rules out the 0-bit precision someone sug= gested ;).

=A0
Different standard - doesn't interest me ;). i don't have a single = application where the difference between 0 and 0.0 is relevant to the outco= me of a calculation (with the minor exception of maybe output formatting).<= br>

I find this particular attitude very troubling, even spoken in jest.

It was not intended as a jest. The ONLY JSON docu= ments which interest me are the original RFC and the one being drafted now.= i have ZERO applications for which there is a semantic difference between = 0 and 0.0, -0, +0, and all the other zeroes. They are the proverbial "= noisy minority," for which much of the fuss has been raised regarding = numbers, but which have zero impact on "the majority" of applicat= ions (=3D=3Dnone i've ever worked on in nearly 30 years of programming)= .

=A0
=A0You may not= care whether the JSON numbers 0 and 0.0 represent different things, but ot= hers do, and are about to push an answer into a W3C recommendation.

And the current RFC does not distinguish, so =A0what= 9;s the problem if it continues not to? JSON, as it is now, is NOT a format= for high-precision numerics because the RFC _clearly_ and _unambiguously_ = does _not_ cover the details important to such cases (e.g. 0!=3D=3D0.0 and = a myriad of others which have been mentioned in recent weeks). If JSON had = been designed for that then i'm quite certain that Doug would have cove= red those topics.

In my opinion, it should be t= he goal of any standard (or quasi-standard) setting body to try to cover al= l the reasonable cases (without, of course, getting bogged down on things l= ike how many Unicode surrogate characters can dance on the head of a JSON s= tring)

One of the charters of the WG is to NOT break JSON comp= atibility, so their hands are tied in this regard. They only way to introdu= ce that level of detail is if one "breaks" JSON vis-a-vis many of= the existing implementations, or otherwise breaks them in the sense of, &q= uot;they worked yesterday but are no longer compliant under the new definit= ion" (kinda like what happened to poor old Pluto - it's big enough= to have more moons than Earth but is no longer considered a planet).


--
----- stephan beal
http://wanderin= ghorse.net/home/stephan/
--bcaec54307a02139c404e127b566-- From pfpschneider@gmail.com Wed Jul 10 05:59: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 0C97E11E8180 for ; Wed, 10 Jul 2013 05:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 U6wkApjMMJtV for ; Wed, 10 Jul 2013 05:59:56 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 86F8711E8170 for ; Wed, 10 Jul 2013 05:59:56 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so8270790obc.41 for ; Wed, 10 Jul 2013 05:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LSGQa6dvriHD1EHXzNo074fsorfc+mn2VTYao5cYWjg=; b=TF0DoIEjw06miFkiknZeNvmKQMUXKNBEOiNn80yFMvNu4wO9bk7gCHlLj1B0PepxX2 Jd5bS+tndopH2qO4NIa/CLuaDr2HvnF+VE2+Rt/vg/1w78cgi/7n9Cyacdg5BYUfrMy3 MjqTrIQYlZCsYonaGbR961FvFEAAwRKjX1rvGZwc8qJqXKM2qjOev2htcAawo/qEfRuD zN4MbrXQpr40sQc12fEbuggmLIMZ/YjurVAsEXlKD7vGLP5bRD3J5Qe1DgOIIPRkHGDT kYVtlUdy0Mntyo+hEsVoU5t8NXsEiTOWI3BmB8iYirJ62U/iw1bn78XW9gilP75srhJ/ A3fA== X-Received: by 10.182.119.229 with SMTP id kx5mr27767030obb.23.1373461194239; Wed, 10 Jul 2013 05:59:54 -0700 (PDT) Received: from [192.168.1.101] (out-on-181.wireless.telus.com. [207.219.69.181]) by mx.google.com with ESMTPSA id rs1sm43395167obb.12.2013.07.10.05.59.52 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 05:59:53 -0700 (PDT) Message-ID: <51DD5AC7.5010403@gmail.com> Date: Wed, 10 Jul 2013 05:59:51 -0700 From: "Peter F. Patel-Schneider" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus Lanthaler References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> <51DCA042.4000303@gmail.com> <51DD3248.3020008@gmail.com> <51dd5132.e686440a.1389.03a1SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: <51dd5132.e686440a.1389.03a1SMTPIN_ADDED_BROKEN@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 12:59:57 -0000 Oops, right you are, the spec says that non-zero fractional parts are float, and 0.0 appears to have a zero fractional part. My fault for not reading enough, particularly now that the situation is spelled out in a part of the document that I have been complaining about. So now we have things the other way around - 0 and 0.0 represent the same thing namely the integer 0 in JSON-LD. This is certainly a decision, and a decision, I think, somewhat different from the one taken by ECMAScript-based implementations of JSON (although it does share with them the situation that 0 and 0.0 represent the same thing. My apologies for misstating the situation, peter On 07/10/2013 05:18 AM, Markus Lanthaler wrote: > On Wednesday, July 10, 2013 12:07 PM, Peter F. Patel-Schneider wrote: >> I would appreciate some evidence to back up the claim that the vast, vast >> majority of JSON is handled in an environment where the JSON numbers 0 and > 0.0 >> do indeed represent the same thing. The RDF W3C workiing group is in the > last >> stages of putting its stamp of approval on JSON-LD, which presents the > JSON >> numbers 0 and 0.0 to RDF as being different. > That's just wrong. When converting JSON-LD to RDF both 0 and 0.0 will result > in a "0"^^xsd:integer. > > > -- > Markus Lanthaler > @markuslanthaler > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From cowan@ccil.org Wed Jul 10 07:20: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 8D5D721E808A for ; Wed, 10 Jul 2013 07:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 rzMe+xWF1f0j for ; Wed, 10 Jul 2013 07:20:05 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2F38721E8064 for ; Wed, 10 Jul 2013 07:20:02 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UwuzC-0007En-BW; Wed, 10 Jul 2013 10:03:14 -0400 Date: Wed, 10 Jul 2013 10:03:14 -0400 From: John Cowan To: Stephan Beal Message-ID: <20130710140314.GB16218@mercury.ccil.org> References: <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> <51DCA042.4000303@gmail.com> <51DD3248.3020008@gmail.com> <51DD53B4.6030207@gmail.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: "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 14:20:09 -0000 Stephan Beal scripsit: > That's the beauty of it - in the context of the JSON RFC it's not an > opinion - it's a technical fact. Unless the WG wants to extend JSON in > incompatible ways (which they are prohibited from doing, from what i > understand) there is zero chance of this revision of it supporting JSON. JSON cannot support binary data *as a distinct type*. It can of course support binary data in a variety of other ways by convention: as an array of 0s and 1s or non-negative numbers < 256 or < 65536, or as an array containing a string whose 16-bit whatever-they-ares represent the binary object 16 bits at a time. > As long as JSON does not specify a numeric precision (and IMO it "MUST NOT" > ;) then any precision which can be represented per the grammar is legal. > i.e. any precision for which we can represent digits 0 to 9 (which rules > out the 0-bit precision someone suggested ;). It doesn't, actually. A JSON implementation can set any numerical limits it likes, from 2^53 to 2^-53, or from 0 to 0 (exclusive). -- My confusion is rapidly waxing John Cowan For XML Schema's too taxing: cowan@ccil.org I'd use DTDs http://www.ccil.org/~cowan If they had local trees -- I think I best switch to RELAX NG. From presnick@qti.qualcomm.com Wed Jul 10 08:25:28 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 E026121F9E88 for ; Wed, 10 Jul 2013 08:25:27 -0700 (PDT) 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 oldnu-h21YTB for ; Wed, 10 Jul 2013 08:25:08 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 76F3721F9E67 for ; Wed, 10 Jul 2013 08:24:59 -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=1373469899; x=1405005899; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=Jb6vQdAP8Q3aabxDor8NgjY7leSdo8NyKUfw0LgFY3Y=; b=D5dDFOBSy2W2COqVZsdTknDEOpKSEQvfI3lXFkYNpVvZ+v5jsLMXhL8t Esy741XRp261/dYDVM0cHyKpX51+5ol87onn/sztX3gZH6wsyH22oFLi4 c8Z6MpJRClJxtH05aQVsRISJ34qLUM4jbKZy4bXiZljbGbRbSMQtsrvF0 I=; X-IronPort-AV: E=Sophos;i="4.87,1036,1363158000"; d="scan'208";a="47131667" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 10 Jul 2013 08:24:54 -0700 Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Jul 2013 08:24:54 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 10 Jul 2013 08:24:54 -0700 Message-ID: <51DD7CC4.4020106@qti.qualcomm.com> Date: Wed, 10 Jul 2013 10:24:52 -0500 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: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [Json] Observations that might help the discussion 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, 10 Jul 2013 15:25:28 -0000 I've been trying to get this note together for a few days now and keep getting interrupted. Hopefully this is useful to move some of the discussion along. I will be posting some specific questions about open issues as well, but I thought these observations might be helpful. This note expresses my personal views. There may be some things in here that WG members disagree with, or that the chairs disagree with, or other IESG members disagree with. Don't take this as scripture. But I am an increasingly old-timer in this community, so I hope these comments are taken as such. Observation 1: We are chartered to "keep changes to a minimum", but we are also chartered to "correct significant errors and inconsistencies". Those two items do not seem in the least bit contradictory to me. If there is a significant error in the spec (and we all agree it is a significant error), then we need to do the minimum to correct the error. That doesn't necessarily mean that the change will be small; just the minimum we can do. Even if we have to write a long explanatory paragraph that describes what we all agree was intended, but has been implemented non-interoperably, I don't think we would have violated the charter. It's not the length of the change; it's whether it is changing the basic intention of the spec or not. Now, we might decide that a change to fix a particular error changes the spec so essentially that we'd no longer be fulfilling our mission of "essentially reclassifying in place" or it would have to be so extensive that it will cause other problems. But I haven't see anything to date that makes me worry about that. Yet. Observation 2: Folks seem to be getting hung up on "declaring older implementations/documents non-conformant". I have a hard time getting too worked up about this issue. IETF specs have traditionally *not* been about conformance; they are supposed to be about interoperability. In particular, if you read over RFC 2119, you'll notice that MUST doesn't mean (as it does in other standards) "You MUST do this to conform to the spec". MUST means "You MUST do this in order to interoperate with someone else." Similarly, SHOULD is not simply a strong suggestion or recommendation. SHOULD means "There might be legitimate reasons not to do this in special circumstances, but if you don't do it, you run the risk of not interoperating with other implementations, so you'd better know what you're doing. Otherwise, you MUST do it." So, if there are implementations out there that don't do X and are getting along just fine interoperating with everyone, then the spec can't legitimately say, "You MUST do X". Conversely, if there are implementations that don't do X and they crash, or screw up bunches of other implementations, or can't interoperate with bunches of implementations, then the spec really needs to say "You MUST do X". The spec isn't "making them non-conformant" (at least in any interesting way to me); the spec is simply being honest and saying that not doing X is demonstrably a bad idea. And if there are implementations that run in particular environments where doing X is really not necessary, but in general you'll be in trouble if you don't do X, then the spec should say, "You SHOULD do X". Finally, if the spec says, "You MUST do X" and an implementation doesn't, an interoperating implementation can't simply crash. You've got to program defensively. And if the spec says, "You SHOULD do X", that doesn't mean that any implementation is perfectly welcome to not do X; if you're not in a particular environment where not doing X is known to be OK, you're not doing the right thing. All in all, I don't think non-conformance is something we should get hung up about. Observation 3: The IETF is often lousy about separating content from encoding. (And we are not alone.) Content is made up of theoretical entities. Maybe it's "characters" or "numeric values" or other things like that. Encoding is how we represent things "on the wire". So if you take a look at the ABNF spec, you will see that the terminals are simply non-negative integers. In particular, they are not characters in the sense of an abstract unit of a written language. ABNF terminals could be code points, but only if you declare when you use them that you are mapping them to a particular coded character set. So we can develop a spec that deals in simply numeric values and separately say whether and how it maps those numeric values into characters. How we encode things into 8-bit (or 7-bit or 16-bit or 32-bit) units is independent of what we are encoding, and is another step on top of mapping. Like I said, I'll be posting some specific questions regarding how these observations apply to some of our current issues, but I wanted to get these out to see if it would center some thinking. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From tsaloranta@gmail.com Wed Jul 10 11: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 1327D21F9E6B for ; Wed, 10 Jul 2013 11:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 E9mjd-7vUpEw for ; Wed, 10 Jul 2013 11:47:52 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C5DD721F9CE6 for ; Wed, 10 Jul 2013 11:47:51 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so11757758wiw.11 for ; Wed, 10 Jul 2013 11:47:51 -0700 (PDT) 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=eFBRP3ZRuxbHD2YI6kgnOTSPEssJe+S+IxQTOj6qzzw=; b=PKKTrgJa/eRn6VO18XyKoeQw+KsXwNmEXnjZiZSWejBvf26lJnBfGew/X6E+RLsYkA 9PzTgjQUrBqAySRQ5tq7WebhWkLFAvdqgRuXEykC14+7oG43SkCz28hshk8cUPZFsKN1 +r3Y+g+rltcflgNkyaW3Mf51F8NPOf62SLcAVnqweYFE/umFQgOFv6d3WLfskc8O50P1 9z2yDMIZHAWVVUR3gEGz89Cjcz7NKK1BfsoyQyavK5A0RHpcYVhNXR84VAqdbqVHOrID 2fUlFP0HM6eTLWccaNVd7YzcZRlc16CRg4n+81j5Ww2CInlqXjOp/8zArAKlBvxZjQRV 7KoA== MIME-Version: 1.0 X-Received: by 10.194.90.244 with SMTP id bz20mr19450010wjb.69.1373482070930; Wed, 10 Jul 2013 11:47:50 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Wed, 10 Jul 2013 11:47:50 -0700 (PDT) In-Reply-To: <20130710024215.GO9153@mercury.ccil.org> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <20130710024215.GO9153@mercury.ccil.org> Date: Wed, 10 Jul 2013 11:47:50 -0700 Message-ID: From: Tatu Saloranta To: John Cowan Content-Type: multipart/alternative; boundary=047d7bfd090af17c2304e12cb6d2 Cc: Nico Williams , Bjoern Hoehrmann , "Peter F. Patel-Schneider" , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 18:47:56 -0000 --047d7bfd090af17c2304e12cb6d2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 7:42 PM, John Cowan wrote: > Tatu Saloranta scripsit: > > > This is not to say that the way JSON (under-)defines numbers is optimal; > > but at this point forcing castrated version of numbers -- which would > lead > > to practical problems like preventing use of 64-bit longs for timestamps > -- > > would be counter-productive and to me a non-starter. > > Apparently, there are already practical problems with interchanging > 64-bit longs: google for [json large numbers bugs] for lots of reports. > While there are apparently int32-only systems out there, it's clearly > understood that they are unusually restricted: such is not the case > for JavaScript-hosted implementations. I am not saying there can't be problems there (and I have gotten feature requests for optional processing limitations to conform to Javascript representation); but rather that these are also successfully and widely used. So it is fine to define or recommend safe(r) profiles that take commonly encountered limitations into account. But just to take care not to consider this strict limitation on all usage. -+ Tatu +- --047d7bfd090af17c2304e12cb6d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2013 at 7:42 PM, John Cowan <cowan@me= rcury.ccil.org> wrote:
Tatu Saloranta scripsit:

> This is not to say that the way JSON (under-)defines numbers is optima= l;
> but at this point forcing castrated version of numbers -- which would = lead
> to practical problems like preventing use of 64-bit longs for timestam= ps --
> would be counter-productive and to me a non-starter.

Apparently, there are already practical problems with interchanging 64-bit longs: google for [json large numbers bugs] for lots of reports.
While there are apparently int32-only systems out there, it's clearly understood that they are unusually restricted: such is not the case
for JavaScript-hosted implementations.

I am= not saying there can't be problems there (and I have gotten feature re= quests for optional processing limitations to conform to Javascript represe= ntation); but rather that these are also successfully and widely used. So i= t is fine to define or recommend safe(r) profiles that take commonly encoun= tered limitations into account.
But just to take care not to consider this strict limitation on = all usage.

-+ Tatu +-


= =A0
--047d7bfd090af17c2304e12cb6d2-- From tsaloranta@gmail.com Wed Jul 10 11:55: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 5512921F8411 for ; Wed, 10 Jul 2013 11:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 7yyUpTZP1885 for ; Wed, 10 Jul 2013 11:55:56 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id E880421F853A for ; Wed, 10 Jul 2013 11:55:42 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so6314587wgh.7 for ; Wed, 10 Jul 2013 11:55:41 -0700 (PDT) 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=b/+mCILCv+yF+LLJCfKZ96pOhUqPqV7Pk3NRVT+LMnM=; b=cUVFV4LtUu6OGEyOby/Imvkz/DAq1YFo9OKWlovLBleNPr1b+v/ZPH+VahSB1pXtyK C+LB8QFkt/1dq+vAEfZInn/MHLJg/Wzn1uFiicv5FNHJmQ6zFxDr7uZF4MQuzJbp04bp sVwPFelBTDC5RqiYKB2S4qnQMOaSVmyp5rUu5ZN6kr+H/qEYYkwSAoWux22ulwdvcuzc 2w7I50XR8X2t5/oIOcObJLvl1MUBrm2jYkrXgsVgyON4mu4OAmNClyuZ7LLzjBKjZp0F CJnN7nHglc67hW7Urah6IbNUagZ4R2hdrW5fPPq/cONKICslNfxhvm8zFuX3YtmL6gMj PYoQ== MIME-Version: 1.0 X-Received: by 10.180.206.70 with SMTP id lm6mr35712190wic.50.1373482541219; Wed, 10 Jul 2013 11:55:41 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Wed, 10 Jul 2013 11:55:41 -0700 (PDT) In-Reply-To: <51DD3248.3020008@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC95B2.8080801@gmail.com> <20130709231139.GC8043@gmail.com> <51DCA042.4000303@gmail.com> <51DD3248.3020008@gmail.com> Date: Wed, 10 Jul 2013 11:55:41 -0700 Message-ID: From: Tatu Saloranta To: "Peter F. Patel-Schneider" Content-Type: multipart/alternative; boundary=001a11c265bef9834b04e12cd219 Cc: Stephan Beal , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 18:55:57 -0000 --001a11c265bef9834b04e12cd219 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 10, 2013 at 3:07 AM, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote: > > On 07/10/2013 02:47 AM, Stephan Beal wrote: > > On Wed, Jul 10, 2013 at 1:44 AM, Peter F. Patel-Schneider < >> pfpschneider@gmail.com > wrote: >> >> That's a very unhappy situation. My interest in JSON is to consume >> data in JSON documents (mostly to use as input into representation >> systems that also use the W3C semantic web languages RDF and OWL). If >> JSON is ambiguous (e.g., as to whether 0.0 and 0 encode/stand >> for/represent the same thing) then JSON isn't very suitable for >> transmitting data, at least for me. >> >> >> While i think we will all agree that, at a technically pedantic level, >> you're absolutely right, JSON has been in heavy use for about 10(?) years >> now with _relatively_ few instances of this causing a problem. >> > > Relatively is one of these weasel words that we all use. I certainly > agree that JSON is useful for transmitting certain kinds of data. > Same can be said about any data formats in wide usage. This whole discussion could go on about XML as well: XML does not define any numeric types at format level. Additional specifications (schema, specs that require one of schema languages) have been defined to handle mapping of potentially unbound numbers. When you think of JSON as counter-part to XML specification, you may be less surprised to see physical limitations -- those may well belong to another layer. XML Schema has wide variety of numeric types as well, including unlimited precision ones. > > However, the working group mailing archives contain evidence that there > are indeed significant problems when using JSON to portably interchange > data, particularly binary data. Why so? Base64 encoding is the de-facto standard for this, and very widely used. Of all things discussed, this seems among lesser problems. And yes, even for transferring large amounts of binary data it is possible to add incremental (.... streaming) processing. I use this for synchronizing gigabyte sized blocks on a distributed storage system (although usually using binary encoding of JSON called Smile: but functionally JSON also works and is used for system tests). > > > Implementors tend to use whatever default limits the platform provides >> (e.g. 32-bit on 32-bit platforms and 64 on 64-bit, and 6-digit precision in >> doubles seems to be conventional in C libraries). >> People using high-precision/very large/very small numbers are certainly >> aware of the limitations/portability problems, and will (possibly after >> falling on their face with JSON) pick a different format. >> > > Are they really aware of all the potential problems? And just what > counts as high-precision/very large/very small? Does 0. belong to any of > these categories? > > > That's all fine and good - i haven't seen anyone here argue that JSON >> needs to be _the_ data format. It needs to be a _useful_ format for a wide >> range of applications, and it is that even if it's hard-coded to be limited >> to 31-bit integer ranges. In my implementations i have had to be very aware >> of system-level precision limits, but i simply document them, add build >> options to use, e.g. 64-bit integers if available, and leave it at that. >> Those details fall comfortably into the normal range of "implementation >> defined" details, IMO, and do _not_ (IMO) fall into JSON's realm of >> authority (JSON just needs to tell me the BNF for reading a number, though >> one could argue that the BNF should/does also imply certain limits). It >> would be impossible to enforce that arbitrary implementations must support >> arbitrarily long numbers, just as it would be silly to arbitrarily limit >> JSON to, say, 20-bit precision. >> >> Using your case of 0 vs 0.0. The vast, vast majority of JSON consumers >> are JavaScript, and JS doesn't differentiate between doubles and integers, >> so 0 is, in effect equivalent to 0.0. In fact, there are few real-world >> applications using JSON where the two are _not_ equivalent (barring >> scientific, high-precision, math-centric apps, of course, and those should >> probably be looking for a different format which guarantees them their >> desired ranges/limits). >> > > I would appreciate some evidence to back up the claim that the vast, vast > majority of JSON is handled in an environment where the JSON numbers 0 and > 0.0 do indeed represent the same thing. The RDF W3C workiing group is in > the last stages of putting its stamp of approval on JSON-LD, which presents > the JSON numbers 0 and 0.0 to RDF as being > I would rather argue that cases where equality matters are minority use cases. So whether they are equal at format level is completely irrelevant. You seem to be implying that this is a common concern -- I do not buy that claim. It does exist, but it is much more favored by theoretical thinkers than actual system implementors. -+ Tatu +- --001a11c265bef9834b04e12cd219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 10, 2013 at 3:07 AM, Peter F. Patel-Schneider = <pfpschneider@gmail.com> wrote:

On 07/10/2013 02:47 AM, Stephan Beal wrote:

On Wed, Jul 10, 2013 at 1:44 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com &= lt;mailto:pfpsc= hneider@gmail.com>> wrote:

=A0 =A0 That's a very unhappy situation. =A0 My interest in JSON is to = consume
=A0 =A0 data in JSON documents (mostly to use as input into representation<= br> =A0 =A0 systems that also use the W3C semantic web languages RDF and OWL). = If
=A0 =A0 JSON is ambiguous (e.g., as to whether 0.0 and 0 encode/stand
=A0 =A0 for/represent the same thing) then JSON isn't very suitable for=
=A0 =A0 transmitting data, at least for me.


While i think we will all agree that, at a technically pedantic level, you&= #39;re absolutely right, JSON has been in heavy use for about 10(?) years n= ow with _relatively_ few instances of this causing a problem.

Relatively is one of these weasel words that we all use. =A0I certainly agr= ee that JSON is useful for transmitting certain kinds of data.

Same can be said about any data formats in wide us= age.

This whole discussion could go on about XML as well: XML does not defin= e any numeric types at format level. Additional specifications (schema, spe= cs that require one of schema languages) have been defined to handle mappin= g of potentially unbound numbers. When you think of JSON as counter-part to= XML specification, you may be less surprised to see physical limitations -= - those may well belong to another layer. XML Schema has wide variety of nu= meric types as well, including unlimited precision ones.

=A0


Implementors tend to use whatever default limits the platform provides (e.g= . 32-bit on 32-bit platforms and 64 on 64-bit, and 6-digit precision in dou= bles seems to be conventional in C libraries).
People using high-precision/very large/very small numbers are certainly awa= re of the limitations/portability problems, and will (possibly after fallin= g on their face with JSON) pick a different format.

Are they really aware of all the potential problems? =A0 And just what coun= ts as high-precision/very large/very small? =A0Does 0. belong to any of the= se categories?


That's all fine and good - i haven't seen anyone here argue that JS= ON needs to be _the_ data format. It needs to be a _useful_ format for a wi= de range of applications, and it is that even if it's hard-coded to be = limited to 31-bit integer ranges. In my implementations i have had to be ve= ry aware of system-level precision limits, but i simply document them, add = build options to use, e.g. 64-bit integers if available, and leave it at th= at. Those details fall comfortably into the normal range of "implement= ation defined" details, IMO, and do _not_ (IMO) fall into JSON's r= ealm of authority (JSON just needs to tell me the BNF for reading a number,= though one could argue that the BNF should/does also imply certain limits)= . It would be impossible to enforce that arbitrary implementations must sup= port arbitrarily long numbers, just as it would be silly to arbitrarily lim= it JSON to, say, 20-bit precision.

Using your case of 0 vs 0.0. The vast, vast majority of JSON consumers are = JavaScript, and JS doesn't differentiate between doubles and integers, = so 0 is, in effect equivalent to 0.0. In fact, there are few real-world app= lications using JSON where the two are _not_ equivalent (barring scientific= , high-precision, math-centric apps, of course, and those should probably b= e looking for a different format which guarantees them their desired ranges= /limits).

I would appreciate some evidence to back up the claim that the vast, vast m= ajority of JSON is handled in an environment where the JSON numbers 0 and 0= .0 do indeed represent the same thing. The RDF W3C workiing group is in the= last stages of putting its stamp of approval on JSON-LD, which presents th= e JSON numbers 0 and 0.0 to RDF as being

I would rather argue that cases where equa= lity matters are minority use cases.
So whether they are equal at format= level is completely irrelevant.

You seem to be implying = that this is a common concern -- I do not buy that claim.
It does exist, but it is much more favored by theoretical thinke= rs than actual system implementors.

-+ Tatu +-=

=A0
--001a11c265bef9834b04e12cd219-- From cromis@gmail.com Wed Jul 10 14:33: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 2274121F9D80 for ; Wed, 10 Jul 2013 14:33:09 -0700 (PDT) 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 ySeKhRZFrO7A for ; Wed, 10 Jul 2013 14:33:08 -0700 (PDT) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9C05211E8123 for ; Wed, 10 Jul 2013 14:33:07 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so4017308qej.25 for ; Wed, 10 Jul 2013 14:33:06 -0700 (PDT) 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 :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=5jO3ePxbljNRf+n8FUCUqVpN8/wo1OhHmBgoApnwmsg=; b=MW2M8hLHiPJimri9tgfKFXo/QwCt/sp/KLYjujwcdHNERCuhMRo2YmkaAa6bq3Y4Mb paIefy+XoXwjeATNILtv22kjlCfMtSRB3GXvVY6/YPl7GWYMzAyl8/DfSDA4jeD5GbYe ScvnKF84FFsBwy1k5MKG3lK32IEfLnPrQIipGlly2MbHRugTbbmW6HznLpOZd+kFHO4O jNFKbE1lKVplUymggFNm7Y/9P7IOAILW1CuDjnHqNsb+mRZkxNF+GUQimc3QFHT+nKpN gh7YBGBO8aJO8eiUUxWu/YZiph4wg0f1GUP5peehVi8HWXVmgjYojiYTlK64mkvrg3cx vvDQ== X-Received: by 10.49.104.35 with SMTP id gb3mr27293703qeb.77.1373491986745; Wed, 10 Jul 2013 14:33:06 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.49.76.42 with HTTP; Wed, 10 Jul 2013 14:32:42 -0700 (PDT) In-Reply-To: <20130710024215.GO9153@mercury.ccil.org> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <20130710024215.GO9153@mercury.ccil.org> From: Jacob Davies Date: Wed, 10 Jul 2013 14:32:42 -0700 X-Google-Sender-Auth: ImQG6MebLhECd7lGPZ7oKKdUsDA Message-ID: To: John Cowan Content-Type: text/plain; charset=ISO-8859-1 Cc: "Peter F. Patel-Schneider" , Nico Williams , Bjoern Hoehrmann , Tatu Saloranta , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 10 Jul 2013 21:33:09 -0000 On Tue, Jul 9, 2013 at 7:42 PM, John Cowan wrote: > Apparently, there are already practical problems with interchanging > 64-bit longs: google for [json large numbers bugs] for lots of reports. The canonical one was Twitter IDs, where they had to introduce a (string) field in their JSON APIs called "id_str" which is not guaranteed to be equal to the obsolete-but-included (number) field "id". > While there are apparently int32-only systems out there, it's clearly > understood that they are unusually restricted: such is not the case > for JavaScript-hosted implementations. Yes, this is why I think the specification itself should note that for interoperability with Javascript, the Javascript size limitations must be respected, even if the specification does not require that in itself. The number of JSON-to-Javascript implementations or uses must surely outnumber all other uses of JSON by several orders of magnitude so I'd argue that as far as "running code" goes the limitation on practical, interoperable number size is quite real and surprising to people trying to send data to Javascript from non-JS environments where larger numbers are available. (I went so far in the Java libraries I wrote as to encode/decode longs & Big* as strings.) From tsaloranta@gmail.com Wed Jul 10 21:10: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 AF4D221F92BB for ; Wed, 10 Jul 2013 21:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 01qapWrsW3ol for ; Wed, 10 Jul 2013 21:10:09 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3F59921F9263 for ; Wed, 10 Jul 2013 21:10:07 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so6617373wes.3 for ; Wed, 10 Jul 2013 21:10:07 -0700 (PDT) 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=1RO9W9STxQDBEn2JmmiZt3hu0o9YXlDoYfZiKBra2FU=; b=uiB/gHKUDrsr1KUhkJyT4Z6k3bDC1luVZ28wM8TuqS+/ayit2m9oxT92/bTCBLJ1/N XAJQBxQYLZNW3jnaulp5QovUJWYmepX6jO9ygIV8evgyQFCTkPG/CYT/dUr60B9R7oR/ lvSiHHtUd5ZgJu35NN54o7QpKv5fxpt9la/yznw0nE2rRRPHvGg+OxHOcJdWhytNQCT+ YpZdT+j3IQU7Hkv4FMh70tvcLs4rfHqf1NBKEXWPFjov8QvyibL95DxiZu6ejvcigl3n REzaqlaQe0m0aN+EyjlwD5XqXZDGq+9ISddeEtFldXFiNl/yMBfaM2GCF8wUy0ww1Ql7 AiGw== MIME-Version: 1.0 X-Received: by 10.180.206.70 with SMTP id lm6mr36671963wic.50.1373515807246; Wed, 10 Jul 2013 21:10:07 -0700 (PDT) Received: by 10.227.34.199 with HTTP; Wed, 10 Jul 2013 21:10:07 -0700 (PDT) In-Reply-To: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <20130710024215.GO9153@mercury.ccil.org> Date: Wed, 10 Jul 2013 21:10:07 -0700 Message-ID: From: Tatu Saloranta To: Jacob Davies Content-Type: multipart/alternative; boundary=001a11c265bec8d04604e1349100 Cc: "Peter F. Patel-Schneider" , Nico Williams , Bjoern Hoehrmann , John Cowan , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 11 Jul 2013 04:10:09 -0000 --001a11c265bec8d04604e1349100 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 10, 2013 at 2:32 PM, Jacob Davies wrote: > On Tue, Jul 9, 2013 at 7:42 PM, John Cowan wrote: > > Apparently, there are already practical problems with interchanging > > 64-bit longs: google for [json large numbers bugs] for lots of reports. > > The canonical one was Twitter IDs, where they had to introduce a > (string) field in their JSON APIs called "id_str" which is not > guaranteed to be equal to the obsolete-but-included (number) field > "id". > > > While there are apparently int32-only systems out there, it's clearly > > understood that they are unusually restricted: such is not the case > > for JavaScript-hosted implementations. > > Yes, this is why I think the specification itself should note that for > interoperability with Javascript, the Javascript size limitations must > be respected, even if the specification does not require that in > itself. The number of JSON-to-Javascript implementations or uses must > surely outnumber all other uses of JSON by several orders of magnitude > so I'd argue that as far as "running code" goes the limitation on > Any data to back that up? I would not assume this -- JSON is being used a lot for service-to-service integration, as well as by native mobile clients. Javascript as client is certainly important, but I would not assume any particular majority (even simple one), and certainly not an order of magnitude. My experience wrt problem reports differs from that of John's, in that while feature requests have been filed to allow limitation or truncation, these have not been highly voted or actively followed. User community also has not brought this up as a significant issue either. I suspect this is because it is relatively easy to work around the problem if and when it occurs. Developers are surprisingly resourceful in solving problems. practical, interoperable number size is quite real and surprising to > people trying to send data to Javascript from non-JS environments > where larger numbers are available. (I went so far in the Java > libraries I wrote as to encode/decode longs & Big* as strings.) > Mentioning limitations is reasonable, and Javascript can be used as a common example. There is nothing wrong in outlining challenges, best practices. But I don't like fearmongering. Javascript's limited support for numbers is not a JSON-specific problem -- same goes for all data formats as well; for example, XML. This is why some concerns wrt JSON seem overblown to me. -+ Tatu +- --001a11c265bec8d04604e1349100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 10, 2013 at 2:32 PM, Jacob Davies <= ;jacob@well.com>= wrote:
On Tue, Jul 9, 2013 at 7:4= 2 PM, John Cowan <cowan@mercur= y.ccil.org> wrote:
> Apparently, there are already practical proble= ms with interchanging
> 64-bit longs: google for [json large numbers bugs] for lots of reports= .

The canonical one was Twitter IDs, where they had to introduce a
(string) field in their JSON APIs called "id_str" which is not guaranteed to be equal to the obsolete-but-included (number) field
"id".

> While there are apparently int32-only systems out there, it's clea= rly
> understood that they are unusually restricted: such is not the case > for JavaScript-hosted implementations.

Yes, this is why I think the specification itself should note that fo= r
interoperability with Javascript, the Javascript size limitations must
be respected, even if the specification does not require that in
itself. The number of JSON-to-Javascript implementations or uses must
surely outnumber all other uses of JSON by several orders of magnitude
so I'd argue that as far as "running code" goes the limitatio= n on

Any data to back that up? I would not assu= me this -- JSON is being used a lot for service-to-service integration, as = well as by native mobile clients.
Javascript as client is cer= tainly important, but I would not assume any particular majority (even simp= le one), and certainly not an order of magnitude.

My experience wrt problem report= s differs from that of John's, in that while feature requests have been= filed to allow limitation or truncation, these have not been highly voted = or actively followed. User community also has not brought this up as a sign= ificant issue either.
I suspect this is because it is relatively easy to work around the problem = if and when it occurs. Developers are surprisingly resourceful in solving p= roblems.

practical, interoperable number size is quit= e real and surprising to
people trying to send data to Javascript from non-JS environments
where larger numbers are available. (I went so far in the Java
libraries I wrote as to encode/decode longs & Big* as strings.)

Mentioning limitati= ons is reasonable, and Javascript can be used as a common example. There is= nothing wrong in outlining challenges, best practices. But I don't lik= e fearmongering.

Javascript's limited support for n= umbers is not a JSON-specific problem -- same goes for all data formats as = well; for example, XML. This is why some concerns wrt JSON seem overblown t= o me.

-+ Tatu +-


--001a11c265bec8d04604e1349100-- From sayrer@gmail.com Wed Jul 10 22:42: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 61BE521F9D5A for ; Wed, 10 Jul 2013 22:42:45 -0700 (PDT) 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, 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 vV6FkHnKMqAU for ; Wed, 10 Jul 2013 22:42:44 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DF05D21F9D3B for ; Wed, 10 Jul 2013 22:42:43 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so12181836wiv.7 for ; Wed, 10 Jul 2013 22:42:42 -0700 (PDT) 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=xq49+6H8xQQZb4VzQjET7ygBFlqmzo8vNgzqiQ05488=; b=c+kv8QmTfYPtCZjh0DEbhK2piYc//yjVBtqulqrvy3mUKw9ohEv4ya9fQ8fXv3oCL9 47ipWOGldg/HpTRxnDjqhKRDe0okAzZXJvVlbMXf0tD+Zl81hOp1X1IgY0QZ7jJHPrGg Qns755mk0AJLtQ9C7+o223J6edbwPPDKDMFOLWMQV+feS15GZVSHWp1mDswETXa4GSVZ rFuOSzMCpulxwdlSioo+IUzgzM0EL5oH95Co9lAsjO9iw3wFwbGJ4jYJCCowdJRUUBJe wfyP0XCTzQp5e2e1gisjgFNBAIFmu8ooISYq/nUDpWr0QfwibTgzinbetvS4o863Ev/b 4yOg== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr19511526wjs.79.1373521362742; Wed, 10 Jul 2013 22:42:42 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Wed, 10 Jul 2013 22:42:42 -0700 (PDT) In-Reply-To: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <20130710024215.GO9153@mercury.ccil.org> Date: Wed, 10 Jul 2013 22:42:42 -0700 Message-ID: From: R S To: Tatu Saloranta Content-Type: multipart/alternative; boundary=047d7ba97518eaf26a04e135dccc Cc: John Cowan , Bjoern Hoehrmann , "json@ietf.org" , Jacob Davies , Nico Williams , "Peter F. Patel-Schneider" Subject: Re: [Json] Limitations on number size? 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, 11 Jul 2013 05:42:45 -0000 --047d7ba97518eaf26a04e135dccc Content-Type: text/plain; charset=ISO-8859-1 Is this thread making any progress over the minimal edit I proposed? I think not, fwiw. - Rob On Wed, Jul 10, 2013 at 9:10 PM, Tatu Saloranta wrote: > > > > On Wed, Jul 10, 2013 at 2:32 PM, Jacob Davies wrote: > >> On Tue, Jul 9, 2013 at 7:42 PM, John Cowan >> wrote: >> > Apparently, there are already practical problems with interchanging >> > 64-bit longs: google for [json large numbers bugs] for lots of reports. >> >> The canonical one was Twitter IDs, where they had to introduce a >> (string) field in their JSON APIs called "id_str" which is not >> guaranteed to be equal to the obsolete-but-included (number) field >> "id". >> >> > While there are apparently int32-only systems out there, it's clearly >> > understood that they are unusually restricted: such is not the case >> > for JavaScript-hosted implementations. >> >> Yes, this is why I think the specification itself should note that for >> interoperability with Javascript, the Javascript size limitations must >> be respected, even if the specification does not require that in >> itself. The number of JSON-to-Javascript implementations or uses must >> surely outnumber all other uses of JSON by several orders of magnitude >> so I'd argue that as far as "running code" goes the limitation on >> > > Any data to back that up? I would not assume this -- JSON is being used a > lot for service-to-service integration, as well as by native mobile clients. > Javascript as client is certainly important, but I would not assume any > particular majority (even simple one), and certainly not an order of > magnitude. > > My experience wrt problem reports differs from that of John's, in that > while feature requests have been filed to allow limitation or truncation, > these have not been highly voted or actively followed. User community also > has not brought this up as a significant issue either. > I suspect this is because it is relatively easy to work around the problem > if and when it occurs. Developers are surprisingly resourceful in solving > problems. > > practical, interoperable number size is quite real and surprising to >> people trying to send data to Javascript from non-JS environments >> where larger numbers are available. (I went so far in the Java >> libraries I wrote as to encode/decode longs & Big* as strings.) >> > > Mentioning limitations is reasonable, and Javascript can be used as a > common example. There is nothing wrong in outlining challenges, best > practices. But I don't like fearmongering. > > Javascript's limited support for numbers is not a JSON-specific problem -- > same goes for all data formats as well; for example, XML. This is why some > concerns wrt JSON seem overblown to me. > > -+ Tatu +- > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --047d7ba97518eaf26a04e135dccc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is this thread making any progress over the minimal edit I= proposed? I think not, fwiw.

- Rob


On Wed, Jul 10, 2013 a= t 9:10 PM, Tatu Saloranta <tsaloranta@gmail.com> wrote:



On Wed, Jul 10, 20= 13 at 2:32 PM, Jacob Davies <jacob@well.com> wrote:
On Tue, Jul 9, 2013 at 7:42 PM, John Co= wan <cowan@m= ercury.ccil.org> wrote:
> Apparently, there are already practical problems with inter= changing
> 64-bit longs: google for [json large numbers bugs] for lots of reports= .

The canonical one was Twitter IDs, where they had to introduce a
(string) field in their JSON APIs called "id_str" which is not guaranteed to be equal to the obsolete-but-included (number) field
"id".

> While there are apparently int32-only systems out there, it's clea= rly
> understood that they are unusually restricted: such is not the case > for JavaScript-hosted implementations.

Yes, this is why I think the specification itself should note that fo= r
interoperability with Javascript, the Javascript size limitations must
be respected, even if the specification does not require that in
itself. The number of JSON-to-Javascript implementations or uses must
surely outnumber all other uses of JSON by several orders of magnitude
so I'd argue that as far as "running code" goes the limitatio= n on

Any data to back that up? I would no= t assume this -- JSON is being used a lot for service-to-service integratio= n, as well as by native mobile clients.
Javascript as client = is certainly important, but I would not assume any particular majority (eve= n simple one), and certainly not an order of magnitude.

My experience wrt problem report= s differs from that of John's, in that while feature requests have been= filed to allow limitation or truncation, these have not been highly voted = or actively followed. User community also has not brought this up as a sign= ificant issue either.
I suspect this is because it is relatively easy to work around the problem = if and when it occurs. Developers are surprisingly resourceful in solving p= roblems.

practical, interoperable number size is quit= e real and surprising to
people trying to send data to Javascript from non-JS environments
where larger numbers are available. (I went so far in the Java
libraries I wrote as to encode/decode longs & Big* as strings.)

Mentioning li= mitations is reasonable, and Javascript can be used as a common example. Th= ere is nothing wrong in outlining challenges, best practices. But I don'= ;t like fearmongering.

Javascript's limited support for n= umbers is not a JSON-specific problem -- same goes for all data formats as = well; for example, XML. This is why some concerns wrt JSON seem overblown t= o me.

-+ Tatu +-

<= br>

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


--047d7ba97518eaf26a04e135dccc-- From fgaliegue@gmail.com Thu Jul 11 13:47:28 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 86D0A21F9FC3 for ; Thu, 11 Jul 2013 13:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 I8hFK8ZwS9it for ; Thu, 11 Jul 2013 13:47:28 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9F16921F9FCF for ; Thu, 11 Jul 2013 13:47:27 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id t10so5838585eei.13 for ; Thu, 11 Jul 2013 13:47:26 -0700 (PDT) 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=FzFVPZC+h6YiBSWPCLr/GDPERuFCLmX/2YYo5Vo+8H0=; b=KgqIALjwAXrcahkG7n4hjqRPesUCAMYnGoZxpzNlLH/hCR4GvbZi2qKyUVjjrAOeff vXZt8mqwPXa8FgkHem12LD/Z4Vp+jJnZEOhfkwIGvTZ4fNWXRutNicZFuU0uKDmKUuDw 1MceF9Inn35fJP/RecAvBO0Z3UpuZFEgDud8n14q7btRcOurXR5oCBNIv1DjCrbfyuFB TpPpEGTOWjd0q/G4KdCvlvUkxU38g190YEiT2dmXBNaCn2qDS1Q1cXZQQFn2vV2i4MHl KXySh/B8y9kwX8XfwB7HrF/NFnRuNpBlen/4U78u5ql0uJW4PmlGZV8KUbaBwakvg7KZ 93RQ== MIME-Version: 1.0 X-Received: by 10.14.241.5 with SMTP id f5mr43817287eer.131.1373575646747; Thu, 11 Jul 2013 13:47:26 -0700 (PDT) Received: by 10.14.175.135 with HTTP; Thu, 11 Jul 2013 13:47:26 -0700 (PDT) In-Reply-To: <51DC92B1.7000908@gmail.com> References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> Date: Thu, 11 Jul 2013 22:47:26 +0200 Message-ID: From: Francis Galiegue To: "Peter F. Patel-Schneider" Content-Type: text/plain; charset=UTF-8 Cc: Nico Williams , Jorge Chamorro , Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 11 Jul 2013 20:47:28 -0000 On Wed, Jul 10, 2013 at 12:46 AM, Peter F. Patel-Schneider wrote: [...] > > But everything that I've read about JSON indicates that JSON is supposed to > be used for (portably) interchanging data. If all there is to JSON is the > grammar then what's the point of JSON? > Some JSON parsers support {de,}serializing numbers of an arbitrary precision and/or scale. Castrating these languages just so that they limit their possible numeric representations is castrating the value of JSON itself. The number production grammar is perfect as it is, I see no reason to change it. -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From nico@cryptonector.com Thu Jul 11 14:04:03 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 8E0AB11E8182 for ; Thu, 11 Jul 2013 14:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 ELbFxWA9jci7 for ; Thu, 11 Jul 2013 14:03:58 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4C15311E8179 for ; Thu, 11 Jul 2013 14:03:57 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id B4B9E67C06E for ; Thu, 11 Jul 2013 14:03:56 -0700 (PDT) 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=7uxe8BJsEuJDMA3iDbJ7 mpuDAX4=; b=INpNGxMfSaee7R3A+A6tjif5RP7R+ll/mH3NZVG3EJZiZ7/5HYb6 FTeXeDGtYtoUDvCP/RmENpeb7QmgPb3E8XZIcrt+ANkjeuf4B7W3VpX5RQIqtCmJ pXY13xjpKcUdBvpaZfY6IrioU+G+Zw0iB71i8D9bvCidGNYZQdgH+nQ= Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id EDF3167C06B for ; Thu, 11 Jul 2013 14:03:54 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so7241900wes.6 for ; Thu, 11 Jul 2013 14:03:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=szjSITRp0TbjpYNhwnIn0aN9HvlTQNG6KJ2XVChh+kA=; b=HLbg2dF196X3BUKCi1sOISL8mdYimRPeDtXMDtITHwJ8j2NAQ9rhApFEm3CIXGFfze 35fWCFgrMo8mHiWDPITHm0Oc4ZlS3MigQFR1CHczPMQeQ/kbHr9xttVb0nAjoc8vckt3 fWqAAJeTiMyfXyXdMbd+n2BqDrMIULSHW7hU+MenPuqPVu+oIm4b4KWsbPU7wTUPgxgw 0j+vUnolfm+8VIbhlFu7j5u4mMfgZHZ7w1NCjrc4ZpU0+yCROjfRl0LVe0kP5hvMExc4 cejBMU70lCZawUxIA2SS5ANRXnKlc96ompqd5y+AzoAx6Vx3yPfLQcr0Qf7cuKo+QJPz GSSg== MIME-Version: 1.0 X-Received: by 10.180.98.231 with SMTP id el7mr38348860wib.33.1373576632682; Thu, 11 Jul 2013 14:03:52 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 14:03:52 -0700 (PDT) In-Reply-To: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> Date: Thu, 11 Jul 2013 16:03:52 -0500 Message-ID: From: Nico Williams To: Francis Galiegue Content-Type: text/plain; charset=UTF-8 Cc: Bjoern Hoehrmann , Jorge Chamorro , "Peter F. Patel-Schneider" , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 11 Jul 2013 21:04:03 -0000 On Thu, Jul 11, 2013 at 3:47 PM, Francis Galiegue wrote: > On Wed, Jul 10, 2013 at 12:46 AM, Peter F. Patel-Schneider > wrote: > [...] >> >> But everything that I've read about JSON indicates that JSON is supposed to >> be used for (portably) interchanging data. If all there is to JSON is the >> grammar then what's the point of JSON? >> > > Some JSON parsers support {de,}serializing numbers of an arbitrary > precision and/or scale. Castrating these languages just so that they > limit their possible numeric representations is castrating the value > of JSON itself. That's not responsive to Peter's comment. Just as we shouldn't leave out bignums, we cannot require bignum support either, and people who create open APIs with the intention to interop will have to face this (and related) problems. > The number production grammar is perfect as it is, I see no reason to change it. The *grammar* is, the semantics are underspecified. This, I think, is more fodder for: publish an update noting the divergent interpretations, *perhaps*, in the same update, also identify a most-likely-to-interop subset of JSON, and finally and separately publish Internet JSON -- a subset of JSON with much less room for interpretation and therefore much higher likelihood of interoperability. From jorge@jorgechamorro.com Thu Jul 11 14:09: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 5B33711E8170 for ; Thu, 11 Jul 2013 14:09:19 -0700 (PDT) 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 cD1ECGkxvcrW for ; Thu, 11 Jul 2013 14:09:13 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5544711E8178 for ; Thu, 11 Jul 2013 14:09:12 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so7418752wes.17 for ; Thu, 11 Jul 2013 14:09:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=dYY8mXOs51mMjVflCl9gCqFZLb9OdPVUkponralwLgk=; b=CoaEAv1DRdJlkP8yxv1vlYvVaVtZ2QgBr39hGxzn73l2rM9TYeNAO6/guSi2pEDpo7 5/4/6GbpWV32Z4QiwcEyjsljSmUpKcQrf3vPyUdd3oi2D03TLBG2X+8f1zdLo9bkrLHa arUTAXZuPEM2NxQAZ/+MHSsxsZvh3fIoPDKlf4bykSmKVClVy4jV0y4DhpNzUl464Cm+ WnL23ia9OY2L1diZe7Z//5tP3MYoKNTEEJ6eAJ0/Yr6hyIqfkjuNlrEtK2T8/VfnCnsD 4/lwrpjMV2ay4fd/6FrJ7xbsXkNKizAAsS22DRRI6oCEdyY5+9GTF/5oQyCy/01tMcj0 I0lQ== X-Received: by 10.180.99.161 with SMTP id er1mr21146659wib.26.1373576950900; Thu, 11 Jul 2013 14:09:10 -0700 (PDT) Received: from [192.168.10.50] (189.Red-79-155-151.dynamicIP.rima-tde.net. [79.155.151.189]) by mx.google.com with ESMTPSA id h8sm44570431wie.1.2013.07.11.14.09.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 14:09:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: Date: Thu, 11 Jul 2013 23:09:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> To: Francis Galiegue X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnOSDZBWCvBSh4UFRqkGD9ZOxqQs7gGf777DZTCTDFkTqP/i651k8nmWoidKY0M2U3C/2jw Cc: Nico Williams , Bjoern Hoehrmann , "Peter F. Patel-Schneider" , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 11 Jul 2013 21:09:19 -0000 On 11/07/2013, at 22:47, Francis Galiegue wrote: >=20 >=20 > The number production grammar is perfect as it is, I see no reason to = change it. +1 --=20 ( Jorge )(); From fgaliegue@gmail.com Thu Jul 11 14:28: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 7E9B311E817F for ; Thu, 11 Jul 2013 14:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BuuXI6InYTu4 for ; Thu, 11 Jul 2013 14:28:18 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id B78B711E812A for ; Thu, 11 Jul 2013 14:28:17 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id b57so5757028eek.36 for ; Thu, 11 Jul 2013 14:28:16 -0700 (PDT) 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=FqtV1m/9QY2JkkdZ5J4+VmLP54qctdiLkrxbMXhs1qo=; b=Aw8+nUMSa5iKU17eGusYXprd3LE2xtyMCtXFRyVZduJljF6kBPIYRQWWEgcwCInF+G GDNwUz49N2YPZis3B3QMv6wg914zqnUAhAbuZO8sVtghi6fKj9NbVcIEcmo6RS1rbqYV JN7ZeieAN0mkZOeaGR8JgBdCl3ov58OWg4DC0cVOvbBMARJZnVbDvxyKc25S/xT1dvu5 wN8ewZs8cseoIbw8I2aDlamGEjtTzETc4v6ObgRteAGGVghkIUO+TCFwCc1svPYKegnV KYol2zhqf8hk9vL186T+BJ4o9hrIg6R9IdIf+yqRuZk0Q49QEx9hRpP4yo8OXlfb6NGc ql2w== MIME-Version: 1.0 X-Received: by 10.14.32.197 with SMTP id o45mr44157401eea.9.1373578096862; Thu, 11 Jul 2013 14:28:16 -0700 (PDT) Received: by 10.14.175.135 with HTTP; Thu, 11 Jul 2013 14:28:16 -0700 (PDT) In-Reply-To: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> Date: Thu, 11 Jul 2013 23:28:16 +0200 Message-ID: From: Francis Galiegue To: Nico Williams Content-Type: text/plain; charset=UTF-8 Cc: Bjoern Hoehrmann , Jorge Chamorro , "Peter F. Patel-Schneider" , json@ietf.org Subject: Re: [Json] Limitations on number size? 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, 11 Jul 2013 21:28:18 -0000 On Thu, Jul 11, 2013 at 11:03 PM, Nico Williams wrote: [...] > > That's not responsive to Peter's comment. Just as we shouldn't leave > out bignums, we cannot require bignum support either, and people who > create open APIs with the intention to interop will have to face this > (and related) problems. > I do not deny this. However: >> The number production grammar is perfect as it is, I see no reason to change it. > > The *grammar* is, the semantics are underspecified. > I don't believe the JSON RFC should _require_ any semantics. Advice, yes, why not. But API programmers are well aware that they have to deal with their own language's/other people's languages limitations. So, even then it does not look necessary at all. -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From nico@cryptonector.com Thu Jul 11 14:57: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 D7CA821F9F8E for ; Thu, 11 Jul 2013 14:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 re29SEJFxedt for ; Thu, 11 Jul 2013 14:57:10 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id EF68321F9F80 for ; Thu, 11 Jul 2013 14:57:09 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 850291005D for ; Thu, 11 Jul 2013 14:57:09 -0700 (PDT) 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=7dJIji186OtfRhOHKR9i 1pIfGgE=; b=kUlQFwb1w9xgxr9vZPTN+72bMqt5Xd2dIqmIC7eNcevyJL/O/0jv NMGYrUhdtkkrI2jWkQFURs686tHouPSchsE6bIJ0NXWPI0BbXK75doP4yaNs2HWR n63r4ss0XGQXV57KLR8ZFMyxGK5ObwBKCiD1IHxIhTd3hW79h6XLyvg= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 256F210058 for ; Thu, 11 Jul 2013 14:57:08 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so7608390wgh.30 for ; Thu, 11 Jul 2013 14:57:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GRwGsDh8GceTL2gRqcB631YyuOzJr5NBZBgP3ANGwK8=; b=c+EnyCaSRxOVhai4KISf9VefGWfWAXvmc71L6M9Xmj+omW6RENiBZzmjqnr8BLpZ07 rpl4fR9j8nrXcEVrPhTQmn4wIwmyQtxtOEGVW8y7g7glao98rI6SPbAyrzdyAokWR3xU MrfC0EkNYiFRT/7qEusCQ3xLpz4zSQkc8jldWluSL7yr3pO8h2jkShJRgBn7GMxVo7M8 0DGYTmBKtbrAinpxM/OwYO8SWBL4A8jurt0tDC/EIUWJraml4xiPvCqLvbb6fi8CvXVS +TJoX1iCLkTbiOxYf9XjX4YRH+UqF7DYzHFTsQPQjjcs9nSbum4m3aSINqgwa0R4BWzf h9rw== MIME-Version: 1.0 X-Received: by 10.194.22.1 with SMTP id z1mr22830333wje.14.1373579827490; Thu, 11 Jul 2013 14:57:07 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 14:57:07 -0700 (PDT) In-Reply-To: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> Date: Thu, 11 Jul 2013 16:57:07 -0500 Message-ID: From: Nico Williams To: Francis Galiegue Content-Type: text/plain; charset=UTF-8 Cc: json@ietf.org, Bjoern Hoehrmann , "Peter F. Patel-Schneider" , Jorge Chamorro Subject: Re: [Json] Limitations on number size? 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, 11 Jul 2013 21:57:15 -0000 On Thu, Jul 11, 2013 at 4:28 PM, Francis Galiegue wrote: > On Thu, Jul 11, 2013 at 11:03 PM, Nico Williams wrote: > [...] >> >> That's not responsive to Peter's comment. Just as we shouldn't leave >> out bignums, we cannot require bignum support either, and people who >> create open APIs with the intention to interop will have to face this >> (and related) problems. >> > > I do not deny this. However: Great! :) >>> The number production grammar is perfect as it is, I see no reason to change it. >> >> The *grammar* is, the semantics are underspecified. > > I don't believe the JSON RFC should _require_ any semantics. Advice, > yes, why not. But API programmers are well aware that they have to > deal with their own language's/other people's languages limitations. > So, even then it does not look necessary at all. Well, OK, but whether we're dealing with APIs or protocols (or plain document formats), we need to concern ourselves with compatibility (APIs) and interoperability (protocols). This requires more than grammar. If we specify no semantics then we're stuck with either the maximal interpretation of the grammar (binary strings! bignums! allow dup names! [since no specific handling of dup names can be considered a maximal interpretation...]) or an agreed subset, de facto or de jure. Given that we're here, that we have formed a WG tasked with looking into this, I think it's proper to look at the question of semantics. You don't want to -- fair and noted, but we have a charter that had consensus, and we may have consensus to actually do something in this space, with or without you. At some point the chairs will have to take action and make some consensus calls (I know, they have, but their earlier consensus calls were not, i think, phrased usefully _in retrospect_; they may yet take another swing and succeed). My proposed consensus calls: 1a) Minimal edit noting divergent interpretations -- yes or no? 1b) If not, should we conclude without further ado, or consider (3) below? -- conclude or work on I-JSON? 2) If yes to (1a), note a likely-to-interop subset of JSON in the same update -- yes or no? 3) Regardless of the answers to (1) and (2), should we re-charter to include publishing of an Internet JSON as a work item -- yes or no? That should suffice for now. If we get consensus for (1a), (2), and/or (3), we'll surely need more consensus calls later, but I think the content of a minimal update and a likely-to-interop subset of JSON are both possible to produce "mechanically", so to speak, leaving only minor controversies plus any controversies in producing I-JSON. Nico -- From fgaliegue@gmail.com Thu Jul 11 15:41: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 0D86021F9FF8 for ; Thu, 11 Jul 2013 15:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7-SwKH1osp3n for ; Thu, 11 Jul 2013 15:41:38 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5578021F9C6B for ; Thu, 11 Jul 2013 15:41:37 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id l15so6080010eak.9 for ; Thu, 11 Jul 2013 15:41:36 -0700 (PDT) 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=+zylcS95dYt9evsIZTIr9iUr1UWx8x9NmQ+SA2wIgfg=; b=goNcqwyD7aypu0kqDITy0WQEsrpzwO2N9eYT3DlVZToAKvb3YrpRhkNcfQmvQMjdaw 5HvitemoDYSlPH1YDjuRw6/PjqoROmR+i/uRLidghquqEwhX9F8xnZhDsNH3RsY0PIoM rFNmRysYHnrCx/Q4/vavedPjsUfrEWXvIHSrcfVB2CZUD4t2hiKnsRNUPlCBArYxDMa4 2PIiABvPAISKnrUeyzvNPVasqjhecBsiCIv/0PvZ0oKizqx7uAk7EfT6tTsz6j82gYlk oF2uLJsfdxHaX+GXasp+v98kjxuWj6KHBdSaWqyW2z17zbQ6ZMXLrUTxIiRx3DOIRwJq jVKA== MIME-Version: 1.0 X-Received: by 10.14.241.5 with SMTP id f5mr44152385eer.131.1373582496359; Thu, 11 Jul 2013 15:41:36 -0700 (PDT) Received: by 10.14.175.135 with HTTP; Thu, 11 Jul 2013 15:41:36 -0700 (PDT) In-Reply-To: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> Date: Fri, 12 Jul 2013 00:41:36 +0200 Message-ID: From: Francis Galiegue To: Nico Williams Content-Type: text/plain; charset=UTF-8 Cc: json@ietf.org, Bjoern Hoehrmann , "Peter F. Patel-Schneider" , Jorge Chamorro Subject: Re: [Json] Limitations on number size? 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, 11 Jul 2013 22:41:39 -0000 On Thu, Jul 11, 2013 at 11:57 PM, Nico Williams wrote: [...] >> >> I don't believe the JSON RFC should _require_ any semantics. Advice, >> yes, why not. But API programmers are well aware that they have to >> deal with their own language's/other people's languages limitations. >> So, even then it does not look necessary at all. > > Well, OK, but whether we're dealing with APIs or protocols (or plain > document formats), we need to concern ourselves with compatibility > (APIs) and interoperability (protocols). I agree, but then it is up to the protocols to define that. Say you want to exchange prices over JSON, then it makes sense to require that numbers be limited to two digits after the decimal point and, why not, require that scientific notation not be used. (and 0.01 cannot be represented reliably with a 64bit IEEE 754 floating point number, too) But I believe this is not the role of JSON proper to define that. > [...] If we specify no semantics then we're stuck with either the > maximal interpretation of the grammar (binary strings! bignums! allow > dup names! [since no specific handling of dup names can be considered > a maximal interpretation...]) or an agreed subset, de facto or de > jure. > I don't believe duplicate object names are quite the same level. This was rather an oversight of RFC 4627 imho. -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From tbray@textuality.com Thu Jul 11 15:56: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 BCBB011E8136 for ; Thu, 11 Jul 2013 15:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=-3.500, 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 uWtvL7JCGZg0 for ; Thu, 11 Jul 2013 15:56:31 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBC121F9BEB for ; Thu, 11 Jul 2013 15:56:30 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id gd11so7278149vcb.16 for ; Thu, 11 Jul 2013 15:56:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XU79WwiOt3+vXQuYXq97Lk9n40NuvZRUfKEtxMQkTnE=; b=Gvccwadc/Q0hdj+U0GBGuOzalr2VN/cPSZifkZcTrUCHMjqL5pqhtz3dOiP2cb98sn KUE2pIKdBy2HigNpqiDN0Ok4qag3fuj9NDvCuJxTqsVnw5UQKM7yakMKqOitZklqu4ic LlqGE1UDN3pi/zBLxu1zMItWFmrAWG9PR7rAmXViJ7ki4xTutdKpRccdvb1u+cJGNjpK zGZkZTapkc8t0/h4FpS/JZX69R6BVg0Sl8BxXzjU+MbaIOvIYX7QEORaN9zx0i/LqLD8 n+kKxAGUY1rAyzL0uSq6gYMq+NzcwF/W1oI7FfX0XLYUkmj8xdBnIrzUETCNCu+7KP2L AmZw== MIME-Version: 1.0 X-Received: by 10.58.54.70 with SMTP id h6mr22959606vep.36.1373583390358; Thu, 11 Jul 2013 15:56:30 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Thu, 11 Jul 2013 15:56:30 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> Date: Thu, 11 Jul 2013 15:56:30 -0700 Message-ID: From: Tim Bray To: Francis Galiegue Content-Type: multipart/alternative; boundary=089e0122ad060d4f2c04e1444e50 X-Gm-Message-State: ALoCoQn8QUyQqo6XLyvXkergad0XsYnVXxgB24UD7ytdGOKhlRC2Tnk/QbBcXtakUtg69rQH4+Uo Cc: Nico Williams , Bjoern Hoehrmann , "Peter F. Patel-Schneider" , Jorge Chamorro , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 11 Jul 2013 22:56:35 -0000 --089e0122ad060d4f2c04e1444e50 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 11, 2013 at 3:41 PM, Francis Galiegue wrot= e: > I agree, but then it is up to the protocols to define that. Say you > want to exchange prices over JSON, then it makes sense to require that > numbers be limited to two digits after the decimal point and, why not, > require that scientific notation not be used. (and 0.01 cannot be > represented reliably with a 64bit IEEE 754 floating point number, too) > Well yeah, but most programmers want to use generic non-app-sensitive libraries to deserialize JSON into structs or objects or database records or whatever, and if you send a 78-digit number that will usually break. So as long as you have pre-agreement and a flexible enough library, you=E2=80= =99re probably good. This is the main reason I thought I-JSON was worth defining, to maximize the chance that you can use a nice simple library at both ends and have the lowest possible chance of breakage. -T > > But I believe this is not the role of JSON proper to define that. > > > [...] If we specify no semantics then we're stuck with either the > > maximal interpretation of the grammar (binary strings! bignums! allow > > dup names! [since no specific handling of dup names can be considered > > a maximal interpretation...]) or an agreed subset, de facto or de > > jure. > > > > I don't believe duplicate object names are quite the same level. This > was rather an oversight of RFC 4627 imho. > > -- > Francis Galiegue, fgaliegue@gmail.com > JSON Schema in Java: http://json-schema-validator.herokuapp.com > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0122ad060d4f2c04e1444e50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 11, 2013 at 3:41 PM, Francis Galiegue <fgal= iegue@gmail.com> wrote:
I agree, but then it is u= p to the protocols to define that. Say you
want to exchange prices over JSON, then it makes sense to require that
numbers be limited to two digits after the decimal point and, why not,
require that scientific notation not be used. (and 0.01 cannot be
represented reliably with a 64bit IEEE 754 floating point number, too)
<= /blockquote>

Well yeah, but most programmers want to use generic no= n-app-sensitive=20 libraries to deserialize JSON into structs or objects or database=20 records or whatever, and if you send a 78-digit number that will usually break.=C2=A0 So as long as you have pre-agreement and a flexible enough=20 library, you=E2=80=99re probably good.=C2=A0 This is the main reason I thou= ght I-JSON was worth defining, to maximize the chance that you can use a nice=20 simple library at both ends and have the lowest possible chance of=20 breakage. -T
=C2=A0

But I believe this is not the role of JSON proper to define that.

> [...] If we specify no semantics then we're stuck with either the<= br>
> maximal interpretation of the grammar (binary string= s! bignums! allow
> dup names! [since no specific handling of dup names can be considered<= br> > a maximal interpretation...]) or an agreed subset, de facto or de
> jure.
>

I don't believe duplicate object names are quite the same level. = This
was rather an oversight of RFC 4627 imho.

--
Francis Galiegue, fgaliegue@gmail.co= m
JSON Schema in Java: http://json-schema-validator.herokuapp.com
___________________________________= ____________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--089e0122ad060d4f2c04e1444e50-- From nico@cryptonector.com Thu Jul 11 16:20: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 E839921F9B89 for ; Thu, 11 Jul 2013 16:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.267, 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 Uq2fussNZW6m for ; Thu, 11 Jul 2013 16:20:51 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id AA37821F9AC4 for ; Thu, 11 Jul 2013 16:20:50 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 13E61163A for ; Thu, 11 Jul 2013 16:20:50 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=O54kqf6Gn7ftDSrYpz7iJjJ/dbg=; b=bBgz7AfizvA Iga+YWk4hvEm8MxPPSfJ7b/thRd6f8+6GUHTUvIe6Jk8WjkDdXEanM0H641LJhfk PHrhm2JPci8adKwrou2ki+0fiXAvupuNSz1+OLTbgxonaQpsr7wa6vJsiyIVJr0t kBzK3QLMpccUrBugdUWh+yoURP4J+ywE= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id B3B8D1621 for ; Thu, 11 Jul 2013 16:20:49 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so98326wiw.2 for ; Thu, 11 Jul 2013 16:20:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZrjQkJX2Kjw9lpr2TtjgiDz/Eg5frkPdrVoBPshUZU0=; b=G22iGukrr9ckULVrNAtk5s5E8tkFWAWzeQXDS4imokgercMmsw6dLsbyP71oHajdi2 5Mci7HK5RrmVYuNuohiiTXGywcbjG1dpvbazQtZkOuWzwxOGTgiF+OgHNu5/iWilLoTs OwCGQ7tMf051y6DvdZArxCwsz0j7fhVeQX2v2530dg4ipvxKoPkcXvbZnRAFaajZ94E/ zvJ4+3/SKDRhxoSqrSlLdzIpSIaAgm3lEWBosx8/xc1HhexWFTdsYQEe3Wb+EQ/rNx00 WvrJpehWrFf1FxoP82YUqSGgiDQnUqGC4+LVGb7quZhqWYwsQKgUgTQlqKTGP8Jj2uwZ 7GNA== MIME-Version: 1.0 X-Received: by 10.180.74.162 with SMTP id u2mr72234wiv.36.1373584848104; Thu, 11 Jul 2013 16:20:48 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Thu, 11 Jul 2013 16:20:47 -0700 (PDT) In-Reply-To: References: <51DC0F95.7010407@gmail.com> <51DC7F87.6060503@gmail.com> <51DC92B1.7000908@gmail.com> Date: Thu, 11 Jul 2013 18:20:47 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Francis Galiegue , Bjoern Hoehrmann , "Peter F. Patel-Schneider" , Jorge Chamorro , "json@ietf.org" Subject: Re: [Json] Limitations on number size? 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, 11 Jul 2013 23:20:56 -0000 On Thu, Jul 11, 2013 at 5:56 PM, Tim Bray wrote: > On Thu, Jul 11, 2013 at 3:41 PM, Francis Galiegue > wrote: >> I agree, but then it is up to the protocols to define that. Say you >> want to exchange prices over JSON, then it makes sense to require that >> numbers be limited to two digits after the decimal point and, why not, >> require that scientific notation not be used. (and 0.01 cannot be >> represented reliably with a 64bit IEEE 754 floating point number, too) Right, we could do that. We thought we would do that for all JSON applications, and it turns out we can't quite do it. It'd be nice, then, to have a reference (or three) subset(s) of JSON, to facilitate interoperable application protocol specifications that want to use JSON. > Well yeah, but most programmers want to use generic non-app-sensitive > libraries to deserialize JSON into structs or objects or database records= or > whatever, and if you send a 78-digit number that will usually break. So = as > long as you have pre-agreement and a flexible enough library, you=E2=80= =99re > probably good. This is the main reason I thought I-JSON was worth defini= ng, > to maximize the chance that you can use a nice simple library at both end= s > and have the lowest possible chance of breakage. -T +1. I think we've reached a conclusion. It's time to confirm it. I believe that conclusion is: RFC4627 is what it is, we can't agree exactly on what that is, and while we can explain some/many of the ways that it's been interpreted, we really need a very-likely-to-interop subset (even or more than one such subsets) of the JSON defined in that RFC. Nico -- From markus.lanthaler@gmx.net Fri Jul 12 02:41: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 D643921F8F09 for ; Fri, 12 Jul 2013 02:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_SORBS_WEB=0.619] 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 ura-BsMASQSH for ; Fri, 12 Jul 2013 02:41:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id A09C621F926E for ; Fri, 12 Jul 2013 02:41:25 -0700 (PDT) Received: from Vostro3500 ([178.115.249.113]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Mcmmn-1UfdKM0t5l-00HsLQ for ; Fri, 12 Jul 2013 11:41:23 +0200 From: "Markus Lanthaler" To: References: <20130711201340.17794.30434.idtracker@ietfa.amsl.com> In-Reply-To: <20130711201340.17794.30434.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2013 11:41:17 +0200 Message-ID: <00c501ce7ee3$f6b77fe0$e4267fa0$@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: Ac5+cy4Yf9Pg+mTbQ5ShiFYja2i5SAAcICJQ X-Provags-ID: V03:K0:ECiowylzyS+5L1tEe+leiEhpHVca/uv59LcCoapygjwyujfvPzs gjRwmLGhBLLiNg7xsTqTUYfKMoh7qAhGS0NVsWHBSxZdteM3QgrKEZC87ZUgW2EhmR1L6+G rE7XlF+nTeTfoS2fgDxlLai3pE4dKPk1UGlCQBsd2liCTdGYtZNMrB5QytuojgZ2xSC+23I qtC+9c0YbWYjtrP+rMFyQ== Subject: Re: [Json] I-D Action: draft-bray-i-json-00.txt 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, 12 Jul 2013 09:41:35 -0000 Tim, In your I-JSON draft you say If an I-JSON Message is an object, it MAY self-identify by including a member whose name is "urn:ietf:i-json" and whose value is an object, which MUST be the first member of the top-level object. Why MUST it be the first member? Would it cause interoperability problems if it would be the, e.g., third member? I don't think so. So I think a SHOULD (because it may allow certain optimizations) is probably the most we can say. -- Markus Lanthaler @markuslanthaler > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Thursday, July 11, 2013 10:14 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-bray-i-json-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The I-JSON Message Format > Author(s) : Tim Bray > Filename : draft-bray-i-json-00.txt > Pages : 5 > Date : 2013-07-11 > > Abstract: > I-JSON is a restricted profile of JSON designed to maximize > interoperability and increase confidence that software can process > it > successfully with predictable results. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bray-i-json > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-bray-i-json-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From cowan@ccil.org Fri Jul 12 08:35: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 177EA21F9E29 for ; Fri, 12 Jul 2013 08:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 du4XKksb24M1 for ; Fri, 12 Jul 2013 08:35:24 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B2A4221F9E15 for ; Fri, 12 Jul 2013 08:35:23 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UxfNN-00026v-QE; Fri, 12 Jul 2013 11:35:17 -0400 Date: Fri, 12 Jul 2013 11:35:17 -0400 From: John Cowan To: Stefan Drees Message-ID: <20130712153517.GC29600@mercury.ccil.org> References: <51D3C63C.5030703@cisco.com> <51D3DC41.4020808@drees.name> <20130703165810.GF32044@mercury.ccil.org> <51D50A46.6000501@drees.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D50A46.6000501@drees.name> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: Nico Williams , Paul Hoffman , Eliot Lear , "json@ietf.org WG" Subject: Re: [Json] Proposed minimal change for duplicate names in objects 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, 12 Jul 2013 15:35:35 -0000 Stefan Drees scripsit: > "lose" what? If this "anyone" (it) wants a self-describing robust form > to interchange data, it will annotate it with metadata accordingly, > publish the dictionary, or choose microxml or the like. "Deserves to lose" is an idiom meaning "deserves the unfortunate consequences of one's actions." > A say sensor automat observing some features, serializing the extracted > info into JSON and pushing this to another collecting automat first > finds some name for the subject ("Stefan") than estimates from > processing further, that this should be tagged with attribute A > ("male"), starts a json object (to wrap it), enters the first member > "Stefan":"male", eventualy pushes the json text part upstream, processes > next observation B "native German", notes it linked to the same subject > as member "Stefan": "native German" and pushes ... My view is that this application design (as opposed, say, to using an array of single-element objects) is an inappropriate way to use JSON, depending as it does on a feature (support for duplicate names) that is not widely provided. > Why not leave this possibility open, more human like bots might act > this way very conveniently, mixing some serial processing somewhere > along the way. It's not much more convenient than [{"Stefan" : "male}, {"Stefan" : "native German", ...], which is entirely safe. > That's very nice, John, thanks. But you gave it some thought, > backtracked mayb, edited and it is very deep nested for a record > missing the family name ;-) That could be some digested output of > the receiving end in my "HumBotTalk" scenario above. True. I wanted it to represent in a machine-processable way all the information in your version (which is not very machine-processable). -- Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, "The Nine Billion Names of God" John Cowan From presnick@qti.qualcomm.com Mon Jul 15 19:55: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 2901B21F8E1F for ; Mon, 15 Jul 2013 19:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.417 X-Spam-Level: X-Spam-Status: No, score=-106.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, 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 KScw+xF-Ir80 for ; Mon, 15 Jul 2013 19:55:49 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 00BD021F8D73 for ; Mon, 15 Jul 2013 19:55:48 -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=1373943349; x=1405479349; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=/Z3okpd2ca56PBnGoEsOJVIi/q1EhG7x4QaYsOwZItg=; b=jMEhS1vQ5zU1tUcbdClzb2yf6KDMyYlomFgMQRpjxtRqz4wCkTeERgx2 bEeM0xAscBa8QsSFb8J/q2ATsZy6ATDWlEJYiC9j3QAmBIJAwt2XVnpCb qLf+OYACbr+C4J7b8ubTrm2rTdZhX1R1/u+6kGtmykvpA9LtZw//dd6Jl M=; X-IronPort-AV: E=Sophos;i="4.89,673,1367996400"; d="scan'208";a="62847281" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 15 Jul 2013 19:55:46 -0700 X-IronPort-AV: E=Sophos;i="4.89,673,1367996400"; d="scan'208";a="515180133" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Jul 2013 19:55:46 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 15 Jul 2013 19:55:46 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 15 Jul 2013 19:55:46 -0700 Message-ID: <51E4B631.3050307@qti.qualcomm.com> Date: Mon, 15 Jul 2013 21:55:45 -0500 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: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [Json] Sticking to the current charter, virtual interim meeting, and discussion questions 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, 16 Jul 2013 02:55:53 -0000 Folks, What follows on the heels of this message are two messages from me with some questions that I hope will drive some of our outstanding issues toward consensus. At the least, I think that if we are able to get good discussion and conclusions on these, we'll know where we are at in the discussion. But these questions are designed to drive us toward consensus *on the chartered work of this working group*. In particular, I want our discussion on the list (and in Berlin) to center around our chartered work for the time being; I think it is currently inappropriate to start talking about rechartering to do other things. The chairs let me know that attendance in Berlin is going to be a bit spotty. Given that, I discussed with them the idea of having a interactive virtual interim meeting soon after Berlin. We'll use the time in Berlin to figure out how to make the virtual interim meeting most useful to the WG. Hopefully with discussion of the topics which you'll see in a moment, we'll have good input to the virtual interim. So, please take this opportunity to express your opinions on the issues in my subsequent messages and see if we can figure out reasonable paths to accomplishing our chartered work. (The are, BTW, discussion points, not test questions. :-) ) Let's delay any talk about rechartering until after we exhaust this conversation (at a minimum until after the virtual interim). Thanks, pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From presnick@qti.qualcomm.com Mon Jul 15 19:57: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 DF1EB11E817B for ; Mon, 15 Jul 2013 19:57:56 -0700 (PDT) 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 r0zcnqebsZtl for ; Mon, 15 Jul 2013 19:57:52 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id A618621F8C9D for ; Mon, 15 Jul 2013 19:57:52 -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=1373943472; x=1405479472; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=k0Y2UHY/XDFe6lxXpeXwlkcVTiEMPhTZlWcP4WdHBPo=; b=bnLdgczmJ6hg7bEX8HPLVGTBnMDeYYLxKyNpmu3WVDJdHMog73a5mPoW rdal16ZmjIeBCVGg/CvXxx+vOzEhyYEzPTaDkV/AM6Xsdhgxe3Ad9T5xE e/d3ysFCc/+VKxwfl2ji29Rxl1DgkAN/0x0kTsTYM0CMgbUFQCWVxNDh6 c=; X-IronPort-AV: E=Sophos;i="4.89,673,1367996400"; d="scan'208";a="47574185" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 15 Jul 2013 19:57:52 -0700 Received: from nasanexhc03.na.qualcomm.com ([172.30.48.26]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Jul 2013 19:57:51 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC03.na.qualcomm.com (172.30.48.26) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 15 Jul 2013 19:57:51 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 15 Jul 2013 19:57:51 -0700 Message-ID: <51E4B6AE.4040502@qti.qualcomm.com> Date: Mon, 15 Jul 2013 21:57:50 -0500 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: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [Json] Questions regarding duplicate names 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, 16 Jul 2013 02:57:57 -0000 There are folks who want the spec to forbid generators from emitting objects that contain duplicate names. There are folks who don't. To the folks that don't: a) Do you actually want a normative statement saying that generators MAY produce duplicate names? b) Do you want/are you OK with text that would give instructions about what parsers should do with duplicate names? If so: c) What should parsers do with duplicate names? Yes/No answers aren't terribly interesting to a) or b). Give some explanation. I'll likely have more questions to follow up on this topic, but these seem like a good starting point. I look forward to your answers. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From presnick@qti.qualcomm.com Mon Jul 15 19:58:29 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 1287B11E817B for ; Mon, 15 Jul 2013 19:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.432 X-Spam-Level: X-Spam-Status: No, score=-106.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, 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 jbOAlQHdtY0U for ; Mon, 15 Jul 2013 19:58:24 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id D8EC711E81B5 for ; Mon, 15 Jul 2013 19:58:24 -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=1373943504; x=1405479504; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=2Nnj+DttJvMRyw+uR+fV3ip78xbzC0/Aw8+/tTP0PMY=; b=GlNrw1MHHHhgNbwLzl9qxtD6hGPEiwwpsz1zwtWRzCUuhX3IuctCanrs FscTRWq0ctAZGIJzT0GmNRlUTzX4S3OsWvry7UPC6FQsc/mAlT/OEJ4Xq 67UIzaEiybu/fFBoKdlwD1L8UkxcwBeFxPj2Byksj8/QWEEl7vlXnEzLV w=; X-IronPort-AV: E=Sophos;i="4.89,673,1367996400"; d="scan'208";a="62942032" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 15 Jul 2013 19:58:20 -0700 X-IronPort-AV: E=Sophos;i="4.89,673,1367996400"; d="scan'208";a="515180940" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Jul 2013 19:58:20 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 15 Jul 2013 19:58:19 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 15 Jul 2013 19:58:19 -0700 Message-ID: <51E4B6CA.2040309@qti.qualcomm.com> Date: Mon, 15 Jul 2013 21:58:18 -0500 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: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 02:58:29 -0000 This is not *specifically* about the issue of json strings, though the answers here will certainly inform that discussion. What do you believe is the theoretical model of 4627 regarding the characters that make up JSON objects? The question is not the original design intention of the authors, but rather about how you see the model in how you (or others) are using the document. So: a) Is it a stream of theoretical characters interpreted as JSON objects? Or: b) Is it a stream of integers, interpreted as characters, and then interpreted as JSON objects? b') If it is a stream of integers, is there an upper limit on the value of those integers in a JSON object? (Interesting choices include 255, 65535, 4294967295. 32767 would be an example of an *extremely* interesting choice.) Or: c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as characters, and then interpreted as JSON objects? If you don't understand the distinction between any of the above choices, that's also an interesting piece of information. I look forward to your answers. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From tsaloranta@gmail.com Mon Jul 15 20:22: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 15BF521E8177 for ; Mon, 15 Jul 2013 20:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 hZdHYFR6f0P5 for ; Mon, 15 Jul 2013 20:22:55 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E8A3A21E80FC for ; Mon, 15 Jul 2013 20:22:54 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so132039wes.26 for ; Mon, 15 Jul 2013 20:22:54 -0700 (PDT) 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=tvX/GN8baev8jNIIu8k16QrY9lF0/fedm4YiYJbtf2g=; b=BQEFA7hguQNP+PRljIWAg4a50FgAg8cndJMgTm0kRFebP6lsUwWb7uTqPhOAvHRYMA 4NbVkfg86LssULlKcm2y4eYp06WlpEnIbj9T6nP5rdhhnqmH0ijF89FMqo2cB8pkWRcL XuInDwsFTB0xy132lvevuhyAcdJPNBjYcWhcQcEBcSMfEKCYcwRacXDn8Nh1tRxbJVrr Uvc7TiAaeDsmafMGt1jNAMTdDBKG4+S2xRpguYd97srS9Qs3UgAgy5oP4iESnA/N5LWq 259/hi6jLBh5xjheK+hRRm8M5rPoM9EDIyKtpvXtmdsUae/1gauLqOioHkXkAzv3YFSz s+8g== MIME-Version: 1.0 X-Received: by 10.194.104.74 with SMTP id gc10mr33725885wjb.48.1373944974009; Mon, 15 Jul 2013 20:22:54 -0700 (PDT) Received: by 10.216.122.198 with HTTP; Mon, 15 Jul 2013 20:22:53 -0700 (PDT) In-Reply-To: <51E4B6AE.4040502@qti.qualcomm.com> References: <51E4B6AE.4040502@qti.qualcomm.com> Date: Mon, 15 Jul 2013 20:22:53 -0700 Message-ID: From: Tatu Saloranta To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7bf10b461deb5004e1987e37 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 03:22:56 -0000 --047d7bf10b461deb5004e1987e37 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 15, 2013 at 7:57 PM, Pete Resnick wrote: > There are folks who want the spec to forbid generators from emitting > objects that contain duplicate names. There are folks who don't. To the > folks that don't: > > a) Do you actually want a normative statement saying that generators > MAY produce duplicate names? > > b) Do you want/are you OK with text that would give instructions about > what parsers should do with duplicate names? If so: > > c) What should parsers do with duplicate names? > > Yes/No answers aren't terribly interesting to a) or b). Give some > explanation. > > I'll likely have more questions to follow up on this topic, but these seem > like a good starting point. > > I look forward to your answers. > > My point is that I do not see any need to produce duplicate names, but that requirement to detect and prevent such output can be unnecessarily expensive. So: (a) I would prefer SHOULD NOT produce, with a note that this may be either impractical, or acceptable to be left at discretion of caller (be it application or higher-level library/framework). Same goes for parsing. (b) I think it makes sense to suggest acceptable behaviors. But there are multiple ones, depending on processing style. I would even be ok with "implementation-dependant" choice. (c) Two common choices suggested have been "only use last one" and "fail". But I would add "expose any and all", as that is approach taken my many libraries, deferring actual handling to caller. Problem here, again, is that different processing models suggest different approaches. Full in-memory, whole-document handling processing can guarantee no duplicates behavior. Open-ended minimal-state parsing, generation work better with more laissez-faire approach. -+ Tatu +- > pr > > -- > Pete Resnick > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --047d7bf10b461deb5004e1987e37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 15, 2013 at 7:57 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
There are folks who want the spec to forbid = generators from emitting objects that contain duplicate names. There are fo= lks who don't. To the folks that don't:

=A0 =A0 a) Do you actually want a normative statement saying that generator= s MAY produce duplicate names?

=A0 =A0 b) Do you want/are you OK with text that would give instructions ab= out what parsers should do with duplicate names? If so:

=A0 =A0 c) What should parsers do with duplicate names?

Yes/No answers aren't terribly interesting to a) or b). Give some expla= nation.

I'll likely have more questions to follow up on this topic, but these s= eem like a good starting point.

I look forward to your answers.


My point is that I do no= t see any need to produce duplicate names, but that requirement to detect a= nd prevent such output can be unnecessarily expensive.

So:

(a) I would prefer SHOULD NOT produce, with a note th= at this may be either impractical, or acceptable to be left at discretion o= f caller (be it application or higher-level library/framework). Same goes f= or parsing.

(b) I think it makes sense to suggest acceptable = behaviors. But there are multiple ones, depending on processing style. I wo= uld even be ok with "implementation-dependant" choice.

(c) Two common choices suggested have been "only use last o= ne" and "fail". But I would add "expose any and all&quo= t;, as that is approach taken my many libraries, deferring actual handling = to caller.

Problem here, again, is that different processing models sug= gest different=A0 approaches. Full in-memory, whole-document handling proce= ssing can guarantee no duplicates behavior. Open-ended minimal-state parsin= g, generation work better with more laissez-faire approach.

-+ Tatu +-
=A0
<= span class=3D"HOEnZb"> pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

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

--047d7bf10b461deb5004e1987e37-- From nico@cryptonector.com Mon Jul 15 21:22: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 87EBA21F9EE9 for ; Mon, 15 Jul 2013 21:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 rJb604x7dUUU for ; Mon, 15 Jul 2013 21:22:34 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4FE21F85F4 for ; Mon, 15 Jul 2013 21:22:33 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 226071E05D for ; Mon, 15 Jul 2013 21:22:33 -0700 (PDT) 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=Ol77cN7Iktieduvv4+CB CcRt9dI=; b=kCDNGK/Uqljsc8XghLZgT1Pu7ytR/BZ2ut9cmjI3rAcREiFtFWcE lR7Zkmt4X0DL1b9FWZ5gI9TbVjm/QLOE7W7ApS+NLtAlTyFY27IJesKX8IthSPRC 1Mmlm/ARjgSW0aNyOpj1jGRYAah6/gUylZ4xSmHBPhg2GGP7STAu8I4= 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-a95.g.dreamhost.com (Postfix) with ESMTPSA id C800E1E05C for ; Mon, 15 Jul 2013 21:22:32 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so164329wev.16 for ; Mon, 15 Jul 2013 21:22:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2pFJZxTzlxHlP4rPJ5Lvt42EII6blROKoVH8xcA0CI4=; b=RITQA1jjLNGYwkeX6SDOln04ZZwG7js1UyI5Or2wzz+W64viSSC7a8unfl1v+sh17Y H5Ic4eIbFjI39h07DUpnLIAS7VWNYXXuxDdCahpW8NeGjfUDkPzT6nW/OxFxDzGOg1yJ aevn5U6980s6TsZa5A28KLjQO4EoE4G7dTD3qBC9hLcO+QHvnhWhf3UF2wIpYZFJg3tW RAjJSiPWSZaXc+BV7awk4ENycT6wEPoJhRqhXR9pvNLHa04W2iuW2u2TtdMC0qFauXkh DpeWSUxBlK6zlD5pD+3Ip5EbmpkAW1Rk1JhSnOz1DmMZeHpft0erJrQOZd/PJ1OxYLQa YYSg== MIME-Version: 1.0 X-Received: by 10.180.84.70 with SMTP id w6mr10822970wiy.36.1373948551423; Mon, 15 Jul 2013 21:22:31 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Mon, 15 Jul 2013 21:22:31 -0700 (PDT) In-Reply-To: <51E4B6AE.4040502@qti.qualcomm.com> References: <51E4B6AE.4040502@qti.qualcomm.com> Date: Mon, 15 Jul 2013 23:22:31 -0500 Message-ID: From: Nico Williams To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 04:22:39 -0000 On Mon, Jul 15, 2013 at 9:57 PM, Pete Resnick wrote: > There are folks who want the spec to forbid generators from emitting objects > that contain duplicate names. There are folks who don't. To the folks that > don't: > > a) Do you actually want a normative statement saying that generators MAY > produce duplicate names? No, it should be "SHOULD NOT produce duplicate names", with text explaining that for some implementation designs there may be no reasonable way to guarantee this. If we say "applications SHOULD NOT produce duplicate names" we cover more cases than if we say "generators SHOULD NOT ..." unless we take the generator to be or include what I'd call the 'application' in the streaming generator case. "MUST NOT" would work for me if the text allows it to be one, the other, or both, of application or generator in any given use case, that guarantees no dup names. Others may not want to go that far. E.g., that would cover an app I use that can a JSON array with a large number of objects, possibly via a streaming generator. The app makes sure that the data is well-formed, so there is never a case where duplicate names can arise. In the general case, however, it may be that neither the app nor the generator can guarantee a lack of dup names -- especially the generator. > b) Do you want/are you OK with text that would give instructions about > what parsers should do with duplicate names? If so: Not necessarily SHOULD nor MUST, for the reasons that Tatu gave (DoS attacks, minimal state streaming parsers). (As an aside, it's worth adding text regarding collision attacks on hash tables, to the security considerations section.) > c) What should parsers do with duplicate names? Undefined behavior, possibly configurable, with loud security considerations text warning applications about this. "Applications where authorization is separate from interpretation the authorization module SHOULD/MUST reject inputs with duplicate names (at least if they are relevant to authorization decisions)." Or even, "applications that use JSON values for making authorization decisions MUST reject inputs with duplicate names". Nico -- From derhoermi@gmx.net Tue Jul 16 07:49: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 EABB221E809B for ; Tue, 16 Jul 2013 07:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, 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 qWXZGbRIdCK0 for ; Tue, 16 Jul 2013 07:49:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 496A611E80D7 for ; Tue, 16 Jul 2013 07:49:05 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.29.232]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MJSuF-1V1ZX11b6B-0035LT; Tue, 16 Jul 2013 16:49:02 +0200 From: Bjoern Hoehrmann To: Pete Resnick Date: Tue, 16 Jul 2013 16:48:55 +0200 Message-ID: References: <51E4B6CA.2040309@qti.qualcomm.com> In-Reply-To: <51E4B6CA.2040309@qti.qualcomm.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:MJ9NWIPSPP7YrKaZtsNtZws0vp2SbxVYQLnQwfgRuI3dwnKUUt8 4/HbSlL/b9v4Q7ZmsnjH6Q9m3qgbMOBLMUkBSrd/iTCsekXcUyaAcJQY84ro/vjxiAtJxbq lLLjKTasI6E8WNY+Rpo7qHfoV62xZytMyKF+5NDty65heRCApLkt9rm5n+bCbZ8sHGOg0Nq Q99GnPFz5ujkkxB6SMGrA== Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 14:49:10 -0000 * Pete Resnick wrote: >This is not *specifically* about the issue of json strings, though the >answers here will certainly inform that discussion. > >What do you believe is the theoretical model of 4627 regarding the >characters that make up JSON objects? The question is not the original >design intention of the authors, but rather about how you see the model >in how you (or others) are using the document. So: The discussion in the Working Group has been aroung the data model for string literals, while the characters that make up JSON objects are `{` and `}` primarily. I believe there is rough consensus in the group to define that unpaired surrogate escapes in string literals do not make JSON documents malformed and non-conforming and point them out as an interoperability problem along with common and good coping strategies. > a) Is it a stream of theoretical characters interpreted as JSON >objects? Or: > > b) Is it a stream of integers, interpreted as characters, and then >interpreted as JSON objects? > b') If it is a stream of integers, is there an upper limit on >the value of those integers in a JSON object? (Interesting choices >include 255, 65535, 4294967295. 32767 would be an example of an >*extremely* interesting choice.) Or: > > c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as >characters, and then interpreted as JSON objects? At one level JSON documents are made of Unicode scalar values, that is what goes into encode_utf8(...) and what comes out of decode_utf8(...). They are often thought of as integers and as characters but that can be misleading at times; for instance, the Unicode specification calls some of the Unicode scalar values "non-characters" but often people include those when they say "characters". There is an uppler limit of U+10FFFF. In other words, the textual JSON syntax is a formal language over an alphabet that is a proper subset of the set of Unicode scalar values. That alphabet excludes integers like 0x0000 and 0xd800. I think that is all well-understood and undisputed in the Working Group. As an aside: There is one thing your message helped me appreciate better, in ecma- script `JSON.parse("\"\ud800\"") == JSON.parse("\"\\ud800\"")` is true and that is not quite in keeping with my answers above, but the domain of JSON.parse being a superset of the domain of encode_utf8(...) is a point too subtle to address 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 derhoermi@gmx.net Tue Jul 16 08:15: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 2B58521E8090 for ; Tue, 16 Jul 2013 08:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=-0.141, 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 H+Hhl8vPyoQk for ; Tue, 16 Jul 2013 08:15:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7B40321F9BC3 for ; Tue, 16 Jul 2013 08:15:53 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.29.232]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0Mdrph-1UmhKs0b3F-00PgtK; Tue, 16 Jul 2013 17:15:52 +0200 From: Bjoern Hoehrmann To: Pete Resnick Date: Tue, 16 Jul 2013 17:15:51 +0200 Message-ID: References: <51E4B6AE.4040502@qti.qualcomm.com> In-Reply-To: <51E4B6AE.4040502@qti.qualcomm.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:N0Fq4V3M1OSzDVqhlxyvoj9Jw0NLMbZi3nmJ1Lu3/kZsKMOUchj rj60oC07k1SbuKUEBOJ7loBY7S8gPAhJwh1sdHrPjukV/QlijntUVRY3KU9mZVAkhwmY6rE 4Wv3iiEjdpk0LOvuju+7WR53J17uHgNoL4vtFGdWF/s7UNjil0vdlQAyrXWHTPp4QkU3Ucu PYcfTDWi+dIWmqgi6UDGQ== Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 15:15:58 -0000 * Pete Resnick wrote: >There are folks who want the spec to forbid generators from emitting >objects that contain duplicate names. There are folks who don't. To the >folks that don't: > > a) Do you actually want a normative statement saying that >generators MAY produce duplicate names? > > b) Do you want/are you OK with text that would give instructions >about what parsers should do with duplicate names? If so: > > c) What should parsers do with duplicate names? I think the Working Group has developed a rough consensus to say that JSON documents with objects with duplicate names are a terrible idea, but they are not unconditionally in violation of the specification and no behavior is unconditionally required of recepients if they encounter such documents, and nobody would mind if the specification points out things like that many implementations always take the last value. The RFC2119 voodoo, if any, expressing the above is uninteresting. JSON is a little bit rough around the edges, as is common with widely used worse-is-better, good-enough, 80/20 style formats, and lacking in some areas, as is common with baseline interoperability formats, and it would be fair to assume that that is part of the reason why it has been successful; and even if Douglas Crockford had vowed to eternally curse anyone who ever dared to make documents with duplicate names or a parser that does not crash and burn when encountering such documents in a huge blinking box in all JSON documentation ever, the reality would not be very different from what it is now with respect to this issue. -- 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 Tue Jul 16 08:51:28 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 87B3C21F9F13 for ; Tue, 16 Jul 2013 08:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, 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 69ShwVw5M2Sz for ; Tue, 16 Jul 2013 08:51:24 -0700 (PDT) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id 144FC21E8090 for ; Tue, 16 Jul 2013 08:51:23 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id p14so579531vbm.32 for ; Tue, 16 Jul 2013 08:51:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=kV1Vu8v2uOjU/2DY9Zvb5XRNrhlmuZI6OTQq8XZ1+M4=; b=glKmE8PEBhfimEN/y+Bm8hTdqC+Ae5d90fG+wXgJ/L7qMK7NGvfPSAoxwgMbuDKJre dSoIgxbeEUI/2SxOLtqK/fZabDBpTRus4rzsQlHRAwgchTVlj2Ju8o3LjVVl6bssZcJt goowD12/rWwt1Tu/77RZnCkdiybfnlrenZt5Kfj7SXTVId89arUi8FwQ5mi4GLsOzzjB Nlqqi56YQm2Vr1JxWnZv9/+BaGU1TdjC2C4OtgJZqq51a9jPyYnn2aRk5xHBkCSC6osT NfGHhCeXThbK+vH5OWrIdLqUk6aqHJfoiwVxoQwsM8xxzoNC7pkEJupw+O1y1TOHQyNh zynw== MIME-Version: 1.0 X-Received: by 10.220.91.75 with SMTP id l11mr609901vcm.82.1373989883159; Tue, 16 Jul 2013 08:51:23 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Tue, 16 Jul 2013 08:51:22 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <51E4B6AE.4040502@qti.qualcomm.com> References: <51E4B6AE.4040502@qti.qualcomm.com> Date: Tue, 16 Jul 2013 08:51:22 -0700 Message-ID: From: Tim Bray To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7b344088e935d904e1a2f253 X-Gm-Message-State: ALoCoQkmIaJCGCpmg16HTOAtAFkSc83ZC+ZCSoACzkYnUqiuL/VMQDYcWlvLB2vSUv6nH2XoF1Zu Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 15:51:28 -0000 --047d7b344088e935d904e1a2f253 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2013 at 7:57 PM, Pete Resnick wr= ote: > a) Do you actually want a normative statement saying that generators > MAY produce duplicate names? > I speak from the constituency that uses JSON in APIs, and the only reason objects exist is to represent hash tables, database records, and the like. In these scenarios, dupes can never be useful and are always evidence of breakage, so please, a big =E2=80=9Cno=E2=80=9D. > b) Do you want/are you OK with text that would give instructions abou= t > what parsers should do with duplicate names? If so: > I suspect it will be hard to achieve consensus on this, and I=E2=80=99m not= sure how useful the effort is, since it will likely have little effect on existing implementations. > c) What should parsers do with duplicate names? > My preferred course of action would be for the receiver of dupe keys to treat this as an error and signal the breakage back to the sender. > > Yes/No answers aren't terribly interesting to a) or b). Give some > explanation. > > I'll likely have more questions to follow up on this topic, but these see= m > like a good starting point. > > I look forward to your answers. > > pr > > -- > Pete Resnick > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --047d7b344088e935d904e1a2f253 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 15, 2013 at 7:57 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
=C2=A0 =C2=A0 a) Do you a= ctually want a normative statement saying that generators MAY produce dupli= cate names?

I speak from the constituency that uses JS= ON in APIs, and the only reason objects exist is to represent hash tables, = database records, and the like. In these scenarios, dupes can never be usef= ul and are always evidence of breakage, so please, a big =E2=80=9Cno=E2=80= =9D.
=C2=A0
=C2=A0 =C2=A0 b) Do you want/are you OK with text that would give instructi= ons about what parsers should do with duplicate names? If so:

I suspect it will be hard to achieve consensus on th= is, and I=E2=80=99m not sure how useful the effort is, since it will likely= have little effect on existing implementations.
=C2=A0
=C2=A0 =C2=A0 c) What should parsers do with duplicate names?

My preferred course of action would be for the receiver of dup= e keys to treat this as an error and signal the breakage back to the sender.
=C2=A0

Yes/No answers aren't terribly interesting to a) or b). Give some expla= nation.

I'll likely have more questions to follow up on this topic, but these s= eem like a good starting point.

I look forward to your answers.
pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

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

--047d7b344088e935d904e1a2f253-- From tbray@textuality.com Tue Jul 16 08:56: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 92BA021F9ADA for ; Tue, 16 Jul 2013 08:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=-0.555, 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 7e974W3BdeAr for ; Tue, 16 Jul 2013 08:56:24 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 09BAD21F9A81 for ; Tue, 16 Jul 2013 08:56:23 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hr11so574278vcb.20 for ; Tue, 16 Jul 2013 08:56:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=FSM9J8y5i6oKvFYyaVkio2w1gozyB92/p64qrHTlEtk=; b=IXly8IHfqnUyGS3/IBGDmdIqTuBov9G/1upIsuorNt84krmsw75hJYWxn7d3Fe8lyS fc1vu19s4R95V7kJt9GdF/q/lSqIpb62Azt9GYpyJ4ZmZ+jEvaCp/3iFw+9khSsQVk0F 3LKN6/bvQJjhr/3X30kLToo8Z2ixm4ujnmGZubxhGqlvgneuWZoMncy1PoaTE1Ny7ILw LRTfvl1Iww7k/ZG+xspEobIbHr1tsKZ7fMBtE4pQpB+aqX0rfmDS0gxYXeccov9urveG 1+BuKsr5p/H0v8bZJCTMXqYITyZVXK/3abSlD9+Em0UzEJpn7yLzrxpjAqMzYNjn245H 1Kdg== MIME-Version: 1.0 X-Received: by 10.58.155.37 with SMTP id vt5mr654773veb.41.1373990183412; Tue, 16 Jul 2013 08:56:23 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Tue, 16 Jul 2013 08:56:23 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <51E4B6CA.2040309@qti.qualcomm.com> References: <51E4B6CA.2040309@qti.qualcomm.com> Date: Tue, 16 Jul 2013 08:56:23 -0700 Message-ID: From: Tim Bray To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7b67239aceb3c604e1a30465 X-Gm-Message-State: ALoCoQndKI6OUWeYBOr7Pf+NYT7+9bat9NaoYFBGIbg8jHs968Z79Slt99KPLR7GbLMKYDiKoNyA Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 15:56:34 -0000 --047d7b67239aceb3c604e1a30465 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2013 at 7:58 PM, Pete Resnick wr= ote: > What do you believe is the theoretical model of 4627 regarding the > characters that make up JSON objects? The question is not the original > design intention of the authors, but rather about how you see the model i= n > how you (or others) are using the document. So: > I believe the design intent of 4627 is that strings be used to contain, as it says explicitly and clearly in the introduction, sequences of Unicode characters. This is how it is universally interpreted by the large community of people who use JSON for network APIs and assume that the only useful purpose of strings is to contain Unicode text, and any instances of bit patterns that cannot be interpreted as ordinary unicode characters is simply an error. > a) Is it a stream of theoretical characters interpreted as JSON > objects? Or: > It should be a stream of Unicode characters. > b) Is it a stream of integers, interpreted as characters, and then > interpreted as JSON objects? > b') If it is a stream of integers, is there an upper limit on the > value of those integers in a JSON object? (Interesting choices include 25= 5, > 65535, 4294967295. 32767 would be an example of an *extremely* interestin= g > choice.) Or: > I wouldn=E2=80=99t worry about the use of unicode codepoints that could be characters but haven't been assigned yet. The chance of this happening by accident is low, and ignoring it future-proofs us against future Unicode releases. > c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as > characters, and then interpreted as JSON objects? > No, it is what the introduction of the RFC says it is, a sequence of Unicode characters. -T > > If you don't understand the distinction between any of the above choices, > that's also an interesting piece of information. > > I look forward to your answers. > > pr > > -- > Pete Resnick > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --047d7b67239aceb3c604e1a30465 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 15, 2013 at 7:58 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
What do you believe is the theoretical model= of 4627 regarding the characters that make up JSON objects? The question i= s not the original design intention of the authors, but rather about how yo= u see the model in how you (or others) are using the document. So:

I believe the design intent of 4627 is tha= t strings be used to contain, as it says explicitly and clearly in the intr= oduction, sequences of Unicode characters.=C2=A0=C2=A0=C2=A0 This is how it= is universally interpreted by the large community of people who use JSON f= or network APIs and assume that the only useful purpose of strings is to co= ntain Unicode text, and any instances of bit patterns that cannot be interp= reted as ordinary unicode characters is simply an error.
=C2=A0
=C2=A0 =C2=A0 a) Is it a stream of theoretical characters interpreted as JS= ON objects? Or:

It should be a stream o= f Unicode characters.
=C2=A0
=C2=A0 =C2=A0 b) Is it a stream of integers, interpreted as characters, and= then interpreted as JSON objects?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b') If it is a stream of integers, is there= an upper limit on the value of those integers in a JSON object? (Interesti= ng choices include 255, 65535, 4294967295. 32767 would be an example of an = *extremely* interesting choice.) Or:

I wouldn=E2=80=99t worry about the use of = unicode codepoints that could be characters but haven't been assigned y= et.=C2=A0 The chance of this happening by accident is low, and ignoring it = future-proofs us against future Unicode releases.
=C2=A0
=C2=A0=C2=A0 c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted= as characters, and then interpreted as JSON objects?
=
No, it is what the introduction of the RFC says it is, a seq= uence of Unicode characters. -T
=C2=A0

If you don't understand the distinction between any of the above choice= s, that's also an interesting piece of information.

I look forward to your answers.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

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

--047d7b67239aceb3c604e1a30465-- From presnick@qti.qualcomm.com Tue Jul 16 08:58: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 E10E221F9B40 for ; Tue, 16 Jul 2013 08:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.55 X-Spam-Level: X-Spam-Status: No, score=-104.55 tagged_above=-999 required=5 tests=[AWL=2.049, BAYES_00=-2.599, 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 fnwXtxmA0K9A for ; Tue, 16 Jul 2013 08:58:11 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 03A2721F9B5D for ; Tue, 16 Jul 2013 08:58:10 -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=1373990290; x=1405526290; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=dJY5v0X/Aw+78Z1PIx1kwRWmbOtgsWPLDN0dFycwMVI=; b=NqJzXHrjAGN82xqMzAUPmSJh2qfgmHs/QvNtXFBYgD8lUp12csbc6HNc slz+6rv27ZdVf7f4/jpq88IJeFv8PwVXCUAeyBOfHYwoLqJG1Ig+7V3Aw y+scPs8ODn+AiFmnSMIYTmT9t+VIm4uXGCWU7SLGC2jPMIMdOeBVg/pY5 w=; X-IronPort-AV: E=Sophos;i="4.89,677,1367996400"; d="scan'208";a="63052957" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 16 Jul 2013 08:58:09 -0700 X-IronPort-AV: E=Sophos;i="4.89,677,1367996400"; d="scan'208";a="505698398" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Jul 2013 08:58:09 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc15.na.qualcomm.com (129.46.52.215) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 16 Jul 2013 08:58:09 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 16 Jul 2013 08:58:08 -0700 Message-ID: <51E56D8F.3070201@qti.qualcomm.com> Date: Tue, 16 Jul 2013 10:58:07 -0500 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" References: <51E4B6AE.4040502@qti.qualcomm.com> In-Reply-To: <51E4B6AE.4040502@qti.qualcomm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 15:58:26 -0000 Wow. I must say that I'm very disappointed. We've had a few replying, but not answering the questions I asked. Let me start here, and I will answer some individual posts in a bit. *Please* try to answer the questions. They are designed to *change* the discussion, not repeat more of the circles this group has been going around. Please read carefully. On 7/15/13 9:57 PM, Pete Resnick wrote: > There are folks who want the spec to forbid generators from emitting > objects that contain duplicate names. There are folks who don't. To > the folks that don't: Note that I asked for the folks who *don't* object to generators emitting duplicate names to answer. > a) Do you actually want a normative statement saying that > generators MAY produce duplicate names? Tatu and Nico say that they want the document to say SHOULD NOT. But that's not what I asked. I asked if you thought that it should say MAY. I take it from their answers that they meant to say, "No, it should not say 'MAY produce duplicate names'". Tim said specifically "No". But I suspect that this means that they are folks who *want* the spec to forbid generators from emitting duplicate names. Do I have this correct? (Bjoern made some inappropriate conclusions about the consensus of the WG, ones that I suspect are actually false, but didn't answer the question at all.) > b) Do you want/are you OK with text that would give instructions > about what parsers should do with duplicate names? Here I did not ask about 2119 language. I asked whether we should be giving instructions at all to parsers. Only Tatu answered that we should. Tim made some comment about not thinking we will achieve consensus to do so, which again doesn't answer the question. > If so: > > c) What should parsers do with duplicate names? Tatu gave a few choices here, but expressed no preference. I'd like to hear what you think *should* be done. Nico gave no indication of what parsers should do. Tim wants such things rejected as an error. Bjoern didn't answer the question. Folks, I'm trying to get the WG to unwedge the conversation. If you don't want to participate in the conversations that I'm trying to start, that's entirely your choice. But please don't drift onto tangents. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From tbray@textuality.com Tue Jul 16 09:24: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 2003511E80F4 for ; Tue, 16 Jul 2013 09:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=-0.416, 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 WIkyBY0Z1rcL for ; Tue, 16 Jul 2013 09:24:26 -0700 (PDT) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id A823D11E80EA for ; Tue, 16 Jul 2013 09:24:26 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id d10so652851vea.24 for ; Tue, 16 Jul 2013 09:24:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=uefKxKnhDzHSGnrOQeCEXa9dLBzcdIvt6Xh89AT0+LE=; b=SArhW43igG4PWLtyV6O6Rz+owPxLzggi7olmxNP3/BT5sYQ5xoY2owkWSmL7WZKIFd hzSFW5Gwx7kmr7JvwKsHGgcvgrHOUE10ku3PSW6zcog/OaxLOVcsfrO5F3xyfgfenHOQ WEqb2ZFZJtJQiTVfGVavsfFV3BM9mgGwBrZqX2L3SwLTJXw8ZzRbNUAHHkVGJDTVSEi5 O4DpEqtJMzSLql1kh/BiDmqDnV8L04mHzRC8CG6CNIzjOnszEa1VSsHktizZfxoZmxyP FpCaqTHXz6ASAp8pRPo0MqcHPKESSF7y0GpB0C250B/76toh2bYIJD1DBqoejjTfPkIP t9Gw== MIME-Version: 1.0 X-Received: by 10.52.94.6 with SMTP id cy6mr541673vdb.108.1373991865983; Tue, 16 Jul 2013 09:24:25 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Tue, 16 Jul 2013 09:24:25 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <51E4B6CA.2040309@qti.qualcomm.com> References: <51E4B6CA.2040309@qti.qualcomm.com> Date: Tue, 16 Jul 2013 09:24:25 -0700 Message-ID: From: Tim Bray To: Pete Resnick Content-Type: multipart/alternative; boundary=20cf307abe9f18b53504e1a369b2 X-Gm-Message-State: ALoCoQliJE3jbUA+N88PFjx2RLQEMd/f/n7U9IyUfycUFygkQkCS1MBZb8/NR2sCQ80MBk1pcsFb Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 16:24:31 -0000 --20cf307abe9f18b53504e1a369b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, I guess I misinterpreted Pete's question. Let me try again. On Mon, Jul 15, 2013 at 7:58 PM, Pete Resnick wr= ote: > What do you believe is the theoretical model of 4627 regarding the > characters that make up JSON objects? c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as characters, and then interpreted as JSON objects? Yes. At greater length: The model I see is that the bit patterns in JSON texts exist to represent sequences of Unicode characters. There are a variety of ways of doing this (UTF-8/16/32), but they encode integers which are, in the case of UTF-8 and UTF-32, Unicode code points, and in the case of UTF-16, code points, and surrogate values which are then used to construct Unicode code points. When parsing JSON texts, all the =E2=80=9Csyntax=E2=80=9D characters ([{},"= :\] and whitespace) are ordinary unicode characters, so lexing/parsing into JSON objects, arrays, numbers, booleans, and strings is straightforward. Inside names and strings, I regard any sequence of bit patterns which are not readable as sequences of Unicode code points which represent characters as an error condition. > If you don't understand the distinction between any of the above choices, > that's also an interesting piece of information. > > I look forward to your answers. > > pr > > -- > Pete Resnick > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > ______________________________**_________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/**listinfo/json > --20cf307abe9f18b53504e1a369b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, I guess I misinterpreted Pete's question. Let me t= ry again.

On Mon, Jul 15, 2013 at 7:58 PM= , Pete Resnick <presnick@qti.qualcomm.com> wrote:
Yes.=C2=A0 At greater length:

The= model I see is that the bit patterns in JSON texts exist to represent=20 sequences of Unicode characters.=C2=A0 There are a variety of ways of doing= =20 this (UTF-8/16/32), but they encode integers which are, in the case of=20 UTF-8 and UTF-32, Unicode code points, and in the case of UTF-16, code=20 points, and surrogate values which are then used to construct Unicode=20 code points.=C2=A0 When parsing JSON texts, all the =E2=80=9Csyntax=E2=80= =9D characters=20 ([{},":\] and whitespace) are ordinary unicode characters, so lexing/p= arsing=20 into JSON objects, arrays, numbers, booleans, and strings is=20 straightforward.

Inside names and strings, I regard any sequence of bit patterns which are not readable as sequences of Unicode code=20 points which represent characters as an error condition.


<= div class=3D"gmail_quote">

If you don't understand the distinction between any of the above choice= s, that's also an interesting piece of information.

I look forward to your answers.
pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

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

--20cf307abe9f18b53504e1a369b2-- From presnick@qti.qualcomm.com Tue Jul 16 09:25: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 740FA21F9ED4 for ; Tue, 16 Jul 2013 09:25:56 -0700 (PDT) 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 iwcM73LjAhB6 for ; Tue, 16 Jul 2013 09:25:52 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 447D821F9A2E for ; Tue, 16 Jul 2013 09:25:52 -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=1373991952; x=1405527952; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ZDwJAROjqRlZsiGsifXzvLAd4mDk5fVnc3dRfIoN444=; b=lN1ZJz4iKqazF1F3WIUJ1L5eAC8PkKdCf6SkhLbvP3cZL2vaCtD0v9NB 6jb8B+F1i2mrucxlYQUKdr1YjTMCXw4k9IxYRbiH37jWGwJj2j6A8GTiT JtVEtV3CpaNU27z1afGwBAQzsmO3HvG1IYVwixmzLxRYNAIj1+oaykOjR g=; X-IronPort-AV: E=Sophos;i="4.89,678,1367996400"; d="scan'208";a="47606586" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 16 Jul 2013 09:25:51 -0700 X-IronPort-AV: E=Sophos;i="4.89,677,1367996400"; d="scan'208";a="505708554" Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Jul 2013 09:25:51 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc13.na.qualcomm.com (172.30.48.20) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 16 Jul 2013 09:25:50 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 16 Jul 2013 09:25:50 -0700 Message-ID: <51E5740D.7020902@qti.qualcomm.com> Date: Tue, 16 Jul 2013 11:25:49 -0500 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" References: <51E4B6CA.2040309@qti.qualcomm.com> In-Reply-To: <51E4B6CA.2040309@qti.qualcomm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 16:25:56 -0000 On 7/15/13 9:58 PM, Pete Resnick wrote: > This is not *specifically* about the issue of json strings, though the > answers here will certainly inform that discussion. > > What do you believe is the theoretical model of 4627 regarding the > characters that make up JSON objects? The question is not the original > design intention of the authors, but rather about how you see the > model in how you (or others) are using the document. So: > > a) Is it a stream of theoretical characters interpreted as JSON > objects? Or: > > b) Is it a stream of integers, interpreted as characters, and then > interpreted as JSON objects? > b') If it is a stream of integers, is there an upper limit on > the value of those integers in a JSON object? (Interesting choices > include 255, 65535, 4294967295. 32767 would be an example of an > *extremely* interesting choice.) Or: > > c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as > characters, and then interpreted as JSON objects? > > If you don't understand the distinction between any of the above > choices, that's also an interesting piece of information. > > I look forward to your answers. It's clear from Bjoern and Tim's answers that I was not clear. I thought I was clear, but they didn't answer the questions I asked at all. So let me try to be clearer: 1. The questions are not about strings in JSON. If you answer about strings, you haven't understood the questions. The questions are about the JSON object itself. I understand that strings appear in JSON objects. But I am not asking about something that is special about strings as against the rest of the JSON object. I am asking about the JSON object. 2. I am not asking about the design intention of 4627. If you tell me what you think the design intention of 4627 is, you haven't understood the questions. I am asking about your view of the theoretical model. 3. The questions are not about Unicode codepoints. You will not see the words "Unicode" or "codepoints" in the questions. 4. The questions are not looking for your opinion of what others think. They ask what *your* answers to the questions are. Resist the temptation to talk about other people's opinions. What are your thoughts? These are very theoretical questions. The answers are not directly going to tell us what text will go into an Internet draft. But I do think this will help get us to something useful. I again look forward to your answers. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nico@cryptonector.com Tue Jul 16 09:26: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 5B9F921E8089 for ; Tue, 16 Jul 2013 09:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=-0.126, 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 7K9cTMpcVBGH for ; Tue, 16 Jul 2013 09:26:51 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8181511E80F7 for ; Tue, 16 Jul 2013 09:26:51 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id B3B6F163F for ; Tue, 16 Jul 2013 09:26:50 -0700 (PDT) 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=JQnt/Gq83w46d4L5/Z6V 6si1KaA=; b=CxJehUuHqrXz+SbEbhxECPthCTCvUPLrZd7npZMI+TixvD3DR4Z4 eIFQAw0FXydBsMhPst0ydXoTogkDlY7FyD+77u5OYqugZVt6myQkzxI2v1Nwx4Rb gCekkELE7WGI4zlptQUfeBDhkr0Xk7kdebX2C//Rpsbjm4406nSBK+o= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 5AB651634 for ; Tue, 16 Jul 2013 09:26:50 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so832473wev.30 for ; Tue, 16 Jul 2013 09:26:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=99i5yJNK0G89ZTGmj3CsETf1jl4wQGkzOPWH4uEmbjo=; b=HdgJPKf83DY0a7DpuyAN2iLIrAir+m0mBXpmg+Q/+c1XkQLzcbO5TzsH21llSCAjP7 ISQiMXQzII17Q/L0fBvZbeIFo7C1eQ/UNGUwng+LRktduJYnCYpFeXL0xUj9hjxTlLva CdYk00y/dCcqydGojba5BvbNIovsoRuFW9PDtK2xa19J2/p1yO/KpTqBIoab0TwMazj0 9FXNo3rFueQjelKHAiBJJmb+pJSNX7qy0mfUxo3NZxtDZj3bMRiT9u/pUbJm2WL9LknL jN3JnunOWOyCK0qA2sJMKn2tvN1OlBov9JReJj188VvPeYokOj8ZiPPwoE0VWzmu1wZC +8cg== MIME-Version: 1.0 X-Received: by 10.180.185.176 with SMTP id fd16mr1770837wic.20.1373992008901; Tue, 16 Jul 2013 09:26:48 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Tue, 16 Jul 2013 09:26:48 -0700 (PDT) In-Reply-To: <51E56D8F.3070201@qti.qualcomm.com> References: <51E4B6AE.4040502@qti.qualcomm.com> <51E56D8F.3070201@qti.qualcomm.com> Date: Tue, 16 Jul 2013 11:26:48 -0500 Message-ID: From: Nico Williams To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 16:26:56 -0000 On Tue, Jul 16, 2013 at 10:58 AM, Pete Resnick wrote: > On 7/15/13 9:57 PM, Pete Resnick wrote: >> a) Do you actually want a normative statement saying that generators >> MAY produce duplicate names? > > Tatu and Nico say that they want the document to say SHOULD NOT. But that's > not what I asked. I asked if you thought that it should say MAY. I take it > from their answers that they meant to say, "No, it should not say 'MAY > produce duplicate names'". Tim said specifically "No". But I suspect that > this means that they are folks who *want* the spec to forbid generators from > emitting duplicate names. Do I have this correct? Well, OK, "MAY" is not the same as "SHOULD NOT", but it seemed close enough because "SHOULD NOT" with text explaining *why* one might nonetheless go ahead, in this case, seems to cover the reasons for the MAY. In any case, you got your answer: no one seems to want that MAY. Nico -- From nico@cryptonector.com Tue Jul 16 09:43: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 DBADB11E80F6 for ; Tue, 16 Jul 2013 09:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=-0.571, 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 mjdamfM3+B5I for ; Tue, 16 Jul 2013 09:43:23 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id DA84F11E80EE for ; Tue, 16 Jul 2013 09:43:22 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id A0196674060 for ; Tue, 16 Jul 2013 09:43:22 -0700 (PDT) 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=mDVOhsUzs5OyyQjGJ3aC WBimPyg=; b=X2vXle+u54IOBVGwZMa4iGJOp3l60LX6OgFmOXrmYLHL0W9AUpw/ IT/QqQ2hQdljhDBNt7eDxb5+bIWfROkHaz+xJJDogQNJTua4XUcreVMgkjab4nyv 1z1YV9ltGgBDY3pxnjl4UOiJ/X9e6gyTLTs5hLDtNnA5BdIkvy6Blw8= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 295C8674059 for ; Tue, 16 Jul 2013 09:43:21 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so925281wiw.13 for ; Tue, 16 Jul 2013 09:43:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IZBLWUsMmkJlG5uHgKgIYxYx/jzI7QwqTWTnO1lZFnk=; b=CjczcrUeJ7DmVHUp0817g4NcAVdiTjdRbBGYpvIvbC+M7s4WyAYkhpLyoMJTGRcFod RcDTykKrsxfpWnabBVjwEj0yXQQ474n4SMnzVLS0Mzny6pwK/2mdiF1Z8urZT706ofy8 31H3ivgkvaIJowYAETR+d+E9WJm+PKE3guV5RzUIBMlmqhF+WGpl+P4H1LdDrOxU9It+ Eltk8oOzKfnY2abMfT6IZnrf8Rdqhs3ebRQfFHS+B3DhD4AWABINFZEKSlC3m0/HSef+ osxJp4MgerszAIQ7wXCoFo7++lG29brskBr1QU067UtXQx7vzSP27Eb7IhSCwW5XJrqi LniQ== MIME-Version: 1.0 X-Received: by 10.180.107.167 with SMTP id hd7mr1763707wib.33.1373993000589; Tue, 16 Jul 2013 09:43:20 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Tue, 16 Jul 2013 09:43:20 -0700 (PDT) In-Reply-To: <51E4B6CA.2040309@qti.qualcomm.com> References: <51E4B6CA.2040309@qti.qualcomm.com> Date: Tue, 16 Jul 2013 11:43:20 -0500 Message-ID: From: Nico Williams To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 16:43:28 -0000 On Mon, Jul 15, 2013 at 9:58 PM, Pete Resnick wrote: > This is not *specifically* about the issue of json strings, though the > answers here will certainly inform that discussion. > > What do you believe is the theoretical model of 4627 regarding the > characters that make up JSON objects? The question is not the original > design intention of the authors, but rather about how you see the model in > how you (or others) are using the document. So: > > a) Is it a stream of theoretical characters interpreted as JSON objects? What does "theoretical characters" mean? > Or: > > b) Is it a stream of integers, interpreted as characters, and then > interpreted as JSON objects? A JSON document is a textual object, specifically one that can be presented to humans safely (e.g., no binary non-textual data must appear in the encoded form). The text in question should be Unicode text. A UTF for JSON documents is not required, and one could use any UTF, or even any other codeset, provided that data is not lost. (E.g., if you escape all JSON string contents that can't be represented in EBCDIC, then output a JSON document in EBCDIC, then you should be able to parse it back into a faithful internal representation of the darned thing.) > b') If it is a stream of integers, is there an upper limit on the > value of those integers in a JSON object? (Interesting choices include 255, > 65535, 4294967295. 32767 would be an example of an *extremely* interesting > choice.) Or: It's Unicode data. In any UTF the highest code point value would be 0x10FFFF. As to what appears on the wire/disk/screens/whatever, that depends on the UTF chosen. UTF-8 is a sequence of bytes, so the highest valued byte that can appear would be... what, 0xF4? Perhaps I'm misunderstanding the question. > c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as > characters, and then interpreted as JSON objects? Yes, see above. Nico -- From nico@cryptonector.com Tue Jul 16 09:46: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 3601A21E8050 for ; Tue, 16 Jul 2013 09:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=-0.124, 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 wRhuDDt4WrVJ for ; Tue, 16 Jul 2013 09:46:31 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 53D3521E8083 for ; Tue, 16 Jul 2013 09:46:31 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 257E7350084 for ; Tue, 16 Jul 2013 09:46:31 -0700 (PDT) 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=7IoRSwOtvVrNvEac88SN HDaSsro=; b=jdIWgKoNC4snhmv8IumERh1EfnWuX9I89ixpsqYt6ABk22qTzTEN ZVi94H84U2dFwdGNwI4byvZRS12MHakiE2XBCr9HyI9TStouGGf6JtFWqDsAubnX 2kIEjRRXdr5GyeC5pXacJJOxYOAXQQ4Yn8jRWhUljJKCypy0FMmcTK4= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id C248235007F for ; Tue, 16 Jul 2013 09:46:30 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so3853770wgg.1 for ; Tue, 16 Jul 2013 09:46:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q1BUTt0G4h3h/jXHDnYMkfioLrYCtUYZvb/p8rd8WP0=; b=SqWvh4hdL7wYbrbepSclM80M1W0xmxLx/dm7pdazett3D5F2E/h2SgvmFZD2facb4m iOPzPevonNG+MgVyAeqqUfhjoicqHO+R9+OGX54IRdE7sXVM74Fr4+394chvDKmiFipL BEjrmCNrmCwu2cr4JortgaHz9lVH7dOkte55uA7hBSuaQbXugap9rNdM52KF/GMPWnoc 0+ZWA9vIqsW7QX5bgQ2+bL/TA17rWPr6JLXOanV2JWIgVplfiYcGMhP6pq9aaqqzrJsO MvZooaTmyI+eF8w91RkPKJB8Ouxo2ypHJRvJ/UWjoRBrOSf1QOYXVzBrjMRf5l7H3awC KsOA== MIME-Version: 1.0 X-Received: by 10.180.185.176 with SMTP id fd16mr1828637wic.20.1373993189306; Tue, 16 Jul 2013 09:46:29 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Tue, 16 Jul 2013 09:46:29 -0700 (PDT) In-Reply-To: References: <51E4B6AE.4040502@qti.qualcomm.com> <51E56D8F.3070201@qti.qualcomm.com> Date: Tue, 16 Jul 2013 11:46:29 -0500 Message-ID: From: Nico Williams To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 16:46:36 -0000 On Tue, Jul 16, 2013 at 11:26 AM, Nico Williams wrote: > In any case, you got your answer: no one seems to want that MAY. It's been pointed out that no one has spoken up in favor of that MAY *yet*. I don't think anyone will if there's a suitable construction that says "SHOULD NOT" that allows whatever it is they do. However, if we can't reach consensus on such a thing, then I suppose MAY is better than silence: it will drive the point home. So perhaps you can even score me as in support of that MAY, mildly anyways. From jhildebr@cisco.com Tue Jul 16 09:50: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 C0BF111E80F7 for ; Tue, 16 Jul 2013 09:50:39 -0700 (PDT) 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 EyUm84MwXyVN for ; Tue, 16 Jul 2013 09:50:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 766DC11E80F9 for ; Tue, 16 Jul 2013 09:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1717; q=dns/txt; s=iport; t=1373993429; x=1375203029; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=eG8TCJC4xXR3zy5VKQ+IlofWtkIQxRLME5bgMLH/B0s=; b=V5Lh9Ea0Uyp2RP3is7dQrylF0A+UKorNm2Kw8T4FWSwq7cGWj1O77SRv q1pWoIiRBjzDk5yii2CGh84nKQJSc48K+GmIAopRpVo7qg8gnY6QjXPMr DpUXun+QkohEKNPzxM5miiVLRpGi5R8OU89rto0YpaOjlZCTmhr/1HEJz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFALF45VGtJXG8/2dsb2JhbABagwaBA8FogRAWdIIjAQEBAwE6RA0BCA4UFEIlAgQBEgiIAga1fI8uOIMMbQOpKYMSgig X-IronPort-AV: E=Sophos;i="4.89,678,1367971200"; d="scan'208";a="235516501" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 16 Jul 2013 16:50:28 +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 r6GGoRYH028523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 16:50:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 11:50:27 -0500 From: "Joe Hildebrand (jhildebr)" To: Pete Resnick , "json@ietf.org" Thread-Topic: [Json] Questions regarding duplicate names Thread-Index: AQHOgdBK1uGi/HlU10SL9y2rObWSOZlndL0A Date: Tue, 16 Jul 2013 16:50:26 +0000 Message-ID: In-Reply-To: <51E4B6AE.4040502@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.129.24.87] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 16:50:39 -0000 I'm intentionally not reading the other replies yet, so I apologize if I'm being redundant. On 7/15/13 8:57 PM, "Pete Resnick" wrote: >There are folks who want the spec to forbid generators from emitting >objects that contain duplicate names. There are folks who don't. To the >folks that don't: > > a) Do you actually want a normative statement saying that >generators MAY produce duplicate names? No. As far as I can tell, the intended semantic was never that duplicate names were a goal, notwithstanding the claims of those who don't understand what "SHOULD" means in a spec that references RFC 2119. The intended semantic is what needs to be adequately described. > b) Do you want/are you OK with text that would give instructions >about what parsers should do with duplicate names? If so: Yes. I think that is important for interoperability. > c) What should parsers do with duplicate names? I think they should have some choices: 1) throw an error. This is important for certain security use cases. 2) use the last one. This is important for ECMA-262 interoperability. 3) report all of them. This MUST only be done by streaming parsers that can't maintain state. If parser events are reified into a concrete object, one of the first two choices MUST be made. Similar choices for generators. If you can, you MUST prevent duplicates. There MUST NOT be special APIs for sending duplicates (e.g. an API input that takes a multimap). Regardless of the choice made above, protocol designers MUST NOT rely on a particular implementation choice, so intentional duplication of keys is prohibited. --=20 Joe Hildebrand From jhildebr@cisco.com Tue Jul 16 09:52: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 C32A221F9302 for ; Tue, 16 Jul 2013 09:52:47 -0700 (PDT) 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 XzuFFgbQ1mfo for ; Tue, 16 Jul 2013 09:52:42 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DB46021F8653 for ; Tue, 16 Jul 2013 09:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=683; q=dns/txt; s=iport; t=1373993562; x=1375203162; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jGcTt5VSB3LXXnPwxgBgWP029XoLyNdR9Uw+GhQOBhI=; b=DOL7H0J2m/Dkf6zKBU6xqXSvChqC+oC7CSM5VNUGjHrA3vSw/6JlKoka WorI6H0O1XsMc04d4qrbCIJ7L+eSB2qZmQV9a2Md1R4dlZcsg5ObMCi0n pQXWF5La9YU3L2LihSIBQm3wRPE5FbwNQC7d1yh4jFejD8AcAitc9T+WH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocFAMN55VGtJV2Y/2dsb2JhbABagwaBA4I/vymBEBZ0giMBAQEDATo/EgEIIhRCJQIEAQ0FCIgCBrV9jy4xB4MMbQOpKYMSgig X-IronPort-AV: E=Sophos;i="4.89,678,1367971200"; d="scan'208";a="235518823" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 16 Jul 2013 16:52:41 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6GGqfIr012388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 16:52:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 11:52:41 -0500 From: "Joe Hildebrand (jhildebr)" To: Nico Williams , Pete Resnick Thread-Topic: [Json] Questions regarding duplicate names Thread-Index: AQHOgdBK1uGi/HlU10SL9y2rObWSOZlnCF6AgABs/wA= Date: Tue, 16 Jul 2013 16:52:40 +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.5.130515 x-originating-ip: [10.129.24.87] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 16:52:48 -0000 On 7/15/13 10:22 PM, "Nico Williams" wrote: >> c) What should parsers do with duplicate names? > >Undefined behavior, possibly configurable, with loud security >considerations text warning applications about this. "Applications >where authorization is separate from interpretation the authorization >module SHOULD/MUST reject inputs with duplicate names (at least if >they are relevant to authorization decisions)." Or even, >"applications that use JSON values for making authorization decisions >MUST reject inputs with duplicate names". I like using strong security language as a way of making this more clear. --=20 Joe Hildebrand From jhildebr@cisco.com Tue Jul 16 09:59:28 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 13EC121F9B18 for ; Tue, 16 Jul 2013 09:59:28 -0700 (PDT) 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 RYmnrby2-KH3 for ; Tue, 16 Jul 2013 09:59:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 788A321F9BD8 for ; Tue, 16 Jul 2013 09:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=907; q=dns/txt; s=iport; t=1373993962; x=1375203562; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zzB08rTbVT1uCI3vryFqdV/59wt9l6zBJ09nvyjXqmg=; b=a4jsM9iDLDlljJWkjthmp469M2bY9zcEom0LduFva4mG5Q+kKppucKOv /x5PFIijKvw//0tzMurZcTcwb1dOap29P/XwR8f+S/3JocUuDEYjVEFsM QaXihM9hnOLbcFo7Bf7+AHrGzYJet8ZKJ2OxkboIVlKqBmMZ8d7PYLJ1v o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYFAOx65VGtJV2c/2dsb2JhbABagwaBA4I/vymBEBZ0giUBBDo/EgEIIhRCJQIEAQ0FCIgItX+PLjEHgwxtA6kpgxKCKA X-IronPort-AV: E=Sophos;i="4.89,678,1367971200"; d="scan'208";a="235603671" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2013 16:59:22 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6GGxKE9010930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 16:59:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 11:59:21 -0500 From: "Joe Hildebrand (jhildebr)" To: Nico Williams , Pete Resnick Thread-Topic: [Json] Questions regarding duplicate names Thread-Index: AQHOgdBK1uGi/HlU10SL9y2rObWSOZlnyreAgAAIAwCAAAWAgP//nwGA Date: Tue, 16 Jul 2013 16:59:21 +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.5.130515 x-originating-ip: [10.129.24.87] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 16:59:28 -0000 On 7/16/13 10:46 AM, "Nico Williams" wrote: >On Tue, Jul 16, 2013 at 11:26 AM, Nico Williams >wrote: >> In any case, you got your answer: no one seems to want that MAY. > >It's been pointed out that no one has spoken up in favor of that MAY >*yet*. > >I don't think anyone will if there's a suitable construction that says >"SHOULD NOT" that allows whatever it is they do. > >However, if we can't reach consensus on such a thing, then I suppose >MAY is better than silence: it will drive the point home. So perhaps >you can even score me as in support of that MAY, mildly anyways. Those people should speak up then. I'm pretty strongly opposed to MAY without a valid technical argument. However, arguments that start with "people who can't read 4627 correctly do it today" haven't yet been compelling to me. --=20 Joe Hildebrand From johnl@iecc.com Tue Jul 16 10:21: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 BAE2E11E80D7 for ; Tue, 16 Jul 2013 10:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.774 X-Spam-Level: X-Spam-Status: No, score=-110.774 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 MvrLO86Jqm4b for ; Tue, 16 Jul 2013 10:20:57 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7554E21E8063 for ; Tue, 16 Jul 2013 10:20:56 -0700 (PDT) Received: (qmail 15014 invoked from network); 16 Jul 2013 17:20:55 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Jul 2013 17:20:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51e580f7.xn--btvx9d.k1307; i=johnl@user.iecc.com; bh=UCR3uzUweDV/pWk5b1GjzwxriHPhW26Ph/1PrSW+I+E=; b=HTsUQplJSwihagPDHrfyqbdGDq7M+RTq9jM/NcPPKzIMHWNzOFA7IhZkPZoyxXnBS+ejh3+6BW/mI+CPNF/srCgOk8egTnkF1tkjwHZFwSJhGDI8tz8QNEK45EwJkLcmKo5NokfIk0dlmH8eM2dhly//L5n0XVxKxZeWgUPr+lOw6JzqpVYduclZnVxVkOE5xKCjRrirg7smsdFbQH0L1LXmiHYnTRgJE812aup3B3soOQhhuV5Fz/EGJdM3tuSL DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51e580f7.xn--btvx9d.k1307; olt=johnl@user.iecc.com; bh=UCR3uzUweDV/pWk5b1GjzwxriHPhW26Ph/1PrSW+I+E=; b=NP19kjyYd83X1recJJs6+2SEfU7BHwO0AivaNye4ww74MzoqlMmyAJBsu6tk697qhU6ILYjlBUuSy0gYbPBdSPkAbyH9qZShV1pLk5iUmpjbmu6Vx2ka1vHwH0ysT6hyrFq55Q1vBlRgI3QuQOWHXJQCrMzHz1OY7CQPTTD9Lx2/1K+CftIqdLMTg3UmI4DvAt9SKX2xGNoiU+22dbjYBF0O5zqWKkRP9NO/4HWHv5R/1SPkeZYVFfjj3HxU5Heq Date: 16 Jul 2013 17:20:33 -0000 Message-ID: <20130716172033.55901.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: <51E4B6AE.4040502@qti.qualcomm.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: presnick@qti.qualcomm.com Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 17:21:02 -0000 > a) Do you actually want a normative statement saying that >generators MAY produce duplicate names? No. MAY means it's OK either way, and dups are clearly bad. I'd prefer SHOULD NOT, noting that some generators may not have the necessary buffering to detect or delete dups. > b) Do you want/are you OK with text that would give instructions >about what parsers should do with duplicate names? If so: No. I'd prefer not to standardize bad behavior. Perhaps note that parsers should at least avoid crashing on dups and observe that many but not all parsers have historically used the last instance so generators can't count on it. R's, John From cowan@ccil.org Tue Jul 16 10:57: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 38D8321F8653 for ; Tue, 16 Jul 2013 10:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 YgY+hmPXDiwj for ; Tue, 16 Jul 2013 10:57:40 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id C7C6A21F9635 for ; Tue, 16 Jul 2013 10:57:39 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Uz9VJ-0004lJ-1y; Tue, 16 Jul 2013 13:57:37 -0400 Date: Tue, 16 Jul 2013 13:57:37 -0400 From: John Cowan To: Pete Resnick Message-ID: <20130716175736.GF1176@mercury.ccil.org> References: <51E4B6CA.2040309@qti.qualcomm.com> <51E5740D.7020902@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E5740D.7020902@qti.qualcomm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 17:57:45 -0000 Pete Resnick scripsit: > What do you believe is the theoretical model of 4627 regarding the > characters that make up JSON objects? The question is not the > original design intention of the authors, but rather about how you > see the model in how you (or others) are using the document. So: > > a) Is it a stream of theoretical characters interpreted as > JSON objects? Or: > > b) Is it a stream of integers, interpreted as characters, and > then interpreted as JSON objects? > b') If it is a stream of integers, is there an upper limit > on the value of those integers in a JSON object? (Interesting > choices include 255, 65535, 4294967295. 32767 would be an example > of an *extremely* interesting choice.) Or: > > c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted > as characters, and then interpreted as JSON objects? > > If you don't understand the distinction between any of the above > choices, that's also an interesting piece of information. Your question is ill-posed in at least two respects, and so people who have certain beliefs are trying to answer the question they think you meant to ask. (See "Geek Answer Syndrome".) 1) Your question does not make clear what "object" means. Do you mean whatever in JSON is not an array, string, number, or boolean? Or do you mean an entity body which purports to conform to RFC 4627? 2) Your question contains a presupposition, namely that such "objects" or entity bodies are composed of a stream of characters. In the case of objects-as-defined-in-the-RFC, I certainlly don't believe that and I don't think anyone does. In the case of entity bodies, I do believe it, but others may not. But taking your question at face value, my reply is the conjunction of (d1) and (d2) below: (d1) An "object", as defined in the JSON spec, is not a stream of characters. (d2) A JSON entity body has nothing to say about the characters which do indeed (so I believe) compose it. "Character" is an undefined term in RFC 4627, which dictates only what characters may appear and in what order. > I look forward to your answers. I look forward to a rephrasing of your question to eliminate the problems above. -- BALIN FUNDINUL UZBAD KHAZADDUMU cowan@ccil.org BALIN SON OF FUNDIN LORD OF KHAZAD-DUM http://www.ccil.org/~cowan From derhoermi@gmx.net Tue Jul 16 10:58: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 CD89821F9C12 for ; Tue, 16 Jul 2013 10:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.734 X-Spam-Level: X-Spam-Status: No, score=-2.734 tagged_above=-999 required=5 tests=[AWL=-0.135, 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 sREvCZq4hpWq for ; Tue, 16 Jul 2013 10:58:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id F28C611E80AD for ; Tue, 16 Jul 2013 10:58:28 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.29.232]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0M6fXs-1UBblD0QtQ-00wYmG; Tue, 16 Jul 2013 19:58:25 +0200 From: Bjoern Hoehrmann To: Pete Resnick Date: Tue, 16 Jul 2013 19:58:23 +0200 Message-ID: <61uau85mpjpj4900c4vb0ntm7e0mih4vi6@hive.bjoern.hoehrmann.de> References: <51E4B6CA.2040309@qti.qualcomm.com> <51E5740D.7020902@qti.qualcomm.com> In-Reply-To: <51E5740D.7020902@qti.qualcomm.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:frJcRaw+vC/EL4Gv5hR0C/poVgxOVlxSkalkPTMyFpPCymtbBi3 AGOt7CQuk1yvhaG1JZnKtVPvFGlnSRPlwJhqvYdedXWHb6bmjnbNkfBHsiwwyQIoQ4EIouL mWEeGjv5ScF/03gt7owZQixxlD7PixoTRkZ7jSFJXDEy3XokHH8FZe+4vlWxvVX+Dg7gXDB yJK4nilfhXZf24hGD88sg== Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 17:58:34 -0000 * Pete Resnick wrote: >On 7/15/13 9:58 PM, Pete Resnick wrote: >> This is not *specifically* about the issue of json strings, though the >> answers here will certainly inform that discussion. >> >> What do you believe is the theoretical model of 4627 regarding the >> characters that make up JSON objects? The question is not the original >> design intention of the authors, but rather about how you see the >> model in how you (or others) are using the document. So: >> >> a) Is it a stream of theoretical characters interpreted as JSON >> objects? Or: >> >> b) Is it a stream of integers, interpreted as characters, and then >> interpreted as JSON objects? >> b') If it is a stream of integers, is there an upper limit on >> the value of those integers in a JSON object? (Interesting choices >> include 255, 65535, 4294967295. 32767 would be an example of an >> *extremely* interesting choice.) Or: >> >> c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as >> characters, and then interpreted as JSON objects? >> >> If you don't understand the distinction between any of the above >> choices, that's also an interesting piece of information. >> >> I look forward to your answers. > >It's clear from Bjoern and Tim's answers that I was not clear. I thought >I was clear, but they didn't answer the questions I asked at all. So let >me try to be clearer: None of the choices comes close to how I see the model and I explained how I see it instead. The problem starts with your use of "JSON object". I see JSON objects as a data model concept, they are collections of pairs. That is how RFC 4627 defines the term "object". They aren't made up of characters. RFC 4627 defines how objects and arrays and other values are represented in textual form, but the options are all for the reverse. I try to think more abstractly than serial processes. There is no difference between `[1,2,3]` and the output of encode_utf8("[1,2,3]") to me as far as any model is concerned, so I would not put my name be- hind the "and then" options b) and c) for that reason alone. Your clarifications are just repetitions of what you wrote or implied, they are not adding new information that could help giving answers. -- 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 tsaloranta@gmail.com Tue Jul 16 11:09: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 E05BD11E80D5 for ; Tue, 16 Jul 2013 11:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=1.131, BAYES_00=-2.599, GB_I_LETTER=-2, 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 OQw+Xu23Kfhb for ; Tue, 16 Jul 2013 11:09:44 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C9A5B21E8054 for ; Tue, 16 Jul 2013 11:09:43 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so937483wes.34 for ; Tue, 16 Jul 2013 11:09:28 -0700 (PDT) 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=oVdxlNOd/XEW1Tuw6zY0RKJVO9xR+uOM+mmBPF/o/sA=; b=Zy9WUpd7bDOT+TsyGTr7AJxvIPrvbtrRQ4lMEL3CZrC2XVFcOIX8to/OLCI2ZRIVZv kFK6exeyVJqqknqrXgR/vsMQEWLrCtWvUVnFK0Sjopk9PG0DueEtLqGmyFGcQifTwOWj V9oQG0iEpvN+FJ/gWrXkDuszr7UHhnAwj3d303eyQtgzZgyjLqeVkQoGvKIjn7LID8nt KHSLFTtNbxR6eT0rDWfrGxaGdBgTWUYyQXZkoa59yS7Kt4/zKg4TfKQbddYwkWxRlo6Q R5IQEkcdOoEt6O3ShFIukLBFTgwizHbYxsj0YNYhBNyRvH6sPE7pEEcrWavwsW2ougD+ HN2Q== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr2105629wjx.84.1373998168011; Tue, 16 Jul 2013 11:09:28 -0700 (PDT) Received: by 10.216.122.198 with HTTP; Tue, 16 Jul 2013 11:09:27 -0700 (PDT) In-Reply-To: <51E5740D.7020902@qti.qualcomm.com> References: <51E4B6CA.2040309@qti.qualcomm.com> <51E5740D.7020902@qti.qualcomm.com> Date: Tue, 16 Jul 2013 11:09:27 -0700 Message-ID: From: Tatu Saloranta To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7bfcf01eb9fe5604e1a4e0af Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 18:09:45 -0000 --047d7bfcf01eb9fe5604e1a4e0af Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 16, 2013 at 9:25 AM, Pete Resnick wrote: > On 7/15/13 9:58 PM, Pete Resnick wrote: > >> This is not *specifically* about the issue of json strings, though the >> answers here will certainly inform that discussion. >> >> What do you believe is the theoretical model of 4627 regarding the >> characters that make up JSON objects? The question is not the original >> design intention of the authors, but rather about how you see the model in >> how you (or others) are using the document. So: >> >> a) Is it a stream of theoretical characters interpreted as JSON >> objects? Or: >> >> b) Is it a stream of integers, interpreted as characters, and then >> interpreted as JSON objects? >> b') If it is a stream of integers, is there an upper limit on the >> value of those integers in a JSON object? (Interesting choices include 255, >> 65535, 4294967295. 32767 would be an example of an *extremely* interesting >> choice.) Or: >> >> c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as >> characters, and then interpreted as JSON objects? >> >> If you don't understand the distinction between any of the above choices, >> that's also an interesting piece of information. >> >> I look forward to your answers. >> > > It's clear from Bjoern and Tim's answers that I was not clear. I thought I > was clear, but they didn't answer the questions I asked at all. So let me > try to be clearer: > > You have managed to rule all answers to all question you asked so far to be invalid. The only thing missing was actual letter grade for how close any of us were. Perhaps you should answer your own questions so that they satisfy criteria you have for answers. -+ Tatu +- --047d7bfcf01eb9fe5604e1a4e0af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 16, 2013 at 9:25 AM, Pete Resnick <= ;presnick@qt= i.qualcomm.com> wrote:
On 7/15/13 9:58 PM, Pete R= esnick wrote:
This is not *specifically* about the issue of json strings, though the answ= ers here will certainly inform that discussion.

What do you believe is the theoretical model of 4627 regarding the characte= rs that make up JSON objects? The question is not the original design inten= tion of the authors, but rather about how you see the model in how you (or = others) are using the document. So:

=A0 =A0 a) Is it a stream of theoretical characters interpreted as JSON obj= ects? Or:

=A0 =A0 b) Is it a stream of integers, interpreted as characters, and then = interpreted as JSON objects?
=A0 =A0 =A0 =A0 b') If it is a stream of integers, is there an upper li= mit on the value of those integers in a JSON object? (Interesting choices i= nclude 255, 65535, 4294967295. 32767 would be an example of an *extremely* = interesting choice.) Or:

=A0 =A0 c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as c= haracters, and then interpreted as JSON objects?

If you don't understand the distinction between any of the above choice= s, that's also an interesting piece of information.

I look forward to your answers.

It's clear from Bjoern and Tim's answers that I was not clear. I th= ought I was clear, but they didn't answer the questions I asked at all.= So let me try to be clearer:


You have managed to rule all answers t= o all question you asked so far to be invalid. The only thing missing was a= ctual letter grade for how close any of us were.
Perhaps you = should answer your own questions so that they satisfy criteria you have for= answers.

-+ Tatu +-

=A0
--047d7bfcf01eb9fe5604e1a4e0af-- From jhildebr@cisco.com Tue Jul 16 11:13: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 B385421F9E1A for ; Tue, 16 Jul 2013 11:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.812 X-Spam-Level: X-Spam-Status: No, score=-9.812 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_PART_OFF=1.574] 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 xP4CjckXq7+G for ; Tue, 16 Jul 2013 11:13:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 20ADB21F9702 for ; Tue, 16 Jul 2013 11:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1886; q=dns/txt; s=iport; t=1373998419; x=1375208019; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=jrcxVUlvqmCfhLKYqUgLBkO3u4hBvjwmzGgtr+jmfJY=; b=bZKmcGvBBuR7MoG9tecF3QzmVXWNXqt9bK6+vywPa5FXRW0BA4wq5LiT cIAjPNkmCP0fL5ZxTvJHKVGKR5QCVCy9mLuDx+Bp3v+/HJAbFo+W4HmjP rcKxebkb9uu6OFmQRPVFj/5CG8Elzm5f1mhkPGmrA9c0C5m9BP1sMMeGN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFANOM5VGtJV2b/2dsb2JhbABagwaBA8F0gREWdIIjAQEBAwE6RA0BCA4UFEIlAgQBEgiIAga2DY4ogQY4gwxtA6kpgxKBaT8 X-IronPort-AV: E=Sophos;i="4.89,678,1367971200"; d="scan'208";a="232552815" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 16 Jul 2013 18:13:38 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GIDZPY016900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 18:13:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 13:13:35 -0500 From: "Joe Hildebrand (jhildebr)" To: Pete Resnick , "json@ietf.org" Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOgdBbR+yeems0Nke/XW02cZd1o5lni/cA Date: Tue, 16 Jul 2013 18:13:34 +0000 Message-ID: In-Reply-To: <51E4B6CA.2040309@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.129.24.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <6AE99E52D1BE9842B453894158F274A9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 18:13:42 -0000 Again, replying before reading others' replies. On 7/15/13 8:58 PM, "Pete Resnick" wrote: > b) Is it a stream of integers, interpreted as characters, and then >interpreted as JSON objects? > b') If it is a stream of integers, is there an upper limit on >the value of those integers in a JSON object? (Interesting choices >include 255, 65535, 4294967295. 32767 would be an example of an >*extremely* interesting choice.) Or: I think this is the closest. The semantic model is that there is a stream of integers, each of which is less than 10FFFFh (1114111d), and is interpreted as a Unicode Scalar Value. That semantic may be rendered into octets on the wire using one of 5 encodings (UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE), of which UTF-8 is both preferred and the default. Inside of a JSON string (*char in the ABNF), aside from certain exceptions, these integers are intended to be rendered into appropriate objects in the local programming environment that typically have names like "Character", "char", etc. Of the exceptions, there are two types. Named escapes, such as \n, represent specific Unicode Scalar Values, and will usually be rendered into the local programming environment as a Character that represents that scalar value. Numeric escapes, such as \u005c, represent 16-bit code units that are intended to be interpreted similarly to UTF-16. When rendered in the local programming environment, they are to be hex-decoded, then all adjacent numeric escapes are to be UTF-16 decoded together, and the resulting Unicode Scalar Values are usually rendered to Characters as above. Expected behavior when errors in decoding are detected at either the first level (UTF-8 to integers) or the second (\u escapes to UTF-16 to integers) are not currently specified. --=20 Joe Hildebrand From cowan@ccil.org Tue Jul 16 11:17: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 EE0F321E8056 for ; Tue, 16 Jul 2013 11:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 y6CT8-+10AKT for ; Tue, 16 Jul 2013 11:17:54 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7EA21F9950 for ; Tue, 16 Jul 2013 11:17:54 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Uz9ow-00072G-27; Tue, 16 Jul 2013 14:17:54 -0400 Date: Tue, 16 Jul 2013 14:17:54 -0400 From: John Cowan To: Pete Resnick Message-ID: <20130716181753.GG1176@mercury.ccil.org> References: <51E4B6CA.2040309@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E4B6CA.2040309@qti.qualcomm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 18:17:59 -0000 Pete Resnick scripsit: > What do you believe is the theoretical model of 4627 regarding the > characters that make up JSON objects? Okay, having answered your question in my previous post, I am now going to ask and answer the question I believe you should have asked. If this be Geek Answer Syndrome, make the most of it. # What do you believe is the theoretical model of 4627 regarding the # elementary units of which JSON texts are composed? I should have said "texts" rather than "entity bodies" in my previous post, as "JSON text" is the term used by the RFC. > a) Is it a stream of theoretical characters interpreted as JSON > objects? Almost. I would reword this as follows: # Is it a sequence of abstract characters (see Unicode 6.2, section 3.4, # definition D7) interpreted as a JSON object or array? To which my answer is unequivocally "Yes". A JSON text is a sequence of characters. It may be encoded as a sequence of integers (which may be encoded as a sequence of bytes). It may also be encoded by a sequence of atoms, as when a JSON text is printed on a piece of paper. It may even be encoded by the *absence* of certain atoms, as when a JSON text is carved in stone. It may not be encoded at all (as far as we know), as when I only *imagine* a JSON text. But in all these cases, the text is a sequence of characters. > b) Is it a stream of integers, interpreted as characters, and > then interpreted as JSON objects? > b') If it is a stream of integers, is there an upper limit > on the value of those integers in a JSON object? (Interesting > choices include 255, 65535, 4294967295. 32767 would be an example of > an *extremely* interesting choice.) Or: No. A text may be encoded as a stream of integers, but also in other ways. > c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted > as characters, and then interpreted as JSON objects? No. A text may be encoded as a stream of 8-bit, 16-bit, or 32-bit words, but also in other ways. > If you don't understand the distinction between any of the above > choices, that's also an interesting piece of information. I believe I do understand the distinctions. -- De plichten van een docent zijn divers, John Cowan die van het gehoor ook. cowan@ccil.org --Edsger Dijkstra http://www.ccil.org/~cowan From jhildebr@cisco.com Tue Jul 16 11:25: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 4CF0A11E80F8 for ; Tue, 16 Jul 2013 11:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.501 X-Spam-Level: X-Spam-Status: No, score=-10.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 1zU03+KZN1dq for ; Tue, 16 Jul 2013 11:25:11 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 145DD21E8050 for ; Tue, 16 Jul 2013 11:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=839; q=dns/txt; s=iport; t=1373999111; x=1375208711; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FWR2vAGMJ4MV+PL8+WMT6QO6HToLPMoAgqY3s0aERJo=; b=grtJfBVI7W9MFjPOG9csYwrRUFz01DWfASu0Zz8zXfZJ2pzvawdPIN1L w23Kn36vMuM353HQXA3+8rzsC3fFKH7QyEi6mmO2szyfOG6d5AJyldciQ twIQyxMZe5LZ3v8zdyjvhQoAMNNzfF/LHfTwvwK9YDbGWTasutSQZnMon k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYFAN6O5VGtJV2b/2dsb2JhbABagwaBA4I/vzWBERZ0giUBBDo/EgEIIhRCJQIEAQ0FCIgIthGPLjEHgwxtA6kpgxKCKA X-IronPort-AV: E=Sophos;i="4.89,678,1367971200"; d="scan'208";a="235559440" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 16 Jul 2013 18:25:10 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GIPAhV012219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 18:25:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 13:25:10 -0500 From: "Joe Hildebrand (jhildebr)" To: John Cowan , Pete Resnick Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOgdBbR+yeems0Nke/XW02cZd1o5ln8cUA//+db4A= Date: Tue, 16 Jul 2013 18:25:09 +0000 Message-ID: In-Reply-To: <20130716181753.GG1176@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.5.130515 x-originating-ip: [10.129.24.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <5DFAD725D040544883C9707FDE0F5518@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 18:25:18 -0000 On 7/16/13 12:17 PM, "John Cowan" wrote: >A JSON text is a sequence of characters. It may be encoded as a >sequence of integers (which may be encoded as a sequence of bytes). >It may also be encoded by a sequence of atoms, as when a JSON text is >printed on a piece of paper. It may even be encoded by the *absence* >of certain atoms, as when a JSON text is carved in stone. It may not be >encoded at all (as far as we know), as when I only *imagine* a JSON text. >But in all these cases, the text is a sequence of characters. OK, I like this better than integers for the overall conceptual model. I think that's the right semantic, but in practice the next step in the programming of JSON is to start to think about Unicode Scalar Values in their integer embodiments. --=20 Joe Hildebrand From cowan@ccil.org Tue Jul 16 11:43: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 6A15821F8E2A for ; Tue, 16 Jul 2013 11:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 F8dCwNJstb1N for ; Tue, 16 Jul 2013 11:42:56 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 75EBC21F994B for ; Tue, 16 Jul 2013 11:42:56 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UzAD6-00015G-LW; Tue, 16 Jul 2013 14:42:53 -0400 Date: Tue, 16 Jul 2013 14:42:52 -0400 From: John Cowan To: Pete Resnick Message-ID: <20130716184250.GH1176@mercury.ccil.org> References: <51E4B6AE.4040502@qti.qualcomm.com> <51E56D8F.3070201@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E56D8F.3070201@qti.qualcomm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding duplicate names 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, 16 Jul 2013 18:43:02 -0000 Pete Resnick scripsit: > >There are folks who want the spec to forbid generators from > >emitting objects that contain duplicate names. There are folks who > >don't. To the folks that don't: > > Note that I asked for the folks who *don't* object to generators > emitting duplicate names to answer. Well, I fall into both camps, because you are equivocating again, not on the noun "object" this time, but on the verb "object". I do not object to generators emitting duplicate names, in the sense that I do not believe that RFC 4627bis should forbid them to do so. I do object to generators emitting duplicate names, in the sense that I believe it is a very bad idea for them to do so. (I've been told privately that I am being excessively snarky and legalistic. But I believe that anyone who insists on narrow interpretations to their questions had better ask carefully stated questions.) > > a) Do you actually want a normative statement saying that > >generators MAY produce duplicate names? No, I don't. That would mean that producing duplicate names is a worthy thing to do, and I believe it isn't. > Tatu and Nico say that they want the document to say SHOULD NOT. But > that's not what I asked. I asked if you thought that it should say > MAY. I take it from their answers that they meant to say, "No, it > should not say 'MAY produce duplicate names'". Tim said specifically > "No". But I suspect that this means that they are folks who *want* > the spec to forbid generators from emitting duplicate names. Do I > have this correct? I don't see how you could possibly believe that anyone who says SHOULD NOT really meant "forbidden", i.e. "MUST NOT". Unless you believe there is some shade of difference between saying that something is forbidden and saying that it MUST NOT be done, in which case I invite you to explain further. > > b) Do you want/are you OK with text that would give > >instructions about what parsers should do with duplicate names? > > Here I did not ask about 2119 language. So here you are distinguishing between "should" and "SHOULD". Alas, I do not know how to say what parsers should do (since they are not moral agents); I only know how to say what they MAY, SHOULD, MUST, SHOULD NOT, or MUST NOT do. I believe that (the authors of) RFC 4627bis should not say that parsers SHOULD do anything in particular in this circumstance. I believe that (the authors of) RFC 4627bis should say that parsers MAY report an error, ignore all dupes except the last, report all dupes, or anything else. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org The native charset of SMS messages supports English, French, mainland Scandinavian languages, German, Italian, Spanish with no accents, and GREEK SHOUTING. Everything else has to be Unicode, which means you get only 70 16-bit characters in a text instead of 160 7-bit characters. From presnick@qti.qualcomm.com Tue Jul 16 13:31:06 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 3E65021F9EC2 for ; Tue, 16 Jul 2013 13:31:06 -0700 (PDT) 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 p4DyoFnDfdlk for ; Tue, 16 Jul 2013 13:31:02 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACD121F9E98 for ; Tue, 16 Jul 2013 13:31:02 -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=1374006662; x=1405542662; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YUazrl2IfyOuohI1CoA4nYlat5NnYkUCPmX6zPBLbSg=; b=wF8z5p99nks/C52MQCngCTlW0+YRLzrJX5zhqHAlA6leDsYghDhUDTNY delGYRWnpQiDioPS32juDRhx3rbKG9h84479vX6unFq8JDpfQSZ6lam3b HB4hvUDO3Yg4xIqLl3h9/50s6xfqTeWCW0WMaXzv1RIJcgDUOldJ0CskF Y=; X-IronPort-AV: E=Sophos;i="4.89,679,1367996400"; d="scan'208";a="47621365" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 16 Jul 2013 13:30:59 -0700 X-IronPort-AV: E=Sophos;i="4.89,679,1367996400"; d="scan'208";a="480659062" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Jul 2013 13:30:59 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 16 Jul 2013 13:30:59 -0700 Message-ID: <51E5AD81.2090000@qti.qualcomm.com> Date: Tue, 16 Jul 2013 15:30:57 -0500 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: John Cowan References: <51E4B6CA.2040309@qti.qualcomm.com> <51E5740D.7020902@qti.qualcomm.com> <20130716175736.GF1176@mercury.ccil.org> In-Reply-To: <20130716175736.GF1176@mercury.ccil.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 20:31:06 -0000 Excellent. The latest messages, especially in this thread, are generating the conversation I was looking for. I already see some very interesting (and in a couple of cases, very surprising) comments. I start with John's message simply because it had a particularly interesting meta-bit that I thought it worth commenting about, but other messages are very useful as well. And I see some serious disagreements in some of the responses so far, and I think resolving those (or at least understanding why people have different models) will be useful. All good. So, in particular: On 7/16/13 12:57 PM, John Cowan wrote: > Your question is ill-posed in at least two respects, and so people who > have certain beliefs are trying to answer the question they think you > meant to ask. (See "Geek Answer Syndrome".) > I think the below are fair criticisms, though in some sense I did want to leave some concepts loose enough to see where people went with them so that we could come up with good common terminology. But to speak to each: > 1) Your question does not make clear what "object" means. Do you mean > whatever in JSON is not an array, string, number, or boolean? Or do you mean an entity body which purports to conform to RFC 4627? > In your subsequent message, you refer to "JSON text". I think that's pretty closer to what I intended, though I didn't want to over-constrain. But using "object" almost certainly over-constrains too, since it refers to one of the container types, but also might refer -- at least in my head -- to the generalized concept of a "JSON thingy". I certainly didn't mean "whatever in JSON is not an array, string, number, or boolean". So, take an email message for example. An email message can contain words and pictures and sounds and other theoretical objects. But for purposes of layer 7, and in the context of (for example) and RFC 822/5322 message, an Internet Mail Format message is a collection of text, and is a series of characters. Words and pictures and sounds can be represented (one layer up), and the entire message can be encoded (one layer down), but at the level of description of the spec, an email message *is* characters. I'm trying to get a grip on how people view JSON "thingys" (just to make up a new term) on the same level of description. > 2) Your question contains a presupposition, namely that such "objects" > or entity bodies are composed of a stream of characters. In the case > of objects-as-defined-in-the-RFC, I certainlly don't believe that and I > don't think anyone does. In the case of entity bodies, I do believe it, > but others may not. > So, do you take "objects" and "arrays" and other things inside a JSON thingy to be analogous to pictures and words and sounds in an email message, and therefore not be "composed of characters", but the overall JSON thingy *is* composed of characters? > But taking your question at face value, my reply is the conjunction of > (d1) and (d2) below: > > (d1) An "object", as defined in the JSON spec, is not a stream of > characters. > > (d2) A JSON entity body has nothing to say about the characters which do > indeed (so I believe) compose it. "Character" is an undefined term in RFC > 4627, which dictates only what characters may appear and in what order. > Reasonable answers. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From cowan@ccil.org Tue Jul 16 15:05:52 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 4DAE921F9590 for ; Tue, 16 Jul 2013 15:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 cGAq3FDXEDsi for ; Tue, 16 Jul 2013 15:05:47 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1624F21F99D2 for ; Tue, 16 Jul 2013 15:05:46 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UzDNP-0005dN-EL; Tue, 16 Jul 2013 18:05:43 -0400 Date: Tue, 16 Jul 2013 18:05:43 -0400 From: John Cowan To: Pete Resnick Message-ID: <20130716220543.GA26701@mercury.ccil.org> References: <51E4B6CA.2040309@qti.qualcomm.com> <51E5740D.7020902@qti.qualcomm.com> <20130716175736.GF1176@mercury.ccil.org> <51E5AD81.2090000@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51E5AD81.2090000@qti.qualcomm.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 16 Jul 2013 22:05:52 -0000 Pete Resnick scripsit: > So, do you take "objects" and "arrays" and other things inside a > JSON thingy to be analogous to pictures and words and sounds in an > email message, and therefore not be "composed of characters", but > the overall JSON thingy *is* composed of characters? Yes. I think it would be nice if JSON strings (unlike objects, arrays, booleans, and numbers) were composed of characters, but unfortunately I don't think they are: they are composed of UTF-16 code units. -- May the hair on your toes never fall out! John Cowan --Thorin Oakenshield (to Bilbo) cowan@ccil.org From ietf@augustcellars.com Tue Jul 16 18:14: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 C6E8621F8D96 for ; Tue, 16 Jul 2013 18:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.608 X-Spam-Level: X-Spam-Status: No, score=-3.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 TczyjyfG2smi for ; Tue, 16 Jul 2013 18:14:31 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 732B921F9AE7 for ; Tue, 16 Jul 2013 18:14:30 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 7D28D38F11; Tue, 16 Jul 2013 18:14:26 -0700 (PDT) From: "Jim Schaad" To: "'Pete Resnick'" , References: <51E4B6CA.2040309@qti.qualcomm.com> In-Reply-To: <51E4B6CA.2040309@qti.qualcomm.com> Date: Tue, 16 Jul 2013 18:13:24 -0700 Message-ID: <012301ce828a$d73d4e60$85b7eb20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEFMhZiRLbgt4ldopC+o54NkAhMEJr6sUKw Content-Language: en-us Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 01:14:36 -0000 > -----Original Message----- > From: json-bounces@ietf.org [mailto:json-bounces@ietf.org] On Behalf Of > Pete Resnick > Sent: Monday, July 15, 2013 7:58 PM > To: json@ietf.org > Subject: [Json] Questions regarding the text model in 4627 > > This is not *specifically* about the issue of json strings, though the answers > here will certainly inform that discussion. > > What do you believe is the theoretical model of 4627 regarding the > characters that make up JSON objects? The question is not the original design > intention of the authors, but rather about how you see the model in how you > (or others) are using the document. So: > > a) Is it a stream of theoretical characters interpreted as JSON objects? Or: > > b) Is it a stream of integers, interpreted as characters, and then interpreted > as JSON objects? > b') If it is a stream of integers, is there an upper limit on the value of > those integers in a JSON object? (Interesting choices include 255, 65535, > 4294967295. 32767 would be an example of an > *extremely* interesting choice.) Or: > > c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as characters, > and then interpreted as JSON objects? Specifically 8-bit octets. This is because I care about something that can be fed in to an encryption function and also converted into an in memory form that holds structure. Jim > > If you don't understand the distinction between any of the above choices, > that's also an interesting piece of information. > > I look forward to your answers. > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From ietf@lindenbergsoftware.com Tue Jul 16 19:19: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 DFED621F9BF7 for ; Tue, 16 Jul 2013 19:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 lCyeL-nYAOtQ for ; Tue, 16 Jul 2013 19:19:08 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8E621F9BAD for ; Tue, 16 Jul 2013 19:19:08 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:48534 helo=[10.0.1.4]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzHKc-002kFO-Uy; Tue, 16 Jul 2013 19:19:07 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Norbert Lindenberg In-Reply-To: <51E4B6CA.2040309@qti.qualcomm.com> Date: Tue, 16 Jul 2013 19:14:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1B055503-EBF4-419D-A4CA-64A53226552C@lindenbergsoftware.com> References: <51E4B6CA.2040309@qti.qualcomm.com> To: "json@ietf.org WG" X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 02:19:18 -0000 On Jul 15, 2013, at 19:58 , Pete Resnick = wrote: > What do you believe is the theoretical model of 4627 regarding the = characters that make up JSON objects? As discussed in the meantime, I read "JSON object" as "JSON text". > c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as = characters, and then interpreted as JSON objects? Close to c), although instead of the undefined term "characters" it = should say "Unicode code points" or "Unicode scalar values", depending = on the environment in which JSON is used. Most of the RFC is only = concerned with the stream of code points; the code units come into play = in sections 3 and 6. Norbert= From ietf@lindenbergsoftware.com Tue Jul 16 19:22: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 4054B21F85C3 for ; Tue, 16 Jul 2013 19:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ORPZa77Bqeuf for ; Tue, 16 Jul 2013 19:22:24 -0700 (PDT) Received: from mirach.lunarpages.com (mirach.lunarpages.com [216.97.235.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5188A21F9BF7 for ; Tue, 16 Jul 2013 19:22:24 -0700 (PDT) Received: from 50-0-136-241.dsl.dynamic.sonic.net ([50.0.136.241]:38576 helo=[10.0.1.4]) by mirach.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzHNk-002kim-Ie; Tue, 16 Jul 2013 19:22:20 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Norbert Lindenberg In-Reply-To: <20130716181753.GG1176@mercury.ccil.org> Date: Tue, 16 Jul 2013 19:22:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E4B6CA.2040309@qti.qualcomm.com> <20130716181753.GG1176@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mirach.lunarpages.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lindenbergsoftware.com X-Get-Message-Sender-Via: mirach.lunarpages.com: authenticated_id: ietf@lindenbergsoftware.com Cc: Norbert Lindenberg , Pete Resnick , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 02:22:30 -0000 On Jul 16, 2013, at 11:17 , John Cowan wrote: > It may also be encoded by a sequence of atoms, as when a JSON text is > printed on a piece of paper. It may even be encoded by the *absence* > of certain atoms, as when a JSON text is carved in stone. It may not = be > encoded at all (as far as we know), as when I only *imagine* a JSON = text. > But in all these cases, the text is a sequence of characters. I'd rather not go there. If we include JSON text printed in paper or = carved into stone into the scope of the RFC, then our interoperability = discussion will have to include the coverage of the Unicode character = set of available fonts, the print resolution, the quality of OCR = algorithms when applied to the Unicode character set, handling of = user-defined or not-yet-defined characters, Unicode normalization, and = probably a few additional factors. Compared to the data loss and data = corruption users would have to expect with these generators and parsers, = the limitations on number size or surrogate code points discussed so far = would be trivial. Norbert From jhildebr@cisco.com Tue Jul 16 23: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 5424621F9DCF for ; Tue, 16 Jul 2013 23:47:19 -0700 (PDT) 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 VyYHC+MO70H9 for ; Tue, 16 Jul 2013 23:47:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BB10521F9D93 for ; Tue, 16 Jul 2013 23:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1450; q=dns/txt; s=iport; t=1374043633; x=1375253233; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=janr+lfBbQlXWMmG+cUPJHFF6KMCvrkkWL8Y+ZhXO0M=; b=AtVQuWtiwV+Vad+0DiA9pvtRZAhVkTWHv0ZDAODbO3/ncoQ9Bk8SiXH2 eMxiMYLF7rmTO5skQE+Fva2W8r0P4JkHqh9YznciFDz9I4vw5iAvQfi6L V+LFvmd7zOE7KSP73TptfZL5U+uWLDiR1r0lmpBoONJSEt8+t5iPF0/V5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAHM75lGtJXHA/2dsb2JhbABagwY0T8IygQwWdIIlAQQ6PxIBCCIUQiUCBAENBQiICLVyjiyBETEHgwxuA6kpgxKBcTc X-IronPort-AV: E=Sophos;i="4.89,682,1367971200"; d="scan'208";a="235810143" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jul 2013 06:47:13 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6H6lCmG013645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 06:47:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 01:47:12 -0500 From: "Joe Hildebrand (jhildebr)" To: John Cowan , Pete Resnick Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOgnCdR+yeems0Nke/XW02cZd1o5loXUWA Date: Wed, 17 Jul 2013 06:47:12 +0000 Message-ID: In-Reply-To: <20130716220543.GA26701@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.5.130515 x-originating-ip: [10.21.71.235] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 06:47:19 -0000 On 7/16/13 4:05 PM, "John Cowan" wrote: >Pete Resnick scripsit: > >> So, do you take "objects" and "arrays" and other things inside a >> JSON thingy to be analogous to pictures and words and sounds in an >> email message, and therefore not be "composed of characters", but >> the overall JSON thingy *is* composed of characters? > >Yes. I think it would be nice if JSON strings (unlike objects, arrays, >booleans, and numbers) were composed of characters, but unfortunately >I don't think they are: they are composed of UTF-16 code units. Can you say more about this? I'm not seeing it yet. If I send you an octet stream that is identified (e.g. via an HTTP Content-Type header) as application/json that consists of the following octets (hex-encoded here for crystal clarity): 5b 22 f0 90 85 83 22 5d You can tell using section 3 that this is encoded using UTF-8. In my view, you have to UTF-8 decode before using the grammar to parse. If the parser generates strings in your programming language that are natively UTF-32, you would end up with an array containing one element that is a string consisting of one UTF-32 code unit. I don't see where there was ever a UTF-16 code point involved. If the parser generates JavaScript-style strings that are UTF-16 code units, then that is an implementation choice, not a property of the underlying semantic model. --=20 Joe Hildebrand From duerst@it.aoyama.ac.jp Wed Jul 17 00:32:08 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 5A5D521F9D87 for ; Wed, 17 Jul 2013 00:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.861 X-Spam-Level: X-Spam-Status: No, score=-102.861 tagged_above=-999 required=5 tests=[AWL=0.929, 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 bvFxzBvy7Zxz for ; Wed, 17 Jul 2013 00:32:01 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD0D21F8417 for ; Wed, 17 Jul 2013 00:32:00 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r6H7Vtx0016324; Wed, 17 Jul 2013 16:31:59 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 7950_37f0_f527a5a8_eeb2_11e2_8d87_001e6722eec2; Wed, 17 Jul 2013 16:31:55 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id E9845C00D3; Wed, 17 Jul 2013 16:30:05 +0900 (JST) Message-ID: <51E6485D.3040409@it.aoyama.ac.jp> Date: Wed, 17 Jul 2013 16:31:41 +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: Pete Resnick References: <51E4B6CA.2040309@qti.qualcomm.com> In-Reply-To: <51E4B6CA.2040309@qti.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 07:32:08 -0000 [independent reply, before reading other's replies] [Excludyng cases such as JSON printed out on paper or written on napkins.] I'd say that JSON is a stream of 8-bit/16-bit-/32-bit words, interpreted as a stream of integers, interpreted as a stream of characters. That's a combination of b) and c), which includes a). That's what you end up when carefully analyzing how characters are represented on computers with a generality that can deal with the range of phenomena found in character encoding. That's what all the relevant documents from the IETF, W3C, and Unicode explain (although they may differ in details or where they put the focus). However, to most intents and purposes, that's not what JSON should be concerned with, because that's common to all textual formats. It's just implicit when we say that UTF-8 is used for transfer over the Internet, or something along these lines. Regards, Martin. On 2013/07/16 11:58, Pete Resnick wrote: > This is not *specifically* about the issue of json strings, though the > answers here will certainly inform that discussion. > > What do you believe is the theoretical model of 4627 regarding the > characters that make up JSON objects? The question is not the original > design intention of the authors, but rather about how you see the model > in how you (or others) are using the document. So: > > a) Is it a stream of theoretical characters interpreted as JSON objects? > Or: > > b) Is it a stream of integers, interpreted as characters, and then > interpreted as JSON objects? > b') If it is a stream of integers, is there an upper limit on the value > of those integers in a JSON object? (Interesting choices include 255, > 65535, 4294967295. 32767 would be an example of an *extremely* > interesting choice.) Or: > > c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as > characters, and then interpreted as JSON objects? > > If you don't understand the distinction between any of the above > choices, that's also an interesting piece of information. > > I look forward to your answers. > > pr > From cowan@ccil.org Wed Jul 17 05:13: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 E965821F9E33 for ; Wed, 17 Jul 2013 05:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 RqmwZmC0eZ3L for ; Wed, 17 Jul 2013 05:13:34 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 944F921F9E28 for ; Wed, 17 Jul 2013 05:13:33 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1UzQbq-00059j-Ne; Wed, 17 Jul 2013 08:13:30 -0400 Date: Wed, 17 Jul 2013 08:13:30 -0400 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20130717121330.GA9412@mercury.ccil.org> References: <20130716220543.GA26701@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 Resnick , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 12:13:39 -0000 Joe Hildebrand (jhildebr) scripsit: > If I send you an octet stream that is identified (e.g. via an HTTP > Content-Type header) as application/json that consists of the following > octets (hex-encoded here for crystal clarity): > > 5b 22 f0 90 85 83 22 5d > > You can tell using section 3 that this is encoded using UTF-8. In my > view, you have to UTF-8 decode before using the grammar to parse. If the > parser generates strings in your programming language that are natively > UTF-32, you would end up with an array containing one element that is a > string consisting of one UTF-32 code unit. The trouble comes in when your parser receives these octets: 5b 22 5c 75 44 38 30 30 22 5d What should it do? It could report an implementation restriction, or it could return invalid UTF-32. Because unfortunately there's no doubt that this is valid JSON. -- Babies are born as a result of the John Cowan mating between men and women, and most http://www.ccil.org/~cowan men and women enjoy mating. cowan@ccil.org --Isaac Asimov in Earth: Our Crowded Spaceship From mamille2@cisco.com Wed Jul 17 06:57: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 ABEDB11E80F8 for ; Wed, 17 Jul 2013 06:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.932 X-Spam-Level: X-Spam-Status: No, score=-10.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 yHAU-67fj1fZ for ; Wed, 17 Jul 2013 06:57:14 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC6911E80A5 for ; Wed, 17 Jul 2013 06:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7178; q=dns/txt; s=iport; t=1374069434; x=1375279034; h=from:to:subject:date:message-id:mime-version; bh=G8Mh3RZF6DzWvAk4hVhr/quEldUeRm1iQpmWB2wNe3E=; b=OKYUSXlCfQoNjCxsm9QqKouyB6E65ZX0Iw3gdAAPkXjuymkdbSDQC64X mphh7jOK/xBnUKtwOpgcWcQ8J1d4p9zYqa3Uxo7Z1pATgirEm8NpG2J2L hk69bBmbGEFFfT6rqov3ujSv7jF2/taCJM/7khfrjtzZ9TInh32jBfnL5 0=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAI2h5lGtJV2Z/2dsb2JhbABagwaBBL9ZgnqBERZ0giUBBIELASomMCcEGwaIApVRoEOPSYNFbgOQD4Etl22DEoIo X-IronPort-AV: E=Sophos;i="4.89,684,1367971200"; d="p7s'?scan'208";a="235922635" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jul 2013 13:57:13 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6HDvDsl032348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Jul 2013 13:57:13 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 08:57:12 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org WG" Thread-Topic: Potential Agenda for IETF 87 Thread-Index: AQHOgvWJpEooi/j2GUy0gXColiZoKA== Date: Wed, 17 Jul 2013 13:57:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.90] Content-Type: multipart/signed; boundary="Apple-Mail=_239AD929-48D6-4E72-B366-D23CFD5E19AC"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Json] Potential Agenda for IETF 87 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, 17 Jul 2013 13:57:19 -0000 --Apple-Mail=_239AD929-48D6-4E72-B366-D23CFD5E19AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello all, The deadline for draft working group agendas is due today (24:00 UTC). = Given the recent discussions initiated by Pete, the chairs propose the = following agenda. Feedback is welcome. Thank you, - Paul Hoffman and Matt Miller -----BEGIN AGENDA----- JSON WG - IETF 87 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 Thursday, 1 August 2013, 09:00 - 10:20 CEST (07:00 - 08:20 UTC) 1. Administrivia and Agenda Bashing - = 5 min (Chairs) 2. WG Status - = 5 min (Chairs) 3. Scope and Approach of Important Issues - = 60 min (TBD) Determine as complete a list as possible of important issues to = address, and some approaches to go about addressing them 4. Virtual Interim Logistics - = 10 min (Chairs, AD) Discussion on the logistics of the proposed virtual interim; venue, = date, acceptable times -----END AGENDA----- --Apple-Mail=_239AD929-48D6-4E72-B366-D23CFD5E19AC Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MTcxMzU3 MTJaMCMGCSqGSIb3DQEJBDEWBBSjo/n1glxB3wIT0n8H54vMJ6Ro1jCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAEFF VQ3dXZyqQ7ubjlsV/GWRDpwJMMytv/HQpWHA4vzgQ52q398efm3b3X6jx/vKXWbqQVHGhrBNdvlF McxnVlgB3MgwdKoAcejPAcOWV+CcvxCqLQQGLZvNa/eYc9ymGqjg4zLufNNne6WiNxZIGVdQ82AX VqN4REkOjIGl4WkEo4tuqCbVDFyDhc/Q0nOuvyoYbma8NTgx7Li1Klh8VSRLvhmKSnY2rI27ZWSI 4bAeP8JWgN+fBkhRLisHqmXg03zu/LfOWqBaT+MjCRlwmNSZ7xoL/HqGsMeBzHQL6oBenUDZAXfw lMa0hbnrgWyruRIHP0RIFuqmb42V6I+Sb8sAAAAAAAA= --Apple-Mail=_239AD929-48D6-4E72-B366-D23CFD5E19AC-- From masinter@adobe.com Wed Jul 17 09:17:12 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 98AD411E80FA for ; Wed, 17 Jul 2013 09:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7NEcY5Oi7Wfz for ; Wed, 17 Jul 2013 09:17:07 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id DA31321F9F85 for ; Wed, 17 Jul 2013 09:17:06 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUebDgBbMD8p8eB454A22poqNzTl20oeo@postini.com; Wed, 17 Jul 2013 09:17:06 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6HGDbD8008081; Wed, 17 Jul 2013 09:13:38 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6HGH2w7002602; Wed, 17 Jul 2013 09:17:03 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Wed, 17 Jul 2013 09:17:02 -0700 From: Larry Masinter To: "Matt Miller (mamille2)" Date: Wed, 17 Jul 2013 09:17:02 -0700 Thread-Topic: [Json] Potential Agenda for IETF 87 Thread-Index: AQHOgwkS7zruB7T5P0upqgN93pGwnA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_jfjdlqdtgrpd2kxt3v2j6dd01374077822496emailandroidcom_" MIME-Version: 1.0 Cc: "json@ietf.org WG" Subject: Re: [Json] Potential Agenda for IETF 87 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, 17 Jul 2013 16:17:12 -0000 --_000_jfjdlqdtgrpd2kxt3v2j6dd01374077822496emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable agenda item 3 I suggest that spending enough time to resolve a few issues to get in room = rough consensus will be a better use of meeting time than a breadth first a= pproach where you get a complete a list of issues as possible. Sent from mobile Larry -- http://larry.masinter.net "Matt Miller (mamille2)" wrote: Hello all, The deadline for draft working group agendas is due today (24:00 UTC). Giv= en the recent discussions initiated by Pete, the chairs propose the followi= ng agenda. Feedback is welcome. Thank you, - Paul Hoffman and Matt Miller -----BEGIN AGENDA----- JSON WG - IETF 87 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 Thursday, 1 August 2013, 09:00 - 10:20 CEST (07:00 - 08:20 UTC) 1. Administrivia and Agenda Bashing - 5= min (Chairs) 2. WG Status - 5= min (Chairs) 3. Scope and Approach of Important Issues - 60= min (TBD) Determine as complete a list as possible of important issues to address,= and some approaches to go about addressing them 4. Virtual Interim Logistics - 10= min (Chairs, AD) Discussion on the logistics of the proposed virtual interim; venue, date= , acceptable times -----END AGENDA----- --_000_jfjdlqdtgrpd2kxt3v2j6dd01374077822496emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
agenda item 3

I suggest that spend= ing enough time to resolve a few issues to get in room rough consensus will= be a better use of meeting time than a breadth first approach where you ge= t a complete a list of issues as possible.

Sent from mobile Larry
--


"Matt Miller (mamille2)" <ma= mille2@cisco.com> wrote:

Hello all,

The deadline for draft working group agendas is due today (24:00 UTC). = ; Given the recent discussions initiated by Pete, the chairs propose the fo= llowing agenda.  Feedback is welcome.


Thank you,

- Paul Hoffman and Matt Miller

-----BEGIN AGENDA-----

JSON WG - IETF 87 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
Thursday, 1 August 2013, 09:00 - 10:20 CEST (07:00 - 08:20 UTC)


1. Administrivia and Agenda Bashing      &nbs= p;            &= nbsp;           &nbs= p;    -  5 min
   (Chairs)

2. WG Status          &nb= sp;            =             &nb= sp;            =            -  5 min<= br>    (Chairs)

3. Scope and Approach of Important Issues     &nbs= p;            &= nbsp;           - 60 min<= br>    (TBD)
   Determine as complete a list as possible of important issues t= o address, and
   some approaches to go about addressing them

4. Virtual Interim Logistics        = ;            &n= bsp;            = ;          - 10 min
   (Chairs, AD)
   Discussion on the logistics of the proposed virtual interim; v= enue, date,
   acceptable times

-----END AGENDA-----

 --_000_jfjdlqdtgrpd2kxt3v2j6dd01374077822496emailandroidcom_-- From masinter@adobe.com Wed Jul 17 09:57: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 CB41221F8206 for ; Wed, 17 Jul 2013 09:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9CoJ5ZhY223c for ; Wed, 17 Jul 2013 09:57:47 -0700 (PDT) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id CE36A21F85E8 for ; Wed, 17 Jul 2013 09:57:46 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUebNCOvr7UCoroOiqop8QtsJJZqwIB5M@postini.com; Wed, 17 Jul 2013 09:57:47 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6HGvhAI026460; Wed, 17 Jul 2013 09:57:43 -0700 (PDT) Received: from SJ1SWM219.corp.adobe.com (sj1swm219.corp.adobe.com [10.5.77.61]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6HGu66E013395; Wed, 17 Jul 2013 09:57:42 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%11]) with mapi; Wed, 17 Jul 2013 09:56:08 -0700 From: Larry Masinter To: Pete Resnick Date: Wed, 17 Jul 2013 09:56:08 -0700 Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: Ac6B0FyLdoll6qlxTemkoGBPiCKaGABPixf3 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_lp8f0bsq5ltgybca7pg4m5n61374079766782emailandroidcom_" MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 16:57:51 -0000 --_000_lp8f0bsq5ltgybca7pg4m5n61374079766782emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is a requirement to support all of these perspectives .... and the speci= fication should be explicit. The URI spec (and IRI after) were not and it led to no end of problems. Sent from mobile Larry -- http://larry.masinter.net Pete Resnick wrote: This is not *specifically* about the issue of json strings, though the answers here will certainly inform that discussion. What do you believe is the theoretical model of 4627 regarding the characters that make up JSON objects? The question is not the original design intention of the authors, but rather about how you see the model in how you (or others) are using the document. So: a) Is it a stream of theoretical characters interpreted as JSON objects? Or: b) Is it a stream of integers, interpreted as characters, and then interpreted as JSON objects? b') If it is a stream of integers, is there an upper limit on the value of those integers in a JSON object? (Interesting choices include 255, 65535, 4294967295. 32767 would be an example of an *extremely* interesting choice.) Or: c) Is it a stream of (8-bit/16-bit-/32-bit) words, interpreted as characters, and then interpreted as JSON objects? If you don't understand the distinction between any of the above choices, that's also an interesting piece of information. I look forward to your answers. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 _______________________________________________ json mailing list json@ietf.org https://www.ietf.org/mailman/listinfo/json --_000_lp8f0bsq5ltgybca7pg4m5n61374079766782emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It is a requirement to support all of these perspectives ..= .. and the specification should be explicit.

The U= RI spec (and IRI after) were not and it led to no end of problems.

Sent from mobile Larry
--
htt= p://larry.masinter.net

Pete Resnick <p= resnick@qti.qualcomm.com> wrote:

This is not *specifically* about = the issue of json strings, though the
answers here will certainly inform that discussion.

What do you believe is the theoretical model of 4627 regarding the
characters that make up JSON objects? The question is not the original
design intention of the authors, but rather about how you see the model in how you (or others) are using the document. So:

     a) Is it a stream of theoretical characters interp= reted as JSON
objects? Or:

     b) Is it a stream of integers, interpreted as char= acters, and then
interpreted as JSON objects?
         b') If it is a stream of i= ntegers, is there an upper limit on
the value of those integers in a JSON object? (Interesting choices
include 255, 65535, 4294967295. 32767 would be an example of an
*extremely* interesting choice.) Or:

     c) Is it a stream of (8-bit/16-bit-/32-bit) words,= interpreted as
characters, and then interpreted as JSON objects?

If you don't understand the distinction between any of the above
choices, that's also an interesting piece of information.

I look forward to your answers.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org= /mailman/listinfo/json
 --_000_lp8f0bsq5ltgybca7pg4m5n61374079766782emailandroidcom_-- From paul.hoffman@vpnc.org Wed Jul 17 10:15: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 17B1921F9F34 for ; Wed, 17 Jul 2013 10:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.359 X-Spam-Level: X-Spam-Status: No, score=-101.359 tagged_above=-999 required=5 tests=[AWL=-1.215, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 B+l3Ta9SOl1L for ; Wed, 17 Jul 2013 10:15:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8F61621F9F1F for ; Wed, 17 Jul 2013 10:15:48 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r6HHFid7065002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Jul 2013 10:15:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Wed, 17 Jul 2013 10:15:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8BB21131-8200-4416-8156-24C4E74EC74D@vpnc.org> References: To: Larry Masinter X-Mailer: Apple Mail (2.1508) Cc: "json@ietf.org WG" Subject: Re: [Json] Potential Agenda for IETF 87 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, 17 Jul 2013 17:15:49 -0000 On Jul 17, 2013, at 9:17 AM, Larry Masinter wrote: > 3. Scope and Approach of Important Issues = - 60 min > (TBD) > Determine as complete a list as possible of important issues to = address, and > some approaches to go about addressing them >=20 > I suggest that spending enough time to resolve a few issues to get in = room rough consensus will be a better use of meeting time than a breadth = first approach where you get a complete a list of issues as possible. We believe that very few of the active participants in the WG will = actually be in Berlin. Thus, getting consensus in the room has very = little value. We are planning a virtual interim for mid-August (see item = 4). Of course, we hope to have some of the issues resolved before the = virtual interim, depending on the results of Pete's recent threads. But = the current assumption is that this will take some work with lots of = people interacting, and we don't think Berlin will be that for this WG. --Matt Miller and Paul Hoffman= From jhildebr@cisco.com Wed Jul 17 11:10: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 49EAC21F9371 for ; Wed, 17 Jul 2013 11:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.212 X-Spam-Level: X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=-0.213, 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 txs3bv1UlRja for ; Wed, 17 Jul 2013 11:10:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC5721E808A for ; Wed, 17 Jul 2013 11:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1436; q=dns/txt; s=iport; t=1374084602; x=1375294202; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3EwU9FXa+mfm+Jgr7VtEivqaIv8DEA/HKCEzi7t7hqo=; b=lkdi4bAV4aBjTRSJlcSedVGWhadvzcSmd+K24SYkVlr5ukNp2zxvFcsy oi3HaizWP3LEM1a6X9Ed+rW+U0YBf6imG0iGqceVFCGh0q31sgha6s/ek qd9xz5hruM9GTunCkgwfYcRSjY8Cxf8C7hYnEMurChgCUgWDa81umjEwC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAbc5lGtJXHB/2dsb2JhbABagwaBBMJRgREWdIIlAQQ6PxIBCCIUQiUCBA4FCIgItW2PSTEHgw1uA6kpgxKCKA X-IronPort-AV: E=Sophos;i="4.89,686,1367971200"; d="scan'208";a="236049361" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jul 2013 18:10:01 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6HIA1ns001092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 18:10:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 13:10:01 -0500 From: "Joe Hildebrand (jhildebr)" To: John Cowan Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOgnCdR+yeems0Nke/XW02cZd1o5loXUWAgAC/xAD///8AgA== Date: Wed, 17 Jul 2013 18:10:00 +0000 Message-ID: In-Reply-To: <20130717121330.GA9412@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.5.130515 x-originating-ip: [10.129.24.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <7E20451900FD2045807E9930B77C3222@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 18:10:11 -0000 On 7/17/13 6:13 AM, "John Cowan" wrote: >The trouble comes in when your parser receives these octets: > >5b 22 5c 75 44 38 30 30 22 5d > >What should it do? It could report an implementation restriction, or >it could return invalid UTF-32. Because unfortunately there's no doubt >that this is valid JSON. In my worldview, this is an ill-formed escape sequence. Unicode 6.2 section 3.9, D75 says: "Isolated surrogate code units have no interpretation on their own", which seems pretty clear. I see the escape mechanism as being explicitly for "characters" (where I see "Unicode Scalar Value" as a more precise word for what the author likely intended), where those "characters" might be either from the BMP or not. The escaping mechanism is not for 16-bit code units, and I think that is made clear in the text of section 2.5, even if the ABNF has a bug that doesn't match the text. The parser might make one of several choices when it encounters an isolated surrogate code unit escape: - Error (useful for security-relevant things) - Replace with U+FFFD (only useful for strings intended for human consumption) - Maintain the data in a form that, while not valid Unicode, is still useful in some unspecified way (what ECMAscript does) Note: I'm trying to describe what my mental model is, not saying that everyone else should think this way. --=20 Joe Hildebrand From tbray@textuality.com Wed Jul 17 11:28: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 EF15021F9AB3 for ; Wed, 17 Jul 2013 11:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.426 X-Spam-Level: X-Spam-Status: No, score=-4.426 tagged_above=-999 required=5 tests=[AWL=-2.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 A-Qp10rZKmH2 for ; Wed, 17 Jul 2013 11:28:54 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id A0C9321E8086 for ; Wed, 17 Jul 2013 11:28:46 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id ht10so1642805vcb.32 for ; Wed, 17 Jul 2013 11:28:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=LDnigioYQpTr5TmJRCJhFWwKpjS4bTFI+ocQfmvmPzc=; b=QBeINjrzK9stRqwUMo7fYj1pAqwle9GGxcbemIl2P8VmXkuSYHsG1rcbL/fI9TxSs2 zCehwyv7UZzURDFFb9qQrgqH6dQxclpTZXD2nBLpM1zQqqAtyP+qIvNgrFVvrqFYEUFz RtM+mCnXsnuyfzeRPYZTzVs0WILT53VAXdEThIDNWX2Qy4/WeDFMyf/DGFi3M1YZV/uP glPnEyL7BVkZoOxY12FDBUCvg1JsK4vqk7FxJrpwpDauiZFN0ydkrDE6QKoh/pDqJZnO bTumrLOQPKMm+hQqTtf5PpmiwnMbo9uXzRhEtTBlxYMSDMK182fBeAvBZqwcM1b7X7fA dzlQ== MIME-Version: 1.0 X-Received: by 10.220.91.75 with SMTP id l11mr2523922vcm.82.1374085725828; Wed, 17 Jul 2013 11:28:45 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Wed, 17 Jul 2013 11:28:45 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <20130717121330.GA9412@mercury.ccil.org> Date: Wed, 17 Jul 2013 11:28:45 -0700 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b34408894633904e1b94390 X-Gm-Message-State: ALoCoQnsAGkBUXu14cyonx6g1b1w8K8YVSrllTptY9UzmZ8TXtVXwJgn87kZSIhUU5vK4RE6ddzc Cc: Pete Resnick , John Cowan , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 18:28:59 -0000 --047d7b34408894633904e1b94390 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My model is entirely consistent with Joe=E2=80=99s. -T On Wed, Jul 17, 2013 at 11:10 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 7/17/13 6:13 AM, "John Cowan" wrote: > > >The trouble comes in when your parser receives these octets: > > > >5b 22 5c 75 44 38 30 30 22 5d > > > >What should it do? It could report an implementation restriction, or > >it could return invalid UTF-32. Because unfortunately there's no doubt > >that this is valid JSON. > > In my worldview, this is an ill-formed escape sequence. Unicode 6.2 > section 3.9, D75 says: "Isolated surrogate code units have no > interpretation on their own", which seems pretty clear. > > I see the escape mechanism as being explicitly for "characters" (where I > see "Unicode Scalar Value" as a more precise word for what the author > likely intended), where those "characters" might be either from the BMP o= r > not. The escaping mechanism is not for 16-bit code units, and I think > that is made clear in the text of section 2.5, even if the ABNF has a bug > that doesn't match the text. > > > The parser might make one of several choices when it encounters an > isolated surrogate code unit escape: > > - Error (useful for security-relevant things) > - Replace with U+FFFD (only useful for strings intended for human > consumption) > - Maintain the data in a form that, while not valid Unicode, is still > useful in some unspecified way (what ECMAscript does) > > Note: I'm trying to describe what my mental model is, not saying that > everyone else should think this way. > > -- > Joe Hildebrand > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b34408894633904e1b94390 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My model is entirely consistent with Joe=E2=80=99s. -T
=


On Wed,= Jul 17, 2013 at 11:10 AM, Joe Hildebrand (jhildebr) <= jhildebr@cisco.com<= /a>> wrote:
On 7/17/13 6:13 AM, "John Cowan" &= lt;cowan@mercury.ccil.org>= wrote:

>The trouble comes in when your parser receives these octets:
>
>5b 22 5c 75 44 38 30 30 22 5d
>
>What should it do? =C2=A0It could report an implementation restriction,= or
>it could return invalid UTF-32. =C2=A0Because unfortunately there's= no doubt
>that this is valid JSON.

In my worldview, this is an ill-formed escape sequence. =C2=A0Unicode 6.2 section 3.9, D75 says: "Isolated surrogate code units have no
interpretation on their own", which seems pretty clear.

I see the escape mechanism as being explicitly for "characters" (= where I
see "Unicode Scalar Value" as a more precise word for what the au= thor
likely intended), where those "characters" might be either from t= he BMP or
not. =C2=A0The escaping mechanism is not for 16-bit code units, and I think=
that is made clear in the text of section 2.5, even if the ABNF has a bug that doesn't match the text.


The parser might make one of several choices when it encounters an
isolated surrogate code unit escape:

- Error (useful for security-relevant things)
- Replace with U+FFFD (only useful for strings intended for human
consumption)
- Maintain the data in a form that, while not valid Unicode, is still
useful in some unspecified way (what ECMAscript does)

Note: I'm trying to describe what my mental model is, not saying that everyone else should think this way.

--
Joe Hildebrand



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

--047d7b34408894633904e1b94390-- From jhildebr@cisco.com Wed Jul 17 12:21: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 7AA1621F9F1F for ; Wed, 17 Jul 2013 12:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 1zxfbS82Vl7z for ; Wed, 17 Jul 2013 12:21:18 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7A59A21F9AE9 for ; Wed, 17 Jul 2013 12:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3251; q=dns/txt; s=iport; t=1374088878; x=1375298478; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gWS028EMEQ+48YTPiyIvhEEEKmYHGACqTVNcsMqUh78=; b=VMrUhkgRgcU2Ydi3BwQbBJAgnbFOdpTFHjaqDXJEmHaMDINNoTyxyT9A wqfDs+37mI9n9jJ3v/uCbLDf1QrYlDPTVTk/zDrBB2dG9Nilfj9kJspkP HPHskHNHXVDGFRIfDpg+Gxe0pqB32BcrrCEp8MxVKfMiUGBaLoHu/V7n8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAPu5lGtJV2c/2dsb2JhbABagwY0UMEWgREWdIIjAQEBBAEBAWQHCxIBCA4KCksLJQIEDgUIiAgMtXcEj0kxB4MNbgOIb6A6gxKCKA X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208";a="236075156" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jul 2013 19:21:18 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6HJLH0q017262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 19:21:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 14:21:17 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOgnCdR+yeems0Nke/XW02cZd1o5loXUWAgAC/xAD///8AgIAAadiA//+qFQA= Date: Wed, 17 Jul 2013 19:21:16 +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.5.130515 x-originating-ip: [10.129.24.87] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <653D7DFF62AF7B478B5C2BD8A69E62A3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick , John Cowan , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 19:21:24 -0000 That model could encoded in ABNF that looks like this: char =3D unescaped / named-escape / bmp-escape / extended-escape unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF named-escape =3D escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 ) ; t tab U+0009 escape =3D %x5C ; \ bmp-escape =3D escape %x75 ( not-d-hex 3HEXDIG / "D" %x30-37 2HEXDIG ) not-d-hex =3D DIGIT / "A" / "B" / "C" / "E" / "F" ; hex, except for D extended-escape =3D high-surrogate low-surrogate high-surrogate =3D escape %x75 "D" high-hex 2HEXDIG high-hex =3D %x38-39 / "A" / "B" low-surrogate =3D escape %x75 "D" low-hex 2HEXDIG low-hex =3D "C" / "D" / "E" / "F" which is of course ugly, but absolutely explicit. I believe that the suggested error handling / recovery patterns are independent from the ABNF. On 7/17/13 12:28 PM, "Tim Bray" wrote: >My model is entirely consistent with Joe=B9s. -T > > > >On Wed, Jul 17, 2013 at 11:10 AM, Joe Hildebrand (jhildebr) > wrote: > >On 7/17/13 6:13 AM, "John Cowan" wrote: > >>The trouble comes in when your parser receives these octets: >> >>5b 22 5c 75 44 38 30 30 22 5d >> >>What should it do? It could report an implementation restriction, or >>it could return invalid UTF-32. Because unfortunately there's no doubt >>that this is valid JSON. > >In my worldview, this is an ill-formed escape sequence. Unicode 6.2 >section 3.9, D75 says: "Isolated surrogate code units have no >interpretation on their own", which seems pretty clear. > >I see the escape mechanism as being explicitly for "characters" (where I >see "Unicode Scalar Value" as a more precise word for what the author >likely intended), where those "characters" might be either from the BMP or >not. The escaping mechanism is not for 16-bit code units, and I think >that is made clear in the text of section 2.5, even if the ABNF has a bug >that doesn't match the text. > > >The parser might make one of several choices when it encounters an >isolated surrogate code unit escape: > >- Error (useful for security-relevant things) >- Replace with U+FFFD (only useful for strings intended for human >consumption) >- Maintain the data in a form that, while not valid Unicode, is still >useful in some unspecified way (what ECMAscript does) > >Note: I'm trying to describe what my mental model is, not saying that >everyone else should think this way. > >-- >Joe Hildebrand > > > >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json > > > > > > --=20 Joe Hildebrand From nico@cryptonector.com Wed Jul 17 12:42: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 9558E11E80E6 for ; Wed, 17 Jul 2013 12:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=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 IaVgLG-s4HxU for ; Wed, 17 Jul 2013 12:42:09 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 1102B21E804C for ; Wed, 17 Jul 2013 12:42:08 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 705DF36006A for ; Wed, 17 Jul 2013 12:42:08 -0700 (PDT) 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=fei/eKf8Xn0qLaYdGhle yOzKv4E=; b=bG3ZZAPLW+MqcmUU8m1AbROK55FuNg2mRfE9dU8MzRqD8bC5q1/6 DE5K/gUT8kgYeZ29VrvmNxK/AQYhYRf5LlUeK5fHWZoT4nbNiJ7Hjo0ho074KMK/ mR3mN5mQhgBjDhLihWqsx/w9AVSExilSqySbOgBs5W2vZ6NJ1irsYF8= 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-a86.g.dreamhost.com (Postfix) with ESMTPSA id 239B536006D for ; Wed, 17 Jul 2013 12:42:07 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so2168974wev.2 for ; Wed, 17 Jul 2013 12:42:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0y/klpignpVqVzdcGD4FvKM55LMSQYX/AOfOeVPN7cE=; b=abSlq/Rx7xVi3mGNsXDEV5RuxKNbnvnRHpC+2LW9R/c9n/Qbkyn3lcr7aXd7R9K94Z aGvG1/41H2+6MvH2NUHecKupIEtzLi2gAaJjkWu6c/cvBKmQ50io6ky73prwrvJ+2CGE Bbbbo+4ugyIx0jhAMOfSXZ/aq6WTfWIV4tNnKg2b6/GdaknsfzKJ/4nCL81LEbotvZYo AQLL+1yBSwQMGy6qsvJiE8aI8NqSxNAY3gzMRDbfqj5FE3NWnwTkmI+76pMRybq8uGHt OHr0HnjTdsZcRNHEVTPyF9Ee43yeb6dXFLIaQ5/d39TI+1f5lHV8cQY/6IrRK2D4z1CW f9AQ== MIME-Version: 1.0 X-Received: by 10.180.107.167 with SMTP id hd7mr5695536wib.33.1374090126485; Wed, 17 Jul 2013 12:42:06 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 17 Jul 2013 12:42:06 -0700 (PDT) In-Reply-To: References: <20130717121330.GA9412@mercury.ccil.org> Date: Wed, 17 Jul 2013 14:42:06 -0500 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: Pete Resnick , John Cowan , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 19:42:22 -0000 On Wed, Jul 17, 2013 at 1:10 PM, Joe Hildebrand (jhildebr) wrote: > On 7/17/13 6:13 AM, "John Cowan" wrote: >>The trouble comes in when your parser receives these octets: >> >>5b 22 5c 75 44 38 30 30 22 5d >> > > In my worldview, this is an ill-formed escape sequence. Unicode 6.2 > section 3.9, D75 says: "Isolated surrogate code units have no > interpretation on their own", which seems pretty clear. I agree as to unescaped code units. > I see the escape mechanism as being explicitly for "characters" (where I That's not clearer than anything else about JSON. It'd be entirely reasonable for the ECMAScript crowd to say "well, unpaired surrogates have to be sent as escaped code units, but obviously not as unescaped". That is, two sides of the argument would disagree over whether a string could contain unpaired surrogates yet agree that the JSON *text* containing such a string MUST NOT contain unpaired surrogates. > see "Unicode Scalar Value" as a more precise word for what the author > likely intended), where those "characters" might be either from the BMP or > not. The escaping mechanism is not for 16-bit code units, and I think > that is made clear in the text of section 2.5, even if the ABNF has a bug > that doesn't match the text. A literal reading of section 2.5 is that strings are of Unicode characters. And yet a large subset of the JSON ecosystem (ECMAScript and friends) doesn't agree. > The parser might make one of several choices when it encounters an > isolated surrogate code unit escape: > > - Error (useful for security-relevant things) > - Replace with U+FFFD (only useful for strings intended for human > consumption) OK, so this brings up questions that I've asked before: 1) Are escaped s supposed to be equivalent to their unescaped forms, for string and deep JSON text comparison purposes? 2) Must/should parsers that can natively represent a given escaped unescape it in the results in produces? 3) If an escaped appears in a JSON string that would result in invalid UTF-8/16/32 when unescaped, what should the parser do? RFC4627 says nothing about this. Much of the discussion seems to assume (or makes most sense to *me*when I assume that the commenters assume) that the answers to (1) and (2) are "yes". My answers would be "yes" to (1), "at the parser's/application's option" for (2), and "optionally reject or pass through in escaped form" for (3). Nico -- From tbray@textuality.com Wed Jul 17 12:49: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 7A53511E80DC for ; Wed, 17 Jul 2013 12:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.043 X-Spam-Level: X-Spam-Status: No, score=-4.043 tagged_above=-999 required=5 tests=[AWL=-1.067, 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 urPFUaFFOGst for ; Wed, 17 Jul 2013 12:49:04 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5215821F84A8 for ; Wed, 17 Jul 2013 12:49:04 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id c13so1836063vea.7 for ; Wed, 17 Jul 2013 12:49:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Cgd/wDvYncSCMx+XAhRF5Xpgy1etARqhNKgaafUw+bE=; b=ShpQb3FlMnz+JNuNpVJQAPPnsWNdCf4sM5YLXzO4BeGo0RHMUuJGfGYMwFcTbegawS MqF3AUaijLPoYpqczSep1R69UfjLeOxFs5XjpWUlet3IJ5hPTPNFXD2i1CPnjDHUkpJU vq2TFeADqKImdPDtHpkm3OWVd8kgS1B9TWlnTrpJp/wr+sUZJJWlHw8AKVCw8U83MrwU ZNvkJUrl4bbkFBS4vHLcPdWFr5kJSU5v+sdg7TKW9FBrZsJh0KhzHV2ocu+uG2lG+vvu to7iupyQoNFC9V7aqzG5TgGZKrVicwlQXqmEXIfWDP2nkKw9wyREtwQvcNlzYvbd9Aqp 5RLg== MIME-Version: 1.0 X-Received: by 10.221.36.4 with SMTP id sy4mr2740127vcb.11.1374090543741; Wed, 17 Jul 2013 12:49:03 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Wed, 17 Jul 2013 12:49:03 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <20130717121330.GA9412@mercury.ccil.org> Date: Wed, 17 Jul 2013 12:49:03 -0700 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=001a11339f38bfccea04e1ba6294 X-Gm-Message-State: ALoCoQkok5rWc9k+9ASBauFQWEolUWj6iq6tbAfzxFmYfK8i35RCQGfwsOOn7+GWQn1AB+rKy52z Cc: Pete Resnick , John Cowan , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 19:49:09 -0000 --001a11339f38bfccea04e1ba6294 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2013 at 12:42 PM, Nico Williams wrot= e: > A literal reading of section 2.5 is that strings are of Unicode > characters. And yet a large subset of the JSON ecosystem (ECMAScript > and friends) doesn't agree. > I admit that I don=E2=80=99t have a good feeling for the structure of the J= SON ecosystem. In the part of it that I can see (people who are using it to structure messages in application-level APIs), the belief that strings are for Unicode characters, and only for Unicode characters, and that anything in there that isn=E2=80=99t a Unicode character is a bug, is pretty well 10= 0%. BTW, I agree with Nico on #1 and #2, and while I=E2=80=99m grumpy about #3,= I suspect our charter doesn=E2=80=99t allow us to force-classify that situati= on as an error, which would be my preference. -T > OK, so this brings up questions that I've asked before: > > 1) Are escaped s supposed to be equivalent to their unescaped > forms, for string and deep JSON text comparison purposes? > > 2) Must/should parsers that can natively represent a given escaped > unescape it in the results in produces? > > 3) If an escaped appears in a JSON string that would result in > invalid UTF-8/16/32 when unescaped, what should the parser do? > > RFC4627 says nothing about this. Much of the discussion seems to > assume (or makes most sense to *me*when I assume that the commenters > assume) that the answers to (1) and (2) are "yes". > > My answers would be "yes" to (1), "at the parser's/application's > option" for (2), and "optionally reject or pass through in escaped > form" for (3). > > Nico > -- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11339f38bfccea04e1ba6294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 17, 2013 at 12:42 PM, Nico Williams <nic= o@cryptonector.com> wrote:
A literal reading of section 2.5 is that str= ings are of Unicode
characters. =C2=A0And yet a large subset of the JSON ecosystem (ECMAScript<= br> and friends) doesn't agree.

I admit= that I don=E2=80=99t have a good feeling for the structure of the JSON eco= system. In the part of it that I can see (people who are using it to struct= ure messages in application-level APIs), the belief that strings are for Un= icode characters, and only for Unicode characters, and that anything in the= re that isn=E2=80=99t a Unicode character is a bug, is pretty well 100%.
BTW, I agree with Nico on #1 and #2, and while I=E2=80=99m g= rumpy about #3, I suspect our charter doesn=E2=80=99t allow us to force-cla= ssify that situation as an error, which would be my preference. -T
=C2=A0
OK, so this brings up questions that I'v= e asked before:

1) Are escaped <thing>s supposed to be equivalent to their unescaped<= br> forms, for string and deep JSON text comparison purposes?

2) Must/should parsers that can natively represent a given escaped
<thing> unescape it in the results in produces?

3) If an escaped <thing> appears in a JSON string that would result i= n
invalid UTF-8/16/32 when unescaped, what should the parser do?

RFC4627 says nothing about this. =C2=A0Much of the discussion seems to
assume (or makes most sense to *me*when I assume that the commenters
assume) that the answers to (1) and (2) are "yes".

My answers would be "yes" to (1), "at the parser's/appli= cation's
option" for (2), and "optionally reject or pass through in escape= d
form" for (3).

Nico
--
___________________________________= ____________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--001a11339f38bfccea04e1ba6294-- From nico@cryptonector.com Wed Jul 17 13:13:04 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 0BF6421F9D30 for ; Wed, 17 Jul 2013 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.384, 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 HB7Z34-tCraR for ; Wed, 17 Jul 2013 13:12:59 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB2321F8F78 for ; Wed, 17 Jul 2013 13:12:59 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id C3A181638 for ; Wed, 17 Jul 2013 13:12:58 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=AKTo3DPnpOLVhM0mX3mrGcw1AfQ=; b=etPCDBcrkZg UNXG+cmQHNef2jnOskgT++bXQwCBtrWkV0eGV9oc11YMsbDyVKF+ngwHtmjp7asx 6vobQggR5d1SfucyMi8SoSIi084gUirsPDaZdr+KhNLYQ/700k+qDtmrMiOY0Oho Fj0vsIshilpZG2QIhOgeQnxVMOiNTVPg= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 499C11634 for ; Wed, 17 Jul 2013 13:12:58 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so2189343wes.38 for ; Wed, 17 Jul 2013 13:12:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fFL8/YiuXRwDvY+9msc0ISjpqnfw3wmJGWlrLU4vn0k=; b=X5iIXpjBRl4TsEac0EeG8DxIEYvFr6yJpGknsOyS3rOVI7toeeYIMg9oVKdygOfwIF cL3L0Z9+ElyA5LURE1eDHFBoeXO88tqP4gBtATKsGjKSiIBoGwYbKoXHDgicsqT/+QRg yNlggXXI/KS/eWOXJaMSzTAnWi3OfWiB07VH3+H9LLixtXKsJ8dYtcSLbbVkIdiULMiu mCxM/ncDYstiMtoQAA0CkVFFzhmiLV6/KSvK3pYeui2fTXC0QKT7IRjU/JM5vULWsFnU TEgV1HuYdmqW+QwQM0LGnSU5f2Y1i6pdz3HX/IRBAIrkPubdI7wJr5n6uoCxsDlk0CzH YLhg== MIME-Version: 1.0 X-Received: by 10.180.98.231 with SMTP id el7mr16834105wib.33.1374091975269; Wed, 17 Jul 2013 13:12:55 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 17 Jul 2013 13:12:55 -0700 (PDT) In-Reply-To: References: <20130717121330.GA9412@mercury.ccil.org> Date: Wed, 17 Jul 2013 15:12:55 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Pete Resnick , John Cowan , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 20:13:04 -0000 On Wed, Jul 17, 2013 at 2:49 PM, Tim Bray wrote: > On Wed, Jul 17, 2013 at 12:42 PM, Nico Williams > wrote: >> >> A literal reading of section 2.5 is that strings are of Unicode >> characters. And yet a large subset of the JSON ecosystem (ECMAScript >> and friends) doesn't agree. > > I admit that I don=E2=80=99t have a good feeling for the structure of the= JSON > ecosystem. In the part of it that I can see (people who are using it to > structure messages in application-level APIs), the belief that strings ar= e > for Unicode characters, and only for Unicode characters, and that anythin= g > in there that isn=E2=80=99t a Unicode character is a bug, is pretty well = 100%. If the server side of your API is running in node.js (which is very popular nowadays, so it well might be) then you might be dealing with ECMAScript (since that's what node.js builds on, just like JavaScript on the browser side). > BTW, I agree with Nico on #1 and #2, and while I=E2=80=99m grumpy about #= 3, I > suspect our charter doesn=E2=80=99t allow us to force-classify that situa= tion as an > error, which would be my preference. -T Were those useful questions then?! I mean, if you and Joe and others can agree with my answers to those three questions then we might well be able to reach a consensus as to strings that we can all live with. I understand the grumpiness re: #3, but it seems like a reasonable compromise (and yes, a bit more code for parsers and generators, but only a tiny bit). I once implemented a convention for encoding binary strings as an object with a specific URN as the only name and base64-encoded string as the value, with the parser and generator both implementing this convention My answer to my #3 is not too unlike such a convention, but with the benefit that the \u escapes are already in the spec *and* some implementations already handle binary strings via \u escapes, so \u escaping is a bit of a more convenient convention for non-Unicode (e.g., octet) strings. Note that my answer to my question #3 effectively allows JSON generators and parsers that natively support binary strings to generate a binary string by escaping all 16-bit code units that cannot form valid Unicode characters, and to detect binary strings on parsing by noticing that some escaped values cannot be unescaped to produce valid Unicode strings, therefore the input must be a binary string. Note that some binary strings can be interpreted as valid Unicode strings and so there's an ambiguity on the parser side (that the application can resolve by casting if it cares about a given string value). Note too that this convention would require that \u00xx be decoded as a single octet, otherwise there's a problem with odd-length octet strings. Such an encoding of binary data would make me somewhat happy: I hated my {"urn:...":""} convention (but base64 will often be more efficient). But this implication will surely upset you, so before you decide that you can grumpily agree to my answer to my #3 you should understand the consequence described above. Nico -- From jhildebr@cisco.com Wed Jul 17 13:33: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 41EC321F9C2E for ; Wed, 17 Jul 2013 13:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 cTBEtYwZQJng for ; Wed, 17 Jul 2013 13:33:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC2321F937E for ; Wed, 17 Jul 2013 13:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3300; q=dns/txt; s=iport; t=1374093200; x=1375302800; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bCKYpdSBOb2t2X6mTCgCpMjHOa1Q1DffMNPLL4zwmv4=; b=Zwlz7QbbEjU3hO+yjxMLf7m0dl4Ytk28KToGP2ov/AdbqUwauLlDiNpN 6hXpDQ1dLx0nFa333c/FXH1MD//WlwiErJ4oq3MA2gpZSMdEPbrO0Qfmz URtxt2SPIxMFR734mBRZxXqVKheR7l+0a9YGdnuUNIk351zcj+Chr3gC8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAIX+5lGtJV2Y/2dsb2JhbABagwY0UMBBgRIWdIIlAQQnEz8SAQgiFEIlAgQOBQiICAy2EwSPSTEHgw1uA6kpgxKCKA X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208";a="236102453" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 17 Jul 2013 20:33:18 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6HKXIhh031659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 20:33:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 15:33:18 -0500 From: "Joe Hildebrand (jhildebr)" To: Nico Williams Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOgnCdR+yeems0Nke/XW02cZd1o5loXUWAgAC/xAD///8AgIAAflYA//+ptQA= Date: Wed, 17 Jul 2013 20:33:17 +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.5.130515 x-originating-ip: [10.129.24.242] Content-Type: text/plain; charset="us-ascii" Content-ID: <171624EA483D1C4AABABB2A8633E3781@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick , John Cowan , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 20:33:34 -0000 On 7/17/13 1:42 PM, "Nico Williams" wrote: >>I see the escape mechanism as being explicitly for "characters" (where I > >That's not clearer than anything else about JSON. Sure. But that's my worldview. There are several different models that could be made to fit the language in 4627. >It'd be entirely >reasonable for the ECMAScript crowd to say "well, unpaired surrogates >have to be sent as escaped code units, but obviously not as >unescaped". That is, two sides of the argument would disagree over >whether a string could contain unpaired surrogates yet agree that the >JSON *text* containing such a string MUST NOT contain unpaired >surrogates. Agree. Note that the difference between "string MAY contain unpaired surrogates" and "string MUST NOT contain unpaired surrogates, and parsers MAY maintain as much state as possible when they detect a parse error" is pretty slim. >A literal reading of section 2.5 is that strings are of Unicode >characters. And yet a large subset of the JSON ecosystem (ECMAScript >and friends) doesn't agree. In the ECMAscript spec, they're talking about a series of UTF-16 code units, because the JSON object assumes that you have already decoded the original encoding (e.g. UTF-8) to an internal representation (error-tolerant UTF-16), and are specifying parsing rules for that internal representation. They have a handy mechanism for dealing with invalid escapes, which is that same error-tolerant UTF-16. That doesn't make either of the error classes less an error, it just means they have prioritized not losing data in those error conditions, and have decided that not throwing an error is the correct Postelian approach. The fact that some folks take advantage of that error-handling tolerance to do fancy tricks is an unintended outcome in several other existing error-tolerant systems. >1) Are escaped s supposed to be equivalent to their unescaped >forms, for string and deep JSON text comparison purposes? In my model, yes. What matters is reproducing the semantic that generated the encoded form. >2) Must/should parsers that can natively represent a given escaped > unescape it in the results in produces? Unqualified yes. If they don't, they can't round trip, assuming that they escape going the other direction. Compare: wire -> internal -> wire ["\u0000"] -> [ "\000" ] -> [ "\u0000" ] ["\u0000"] -> [ "\u0000" ] -> [ "\\u0000" ] >3) If an escaped appears in a JSON string that would result in >invalid UTF-8/16/32 when unescaped, what should the parser do? To be clear, I think the only way this can happen is with invalid surrogate sequences. Obviously if there's an encoding error a layer down with invalid UTF8, an error must be thrown or some sort of error-tolerance mechanism must be invoked. See: https://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences for some ideas. And I think that there are multiple different answers, which is why sending such sequences should be avoided if you want to interop with code you don't control. >RFC4627 says nothing about this. Agree. We could argue over what it implies, but not that it specifies how to deal with errors. --=20 Joe Hildebrand From nico@cryptonector.com Wed Jul 17 14:17:29 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 D96D321F9D4F for ; Wed, 17 Jul 2013 14:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=-0.377, 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 RZ108CuP2m4f for ; Wed, 17 Jul 2013 14:17:25 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5D50321F9CA8 for ; Wed, 17 Jul 2013 14:17:25 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 73BE026C069 for ; Wed, 17 Jul 2013 14:17:24 -0700 (PDT) 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=zInnKveY4jDZYmekdpcm hIi+vR0=; b=FbVn0brvBX+zAfunlNrsEaRFqv+jZrI6rWoxaa9nQ/3OGsbTS+kW WY3n0xsmeQAhzTy1lh5YjmViHiwOGphsou9nVCdIUrksmcOIsFP3sNJBnBxMiu86 Zo6v02yB8ERhONWyFQzmv7vkYiLZJX+IczSWPLuSpz6s8dmN4LAH6OY= 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-a87.g.dreamhost.com (Postfix) with ESMTPSA id 0290526C063 for ; Wed, 17 Jul 2013 14:17:23 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so2254728wev.16 for ; Wed, 17 Jul 2013 14:17:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=csZPccXSfofW6yHnJ8hnCtTqOl8c3WwAfZZkv3zj1U8=; b=C3LPr8DbHFqK8k/Qqzo0Xsrz12ABCMNOyU+cQiDP1bZG1tU3QA8Pr69FcUyt2pcjPP pBIfs4gp5EPSpN5FNoV3iunngMNbew3fx7uy49KbLO9wYHCoNiRggzs6/V1CmIp181Gi 11u4rdoiPro3Zk460qATnFXuv5SNf8azWawL/ao3GAebe6SpuOJZj6O+7sfwxYutJLt7 F0QuYNEgSIzppkkZvc9R2rq8yBccecG4k8wRPWgvEqIKogWsMLLU8mIJlKcIQEJFdUFy eTsPBeFIt2PvI/YKMRRNQ9HvwlxPu6XnKToKTE61tAUT0URyDZxg9ieVUOtFJhbDcOhc +f+Q== MIME-Version: 1.0 X-Received: by 10.180.185.176 with SMTP id fd16mr6026006wic.20.1374095842430; Wed, 17 Jul 2013 14:17:22 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 17 Jul 2013 14:17:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 16:17:22 -0500 Message-ID: From: Nico Williams To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: Pete Resnick , John Cowan , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 21:17:30 -0000 On Wed, Jul 17, 2013 at 3:33 PM, Joe Hildebrand (jhildebr) wrote: > On 7/17/13 1:42 PM, "Nico Williams" wrote: > Agree. Note that the difference between "string MAY contain unpaired > surrogates" and "string MUST NOT contain unpaired surrogates, and parsers > MAY maintain as much state as possible when they detect a parse error" is > pretty slim. Hmm, well, it is, but maintainers of generators that will produce them will object. >>A literal reading of section 2.5 is that strings are of Unicode >>characters. And yet a large subset of the JSON ecosystem (ECMAScript >>and friends) doesn't agree. > > In the ECMAscript spec, they're talking about a series of UTF-16 code > units, because the JSON object assumes that you have already decoded the > original encoding (e.g. UTF-8) to an internal representation > (error-tolerant UTF-16), and are specifying parsing rules for that > internal representation. They have a handy mechanism for dealing with > invalid escapes, which is that same error-tolerant UTF-16. The UTF-16 in ECMAScript is incidental. What's fundamental is that they allow *any* 16-bit code units, certainly escaped, and who knows if unescaped (it'd be nice to find out). > That doesn't make either of the error classes less an error, it just means > they have prioritized not losing data in those error conditions, and have > decided that not throwing an error is the correct Postelian approach. The > fact that some folks take advantage of that error-handling tolerance to do > fancy tricks is an unintended outcome in several other existing > error-tolerant systems. That's a reasonable view of the parser side. But from the ECMAScript pov it's probably not a reasonable view of the generator side. Still, as long as the parser can get by then the stricture on generators can be disregarded safely (as long as crap is escaped), and we might have consensus! >>1) Are escaped s supposed to be equivalent to their unescaped >>forms, for string and deep JSON text comparison purposes? > > In my model, yes. What matters is reproducing the semantic that generated > the encoded form. I think we can have broad agreement on this. >>2) Must/should parsers that can natively represent a given escaped >> unescape it in the results in produces? > > Unqualified yes. If they don't, they can't round trip, assuming that they > escape going the other direction. Compare: What if the , unescaped, results in invalid UTF/Unicode? That's where #3 goes. > wire -> internal -> wire > ["\u0000"] -> [ "\000" ] -> [ "\u0000" ] > ["\u0000"] -> [ "\u0000" ] -> [ "\\u0000" ] Yes, but if my internal format is C strings... (I know, that means I have other problems), or if the escaped code units included unpaired surrogates and my native format must be valid UTF-8 (or 16, or 32), then what? I think the only sensible answers are: - reject or - preserve the offending escapes in escaped form >>3) If an escaped appears in a JSON string that would result in >>invalid UTF-8/16/32 when unescaped, what should the parser do? > > To be clear, I think the only way this can happen is with invalid > surrogate sequences. Obviously if there's an encoding error a layer down > with invalid UTF8, an error must be thrown or some sort of error-tolerance > mechanism must be invoked. See: It could happen with \u0000 if my native representation is C strings. > https://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences > > > for some ideas. And I think that there are multiple different answers, > which is why sending such sequences should be avoided if you want to > interop with code you don't control. OK, but what's your answer to #3? Is it determined by your "unqualified yes" to #2? I was hoping your answer to #3 would be to allow the parser to preserve the offending escapes as escapes at the application's or implementor's option (as well as to reject the input, and perhaps map out the offending escapes). >>RFC4627 says nothing about this. > > Agree. We could argue over what it implies, but not that it specifies how > to deal with errors. But I think we should state this equivalence explicitly. Nico -- From tbray@textuality.com Wed Jul 17 14:35:01 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 C7A2C21F9963 for ; Wed, 17 Jul 2013 14:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.776 X-Spam-Level: X-Spam-Status: No, score=-3.776 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 Gxs+pumT95kh for ; Wed, 17 Jul 2013 14:34:57 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB9021F9967 for ; Wed, 17 Jul 2013 14:34:57 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ib11so54282vcb.0 for ; Wed, 17 Jul 2013 14:34:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=7wCxlt619g9LIgsrBdzmGB02faBqCVPT86PiP3U9grE=; b=NhEyfFwet/HFmUYzyS8qE3AEwDv1RErQMKmxVqpnKlOxUp4tyRT8yaxjVXy+1fIyzI ovjAOynHYwLcKORyeq/R0En++nOeun9+3xYbYgGdBk2BHGoMH4bfyabjNqyLPysrSg8c m33NdrpMifQfmPegMiEVe91WrRIhyTaQLGnE38z11RKz+YFfnoYTW1JLZ4EM27XCdFMe xxd1MRR+95RmfzGfHyqclWWCQk3SVFWg1pGCqR4I1jflZNFZHQVUBLt140pLO7gntetO nSKXLiDh4i2ZvJgEa1f59HoaIf5uuLjhi9GMFlS8m3U/5ZnVgI2AaoronjoCylYJfiV+ bAlg== MIME-Version: 1.0 X-Received: by 10.52.66.49 with SMTP id c17mr2428404vdt.94.1374096895567; Wed, 17 Jul 2013 14:34:55 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Wed, 17 Jul 2013 14:34:55 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Wed, 17 Jul 2013 14:34:55 -0700 Message-ID: From: Tim Bray To: Nico Williams Content-Type: multipart/alternative; boundary=20cf3071d00a59062904e1bbdd73 X-Gm-Message-State: ALoCoQnmTBGat2bO2upFAla3uLnk7AZLzzqlgeSc09eAcoDI48hv5w0A7NPqQoltKij+eyVMssji Cc: Pete Resnick , John Cowan , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 21:35:01 -0000 --20cf3071d00a59062904e1bbdd73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2013 at 2:17 PM, Nico Williams wrote= : > The UTF-16 in ECMAScript is incidental. What's fundamental is that > they allow *any* 16-bit code units, certainly escaped, and who knows > if unescaped (it'd be nice to find out). > > That's a reasonable view of the parser side. But from the ECMAScript > pov it's probably not a reasonable view There=E2=80=99s a community that apparently matters but which we=E2=80=99re= not hearing from. You keep talking about the ECMAscript needs and the ECMAScript POV. This implies that there is a community of implementers whose success depends on being able to stuff naked surrogates into JSON strings. Could we meet one, please? I guess they=E2=80=99d have to be building Browser-J= S <=3D> NodeJS apps, and that is a reasonably popular configuration, so it shouldn=E2=80=99t be that hard to find someone. Could we actually have one = such person step up and explain their needs? Rob Sayre, this sort of sounds like your territory, care to chip in? Because I=E2=80=99ve been using JSON all the time on a wide variety of apps= for like 5 years now and I=E2=80=99ve never met anyone who regarded payloads co= ntaining non-characters as anything but an egregious bug. I=E2=80=99m quite sure that there are groups to whose needs my experience h= as left me oblivious. But this debate would work better if we could actually hear from them what their needs are, and what we can't put in 4267bis without breaking them. -T > of the generator side. Still, > as long as the parser can get by then the stricture on generators can > be disregarded safely (as long as crap is escaped), and we might have > consensus! > > >>1) Are escaped s supposed to be equivalent to their unescaped > >>forms, for string and deep JSON text comparison purposes? > > > > In my model, yes. What matters is reproducing the semantic that > generated > > the encoded form. > > I think we can have broad agreement on this. > > >>2) Must/should parsers that can natively represent a given escaped > >> unescape it in the results in produces? > > > > Unqualified yes. If they don't, they can't round trip, assuming that > they > > escape going the other direction. Compare: > > What if the , unescaped, results in invalid UTF/Unicode? > That's where #3 goes. > > > wire -> internal -> wire > > ["\u0000"] -> [ "\000" ] -> [ "\u0000" ] > > ["\u0000"] -> [ "\u0000" ] -> [ "\\u0000" ] > > Yes, but if my internal format is C strings... (I know, that means I > have other problems), or if the escaped code units included unpaired > surrogates and my native format must be valid UTF-8 (or 16, or 32), > then what? I think the only sensible answers are: > > - reject > or > - preserve the offending escapes in escaped form > > >>3) If an escaped appears in a JSON string that would result in > >>invalid UTF-8/16/32 when unescaped, what should the parser do? > > > > To be clear, I think the only way this can happen is with invalid > > surrogate sequences. Obviously if there's an encoding error a layer do= wn > > with invalid UTF8, an error must be thrown or some sort of > error-tolerance > > mechanism must be invoked. See: > > It could happen with \u0000 if my native representation is C strings. > > > https://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences > > > > > > for some ideas. And I think that there are multiple different answers, > > which is why sending such sequences should be avoided if you want to > > interop with code you don't control. > > OK, but what's your answer to #3? Is it determined by your > "unqualified yes" to #2? I was hoping your answer to #3 would be to > allow the parser to preserve the offending escapes as escapes at the > application's or implementor's option (as well as to reject the input, > and perhaps map out the offending escapes). > > >>RFC4627 says nothing about this. > > > > Agree. We could argue over what it implies, but not that it specifies > how > > to deal with errors. > > But I think we should state this equivalence explicitly. > > Nico > -- > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --20cf3071d00a59062904e1bbdd73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 17, 2013 at 2:17 PM, Nico Williams <nic= o@cryptonector.com> wrote:
The UTF-16 in ECMAScript is incidental. =C2= =A0What's fundamental is that
they allow *any* 16-bit code units, certainly escaped, and who knows
if unescaped (it'd be nice to find out).

That's a reasonable view of the parser side. =C2=A0But from the E= CMAScript
pov it's probably not a reasonable view

There=E2=80=99s a community that apparently matters but which we=E2=80=99r= e not hearing from. You keep talking about the ECMAscript needs and the ECM= AScript POV.=C2=A0 This implies that there is a community of implementers w= hose success depends on being able to stuff naked surrogates into JSON stri= ngs.=C2=A0 Could we meet one, please?=C2=A0 I guess they=E2=80=99d have to = be building=C2=A0 Browser-JS <=3D> NodeJS apps, and that is a reasona= bly popular configuration, so it shouldn=E2=80=99t be that hard to find som= eone. Could we actually have one such person step up and explain their need= s?=C2=A0 Rob Sayre, this sort of sounds like your territory, care to chip i= n?

Because I=E2=80=99ve been using JSON all the time on a wide = variety of apps for like 5 years now and I=E2=80=99ve never met anyone who = regarded payloads containing non-characters as anything but an egregious bu= g.

I=E2=80=99m quite sure that there are groups to whose needs my experie= nce has left me oblivious. But this debate would work better if we could ac= tually hear from them what their needs are, and what we can't put in 42= 67bis without breaking them. -T

=C2=A0
of the generator= side. =C2=A0Still,
as long as the parser can get by then the stricture on generators can
be disregarded safely (as long as crap is escaped), and we might have
consensus!

>>1) Are escaped <thing>s supposed to be equivalent to their un= escaped
>>forms, for string and deep JSON text comparison purposes?
>
> In my model, yes. =C2=A0What matters is reproducing the semantic that = generated
> the encoded form.

I think we can have broad agreement on this.

>>2) Must/should parsers that can natively represent a given escaped<= br> >><thing> unescape it in the results in produces?
>
> Unqualified yes. =C2=A0If they don't, they can't round trip, a= ssuming that they
> escape going the other direction. =C2=A0Compare:

What if the <thing>, unescaped, results in invalid UTF/Unicode?=
That's where #3 goes.

> wire -> internal -> wire
> ["\u0000"] -> [ "\000" ] -> [ "\u0000&q= uot; ]
> ["\u0000"] -> [ "\u0000" ] -> [ "\\u000= 0" ]

Yes, but if my internal format is C strings... (I know, that means I<= br> have other problems), or if the escaped code units included unpaired
surrogates and my native format must be valid UTF-8 (or 16, or 32),
then what? =C2=A0I think the only sensible answers are:

=C2=A0- reject
or
=C2=A0- preserve the offending escapes in escaped form

>>3) If an escaped <thing> appears in a JSON string that would = result in
>>invalid UTF-8/16/32 when unescaped, what should the parser do?
>
> To be clear, I think the only way this can happen is with invalid
> surrogate sequences. =C2=A0Obviously if there's an encoding error = a layer down
> with invalid UTF8, an error must be thrown or some sort of error-toler= ance
> mechanism must be invoked. =C2=A0See:

It could happen with \u0000 if my native representation is C strings.=

> https://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequenc= es
>
>
> for some ideas. =C2=A0And I think that there are multiple different an= swers,
> which is why sending such sequences should be avoided if you want to > interop with code you don't control.

OK, but what's your answer to #3? =C2=A0Is it determined by your<= br> "unqualified yes" to #2? =C2=A0I was hoping your answer to #3 wou= ld be to
allow the parser to preserve the offending escapes as escapes at the
application's or implementor's option (as well as to reject the inp= ut,
and perhaps map out the offending escapes).

>>RFC4627 says nothing about this.
>
> Agree. =C2=A0We could argue over what it implies, but not that it spec= ifies how
> to deal with errors.

But I think we should state this equivalence explicitly.

Nico
--
___________________________________= ____________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json

--20cf3071d00a59062904e1bbdd73-- From jhildebr@cisco.com Wed Jul 17 14:55: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 9F9E021F9EAF for ; Wed, 17 Jul 2013 14:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.266 X-Spam-Level: X-Spam-Status: No, score=-11.266 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, GB_I_LETTER=-2, 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 KpidWOAceu5e for ; Wed, 17 Jul 2013 14:55:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 38A2E21F9DFA for ; Wed, 17 Jul 2013 14:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6081; q=dns/txt; s=iport; t=1374098134; x=1375307734; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BQtIBrjw+RpGRwrBrq/CU571gXqz+jUE3cogqfDyOLs=; b=AT8d49bZ1PVpwjJiYXz7vu9gGK3xY2h79tJh5I3bYm4vWubR8eZFBQj1 Lj+/4yAJFr6+EFk9eCxSTsT2d4ReDFfTOCBdRo9DU5KmsQAoeP6PbtJoh BdhE0aQ78/ZX9E0KtrwteJQBJvrBrdoEehx43/JdMH8KgZPye2c8zadew s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAkS51GtJXG9/2dsb2JhbABagwY0UMA/gRIWdIIjAQEBAwE6PxIBCBgKFEIlAgQOBQiIAgYMtiMEj0kxB4MNbgOpKYMSgig X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208";a="236140219" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 17 Jul 2013 21:55:27 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6HLtQgM005532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 21:55:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 16:55:26 -0500 From: "Joe Hildebrand (jhildebr)" To: Nico Williams Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOgnCdR+yeems0Nke/XW02cZd1o5loXUWAgAC/xAD///8AgIAAflYA//+ptQCAAHDpAP//pgqA Date: Wed, 17 Jul 2013 21:55:25 +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.5.130515 x-originating-ip: [10.129.24.242] Content-Type: text/plain; charset="us-ascii" Content-ID: <5ABBCA2AA25EFB4B880AA7B49FA12A54@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pete Resnick , John Cowan , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 21:55:53 -0000 On 7/17/13 3:17 PM, "Nico Williams" wrote: >On Wed, Jul 17, 2013 at 3:33 PM, Joe Hildebrand (jhildebr) > wrote: >> On 7/17/13 1:42 PM, "Nico Williams" wrote: > >> Agree. Note that the difference between "string MAY contain unpaired >> surrogates" and "string MUST NOT contain unpaired surrogates, and >>parsers >> MAY maintain as much state as possible when they detect a parse error" >>is >> pretty slim. > >Hmm, well, it is, but maintainers of generators that will produce them >will object. I don't care too much. Just because you can make something work doesn't mean that you should. Also, I bet they don't really care if they are compliant with the letter of the law; their code will still work in practice. >>In the ECMAscript spec, they're talking about a series of UTF-16 code >> units, because the JSON object assumes that you have already decoded the >> original encoding (e.g. UTF-8) to an internal representation >> (error-tolerant UTF-16), and are specifying parsing rules for that >> internal representation. They have a handy mechanism for dealing with >> invalid escapes, which is that same error-tolerant UTF-16. > >The UTF-16 in ECMAScript is incidental. What's fundamental is that >they allow *any* 16-bit code units, certainly escaped, and who knows >if unescaped (it'd be nice to find out). Not quite. If I do feed ECMAScript a valid UTF-16 surrogate pair, it will do interesting things with it. For example: console.log("\uD800\uDD43") will print the glyph for GREEK ACROPHONIC ATTIC FIVE. I see my characterization of their string type as fault-tolerant UTF-16 as justified. Also ECMA-262 section 4.3.16 says: """ NOTE A String value is a member of the String type. Each integer value in the sequence usually represents a single 16-bit unit of UTF-16 text. However, ECMAScript does not place any restrictions or requirements on the values except that they must be 16-bit unsigned integers. """ JSON.parse takes a String. >> That doesn't make either of the error classes less an error, it just >>means >> they have prioritized not losing data in those error conditions, and >>have >> decided that not throwing an error is the correct Postelian approach. >>The >> fact that some folks take advantage of that error-handling tolerance to >>do >> fancy tricks is an unintended outcome in several other existing >> error-tolerant systems. > >That's a reasonable view of the parser side. But from the ECMAScript >pov it's probably not a reasonable view of the generator side. Still, >as long as the parser can get by then the stricture on generators can >be disregarded safely (as long as crap is escaped), and we might have >consensus! That was what I was hoping for. Real-world interoperability while ensuring that the moral indignation we feel toward those who generate technically invalid output is captured in the spec. >>>2) Must/should parsers that can natively represent a given escaped >>> unescape it in the results in produces? >> >> Unqualified yes. If they don't, they can't round trip, assuming that >>they >> escape going the other direction. Compare: > >What if the , unescaped, results in invalid UTF/Unicode? >That's where #3 goes. That's up to the parser. Some may error,=20 Some replace,=20 Some may leave the trash in place. No matter if they think it's trash Parsers make a choice or crash If you send half a pair Please remember have a care Parsers choose, you know not which, How to handle surrogates (sorry, it's been a long week already) >Yes, but if my internal format is C strings... (I know, that means I >have other problems), or if the escaped code units included unpaired >surrogates and my native format must be valid UTF-8 (or 16, or 32), >then what? I think the only sensible answers are: > > - reject >or > - preserve the offending escapes in escaped form Or convert to U+FFFD. >>>3) If an escaped appears in a JSON string that would result in >>>invalid UTF-8/16/32 when unescaped, what should the parser do? >> >> To be clear, I think the only way this can happen is with invalid >> surrogate sequences. Obviously if there's an encoding error a layer >>down >> with invalid UTF8, an error must be thrown or some sort of >>error-tolerance >> mechanism must be invoked. See: > >It could happen with \u0000 if my native representation is C strings. Yes, I see that. The NULL would terminate the string. >> https://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences >> >> >> for some ideas. And I think that there are multiple different answers, >> which is why sending such sequences should be avoided if you want to >> interop with code you don't control. > >OK, but what's your answer to #3? Is it determined by your >"unqualified yes" to #2? I was hoping your answer to #3 would be to >allow the parser to preserve the offending escapes as escapes at the >application's or implementor's option (as well as to reject the input, >and perhaps map out the offending escapes). I think the question isn't terribly accurate. There are two pieces: 1) What should happen upon UTFx-decoding errors with the overall stream? I have a strong bias for aborting with an error, but allow for the possibility that folks may want to be tolerant of some classes of errors. I think the spec should make a recommendation, but tell senders they MUST NOT rely on specific behavior for interoperability. 2) What should happen upon UTF-16 decoding errors from unicode escape sequences? Effectively the same answer as above, but I have slightly more tolerance for preserving the broken data, since there are several implementations that do it today. Regardless, senders MUST NOT rely on a specific behavior for interoperability. >But I think we should state this equivalence explicitly. Yup. I think that's a fine way forward. --=20 Joe Hildebrand From nico@cryptonector.com Wed Jul 17 15:04: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 A44CC21F9E6E for ; Wed, 17 Jul 2013 15:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.640, 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 yTPHkIHTWXlz for ; Wed, 17 Jul 2013 15:04:10 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id C437421F9D87 for ; Wed, 17 Jul 2013 15:04:10 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 784AF50808E for ; Wed, 17 Jul 2013 15:04:10 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=x6TI0e1l7JColAmCFnXx7bCXIOY=; b=FUJg9U6ya6J b9ltOK9kcC/hfaRXnZTsddJQi1DTxIxeYZwH37JWTIvPnQ4V0MP1ybgYsBZyvsil 7jyBOMejl/4K2WBmxl6THlCQa9D3FoDPtqUfTxDcJhda1tq9erxreGHYYrKLqATN D6Iia8H9ZjQvnyXGNw2RTRyzXehZIaio= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 18148508063 for ; Wed, 17 Jul 2013 15:04:09 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so5983978wib.0 for ; Wed, 17 Jul 2013 15:04:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rc/xu/UlU1K+jSc8kMoWrNCw6N13G9Bxc0fvEhbi/yk=; b=lY9Eu6yYGg9lVw7Uvy+8/E0tt9xu5FnkD3LW7Sv1uN1s7Hgwd6HDm8zQanZ1NsJori sEqxYv7pdRl/4Yh/DF0wXJDSDbO6c89WPMpEI9ewAttZCkjgg9mDOtKpS06zB13OFAD9 7axsAw/oUbLLYNnp/nf70X+8CW9WHcv0Z9Hg/VZ1HxbkwJ2mhbQn3O+SQ28mbHd3Snjm AxklLlu+a5xgwDQl1TscJ43iAumneknlKNCNrnFWy2CaNsd1gOhCYZPKHfT7PmnRCDPx /7ZvVzGOVee5w+em1uE/EvFctxuN5sotUAFi+WoucIJhZ1mnl/g/dv02USyrE6KzDHO8 8lMA== MIME-Version: 1.0 X-Received: by 10.180.74.162 with SMTP id u2mr17138389wiv.36.1374098648585; Wed, 17 Jul 2013 15:04:08 -0700 (PDT) Received: by 10.217.38.138 with HTTP; Wed, 17 Jul 2013 15:04:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 17:04:08 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Pete Resnick , John Cowan , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 17 Jul 2013 22:04:15 -0000 On Wed, Jul 17, 2013 at 4:34 PM, Tim Bray wrote: > On Wed, Jul 17, 2013 at 2:17 PM, Nico Williams > wrote: >> That's a reasonable view of the parser side. But from the ECMAScript >> pov it's probably not a reasonable view > > There=E2=80=99s a community that apparently matters but which we=E2=80=99= re not hearing > from. You keep talking about the ECMAscript needs and the ECMAScript POV. Er, I thought we'd heard from some people from that subset of the community. And there was even an odd exchange about who could and could not represent ECMA itself here. I myself am not a member of that community, so I can remind us that they ex= ist. There's also the issue that we may need a liason. The WG's charter explicitly mentions the ECMA. But there may be no one representing the ECMA's interests. Can we make progress without a liason or explicit call for participation from ECMA? Nico -- From jorge@jorgechamorro.com Wed Jul 17 17:45: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 326C421F9CE7 for ; Wed, 17 Jul 2013 17:45:51 -0700 (PDT) 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 ggJHXGj6vb6I for ; Wed, 17 Jul 2013 17:45:46 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 11B2021F9CB1 for ; Wed, 17 Jul 2013 17:45:45 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id c11so2327063wgh.13 for ; Wed, 17 Jul 2013 17:45:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=O04kn+3aWY+m0WdMmEYHk7p0Y24CGBywBPJo9+UQdLk=; b=SkBVQAtDKGzTXSpOnOPhYuftDflYyL08Mbx0rDWDLTJ7k42BnO1x65Sd4kjZqRanaC vleGNk6OFZheUz1KKbj9Dt1rScpQVhaDs3OB7fbD0dAljg1Uq9hVsepeBZPAeTrY7PBu rXXveNsEm1q4IaUejN1VNZoo8JvvEDvLX75mUN+SXKoOIn+vvwK96ZaDOPk14On8rqmE TaPC/z7by9jYbuO0qAdkMZyQKvtC5VVcFGSmP9/HzKGZcIZzxiw/fDShPjQVnjpCgGg+ zJ4a1nsFDHbjYYzy6rAtXeamyeS0jP3ecb5XCmMBlSQeuI0sBbI8YmhnyISUEPnU6Don M2hA== X-Received: by 10.180.39.212 with SMTP id r20mr6418036wik.30.1374108343867; Wed, 17 Jul 2013 17:45:43 -0700 (PDT) Received: from [192.168.10.50] (189.Red-79-155-151.dynamicIP.rima-tde.net. [79.155.151.189]) by mx.google.com with ESMTPSA id i1sm38515974wiz.6.2013.07.17.17.45.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 17:45:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: <20130716181753.GG1176@mercury.ccil.org> Date: Thu, 18 Jul 2013 02:45:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E4B6CA.2040309@qti.qualcomm.com> <20130716181753.GG1176@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmAVw30RCaj7/RB8P5WZr37Z8WBWBt/spQAv4Bl9Mp9cggDgPVYt9feJhuAi6gnMPNdOvMn Cc: Pete Resnick , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 00:45:51 -0000 On 16/07/2013, at 20:17, John Cowan wrote: >=20 > A JSON text is a sequence of characters. It may be encoded as a > sequence of integers (which may be encoded as a sequence of bytes). > It may also be encoded by a sequence of atoms, as when a JSON text is > printed on a piece of paper. It may even be encoded by the *absence* > of certain atoms, as when a JSON text is carved in stone. It may not = be > encoded at all (as far as we know), as when I only *imagine* a JSON = text. > But in all these cases, the text is a sequence of characters. And that's why we need -at least- *two* separate docs: On 13/06/2013, at 17:50, Douglas Crockford wrote: > The confusion and controversy around this work is due to a mistake = that I > made in RFC 4627. The purpose of the RFC, which is clearly indicated > in the title, was to establish a MIME type. I also gave a description = of > the JSON Data Interchange Format. My mistake was in conflating the = two, > putting details about the MIME type into the description of the = format. My > intention was to add clarity. That obviously was not the result. >=20 > JSON is just a format. It describes a syntax of brackets and commas = that > is useful in many contexts, profiles, and applications. JSON is = agnostic > about all of that stuff. JSON shouldn't even care about character = encoding. > Its only dependence on Unicode in the hex numbers used in the \u = notation. > JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON = can > be used in contexts where there is no character encoding at all, such = as > paper documents and marble monuments. >=20 > There are uses of JSON however in which such choices matter, and where > behavior needs to be attached to or derived from the syntax. That is > important stuff, and it belongs in different documents. Such documents > will place necessary restrictions on JSON's potential. No such = document > can fit all applications, which causes much of the controversy we've = seen > here. One size cannot fit all. JSON the format is universal. But real > applications require reasonable restrictions. >=20 > So we should be working on at least two documents, which is something = we have > discussed earlier. The first is The JSON Data Interchange Format, = which is > a simple grammar. The second is a best practices document, which = recommends > specific conventions of usage. We're going in circles. --=20 ( Jorge )();= From cowan@ccil.org Wed Jul 17 18:08: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 375E021F9655 for ; Wed, 17 Jul 2013 18:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 dbJN1cuyG1KU for ; Wed, 17 Jul 2013 18:08:21 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85121F96EF for ; Wed, 17 Jul 2013 18:08:21 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Uzchd-0001KQ-Tx; Wed, 17 Jul 2013 21:08:17 -0400 Date: Wed, 17 Jul 2013 21:08:17 -0400 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20130718010817.GC29248@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: Nico Williams , Pete Resnick , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 01:08:26 -0000 Joe Hildebrand (jhildebr) scripsit: > Agree. Note that the difference between "string MAY contain unpaired > surrogates" and "string MUST NOT contain unpaired surrogates, and parsers > MAY maintain as much state as possible when they detect a parse error" is > pretty slim. Au contraire, it is fundamental. If they MAY contain unpaired surrogates, then it is legitimate to use JSON strings to encode sequences of arbitrary 16-bit integers (with proper escaping). If they MUST NOT, then it is not legitimate to do so even if it happens to work for some generator-parser combinations. -- Even a refrigerator can conform to the XML John Cowan Infoset, as long as it has a door sticker cowan@ccil.org saying "No information items inside". http://www.ccil.org/~cowan --Eve Maler From sayrer@gmail.com Wed Jul 17 18:10: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 A9BD121F999B for ; Wed, 17 Jul 2013 18:10:45 -0700 (PDT) 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, 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 qYTausjZk8N5 for ; Wed, 17 Jul 2013 18:10:44 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 32C1121F9929 for ; Wed, 17 Jul 2013 18:10:44 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so2386774wev.16 for ; Wed, 17 Jul 2013 18:10:43 -0700 (PDT) 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=4tBDdwaCt51mRoB8CeKbYDvtz2fkPOjjaKOnlLKx2Yc=; b=ECLPY0nq9i4Wwnyh6wQMz8MFpFp35/+RGFtLxAluGmmtzR8xmNVtZ/oiFxnMqZLc2V EkwCmM6pK+EyDguihyUowt4aOyS5c84Ypss4S6GLxPtWLJwXRCoJ3vp7dM1p559UBfws K3AP0y+oJB98IBger+OHcrjamFjA/7iL+VHslD8/D5xj9s+JXci1uIkFEyOd97JYmDbp FzPylsBw84CWp0Scj7lFwBNdVMnPgsdFldDP5pxjjMn9j71yD4i8DOROtc7YJyWwpIJW YXqetdo9ZMqE4QLLco6nTNruutPzwEFy6s327ncjCFVI5lJYp+D2qUyRopO+IyrYmTTC 1zwA== MIME-Version: 1.0 X-Received: by 10.194.78.42 with SMTP id y10mr6583880wjw.93.1374109843336; Wed, 17 Jul 2013 18:10:43 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Wed, 17 Jul 2013 18:10:43 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 18:10:43 -0700 Message-ID: From: R S To: Tim Bray Content-Type: multipart/alternative; boundary=047d7bfcfdce18324b04e1bee1a2 Cc: Nico Williams , Pete Resnick , John Cowan , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 01:10:45 -0000 --047d7bfcfdce18324b04e1bee1a2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2013 at 2:34 PM, Tim Bray wrote: > On Wed, Jul 17, 2013 at 2:17 PM, Nico Williams wro= te: > >> The UTF-16 in ECMAScript is incidental. What's fundamental is that >> they allow *any* 16-bit code units, certainly escaped, and who knows >> if unescaped (it'd be nice to find out). >> >> That's a reasonable view of the parser side. But from the ECMAScript >> pov it's probably not a reasonable view >> > > There=92s a community that apparently matters but which we=92re not heari= ng > from. You keep talking about the ECMAscript needs and the ECMAScript POV. > This implies that there is a community of implementers whose success > depends on being able to stuff naked surrogates into JSON strings. Could > we meet one, please? I guess they=92d have to be building Browser-JS <= =3D> > NodeJS apps, and that is a reasonably popular configuration, so it > shouldn=92t be that hard to find someone. Could we actually have one such > person step up and explain their needs? Rob Sayre, this sort of sounds > like your territory, care to chip in? > This message from Waldemar Horwat may be informative: If I've learned anything about ECMAScript, it's this: if it works today, there is unmaintained content depending on it. Breaking content is just about the worst thing an ECMAScript implementation can do, so none of them ever will in a market with 5+ credible implementations. I'd recommend reading the entire thread I linked, particularly the messages from Jason Orendorff and Douglas Crockford. Nothing has changed in the four years since, which should tell this WG that we are not here to legislate correctness, but to document the status quo. - Rob --047d7bfcfdce18324b04e1bee1a2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 17, 2013 at 2:34 PM, Tim Bray <tbray@textu= ality.com> wrote:
On Wed, Jul 17, 2013 at= 2:17 PM, Nico Williams <nico@cryptonector.com> wrote:
The UTF-16 in ECMAScript is incidental. = =A0What's fundamental is that
they allow *any* 16-bit code units, certainly escaped, and who knows
if unescaped (it'd be nice to find out).

That's a reasonable view of the parser si= de. =A0But from the ECMAScript
pov it's probably not a reasonable view

There=92s a community that apparently matters but which we=92re not = hearing from. You keep talking about the ECMAscript needs and the ECMAScrip= t POV.=A0 This implies that there is a community of implementers whose succ= ess depends on being able to stuff naked surrogates into JSON strings.=A0 C= ould we meet one, please?=A0 I guess they=92d have to be building=A0 Browse= r-JS <=3D> NodeJS apps, and that is a reasonably popular configuratio= n, so it shouldn=92t be that hard to find someone. Could we actually have o= ne such person step up and explain their needs?=A0 Rob Sayre, this sort of = sounds like your territory, care to chip in?


This mess= age from Waldemar Horwat may be informative:

<<= a href=3D"https://mail.mozilla.org/pipermail/es5-discuss/2009-October/00338= 5.html">https://mail.mozilla.org/pipermail/es5-discuss/2009-October/003385.= html>

If I've learned anything about ECMAScript, it's= this: if it works today, there is unmaintained content depending on it. Br= eaking content is just about the worst thing an ECMAScript implementation c= an do, so none of them ever will in a market with 5+ credible implementatio= ns.

I'd recommend reading the entire thread I linked, p= articularly the messages from Jason Orendorff and Douglas Crockford. Nothin= g has changed in the four years since, which should tell this WG that we ar= e not here to legislate correctness, but to document the status quo.

- Rob
--047d7bfcfdce18324b04e1bee1a2-- From tbray@textuality.com Wed Jul 17 18:55:06 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 95F2F21F9AAE for ; Wed, 17 Jul 2013 18:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.500, 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 oSMUa36Z+JMt for ; Wed, 17 Jul 2013 18:55:01 -0700 (PDT) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id D56A921F9A99 for ; Wed, 17 Jul 2013 18:55:00 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jz10so2067153veb.31 for ; Wed, 17 Jul 2013 18:54:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TI6XIH758HF08XBK9dHb0yRxdkz5WkVTLgpH2ObVSmk=; b=Fs0Y47bBFTgVlcHW2nwQm2jq+KTpRo8zyYogm6EqBRYIYvBDOCPIWSI+WBrqcfM8DO YWUO9Q00fYpCyMxc9mnGdNKBS67710epSWKpzdSve3FbaUeTPFY3KPct1/WgpZxPagP0 RQsCJfug9vgJXeeR5ojKgMJxpeAnG0R9ZCjI40Rmsc2pGotWvStHtXCU6MUg2tXHXXoF Guz98zAK6vPdqzciyn7paTHJvXRSsZPduzd/NqAUZBxrxdRgltbFjzLl7tq4XP7NhPIL 1P6jeTYmJxBnbebw8jMX4g1vE0XmqlixUR7angPx7yj5okApVDZsvLx17gGIfGfy2Z/j oCYA== MIME-Version: 1.0 X-Received: by 10.52.236.199 with SMTP id uw7mr2723604vdc.18.1374112499199; Wed, 17 Jul 2013 18:54:59 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Wed, 17 Jul 2013 18:54:59 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Wed, 17 Jul 2013 18:54:59 -0700 Message-ID: From: Tim Bray To: R S Content-Type: multipart/alternative; boundary=089e0111d9246582a304e1bf7ff2 X-Gm-Message-State: ALoCoQmJz5DBcizuEWSn39j0aYb3cIeHELrIq1YwrWvd6sGNAE8hfW1K7PEb5ZjWi80FnmNileIy Cc: Nico Williams , Pete Resnick , John Cowan , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 01:55:06 -0000 --089e0111d9246582a304e1bf7ff2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I read the 18 messages in the thread and the discussion was at the level of theory. The constituency I=E2=80=99d like to hear from - actual developers = who actually exchange actual JSON strings that can=E2=80=99t be expressed as se= quences of Unicode codepoints - remains un-heard from. Remember that rough consensus & running code thing? I=E2=80=99d really, really like to hear ab= out instances of running code that depend on behavior that flatly contradicts the assertion in the RFC introduction that JSON strings are sequences of Unicode characters. Yes, I understand that: - the ABNF allows arbitrary 16-bit quantities in strings, despite what the intro says - the ECMAScript standardization project has explicitly blessed this - Douglas Crockford says receiving software should just shut up and deal with naked surrogates I just want to meet and understand the constituency we=E2=80=99re trying to= serve by allowing behavior that, to 100% of the users of JSON implementations that I know, is self-evidently incorrect. -T On Wed, Jul 17, 2013 at 6:10 PM, R S wrote: > On Wed, Jul 17, 2013 at 2:34 PM, Tim Bray wrote: > >> On Wed, Jul 17, 2013 at 2:17 PM, Nico Williams wr= ote: >> >>> The UTF-16 in ECMAScript is incidental. What's fundamental is that >>> they allow *any* 16-bit code units, certainly escaped, and who knows >>> if unescaped (it'd be nice to find out). >>> >>> That's a reasonable view of the parser side. But from the ECMAScript >>> pov it's probably not a reasonable view >>> >> >> There=E2=80=99s a community that apparently matters but which we=E2=80= =99re not hearing >> from. You keep talking about the ECMAscript needs and the ECMAScript POV= . >> This implies that there is a community of implementers whose success >> depends on being able to stuff naked surrogates into JSON strings. Coul= d >> we meet one, please? I guess they=E2=80=99d have to be building Browse= r-JS <=3D> >> NodeJS apps, and that is a reasonably popular configuration, so it >> shouldn=E2=80=99t be that hard to find someone. Could we actually have o= ne such >> person step up and explain their needs? Rob Sayre, this sort of sounds >> like your territory, care to chip in? >> > > > This message from Waldemar Horwat may be informative: > > > > If I've learned anything about ECMAScript, it's this: if it works today, > there is unmaintained content depending on it. Breaking content is just > about the worst thing an ECMAScript implementation can do, so none of the= m > ever will in a market with 5+ credible implementations. > > I'd recommend reading the entire thread I linked, particularly the > messages from Jason Orendorff and Douglas Crockford. Nothing has changed = in > the four years since, which should tell this WG that we are not here to > legislate correctness, but to document the status quo. > > - Rob > --089e0111d9246582a304e1bf7ff2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I read the 18 messages in the thr= ead and the discussion was at the level of theory. The constituency I=E2=80= =99d like to hear from - actual developers who actually exchange actual JSO= N strings that can=E2=80=99t be expressed as sequences of Unicode codepoint= s - remains un-heard from. =C2=A0 Remember that rough consensus & runni= ng code thing?=C2=A0 I=E2=80=99d really, really like to hear about instance= s of running code that depend on behavior that flatly contradicts the asser= tion in the RFC introduction that JSON strings are sequences of Unicode cha= racters.

Yes, I understand that:
- the ABNF allows arbitrary 16-b= it quantities in strings, despite what the intro says
- the ECMASc= ript standardization project has explicitly blessed this
- Douglas= Crockford says receiving software should just shut up and deal with naked = surrogates

I just want to meet and understand the constituency we=E2=80=99re= trying to serve by allowing behavior that, to 100% of the users of JSON im= plementations that I know, is self-evidently incorrect.=C2=A0 -T
<= div class=3D"gmail_extra">

On Wed, Jul 17, 2013 at 6:10 PM, R S <sa= yrer@gmail.com> wrote:
On Wed, Jul 17, 2013 at 2:34 PM, Tim Bra= y <tbray@textuality.com> wrote:
On Wed, Jul 17, 2013 at 2:17 PM, Nic= o Williams <nico@cryptonector.com> wrote:
The UTF-16 in ECMAScript is incidental. =C2=A0What= 9;s fundamental is that
they allow *any* 16-bit code units, certainly escaped, and who knows
if unescaped (it'd be nice to find out).

That's a reasonable view of the parser side. =C2=A0But= from the ECMAScript
pov it's probably not a reasonable view

There=E2=80=99s a community that apparently matters but which we=E2= =80=99re not hearing from. You keep talking about the ECMAscript needs and = the ECMAScript POV.=C2=A0 This implies that there is a community of impleme= nters whose success depends on being able to stuff naked surrogates into JS= ON strings.=C2=A0 Could we meet one, please?=C2=A0 I guess they=E2=80=99d h= ave to be building=C2=A0 Browser-JS <=3D> NodeJS apps, and that is a = reasonably popular configuration, so it shouldn=E2=80=99t be that hard to f= ind someone. Could we actually have one such person step up and explain the= ir needs?=C2=A0 Rob Sayre, this sort of sounds like your territory, care to= chip in?


Thi= s message from Waldemar Horwat may be informative:

<https://mail.mozilla.org/pipermail/es5-disc= uss/2009-October/003385.html>

If I've learned anything about ECMAScript, it's= this: if it works today, there is unmaintained content depending on it. Br= eaking content is just about the worst thing an ECMAScript implementation c= an do, so none of them ever will in a market with 5+ credible implementatio= ns.

I'd recommend reading the entire thread I linked, p= articularly the messages from Jason Orendorff and Douglas Crockford. Nothin= g has changed in the four years since, which should tell this WG that we ar= e not here to legislate correctness, but to document the status quo.

- Rob

--089e0111d9246582a304e1bf7ff2-- From nico@cryptonector.com Wed Jul 17 19:48: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 3855621F8C3E for ; Wed, 17 Jul 2013 19:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=-0.714, 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 07able4I+mOv for ; Wed, 17 Jul 2013 19:48:40 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6A421F894E for ; Wed, 17 Jul 2013 19:48:40 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id A117D163A for ; Wed, 17 Jul 2013 19:48:38 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=00bSzD3DfHyTFsjKp7Mc8VzHiNE=; b=kvxZ47x7J1G WFtziYLUxixFCK9zBVmmID0ASdQ6QsSXjCI6+pJ0bmCuCcQNGds+mUSRYUU6JWqU jFkreY7xSf3HzXx3/rREs2xobDq74r8EnX9aCjC/e1QokNj6Sj91LFjdU56p/Aun b9Z2jPpBmVeRYF6SPW/AZEvW/d3cXy/M= Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 806E81634 for ; Wed, 17 Jul 2013 19:48:38 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so5642529iea.25 for ; Wed, 17 Jul 2013 19:48:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kk19eE9RxrcY/KCafnY9TBDOz3Op5RQRT5pglNHh8UQ=; b=WglARHdGetea2HIxM8WtzCfRqeQ7giw+g2w5JmGD2Ue3B2Oa6oxoEqXF0j+ilRgJI6 +rq0mrb9wn8e/px3sXm/D7PC1CHh99k1zGkauxqjFqjyvRIKTD4xHcw3TF1GwaSRCXt5 e0rzl/rgdQXdsRdnJtF6TisAhwo5NIq9ZNEydrZUM0XntkXzvBijT+I0BjPZbRfefT6p np/w5BftCdug+8kXJMGup4eiyoxLMwp2ajnd606JuJMIW4iTeiAYBt/G3QPq5TVGL1lP YgQ1whNtcQzLFqk8UfeGlvFtLzCqPou7kYv+9jftJlXY/oVFJwdv/SsAridyztDjPlWn FOIA== MIME-Version: 1.0 X-Received: by 10.42.222.135 with SMTP id ig7mr5802607icb.69.1374115717639; Wed, 17 Jul 2013 19:48:37 -0700 (PDT) Received: by 10.64.130.169 with HTTP; Wed, 17 Jul 2013 19:48:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 21:48:37 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Pete Resnick , "json@ietf.org" , John Cowan , "Joe Hildebrand \(jhildebr\)" , R S Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 02:48:45 -0000 On Wed, Jul 17, 2013 at 8:54 PM, Tim Bray wrote: > I just want to meet and understand the constituency we=E2=80=99re trying = to serve by > allowing behavior that, to 100% of the users of JSON implementations that= I > know, is self-evidently incorrect. -T Assuming they exist, they're probably not here, making us the wrong crowd, in the wrong forum. BTW, I have done a few searches for how best to handle binary strings in JS, and... I've found just one place so far indicating that binary data in JSON strings works: comment #1 on stackoverflow question 17227998 (http://stackoverflow.com/questions/17227998/embedding-binary-data= -in-web-page). This says nothing about how prevalent this is. From nico@cryptonector.com Wed Jul 17 20:02: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 6D94321F9958 for ; Wed, 17 Jul 2013 20:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 mv-2uEaQRc4c for ; Wed, 17 Jul 2013 20:02:09 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id E78C021F9943 for ; Wed, 17 Jul 2013 20:02:06 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id C6F191F0084 for ; Wed, 17 Jul 2013 20:02:04 -0700 (PDT) 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:content-transfer-encoding; s= cryptonector.com; bh=3AV1QHolkWg+Dx7kfSCawc8I89s=; b=g3hoHgyDTwt MRNqDZeNvMuKbMdwYYzxmSxGcACw0mZzN2+NnudLhu99LZUo1ZxD8XGZqhqJ25BR 5CRjM7wz0t4TZM2vObxwBQhe2AtOnInc5Oli58vz282TNJMhpNHKVhDkT81Jryk4 f/BU6nGnx687+R9dxjgg3GiVS4B10sTQ= Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id A00561F0081 for ; Wed, 17 Jul 2013 20:02:04 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e11so5926163iej.1 for ; Wed, 17 Jul 2013 20:02:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qzPCF/5rhuoY3szY+NdIQvDz/Fcljk3xsSpp3EIjJV0=; b=aYRuv9aXAM6jJIWLnszLnAk9Ya0FS+p95UFPJV06fYpa+RIk1mX5jClTGLY3YjN11D 2YHaPN4dP/rmYIIz51qBJgfiGnsQ7PVvZE9NCVV7LvsvTiHb9TDAcMuqwV0Cg1MmrHKE bHambUOqo2eoIvQRnJ8YPWKHM60dvIDPs/zvLsm6wmsDt4SzV2ivhy3VGMg8u1zmE4ny pxMFZwBWDuJbYq+PJXNTzIioGNB4u3CqOdzkILBjbLC4FB1oXOeEVJe+J2nCLsvZ/7Ev YZyevCdMWR0VH7q7f1EVsGEntLP33qL+C7AqDIlsNd3QuVIrpQyNEgWZiDaF/TSWokOQ yAEA== MIME-Version: 1.0 X-Received: by 10.50.11.103 with SMTP id p7mr2392401igb.24.1374116524112; Wed, 17 Jul 2013 20:02:04 -0700 (PDT) Received: by 10.64.130.169 with HTTP; Wed, 17 Jul 2013 20:02:03 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 22:02:03 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Pete Resnick , "json@ietf.org" , John Cowan , "Joe Hildebrand \(jhildebr\)" , R S Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 03:02:14 -0000 Oh, I just found this: http://snia.org/sites/default/files/Multi-part%20MIME%20Extension%20v1.0g.p= df The following is a quote from that doc, but I'm nto sure that it's really indicative of anything, except awareness that JSON strings "work" for binary data, just very inefficiently: Multi-part MIME Transfer Extension Overview CDMI provides three methods by which the value of a data object may be transferred between CDMI clients and servers: =E2=80=A2 UTF-8 encoding in JSON using a CDMI content type request/response= , =E2=80=A2 Base64 encoding in JSON using a CDMI content type request/respons= e, and =E2=80=A2 raw binary using a non-CDMI content type request/response. UTF-8 encoding is sufficient for most text use cases, and using raw binary transfer provided by the non-CDMI PUT and GET operations is sufficient for some binary use cases. However, there is a need to be able to efficiently transfer binary data alongside CDMI object metadata without incurring the overhead of the UTF-8 or Base64 encoding and validation required to represent binary data in JSON. This proposed extension adds the ability to use a multi-part MIME body with CDMI to allow the value to be included as raw binary data in a separate MIME part of a single CDMI content type request/response that does not require any encoding or validation of the da= ta. From duerst@it.aoyama.ac.jp Wed Jul 17 21:28: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 321EB21F9970 for ; Wed, 17 Jul 2013 21:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.04 X-Spam-Level: X-Spam-Status: No, score=-103.04 tagged_above=-999 required=5 tests=[AWL=0.750, 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 6lAkt1wc-m1h for ; Wed, 17 Jul 2013 21:28:27 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA1121F996F for ; Wed, 17 Jul 2013 21:28:25 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r6I4SBl6030179; Thu, 18 Jul 2013 13:28:11 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0f06_bcef_743a4c10_ef62_11e2_9e32_001e6722eec2; Thu, 18 Jul 2013 13:28:10 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 17895BF4DD; Thu, 18 Jul 2013 13:26:20 +0900 (JST) Message-ID: <51E76EC0.9060708@it.aoyama.ac.jp> Date: Thu, 18 Jul 2013 13:27: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: Tim Bray References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Nico Williams , Pete Resnick , John Cowan , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 04:28:34 -0000 On 2013/07/18 6:34, Tim Bray wrote: > There=E2=80=99s a community that apparently matters but which we=E2=80=99= re not hearing > from. You keep talking about the ECMAscript needs and the ECMAScript PO= V. > This implies that there is a community of implementers whose success > depends on being able to stuff naked surrogates into JSON strings. Cou= ld > we meet one, please? I guess they=E2=80=99d have to be building Brows= er-JS<=3D> > NodeJS apps, and that is a reasonably popular configuration, so it > shouldn=E2=80=99t be that hard to find someone. Could we actually have = one such > person step up and explain their needs? Rob Sayre, this sort of sounds > like your territory, care to chip in? > > Because I=E2=80=99ve been using JSON all the time on a wide variety of = apps for > like 5 years now and I=E2=80=99ve never met anyone who regarded payload= s containing > non-characters as anything but an egregious bug. I'd of course agree with this sentiment. > I=E2=80=99m quite sure that there are groups to whose needs my experien= ce has left > me oblivious. But this debate would work better if we could actually he= ar > from them what their needs are, and what we can't put in 4267bis withou= t > breaking them. -T There's one possibility that just occurred to me, which is actually more=20 in the future than in the past: There is work going on for ECMAScript to get a 'binary' datatype. This=20 will increase the amount of binary data being handled, and this will=20 increase the pressure on JSON to carry binary data. So it may be that even if there isn't much binary data in JSON out there=20 at the moment, it may increase in the future. We might argue that if we finish our work quickly, and make clear that's=20 a very bad idea, we can avoid that (and that would be very good), but in=20 a worst case scenario, that's not what might happen. An alternative would be to think about a new version of JSON (JSON+?)=20 that explicitly handles binary data, too. Regards, Martin. From markus.lanthaler@gmx.net Thu Jul 18 00:17: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 0B3EF21F8426 for ; Thu, 18 Jul 2013 00:17:39 -0700 (PDT) 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 MY9aBjp3KA4F for ; Thu, 18 Jul 2013 00:17:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id F3FB611E80E2 for ; Thu, 18 Jul 2013 00:17:30 -0700 (PDT) Received: from Vostro3500 ([89.190.188.213]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mecqq-1UomGD3kiG-00OKFU for ; Thu, 18 Jul 2013 09:17:28 +0200 From: "Markus Lanthaler" To: References: In-Reply-To: Date: Thu, 18 Jul 2013 09:17:21 +0200 Message-ID: <00a201ce8386$dab05a90$90110fb0$@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: Ac6DWdWkqPakHXlJQm+1zW3FHgGewAALNlgA Content-Language: de X-Provags-ID: V03:K0:bAfy+t7Scq4TqNIA8tRUp5tK9H8p5Kv9tsJvc21pI1RDB6s575m l7ih+24yQosFWXZiKzG1xjyOxJhluP/6hHNHH/qHCd/joCZttQPjCaLR7+o2fOEltVns8YR SmbB5UIZcnikSFihz4/bohSzns6fiM5iHA8OAECI/CFFt48pngrnSgv1/uaPP4xsLX/3NYl 6clvZDlATQnD/VzSSORvw== Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 07:17:39 -0000 On Thursday, July 18, 2013 3:55 AM, Tim Bray wrote: > I read the 18 messages in the thread and the discussion was at the > level of theory. The constituency I=E2=80=99d like to hear from - = actual > developers who actually exchange actual JSON strings that = can=E2=80=99t be > expressed as sequences of Unicode codepoints - remains un-heard from. > Remember that rough consensus & running code thing? I=E2=80=99d = really, > really like to hear about instances of running code that depend on > behavior that flatly contradicts the assertion in the RFC introduction > that JSON strings are sequences of Unicode characters. >=20 > Yes, I understand that: > - the ABNF allows arbitrary 16-bit quantities in strings, despite what > the intro says > - the ECMAScript standardization project has explicitly blessed this > - Douglas Crockford says receiving software should just shut up and > deal with naked surrogates >=20 > I just want to meet and understand the constituency we=E2=80=99re = trying to > serve by allowing behavior that, to 100% of the users of JSON > implementations that I know, is self-evidently incorrect. -T +1, me too -- Markus Lanthaler @markuslanthaler From cowan@ccil.org Thu Jul 18 08:30: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 E4D1721E8122 for ; Thu, 18 Jul 2013 08:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Sza2nA1K3ONT for ; Thu, 18 Jul 2013 08:30:42 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC3321F943C for ; Thu, 18 Jul 2013 08:30:15 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Uzq9j-0002M4-2c; Thu, 18 Jul 2013 11:30:11 -0400 Date: Thu, 18 Jul 2013 11:30:11 -0400 From: John Cowan To: R S Message-ID: <20130718153010.GB27824@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: Nico Williams , Pete Resnick , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 15:30:47 -0000 R S scripsit: > This message from Waldemar Horwat may be informative: > > That message is misleading without its context. It replies to a message of mine which is about CouchDB, as I point out in my reply. CouchDB has nothing to do with ECMAscript. What is more, in that thread I affirm that escaped unpaired surrogates are permitted in JSON; what I am denying is that unescaped unpaired surrogates are permitted in JSON-on-the-wire, which must be encoded in Unicode (that is, in some Unicode character encoding scheme) per the RFC. > If I've learned anything about ECMAScript, it's this: if it works today, > there is unmaintained content depending on it. Breaking content is just > about the worst thing an ECMAScript implementation can do, so none of them > ever will in a market with 5+ credible implementations. +1 > I'd recommend reading the entire thread I linked, particularly the messages > from Jason Orendorff and Douglas Crockford. Nothing has changed in the four > years since, which should tell this WG that we are not here to legislate > correctness, but to document the status quo. The trouble is that there are too many status quos. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin From jhildebr@cisco.com Thu Jul 18 08:53:03 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 7494821E8102 for ; Thu, 18 Jul 2013 08:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.639 X-Spam-Level: X-Spam-Status: No, score=-10.639 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 EYkN5d8HxEp8 for ; Thu, 18 Jul 2013 08:52:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE0C11E8175 for ; Thu, 18 Jul 2013 08:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=940; q=dns/txt; s=iport; t=1374162769; x=1375372369; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nSmV5cL0UkuSbQ18Dq3w6EYPV9lquTfJCEjT9uP+Hfo=; b=b0C9ylThJ3L99wvOtovxT043hLjmgrH2tAzc1GuP5XTCFFaHzXlI2c44 xqNUIsldFcfHHbrRPVICDhIgOw3lUry6L8lYTMaotmuW8xQg31ksg91Sf bLOtWnSnLKhaeTPpnv+NwAULfTQLGThI8VIMx52NMUMYR0kNXe74OnUEL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAGgO6FGtJV2d/2dsb2JhbABagwaBBcBEgREWdIImAQEDOj8SAQgiFEIlAgQOBQiICLYtj14xB4MObgOpKoMSgio X-IronPort-AV: E=Sophos;i="4.89,694,1367971200"; d="scan'208";a="236309494" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jul 2013 15:52:48 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6IFqmIR009593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 15:52:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 10:52:48 -0500 From: "Joe Hildebrand (jhildebr)" To: John Cowan Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOgnCdR+yeems0Nke/XW02cZd1o5loXUWAgAC/xAD///8AgIAAflYA//+ptQCAALFugIAAkouA Date: Thu, 18 Jul 2013 15:52:47 +0000 Message-ID: In-Reply-To: <20130718010817.GC29248@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.5.130515 x-originating-ip: [10.21.115.243] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nico Williams , Pete Resnick , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 15:53:03 -0000 On 7/17/13 7:08 PM, "John Cowan" wrote: >Joe Hildebrand (jhildebr) scripsit: > >> Agree. Note that the difference between "string MAY contain unpaired >> surrogates" and "string MUST NOT contain unpaired surrogates, and >>parsers >> MAY maintain as much state as possible when they detect a parse error" >>is >> pretty slim. > >Au contraire, it is fundamental. If they MAY contain unpaired surrogates, >then it is legitimate to use JSON strings to encode sequences of >arbitrary 16-bit integers (with proper escaping). If they MUST NOT, >then it is not legitimate to do so even if it happens to work for some >generator-parser combinations. I would be perfectly fine with telling people that this use of JSON is illegitimate, but still having it work sometimes if you can control both endpoints - knowing that what you're doing is unlikely to widely interoperate. --=20 Joe Hildebrand From derhoermi@gmx.net Thu Jul 18 10:37: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 D66E621E814C for ; Thu, 18 Jul 2013 10:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, J_CHICKENPOX_83=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 q2glz6xdM9c1 for ; Thu, 18 Jul 2013 10:37:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5A47511E81A1 for ; Thu, 18 Jul 2013 10:37:45 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.51.152]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0M8e5P-1UEWI93MEl-00wExz for ; Thu, 18 Jul 2013 19:37:44 +0200 From: Bjoern Hoehrmann To: Tim Bray Date: Thu, 18 Jul 2013 19:37:43 +0200 Message-ID: <5t3gu89ogvb0e9093udnn1egjs7l8knpqj@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:fVVg78GqsL3/OCTEpW7eu3dVG9WJXXLLNPcZamCjGRKSdneQsfQ pUbdcFUCpOOfs16rFanLWrtTNj/PtlQI9fI5amnbbEsqGPV17G4T9GgJg0B+oYnqCfF1ngg bcppuMNyUTFok9+bJoXdMwgRR2IuJb21+Q6fV8DTQ1JCoUpGTPmJlZl8AzlspfI8Lz70ckk kxQyZK55cdYsTdAinxJZQ== Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 17:37:51 -0000 * Tim Bray wrote: >I read the 18 messages in the thread and the discussion was at the level of >theory. The constituency I’d like to hear from - actual developers who >actually exchange actual JSON strings that can’t be expressed as sequences >of Unicode codepoints - remains un-heard from. Remember that rough >consensus & running code thing? I’d really, really like to hear about >instances of running code that depend on behavior that flatly contradicts >the assertion in the RFC introduction that JSON strings are sequences of >Unicode characters. I am such a developer and you are failing to appreciate that making sure code does not end up generating JSON with isolated surrogates is a lot of hard work that the common libraries do not help you with. The onus is rather on you to show us that running code actively sanatises strings to keep isolated surrogates away from the JSON serialisers, or that typical libraries do that for you, or refuse to serialise strings with them. In ecmascript JSON.stringify does not mind isolated surrogates and there are no sanitisation options. There are three options to do that yourself by traversing an object replacing its strings as necessary, or creating a copy to the same effect, replacing the surrogate escapes in the result string, or using the replacer function feature. The code for the latter in http://www.ietf.org/mail-archive/web/json/current/msg01170.html was JSON.stringify(obj, function(key, value) { if (typeof value == 'string') { return value.replace(/.../g, "\uFFFD"); } return value; }) That is not something that people actually do in practise. People also do not usually try to transmit isolated surrogate code points on purpose but they do things like truncating strings to the first 140 16-bit code units because that is how their String.substring function works, without them ever having heard about Unicode surrogates. In Perl the JSON modules JSON::XS and JSON::PP have no problem printing out isolated surrogate escapes and there is no sanitisation option I've been able to find. Am I supposed to regex them out of the serialized JSON text? Can you write down the regex substitution code in a language of your choice in under one minute and have it work correctly on first try? In Microsoft's .NET framework for the DataContractJsonSerializer I do not see any documentation how to make it sanatise isolated surrogates, and by default it happily passes them through as `\u....` escapes; and in C# "\U0010FFFF".Length is 2 of course, so all substring operations risk making JSON protocol breaking mistakes, if you had it your way. Perhaps you can talk to the developers of Google's Gson library to tell them about self-evidently incorrect behavior and an egregious bug you've discovered in their code? What makes you think these actual developers who generate isolated surrogates in JSON when somebody puts a non-BMP character in a place they did not anticipate aren't actually almost all of us? -- 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 Thu Jul 18 11:06: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 4E9AD21E8162 for ; Thu, 18 Jul 2013 11:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.616 X-Spam-Level: X-Spam-Status: No, score=-3.616 tagged_above=-999 required=5 tests=[AWL=-0.640, 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 AiKO5Frdbs7I for ; Thu, 18 Jul 2013 11:06:41 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 779E221E8164 for ; Thu, 18 Jul 2013 11:06:37 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id ox1so2737332veb.41 for ; Thu, 18 Jul 2013 11:06:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZWERjf5pBwwS1TyfVPsl0/wy7l1MSNQUNTQumZnYtUY=; b=pRJhyrNhxUzePsWNshJwHvHm/aZGrCor4RppQX+znG07P1e6TI16beX9viwwgjdK6W E0fAQz85pXGXtY/5usMolBI+qIqsmdAaJG0t2RqdU0ks6Gv5Kj4rE4Mit1QEvVYwp4VS 9dq618YGTGtv4LnFILu7jIlnUVma5JukSRnf9rpxC7MUNNrJxPFVYAUO3b99MDEpPO9g WbvpRCd5cQryzxFW5Eu77NNhkEJLdrwwhxJzyUqAAtS5wO9R8M6PIdTTKDQsZIl2j9Yw bY9G/yOPx0SLAs3N8jcHaoqdbXhFARHOuTGPSKccYzPc4q6I+KLvD2LWnxqj4XsI6mtm bhOA== MIME-Version: 1.0 X-Received: by 10.58.155.37 with SMTP id vt5mr4530678veb.41.1374170796751; Thu, 18 Jul 2013 11:06:36 -0700 (PDT) Received: by 10.220.219.200 with HTTP; Thu, 18 Jul 2013 11:06:36 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <5t3gu89ogvb0e9093udnn1egjs7l8knpqj@hive.bjoern.hoehrmann.de> References: <5t3gu89ogvb0e9093udnn1egjs7l8knpqj@hive.bjoern.hoehrmann.de> Date: Thu, 18 Jul 2013 11:06:36 -0700 Message-ID: From: Tim Bray To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=047d7b67239a33981304e1cd1220 X-Gm-Message-State: ALoCoQnCewtYmUhYKB8yhlPfZ61ZOmfZDc1kT0Mn8XKVQvy6ENJffR2tX+FKDfrSOZEHGCa54NSa Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 18:06:46 -0000 --047d7b67239a33981304e1cd1220 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, thanks Bjoern, we have the first actual real example of how naked surrogates could reasonably arise in a real application: On Thu, Jul 18, 2013 at 10:37 AM, Bjoern Hoehrmann wrote= : > > I am such a developer Actually, you haven=E2=80=99t quite convinced me that your software=E2=80= =99s working correctly depends on being able to stuff naked surrogates into JSON strings. But... > People also > do not usually try to transmit isolated surrogate code points on purpose > but they do things like truncating strings to the first 140 16-bit code > units because that is how their String.substring function works, without > them ever having heard about Unicode surrogates. > And there=E2=80=99s the use case. Nobody actually *wants* to interchange n= aked surrogates, it=E2=80=99s just that there=E2=80=99s a cost to implementing t= hings like Substring() to avoid this happening, and it hasn=E2=80=99t been done. BTW,= I have previously (10 years ago!) complained publicly about the broken behavior of Java string-handling: http://www.tbray.org/ongoing/When/200x/2003/04/30/JavaStrings#p-1 A genuinely new contribution to the conversation; thanks once again. I=E2= =80=99ll have to think some to figure out whether this changes my opinion. -T --047d7b67239a33981304e1cd1220 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, thanks Bjoern, we have the first actual real example o= f how naked surrogates could reasonably arise in a real application:
On Thu, Jul 18, 2013 at 10:37 AM, Bjoern Hoehrmann <<= a href=3D"mailto:derhoermi@gmx.net" target=3D"_blank">derhoermi@gmx.net= > wrote:

I am such a developer

Actually, you h= aven=E2=80=99t quite convinced me that your software=E2=80=99s working corr= ectly depends on being able to stuff naked surrogates into JSON strings.=C2= =A0 But...
=C2=A0
=C2=A0 P= eople also
do not usually try to transmit isolated surrogate code points on purpose but they do things like truncating strings to the first 140 16-bit code
units because that is how their String.substring function works, without them ever having heard about Unicode surrogates.

<= /div>
And there=E2=80=99s the use case.=C2=A0 Nobody actually *wants* t= o interchange naked surrogates, it=E2=80=99s just that there=E2=80=99s a co= st to implementing things like Substring() to avoid this happening, and it = hasn=E2=80=99t been done.=C2=A0 BTW, I have previously (10 years ago!) comp= lained publicly about the broken behavior of Java string-handling: http= ://www.tbray.org/ongoing/When/200x/2003/04/30/JavaStrings#p-1

A genuinely new contribution to the conversation; thanks onc= e again.=C2=A0 I=E2=80=99ll have to think some to figure out whether this c= hanges my opinion. -T


--047d7b67239a33981304e1cd1220-- From jhildebr@cisco.com Thu Jul 18 12:33: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 B449B11E81CB for ; Thu, 18 Jul 2013 12:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 YqABYzaIeKDw for ; Thu, 18 Jul 2013 12:33:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 10E6411E81CC for ; Thu, 18 Jul 2013 12:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=405; q=dns/txt; s=iport; t=1374176017; x=1375385617; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2nvrRCNAyl43lo9wZn1TOt/8X6UZPaShd5lMaM9gLHo=; b=anIfDbS4bl1eDs11z47aHA7BI7P+P4nmkmpPDOT3IXCI7kwhGoqRd6Yi fvQONgjQjnKdHhySf/6OqEVUxkVciI2ayiJDUnv9wMlvVUBnwUq4JZFd1 6avRoDhQsLDEgUnvVF5uOIekLaBNs6uSG8exO9nAsKHVzSU/Gx0YzMYUs 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAA1C6FGtJV2c/2dsb2JhbABagwaBBcBEgRMWdIImAQEDeRIBCA4UViUCBAENBQiICLYej1wCMQeDDm4DiHCgOoMSgio X-IronPort-AV: E=Sophos;i="4.89,695,1367971200"; d="scan'208";a="236691829" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 18 Jul 2013 19:33:36 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6IJXaqZ020205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 19:33:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 14:33:35 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , Bjoern Hoehrmann Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOg1OfR+yeems0Nke/XW02cZd1o5lqAMiAgAEHZoCAAAgSAP//s7QA Date: Thu, 18 Jul 2013 19:33:35 +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.5.130515 x-originating-ip: [10.129.24.242] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5F064CF14FD14848934A30019575CD01@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 18 Jul 2013 19:33:42 -0000 On 7/18/13 12:06 PM, "Tim Bray" wrote: >A genuinely new contribution to the conversation; thanks once again. >I=B9ll have to think some to figure out whether this changes my opinion. -= T Agree. One possible approach would be to say that we use this illegitimatization of isolated surrogates to explore how to make the problem better over time. --=20 Joe Hildebrand From tbray@textuality.com Wed Jul 24 10:49: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 440A711E821B for ; Wed, 24 Jul 2013 10:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_24=1.552, 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 9-nQhlnCNwXc for ; Wed, 24 Jul 2013 10:49:15 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id CAE8C11E80F8 for ; Wed, 24 Jul 2013 10:49:13 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id fj20so572902lab.12 for ; Wed, 24 Jul 2013 10:49:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=CK2SU3DcW/DCFbhxesv0T3DDB7UouI6UaTpRzI/CN6U=; b=LUTq5Ms+FKJR0o83MmMjfk5YCCEbDJsSRSSwcic2a5jYqGvDG0SkvpFFPStat2+G/P 1TItG29XLGr15ogjE973tvVI8mm/9QReuuK9MCQDPdsUe/miMwqUi4nQGQMjt8nQlJV9 uqiNWCyM7v6SyfMVpwKb2jtTKnyHh58xfCcNX6+MXIxv9pM/k8QVHFWDNhZntrfI3SQD 6wj8KpnhQqFxwC5jaj+fswEHmDFAJ/jO8HYmyyRIur71l2kqtcekp+eQ1RhpGLG9bndn ADJfx3ppjKTC3d2ZQtbXpWK7JIe8lF/CsIup9QS9LcG64pU/ke++WDUSs9vuSd4mmRmN vajw== MIME-Version: 1.0 X-Received: by 10.152.8.198 with SMTP id t6mr17615860laa.36.1374688151074; Wed, 24 Jul 2013 10:49:11 -0700 (PDT) Received: by 10.114.21.132 with HTTP; Wed, 24 Jul 2013 10:49:10 -0700 (PDT) X-Originating-IP: [208.54.32.135] In-Reply-To: References: <5t3gu89ogvb0e9093udnn1egjs7l8knpqj@hive.bjoern.hoehrmann.de> Date: Wed, 24 Jul 2013 10:49:10 -0700 Message-ID: From: Tim Bray To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=089e0153844aec08d604e2458630 X-Gm-Message-State: ALoCoQmCZiBvLW6l3cgDYeq0XiiM9qFcVGFrJt77QnnrArfr3Z36rL/AJdb671Ez4PVp8umkDw3v Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 24 Jul 2013 17:49:21 -0000 --089e0153844aec08d604e2458630 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 18, 2013 at 11:06 AM, Tim Bray wrote: > OK, thanks Bjoern, we have the first actual real example of how naked > surrogates could reasonably arise in a real application: > >> People also >> do not usually try to transmit isolated surrogate code points on purpose >> but they do things like truncating strings to the first 140 16-bit code >> units because that is how their String.substring function works, without >> them ever having heard about Unicode surrogates. >> > > And there=E2=80=99s the use case. Nobody actually *wants* to interchange= naked > surrogates, it=E2=80=99s just that there=E2=80=99s a cost to implementing= things like > Substring() to avoid this happening, and it hasn=E2=80=99t been done. > So, someone jogged me and said =E2=80=9CSo have you anti-naked-surrogate ty= pes changed your minds?=E2=80=9D After reflection, I ended up back where I started. We still haven=E2=80=99t heard from anyone whose success depends on being a= ble ot use JSON strings for non-character uses involving naked surrogates. We have heard one scenario how a buggy-but-popular Java library could accidentally create one. I think that for 4267bis it remains an error condition that should be warned against, and should we proceed to do i-json or equivalent, it should become a MUST NOT; when you=E2=80=99re doing network interop, the implement= er burden of doing a post-truncation check when your library is known to be buggy is not excessive. --089e0153844aec08d604e2458630 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 18, 2013 at 11:06 AM, Tim Bray <tbray@text= uality.com> wrote:
OK, than= ks Bjoern, we have the first actual real example of how naked surrogates co= uld reasonably arise in a real application:
=C2=A0 People also
do not usually try to transmit isolated surrogate code points on purpose but they do things like truncating strings to the first 140 16-bit code
units because that is how their String.substring function works, without them ever having heard about Unicode surrogates.

<= /div>
And there=E2=80=99s the use case.=C2=A0 Nobody actually *wa= nts* to interchange naked surrogates, it=E2=80=99s just that there=E2=80=99= s a cost to implementing things like Substring() to avoid this happening, a= nd it hasn=E2=80=99t been done.

So, som= eone jogged me and said =E2=80=9CSo have you anti-naked-surrogate types cha= nged your minds?=E2=80=9D

After reflection, I ended up back where I = started.=C2=A0

We still=20 haven=E2=80=99t heard from anyone whose success depends on being able ot us= e=20 JSON strings for non-character uses involving naked surrogates.=C2=A0 We ha= ve heard one scenario how a buggy-but-popular Java library could=20 accidentally create one.=C2=A0

I think that for 4267bis it remains an error condition that should=20 be warned against, and should we proceed to do i-json or equivalent, it=20 should become a MUST NOT; when you=E2=80=99re doing network interop, the=20 implementer burden of doing a post-truncation check when your library is known to be buggy is not excessive.



--089e0153844aec08d604e2458630-- From jhildebr@cisco.com Thu Jul 25 00:37: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 6C7F821F88FE for ; Thu, 25 Jul 2013 00:37:21 -0700 (PDT) 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 bOgBL1Ge3bZG for ; Thu, 25 Jul 2013 00:37:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 10F0B21F88DB for ; Thu, 25 Jul 2013 00:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=932; q=dns/txt; s=iport; t=1374737831; x=1375947431; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Ko5lloDBCFe4pzUukzrvc3JborBn/mjHfWNIfuVSN7g=; b=lp0VfdnJkAGu+h/8S8pBvp55x9o+cAYbVP1WfKzU1wuxMZhmoy0/pBG9 0sfLIYNwZe8KxVkwSYB995XwOvIPFtWCdEGAQBPpq0EqW3jCNnv6q4Im3 8GYvSMhBpfNL45vZQBx1SmneF3ynHLtHh/YH8eBSFoUTkSjbIgOZXd0rv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAGvV8FGtJV2Z/2dsb2JhbABagwaBBYJFuxmBGBZ0giYBBHkSAQgOFFYlAgQBDQUIiAi6G49KAjEHgxJuA4hyoDqDFIFoBjw X-IronPort-AV: E=Sophos;i="4.89,741,1367971200"; d="scan'208";a="239239784" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jul 2013 07:36:52 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6P7ap1A017231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 07:36:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.35]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 02:36:51 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , Bjoern Hoehrmann Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOiJZQiE83XeIGWkix+H3zUQ7zg5l08XsA Date: Thu, 25 Jul 2013 07:36:50 +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.6.130613 x-originating-ip: [10.21.88.76] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7199355DBE59B24580ADCCCF6F42E790@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 25 Jul 2013 07:37:21 -0000 On 7/24/13 11:49 AM, "Tim Bray" wrote: >After reflection, I ended up back where I started. > >We still haven=B9t heard from anyone whose success depends on being able o= t >use JSON strings for non-character uses involving naked surrogates. We >have heard one scenario how a buggy-but-popular Java library could >accidentally create one. > > >I think that for 4267bis it remains an error condition that should be >warned against, and should we proceed to do i-json or equivalent, it >should become a MUST NOT; when you=B9re doing network interop, the >implementer burden of doing a post-truncation check when your library is >known to be buggy is not excessive. Agree, with the further stipulation that I'd like to recommend some ways to process the error, to make it clear why senders can't depend on a receiving implementation choosing a specific approach. --=20 Joe Hildebrand From tbray@textuality.com Thu Jul 25 00:42: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 7BB9821F8C71 for ; Thu, 25 Jul 2013 00:42:53 -0700 (PDT) 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 ftkFzz0rhU0O for ; Thu, 25 Jul 2013 00:42:47 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3BE21F9287 for ; Thu, 25 Jul 2013 00:42:47 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id eh20so1119881lab.15 for ; Thu, 25 Jul 2013 00:42:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=hJJsqnDu9D6xMqxVE0EsAKncqDzXwIEsfZFaAmgxrgc=; b=OhotH76+Cm+yIA9Y2I9psGSxSZtOh5lFmIgUM4d7B3BAaB5jRvUT+yXqekEFJ/Kro3 1iCQgsSqNJ7wu+DbstfrAmgO73qNVfXB2k3k8PIqNnEpSGdlNdlsXSrJFmtbBpBTNi68 4yOLKD0utMvOFeWJNRTx0YsO/K863Q0elGtoWPO5qWJm7mr4shm8E34c9mmRP8u888a0 8BO8C/5lmAHgCiUvhahJuuAuOqJnqRDRKDR29eyDMFlE9n9xRmEnENZGqv42stnmGaIF leHQ7JpJc4cx1P4Dd1dminO2+d9ns/ZQRJfOa1kHfuFRxT9HVIB0AoWJTu1A4CRyrjot 9Kcw== MIME-Version: 1.0 X-Received: by 10.152.8.198 with SMTP id t6mr18748642laa.36.1374738166136; Thu, 25 Jul 2013 00:42:46 -0700 (PDT) Received: by 10.114.21.132 with HTTP; Thu, 25 Jul 2013 00:42:45 -0700 (PDT) X-Originating-IP: [70.102.97.201] In-Reply-To: References: Date: Thu, 25 Jul 2013 00:42:45 -0700 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=089e0153844a0d509304e2512c9a X-Gm-Message-State: ALoCoQkvnq/5HQjdMUpFRTB6Y1LmfRdMSa3x0naz0kVZoJZ0Ci/0wEehXCL4nVnu1w9ZzcRsBpMr Cc: Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 25 Jul 2013 07:42:53 -0000 --089e0153844a0d509304e2512c9a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good idea. Do you have a recommendation, Joe? Now would be a good time to make it. -T On Thu, Jul 25, 2013 at 12:36 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > > On 7/24/13 11:49 AM, "Tim Bray" wrote: > > >After reflection, I ended up back where I started. > > > >We still haven=C2=B9t heard from anyone whose success depends on being a= ble ot > >use JSON strings for non-character uses involving naked surrogates. We > >have heard one scenario how a buggy-but-popular Java library could > >accidentally create one. > > > > > >I think that for 4267bis it remains an error condition that should be > >warned against, and should we proceed to do i-json or equivalent, it > >should become a MUST NOT; when you=C2=B9re doing network interop, the > >implementer burden of doing a post-truncation check when your library is > >known to be buggy is not excessive. > > Agree, with the further stipulation that I'd like to recommend some ways > to process the error, to make it clear why senders can't depend on a > receiving implementation choosing a specific approach. > > -- > Joe Hildebrand > > > > --089e0153844a0d509304e2512c9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good idea. Do you have a recommendation, Joe? Now would be= a good time to make it. -T


On Thu, Jul 25, 2013 at 12:36 AM, Joe Hildebrand (j= hildebr) <jhildebr@cisco.com> wrote:

On 7/24/13 11:49 AM, "Tim Bray" <tbray@textuality.com> wrote:

>After reflection, I ended up back where I started.
>
>We still haven=C2=B9t heard from anyone whose success depends on being = able ot
>use JSON strings for non-character uses involving naked surrogates. =C2= =A0We
>have heard one scenario how a buggy-but-popular Java library could
>accidentally create one.
>
>
>I think that for 4267bis it remains an error condition that should be >warned against, and should we proceed to do i-json or equivalent, it >should become a MUST NOT; when you=C2=B9re doing network interop, the >implementer burden of doing a post-truncation check when your library i= s
>known to be buggy is not excessive.

Agree, with the further stipulation that I'd like to recommend so= me ways
to process the error, to make it clear why senders can't depend on a receiving implementation choosing a specific approach.

--
Joe Hildebrand




--089e0153844a0d509304e2512c9a-- From sayrer@gmail.com Thu Jul 25 01:05: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 7AAE221F9A16 for ; Thu, 25 Jul 2013 01:05:13 -0700 (PDT) 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, 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 OkO34wijTL1a for ; Thu, 25 Jul 2013 01:05:12 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1809E21F99F4 for ; Thu, 25 Jul 2013 01:05:04 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id l18so1331292wgh.35 for ; Thu, 25 Jul 2013 01:05:04 -0700 (PDT) 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=uEdL6rgvxwl6Q6QAQk2P0JwqclNsGTXtFaDWe/+YITo=; b=YcAsN2COFuJGeaLCBzGtuL0l2TgHL4f/1TwcfHV+6EojF/rTXUwvYx3v0uipACBDPt kyB8AjNIdGuyAQjQLMRSzY0o7U8GxnGL7lYA9sRAXh4irfSjzlJOcOZYsIley2bKZG3W CkG0OAmOkmj1BpAbvR09G2qLR9Zbvb3f0EyqQuKcZWe+x8IER98Q28FhfgheI0pkNSDV hv3GXLIu3wzEKr1+kD4SE4zprSYP/UGaIJc1sRoNVlhg/UDmALv9EoxDn+WxMMfkDSKA yFJLW/BdS5hcNdAjvse2Ut5iaXY68Ttq3x5/J66bAbenQJOumXGGbUMf3j5d0X4Wnd4X cpVg== MIME-Version: 1.0 X-Received: by 10.194.58.239 with SMTP id u15mr29588770wjq.87.1374739504244; Thu, 25 Jul 2013 01:05:04 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Thu, 25 Jul 2013 01:05:04 -0700 (PDT) Received: by 10.194.44.138 with HTTP; Thu, 25 Jul 2013 01:05:04 -0700 (PDT) In-Reply-To: References: <5t3gu89ogvb0e9093udnn1egjs7l8knpqj@hive.bjoern.hoehrmann.de> Date: Thu, 25 Jul 2013 01:05:04 -0700 Message-ID: From: R S To: Tim Bray Content-Type: multipart/alternative; boundary=047d7ba97b94cf2fe804e2517b35 Cc: Bjoern Hoehrmann , json@ietf.org Subject: Re: [Json] Questions regarding the text model in 4627 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, 25 Jul 2013 08:05:13 -0000 --047d7ba97b94cf2fe804e2517b35 Content-Type: text/plain; charset=ISO-8859-1 On Jul 24, 2013 10:50 AM, "Tim Bray" wrote: > > I think that for 4267bis it remains an error condition That rhetoric is not convincing to me. People stick random bytes, the results of hash functions, etc into JavaScript strings. Newer APIs do use typed arrays and avoid this, but JSON doesn't have a direct analog. More importantly, claiming that this is some kind of an error is inaccurate. I don't think any of these seemingly credible implementors will show up, because they don't have to. This working group can write down what actually works or it can lie. The running code will still run, and the rough consensus will remain. It's common for IETF participants to think "rough consensus" refers to the working group. Sometimes it does. For standards that are actually widely used, the group is the wider Internet. - Rob --047d7ba97b94cf2fe804e2517b35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 24, 2013 10:50 AM, "Tim Bray" <tbray@textuality.com> wrote:
>
> I think that for 4267bis it remains an error condition

That rhetoric is not convincing to me. People stick random b= ytes, the results of hash functions, etc into JavaScript strings. Newer API= s do use typed arrays and avoid this, but JSON doesn't have a direct an= alog.

More importantly, claiming that this is some kind of an erro= r is inaccurate. I don't think any of these seemingly credible implemen= tors will show up, because they don't have to. This working group can w= rite down what actually works or it can lie. The running code will still ru= n, and the rough consensus will remain.

It's common for IETF participants to think "rough c= onsensus" refers to the working group. Sometimes it does. For standard= s that are actually widely used, the group is the wider Internet.

- Rob

--047d7ba97b94cf2fe804e2517b35-- From jhildebr@cisco.com Thu Jul 25 11:46: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 511A521F8E98 for ; Thu, 25 Jul 2013 11:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.999 X-Spam-Level: X-Spam-Status: No, score=-11.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 cSfPbdpfTes4 for ; Thu, 25 Jul 2013 11:45:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8B21121F85B4 for ; Thu, 25 Jul 2013 11:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4707; q=dns/txt; s=iport; t=1374777956; x=1375987556; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1YHJ7ErXnskZuUuvs9rfW96n7bUAfqFypB1ABvOZcnc=; b=SMLwNMrn0G1DzHzNrhGbnadHiESRX5m+yolY0Mj2OU1kbsM8tS6Xi5P2 sMqKKYIZA7JQtDsynIJTldUJZ9hKY3MJ7VhGSx/+YClzGco4HtRdCHngB wSMk8gZRL2wlKHdvZ+mnoJ+oZ3Q+Fq5gsbUAOmvbj8iOnZniIvWrShLTF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAAJy8VGtJV2b/2dsb2JhbABbgwaBBb1hgRcWdIImAQQ6LRISAQgOFBRCJQIEDgUIiAi6Co9MMQeDEm4DqSyDFIIq X-IronPort-AV: E=Sophos;i="4.89,744,1367971200"; d="scan'208";a="239316134" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jul 2013 18:45:56 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6PIjuOu003545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 18:45:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.35]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 13:45:55 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOiJZQiE83XeIGWkix+H3zUQ7zg5l08XsAgABmRICAAFSwAA== Date: Thu, 25 Jul 2013 18:45:55 +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.6.130613 x-originating-ip: [10.129.24.242] Content-Type: text/plain; charset="us-ascii" Content-ID: <33FE3EAEC7047D4B876E2BE58A0EF712@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 25 Jul 2013 18:46:02 -0000 On 7/25/13 1:42 AM, "Tim Bray" wrote: >Good idea. Do you have a recommendation, Joe? Now would be a good time to >make it. -T Yes. This is a start: """ 2.5 Strings The representation of strings is similar to conventions used in the C family of programming languages. A string begins and ends with quotation marks. All Unicode scalar values may be placed within the quotation marks except for the characters that must be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F). Note that Unicode code points that are reserved for UTF-16 surrogates (U+D800 through U+DFFF) are not valid Unicode scalar values. Any Unicode scalar value may be escaped. If the Unicode scalar value is in the Basic Multilingual Plane (U+0000 through U+D7FF and U+E000 through U+FFFF), then it may be represented as a six-character sequence: a reverse solidus, followed by the lowercase letter u, followed by four hexadecimal digits that encode the Unicode scalar value's code point. The hexadecimal letters A though F can be upper- or lowercase. So, for example, a string containing only a single reverse solidus character may be represented as "\u005C". Alternatively, there are two-character sequence escape representations of some popular characters. So, for example, a string containing only a single reverse solidus character may be represented more compactly as "\\". To escape an Unicode scalar value that is not in the Basic Multilingual Plane, the character is represented as a twelve-character sequence, encoding the UTF-16 surrogate pair that corresponds to the code point for the Unicode scalar value. So, for example, a string containing only the G clef character (U+1D11E) may be represented as "\uD834\uDD1E". To compare strings for equality (for example, the uniqueness of names in an object), escape sequences of any of the previous three kinds MUST be normalized, then the strings are compared code point by code point. If errors occur in string parsing, such as: - unescaped surrogates after decoding - unpaired escaped surrogate - invalid second character in a two-character escape sequence implementations MAY make one of several different choices: - return an error and stop processing. This is RECOMMENDED for security-sensitve deployments. - replace the offending code point with U+FFFD (REPLACEMENT CHARACTER). Strings that are intended to be human-readable might take this approach. - keep as much data as possible. For example, some programming environments allow unpaired surrogates in their string representations, so unpaired surrogates may be retained. This approach is used by several existing implementations. Because there are multiple valid choices for how to process invalid data, senders SHOULD ensure that their strings are valid according to the above rules. Existing implementations are strongly encouraged to be updated to always generate valid strings. Examples of use cases to test include: - string slicing operations that operate on 16-bit code units, rather than code points, which might generate an unpaired high surrogate at the beginning or end of the substring - unpaired surrogates that are valid in a given programming language New implementations MUST NOT rely on a specific error implementation choice for interoperability. char =3D unescaped / named-escape / bmp-escape / extended-escape unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF named-escape =3D escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 ) ; t tab U+0009 escape =3D %x5C ; \ bmp-escape =3D escape %x75 ( not-d-hex 3HEXDIG / "D" %x30-37 2HEXDIG ) not-d-hex =3D DIGIT / "A" / "B" / "C" / "E" / "F" ; hex, except for D extended-escape =3D high-surrogate low-surrogate high-surrogate =3D escape %x75 "D" high-hex 2HEXDIG high-hex =3D %x38-39 / "A" / "B" low-surrogate =3D escape %x75 "D" low-hex 2HEXDIG low-hex =3D "C" / "D" / "E" / "F" """ --=20 Joe Hildebrand From duerst@it.aoyama.ac.jp Fri Jul 26 00:52: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 0899E21F92B7 for ; Fri, 26 Jul 2013 00:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.49 X-Spam-Level: X-Spam-Status: No, score=-104.49 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_14=0.6, 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 v8SqZRxlMyIG for ; Fri, 26 Jul 2013 00:52:08 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 32C5321F8E2D for ; Fri, 26 Jul 2013 00:52:08 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r6Q7pdSm020437; Fri, 26 Jul 2013 16:51:39 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 36b3_30ae_3439c728_f5c8_11e2_871a_001e6722eec2; Fri, 26 Jul 2013 16:51:39 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D5DECBF535; Fri, 26 Jul 2013 16:49:39 +0900 (JST) Message-ID: <51F22A69.7030503@it.aoyama.ac.jp> Date: Fri, 26 Jul 2013 16:51:05 +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: "Joe Hildebrand (jhildebr)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bjoern Hoehrmann , Tim Bray , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 26 Jul 2013 07:52:15 -0000 Some detailed comments inline: On 2013/07/26 3:45, Joe Hildebrand (jhildebr) wrote: > On 7/25/13 1:42 AM, "Tim Bray" wrote: > >> Good idea. Do you have a recommendation, Joe? Now would be a good time to >> make it. -T > > Yes. This is a start: > > """ > 2.5 Strings > > > The representation of strings is similar to conventions used in the C > family of programming languages. A string begins and ends with > quotation marks. All Unicode scalar values may be placed within the > quotation marks except for the characters that must be escaped: > quotation mark, reverse solidus, and the control characters (U+0000 > through U+001F). Note that Unicode code points that are reserved for > UTF-16 surrogates (U+D800 through U+DFFF) are not valid Unicode scalar > values. > > > Any Unicode scalar value may be escaped. If the Unicode scalar value > is in the Basic Multilingual Plane (U+0000 through U+D7FF and U+E000 > through U+FFFF), then it may be represented as a six-character > sequence: a reverse solidus, followed by the lowercase letter u, > followed by four hexadecimal digits that encode the Unicode scalar > value's code point. The hexadecimal letters A though > F can be upper- or lowercase. So, for example, a string containing > only a single reverse solidus character may be represented as > "\u005C". > > Alternatively, there are two-character sequence escape > representations of some popular characters. So, for example, a > string containing only a single reverse solidus character may be > represented more compactly as "\\". Better add a pointer here to the list of these escapes. > To escape an Unicode scalar value that is not in the Basic Multilingual > Plane, the character is represented as a twelve-character sequence, > encoding the UTF-16 surrogate pair that corresponds to the code point > for the Unicode scalar value. So, for example, a string > containing only the G clef character (U+1D11E) may be represented as > "\uD834\uDD1E". > > To compare strings for equality (for example, the uniqueness of names > in an object), escape sequences of any of the previous three kinds MUST > be normalized, I don't think normalizing escape sequences is the right term. I'd say unescaping. > then the strings are compared code point by code point. > > > If errors occur in string parsing, such as: > - unescaped surrogates after decoding The "after decoding" doesn't add anything here (except potential confusion). > - unpaired escaped surrogate > - invalid second character in a two-character escape sequence The first item is plural, the rest singular. I'd choose one or the other. > implementations MAY make one of several different choices: > - return an error and stop processing. This is RECOMMENDED for > security-sensitve deployments. > - replace the offending code point with U+FFFD (REPLACEMENT CHARACTER). > Strings that are intended to be human-readable might take this > approach. Strings don't take any approach. -> "This approach might be taken for Strings intended to be human-readable." or "This approach is suitable for strings intended for display to humans." or some such. > - keep as much data as possible. For example, some programming > environments allow unpaired surrogates in their string > representations, so unpaired surrogates may be retained. > This approach is used by several existing implementations. I'd change "allow" to "tolerate". > Because there are multiple valid choices for how to process invalid > data, senders SHOULD ensure that their strings are valid according to > the above rules. Existing implementations are strongly encouraged to > be updated to always generate valid strings. Examples of use cases to > test include: > > - string slicing operations that operate on 16-bit code units, rather > than code points, which might generate an unpaired high surrogate > at the beginning or end of the substring > - unpaired surrogates that are valid in a given programming language I'd change the "valid" to something like "tolerated" or so. Regards, Martin. > New implementations MUST NOT rely on a specific error implementation > choice for interoperability. > > > char = unescaped / named-escape / bmp-escape / extended-escape > unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF > named-escape = > escape ( > %x22 / ; " quotation mark U+0022 > %x5C / ; \ reverse solidus U+005C > %x2F / ; / solidus U+002F > %x62 / ; b backspace U+0008 > %x66 / ; f form feed U+000C > %x6E / ; n line feed U+000A > %x72 / ; r carriage return U+000D > %x74 ) ; t tab U+0009 > escape = %x5C ; \ > bmp-escape = escape %x75 ( > not-d-hex 3HEXDIG / > "D" %x30-37 2HEXDIG > ) > not-d-hex = DIGIT / "A" / "B" / "C" / "E" / "F" ; hex, except for D > extended-escape = high-surrogate low-surrogate > high-surrogate = escape %x75 "D" high-hex 2HEXDIG > high-hex = %x38-39 / "A" / "B" > low-surrogate = escape %x75 "D" low-hex 2HEXDIG > low-hex = "C" / "D" / "E" / "F" > > """ > > > From stefan@drees.name Fri Jul 26 06:19: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 10B5921F9950 for ; Fri, 26 Jul 2013 06:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, 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 9lPLJaRDH8+y for ; Fri, 26 Jul 2013 06:19:01 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id F15D221F994C for ; Fri, 26 Jul 2013 06:19:00 -0700 (PDT) Received: from newyork.local.box ([93.197.213.17]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0LzsKN-1TyS1q40fb-0150w1 for ; Fri, 26 Jul 2013 15:18:58 +0200 Message-ID: <51F2773D.7030506@drees.name> Date: Fri, 26 Jul 2013 15:18:53 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <51F22A69.7030503@it.aoyama.ac.jp> In-Reply-To: <51F22A69.7030503@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:IYDiQaDvot7XUwcMQKc4+5CbEO+4EpFz6KQaElAJM1c1a+fJyGZ f2EXu7L7VBf+DLvvlqP1bdr6Fbeh2o+iIkVjnn4W49QPfcOAvLM5LPuBK2M7H2Llu7G1FCI oEsYcqiqne0ItgerUXkcHUg8XyDLP9nM9JTSUUwyPL1uxqM9cRuyqZ2xty74qbzd9mMOYwX rRwl5aDNZXqMLFFDaqf/w== Cc: Bjoern Hoehrmann , Tim Bray , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 13:19:07 -0000 On 2013-07-26 09:51 CEST, "Martin J. Dürst" wrote: > Some detailed comments inline: > > On 2013/07/26 3:45, Joe Hildebrand (jhildebr) wrote: >> On 7/25/13 1:42 AM, "Tim Bray" wrote: >> >>> Good idea. Do you have a recommendation, Joe? Now would be a good >>> time to >>> make it. -T >> >> Yes. This is a start: >> >> """ >> 2.5 Strings >> >> >> The representation of strings is similar to conventions used in the C >> family of programming languages. A string begins and ends with >> quotation marks. All Unicode scalar values may be placed within the >> quotation marks except for the characters that must be escaped: >> quotation mark, reverse solidus, and the control characters (U+0000 >> through U+001F). Note that Unicode code points that are reserved for >> UTF-16 surrogates (U+D800 through U+DFFF) are not valid Unicode scalar >> values. >> >> >> Any Unicode scalar value may be escaped. If the Unicode scalar value >> is in the Basic Multilingual Plane (U+0000 through U+D7FF and U+E000 >> through U+FFFF), then it may be represented as a six-character >> sequence: a reverse solidus, followed by the lowercase letter u, >> followed by four hexadecimal digits that encode the Unicode scalar >> value's code point. The hexadecimal letters A though >> F can be upper- or lowercase. So, for example, a string containing >> only a single reverse solidus character may be represented as >> "\u005C". >> >> Alternatively, there are two-character sequence escape >> representations of some popular characters. So, for example, a >> string containing only a single reverse solidus character may be >> represented more compactly as "\\". > > Better add a pointer here to the list of these escapes. esp. as the above notion of ' single reverse solidus ... represented more compactly as "\\" ' might irritate the reader, because the representation it compares with is **not** a string containing "\" but "\u005C" (as noted in the preceding paragraph). > ... {"Stefan": true} From jhildebr@cisco.com Fri Jul 26 06:49: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 1A31E21F9684 for ; Fri, 26 Jul 2013 06:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.849 X-Spam-Level: X-Spam-Status: No, score=-10.849 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, 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 lmruowPgj5zp for ; Fri, 26 Jul 2013 06:49:31 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7F37B21F967C for ; Fri, 26 Jul 2013 06:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3062; q=dns/txt; s=iport; t=1374846571; x=1376056171; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=znlKRb/MOFy9NkxdRF8bMentPOlmah08VK7TsNvUIqE=; b=ftE508S7gI89VB0n7vu5UNk/qBq3mqpqXG7CKiyNQUZ2anFejUyiUoDW HluTVE4E+h55OstorPi08kWFBpqrbR0w51KkfdZzKA+Ph1P0ZsQE1/ALV AOZkYkvgTnDXvWpLW314AZNCtp47qVl7G3obf2XDSlfSJ+a+dTsimTH+n s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAKR98lGtJXG//2dsb2JhbABaDoJ4gQW9Q4EYFnSCJAEBAQMBJ1ISAQgYClYlAgQOBQiIAga5JI9MMQeDFm8DiHKgOYJWPoIq X-IronPort-AV: E=Sophos;i="4.89,751,1367971200"; d="scan'208";a="239679666" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2013 13:49:31 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6QDnUFN015781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 13:49:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.35]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 08:49:30 -0500 From: "Joe Hildebrand (jhildebr)" To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOiJZQiE83XeIGWkix+H3zUQ7zg5l08XsAgABmRICAAFSwAIABP/mAgACFp4A= Date: Fri, 26 Jul 2013 13:49:30 +0000 Message-ID: In-Reply-To: <51F22A69.7030503@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.147.37] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bjoern Hoehrmann , Tim Bray , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 26 Jul 2013 13:49:37 -0000 On 7/26/13 9:51 AM, ""Martin J. D=FCrst"" wrote: >> >> Alternatively, there are two-character sequence escape >> representations of some popular characters. So, for example, a >> string containing only a single reverse solidus character may be >> represented more compactly as "\\". > >Better add a pointer here to the list of these escapes. Agree. >> To compare strings for equality (for example, the uniqueness of names >> in an object), escape sequences of any of the previous three kinds MUST >> be normalized, > >I don't think normalizing escape sequences is the right term. I'd say >unescaping. I wanted to allow for applications doing something that was more optimal for their environment, but I really don't care that much. >> then the strings are compared code point by code point. >> >> >> If errors occur in string parsing, such as: >> - unescaped surrogates after decoding > >The "after decoding" doesn't add anything here (except potential >confusion). I'm fine with removing it. The intent here was that of course surrogates are ok before decoding if your wire format was UTF16. Once we get to the land of codepoints however, they can't exist. CESU-8 isn't a valid encoding for JSON. >> - unpaired escaped surrogate >> - invalid second character in a two-character escape sequence > >The first item is plural, the rest singular. I'd choose one or the other. Nod. >> implementations MAY make one of several different choices: >> - return an error and stop processing. This is RECOMMENDED for >> security-sensitve deployments. >> - replace the offending code point with U+FFFD (REPLACEMENT >>CHARACTER). >> Strings that are intended to be human-readable might take this >> approach. > >Strings don't take any approach. -> "This approach might be taken for >Strings intended to be human-readable." or "This approach is suitable >for strings intended for display to humans." or some such. Agree. >> - keep as much data as possible. For example, some programming >> environments allow unpaired surrogates in their string >> representations, so unpaired surrogates may be retained. >> This approach is used by several existing implementations. > >I'd change "allow" to "tolerate". I like that a lot better. >> Because there are multiple valid choices for how to process invalid >> data, senders SHOULD ensure that their strings are valid according to >> the above rules. Existing implementations are strongly encouraged to >> be updated to always generate valid strings. Examples of use cases to >> test include: >> >> - string slicing operations that operate on 16-bit code units, rather >> than code points, which might generate an unpaired high surrogate >> at the beginning or end of the substring >> - unpaired surrogates that are valid in a given programming language > >I'd change the "valid" to something like "tolerated" or so. Agree. --=20 Joe Hildebrand From jhildebr@cisco.com Sat Jul 27 01:49: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 F2FB221F9DF0 for ; Sat, 27 Jul 2013 01:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.149 X-Spam-Level: X-Spam-Status: No, score=-11.149 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, 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 k1Pi6GgZbpFY for ; Sat, 27 Jul 2013 01:49:21 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3F021F8FA1 for ; Sat, 27 Jul 2013 01:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4938; q=dns/txt; s=iport; t=1374914961; x=1376124561; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=G2sH3daT5TWqRy+aAz2qUs2thjnQdaevFtwSOo3nQ6s=; b=gsiOmyZeXJS44BQFYFrjgrLRE/mviVQ5X9cIe6iKO9iy4NPzZ4+/Tqg1 Rgo5AgSkfUqQkjQlU9+q4u0i+kqBSYsNd5+ijYjvysmBDOCo49n8LLjbb 8+BWqcHQc/tEsKhRxfT5nBNYWPHKykibcOl1DzSDcGdQoc2SZyLx7CeT+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAAuJ81GtJV2Y/2dsb2JhbABaDoJ4gQW9XIEVFnSCJgEEZxISAQgiViUCBA4FCIgIuGWPTDEHgxZvA4hyoDmCVj6CKg X-IronPort-AV: E=Sophos;i="4.89,756,1367971200"; d="scan'208";a="240236021" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jul 2013 08:49:20 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6R8nKG2000967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jul 2013 08:49:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.35]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Sat, 27 Jul 2013 03:49:19 -0500 From: "Joe Hildebrand (jhildebr)" To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOiJZQiE83XeIGWkix+H3zUQ7zg5l08XsAgABmRICAAFSwAIABP/mAgAHCDgA= Date: Sat, 27 Jul 2013 08:49:19 +0000 Message-ID: In-Reply-To: <51F22A69.7030503@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.145.8] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3F4513115A99034E9DFED2558D8888BB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bjoern Hoehrmann , Tim Bray , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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: Sat, 27 Jul 2013 08:49:27 -0000 On 7/26/13 9:51 AM, ""Martin J. D=FCrst"" wrote: >Some detailed comments inline: OK, I think I got all of your comments included: """ 2.5 Strings The representation of strings is similar to conventions used in the C family of programming languages. A string begins and ends with quotation marks. All Unicode scalar values may be placed within the quotation marks except for the characters that must be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F). Note that Unicode code points that are reserved for UTF-16 surrogates (U+D800 through U+DFFF) are not valid Unicode scalar values. Any Unicode scalar value may be escaped. If the Unicode scalar value is in the Basic Multilingual Plane (U+0000 through U+D7FF and U+E000 through U+FFFF), then it may be represented as a six-character sequence: a reverse solidus, followed by the lowercase letter u, followed by four hexadecimal digits that encode the Unicode scalar value's code point. The hexadecimal letters A though F can be upper- or lowercase. So, for example, a string containing only a single reverse solidus character may be represented as "\u005C". Alternatively, there are two-character sequence escape representations of some popular characters, listed below: - \" U+0022 (QUOTATION MARK) - \\ U+005C (REVERSE SOLIDUS) - \/ U+002F (SOLIDUS) - \b U+0008 (BACKSPACE) - \f U+000C (FORM FEED) - \n U+000A (LINE FEED) - \r U+000D (CARRIAGE RETURN) - \t U+0009 (CHARACTER TABULATION) So, for example, a string containing only a single reverse solidus character may be represented more compactly than "\u005c" as "\\". To escape an Unicode scalar value that is not in the Basic Multilingual Plane, the character is represented as a twelve-character sequence, encoding the UTF-16 surrogate pair that corresponds to the code point for the Unicode scalar value. So, for example, a string containing only the G clef character (U+1D11E) may be represented as "\uD834\uDD1E". To compare strings for equality (for example, the uniqueness of names in an object), escape sequences of any of the previous three kinds MUST be unescaped, then the strings are compared code point by code point. If errors occur in string parsing, such as: - unescaped surrogate - unpaired escaped surrogate - invalid second character in a two-character escape sequence implementations MAY make one of several different choices: - return an error and stop processing. This is RECOMMENDED for security-sensitve deployments. - replace the offending code point with U+FFFD (REPLACEMENT CHARACTER). This approach might be taken for Strings intended for display to humans. - keep as much data as possible. For example, some programming environments tolerate unpaired surrogates in their string representations, so unpaired surrogates may be retained. This approach is used by several existing implementations. Because there are multiple valid choices for how to process invalid data, senders SHOULD ensure that their strings are valid according to the above rules. Existing implementations are strongly encouraged to be updated to always generate valid strings. Examples of use cases to test include: - string slicing operations that operate on 16-bit code units, rather than code points, which might generate an unpaired high surrogate at the beginning or end of the substring - unpaired surrogates that are tolerated in a given programming language New implementations MUST NOT rely on a specific error implementation choice for interoperability. char =3D unescaped / named-escape / bmp-escape / extended-escape unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF named-escape =3D escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 ) ; t tab U+0009 escape =3D %x5C ; \ bmp-escape =3D escape %x75 ( not-d-hex 3HEXDIG / "D" %x30-37 2HEXDIG ) not-d-hex =3D DIGIT / "A" / "B" / "C" / "E" / "F" ; hex, except for D extended-escape =3D high-surrogate low-surrogate high-surrogate =3D escape %x75 "D" high-hex 2HEXDIG high-hex =3D %x38-39 / "A" / "B" low-surrogate =3D escape %x75 "D" low-hex 2HEXDIG low-hex =3D "C" / "D" / "E" / "F" """ --=20 Joe Hildebrand From mamille2@cisco.com Sat Jul 27 13:23:06 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 E1BA621F860B for ; Sat, 27 Jul 2013 13:23:04 -0700 (PDT) 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 Bc+9pCg5un+I for ; Sat, 27 Jul 2013 13:22:57 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A157711E80F3 for ; Sat, 27 Jul 2013 13:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7318; q=dns/txt; s=iport; t=1374956576; x=1376166176; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qGhgYv1FXMk+tGAQnlnajvNIs0X5EQ0k/vY7I7kdkI0=; b=bGaaDjUSJGH/yD/yv9NO1HvUzNV0bfr6ZlTwnRF//QCbZpB5DRZ1J3nc 2fhz94we7QvRHrZaudfyYbfJYrGGm1OHu0YOqmxT73f/eTz/jK2uXR56d MzrlzzTgVVN6HA9qhZI3kICtTjgMRGax6YdGoAwu/WuujPgDCY8rKzUXE 8=; X-Files: smime.p7s : 4136 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAAEr9FGtJV2a/2dsb2JhbABbgwaBBb1WgRoWdIIlAQEEgQkCAQgiJAIwJQIEGwaIArgNjkiBBDiDFm8DkBKBLZdsgxSBaEI X-IronPort-AV: E=Sophos;i="4.89,758,1367971200"; d="p7s'?scan'208";a="240321768" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jul 2013 20:22:54 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6RKMsZD010198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 27 Jul 2013 20:22:54 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.159]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Sat, 27 Jul 2013 15:22:54 -0500 From: "Matt Miller (mamille2)" To: "json@ietf.org WG" Thread-Topic: [Json] Questions regarding duplicate names Thread-Index: AQHOgdBKgh653pxNL0igmJOeyMV3Rpl5XlQA Date: Sat, 27 Jul 2013 20:22:53 +0000 Message-ID: References: <51E4B6AE.4040502@qti.qualcomm.com> In-Reply-To: <51E4B6AE.4040502@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.77.3] Content-Type: multipart/signed; boundary="Apple-Mail=_1E8107AD-1930-4AFF-9F17-7799C2D16E1B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [Json] Questions regarding duplicate names 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: Sat, 27 Jul 2013 20:23:06 -0000 --Apple-Mail=_1E8107AD-1930-4AFF-9F17-7799C2D16E1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello all, Here is an attempt to summarize responses to the duplicate names = questions. The consensus from this thread seems to be that duplicate names within = the same JSON object are not generally desirable. There appears to be rough consensus that a generator (for some = definition of "generator") ought to take steps to avoid emitting = duplicate names, but that there exists a non-trivial amount of software = where the prohibition of duplicates cannot be completely enforced. There appears to be consensus that parsers (for some definition of = "parser") need to be able to deal with duplicate names in some manner. = There is rough consensus that 4627bis ought to provide guidance on how = parsers deal with duplicate names. However, there is no one option that = has any consensus; instead, there appears to be acquiescence that a = given parser ought to support one option from a limited set of = documented choices. The most common suggestions -- which appear to = reflect the majority of existing implementations -- far so: * report an error in some manner * report the last value that appears in the JSON text * report all the values that appear in the JSON text - Paul Hoffman and Matt Miller= --Apple-Mail=_1E8107AD-1930-4AFF-9F17-7799C2D16E1B Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMezCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDBoRIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDMwMjE1NDQyWhcNMTQwNTAyMDUzOTA0WjBbMRkwFwYDVQQNExBiN2F6NndOY0t0R3JtMEpF MRswGQYDVQQDDBJtYW1pbGxlMkBjaXNjby5jb20xITAfBgkqhkiG9w0BCQEWEm1hbWlsbGUyQGNp c2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJbKBMsG+9UFTx9uq/bhhXgu vJvO8z7cwKaqqwZhVf5z/kHFyCNijtmTOE+YXjA8mWR4aoBwB5SvGypI/cJUofJ+AlBTC4g+RMx/ K0Ab4/jQqTQz9CDzMOB+Wm+rt8ZJ7A8ZzOJmNDAsf/VvB8l2A1SQz1UsAixgH16NTr8SlblAXEKk 4hwpCudUiNjjQokqJ0H686UBKVorcZSgXaza8XMqGtJF/8mNhR9GQYi7Xht1ky+9LFOrto2daZto KJRwMeVusVdHUeKEQSu7jztw8HchH3KEb7Q+r5X+hhDZoddfKE8d5eyPuhiZdrzv7OlNZ0fSLdx7 3AE3nx9/R5YlXucCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUxGd+/qrdVudHrIKkw5xOMY7eaLUwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESbWFtaWxsZTJAY2lzY28u Y29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAlDhXbGEI7lbqUcu5r2JHZaMsbRZda/99ZqODzWGX 0llou9jGccsAWDPPwRRe2+ROpXfH4cuJZElTcLDeZSp/qpXKhjYieFSX8+Ml9sKEj5UOSqQLyoLk PtrIJV12Jk3nuG2Jc0UeEnGwK/aqtzy7+bfEVI0ziyVM2gChHh0RH74KyiwYWknbOTRIkZcz/ulE DVFQp63uj6wfmDNvAUHBAdhKVqA1S/rfP1KcDZpf1NfvwXJibiqTRA6K1EOxTJOP41n/XdvHqHXL RWL2xrOUI9/URANr/ok3OrsuZEMFnAAGefS1bWS/hFtUGVkHGiKEBbyDW7da2ULXbuC7umrQnzGC A28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDAJBgUrDgMCGgUA oIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MjcyMDIy NTNaMCMGCSqGSIb3DQEJBDEWBBQhUdpun8EjlEOwmoSBPeL4r/yEmDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg MSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwaESDCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBoRIMA0GCSqGSIb3DQEBAQUABIIBAJYU BSKlyQvJBu/9RROM/9D9tkKAsBR0TZ7UePxLAeafABukDo7Qf0eBhKi1atqNN80SzonshbFzdjOz FEYGtWZCoIHIiDEYm5Z3xQmZZLvfNkBkDbRmLbzvEJtmHyJj2ZnSdTX3kPcZTs3NH21FdEZyB8jG UVyGloBHFrXSh2k5tjiHAVl0xH5hmhAh0fViZvX1UNIrI9Sa8MBm9pzv4csawdg63A37BsNQDABy RM/T3GN3MutvArHMfifVZgIYoabp/6SYKSpcNTehSH+DzqZYkAuftHldi10t+FgQBGGY9l7FYh4H bz4DJc8+Ga02mRUUc3X4VuB4JOvK9ma8ggQAAAAAAAA= --Apple-Mail=_1E8107AD-1930-4AFF-9F17-7799C2D16E1B-- From tbray@textuality.com Sat Jul 27 14:19: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 DEEC811E80FF for ; Sat, 27 Jul 2013 14:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.833, 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 r9pLkr3xvd36 for ; Sat, 27 Jul 2013 14:18:56 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7967A11E80F7 for ; Sat, 27 Jul 2013 14:18:52 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id jw11so2100671veb.32 for ; Sat, 27 Jul 2013 14:18:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/NsLxWXGyRiSBjadKGYsznoVfJc6M301PDdP9LI513M=; b=eJ1QfIPbOHSu5bsMaEO/deX9wiGCcg4xG0c1qrvr/tmnMMU50Le+qoRJDHGrj9cRRq 8hZ8vC2jbijXmidi4zVyo4ihOZloZ3+5mwta+TBFPzMZ7t7xeJRSYTrnVGKV2SMW2YLe uixZskFVD1TqPgfbiFENJi/OUy9qN3hvOiHV4vE4m9QWSEV/2BF7wcJxqu6wh0vZMB0R YsKA4f1TirEZsehmnD9cLwNqi1KcINtyV81VpoepVPUuldcrXuoUH2saTx5WW63QTtPu X1RR2gt6dkMiSPqTWK5883tcJfRDP5V03vZO/kZj01oisfoDmu89sEGR7yHY4vp+/Wtp RaFQ== MIME-Version: 1.0 X-Received: by 10.58.2.137 with SMTP id 9mr23681038veu.50.1374959931707; Sat, 27 Jul 2013 14:18:51 -0700 (PDT) Received: by 10.220.248.198 with HTTP; Sat, 27 Jul 2013 14:18:51 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <51E4B6AE.4040502@qti.qualcomm.com> Date: Sat, 27 Jul 2013 14:18:51 -0700 Message-ID: From: Tim Bray To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=047d7b2e75cc4f70b604e284ce0a X-Gm-Message-State: ALoCoQkk8QznMp1XOAPnbV+dSk/wmX6Y0yp1Jmckz6zOCbh1JvnuUQfEfz341BBu3xXoHuqImcKL Cc: "json@ietf.org WG" Subject: Re: [Json] Questions regarding duplicate names 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: Sat, 27 Jul 2013 21:19:01 -0000 --047d7b2e75cc4f70b604e284ce0a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree with chairs=E2=80=99 outline of the rough consensus. -T On Sat, Jul 27, 2013 at 1:22 PM, Matt Miller (mamille2) wrote: > Hello all, > > Here is an attempt to summarize responses to the duplicate names question= s. > > The consensus from this thread seems to be that duplicate names within th= e > same JSON object are not generally desirable. > > There appears to be rough consensus that a generator (for some definition > of "generator") ought to take steps to avoid emitting duplicate names, bu= t > that there exists a non-trivial amount of software where the prohibition = of > duplicates cannot be completely enforced. > > There appears to be consensus that parsers (for some definition of > "parser") need to be able to deal with duplicate names in some manner. > There is rough consensus that 4627bis ought to provide guidance on how > parsers deal with duplicate names. However, there is no one option that > has any consensus; instead, there appears to be acquiescence that a given > parser ought to support one option from a limited set of documented > choices. The most common suggestions -- which appear to reflect the > majority of existing implementations -- far so: > > * report an error in some manner > * report the last value that appears in the JSON text > * report all the values that appear in the JSON text > > > - Paul Hoffman and Matt Miller > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --047d7b2e75cc4f70b604e284ce0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree with chairs=E2=80=99 outline of the rough consensus.= -T


= On Sat, Jul 27, 2013 at 1:22 PM, Matt Miller (mamille2) &= lt;mamille2@cisco.c= om> wrote:
Hello all,

Here is an attempt to summarize responses to the duplicate names questions.=

The consensus from this thread seems to be that duplicate names within the = same JSON object are not generally desirable.

There appears to be rough consensus that a generator (for some definition o= f "generator") ought to take steps to avoid emitting duplicate na= mes, but that there exists a non-trivial amount of software where the prohi= bition of duplicates cannot be completely enforced.

There appears to be consensus that parsers (for some definition of "pa= rser") need to be able to deal with duplicate names in some manner. = =C2=A0There is rough consensus that 4627bis ought to provide guidance on ho= w parsers deal with duplicate names. =C2=A0However, there is no one option = that has any consensus; instead, there appears to be acquiescence that a gi= ven parser ought to support one option from a limited set of documented cho= ices. =C2=A0The most common suggestions -- which appear to reflect the majo= rity of existing implementations -- far so:

* report an error in some manner
* report the last value that appears in the JSON text
* report all the values that appear in the JSON text


- Paul Hoffman and Matt Miller
_________________________________________= ______
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json


--047d7b2e75cc4f70b604e284ce0a-- From jorge@jorgechamorro.com Sat Jul 27 15:10: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 3211B11E8117 for ; Sat, 27 Jul 2013 15:10:33 -0700 (PDT) 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 y-RBTDGeWq-1 for ; Sat, 27 Jul 2013 15:10:27 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC5411E8116 for ; Sat, 27 Jul 2013 15:10:26 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hr7so246406wib.0 for ; Sat, 27 Jul 2013 15:10:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=NC+SblD2JiNr/d0s/4QoaJdcCFSLeDUpA7UqwHD6gtk=; b=eH4kNJO9eASFeim03+G+5gJjHPTCE3yS8n71ML+HPb7CHlQyPwha+49cVNSjP7q7LC cEXt50FPHylLnDy/02vH1omcZPZdoIGTnqAzPoGwsi79bDoT+irHhpinWeOIdzdh13Sf wriagPpQK3Li2IEu2UnEH44OK6/vkpDP2bO2Vt+OpJvBPWVCFUZxDlhTVpvk7bcqp/A8 nZSlxJtAKVAc+8UzraJlznkXmuQNiPGdeVcqWJpBlSqtohmBYG0c2aOvu3yHl0L/+pfW prEDaTi9V1yf5X2naWD51AQm5irQr1e82Xn/0qAohWqNz50+V6UqGrWr8u5nP2tU/mvu zNgw== X-Received: by 10.194.76.98 with SMTP id j2mr38238652wjw.50.1374963024142; Sat, 27 Jul 2013 15:10:24 -0700 (PDT) Received: from [192.168.10.50] (4.Red-83-41-147.dynamicIP.rima-tde.net. [83.41.147.4]) by mx.google.com with ESMTPSA id nb12sm13091231wic.7.2013.07.27.15.10.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jul 2013 15:10:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: Date: Sun, 28 Jul 2013 00:10:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> To: Stephen Dolan X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmIugY3ztWTc+m4uel4PxWslnBND3qlVVWEy/25N+GrPn3S7/jTIF8QRNyHlRBoxtlP+sRh Cc: Vinny A , stefan@drees.name, Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. 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: Sat, 27 Jul 2013 22:10:33 -0000 On 27/07/2013, at 22:22, Matt Miller (mamille2) wrote: > Hello all, >=20 > Here is an attempt to summarize responses to the duplicate names = questions. >=20 > The consensus from this thread seems to be that duplicate names within = the same JSON object are not generally desirable. >=20 > There appears to be rough consensus that a generator (for some = definition of "generator") ought to take steps to avoid emitting = duplicate names, but that there exists a non-trivial amount of software = where the prohibition of duplicates cannot be completely enforced. >=20 > There appears to be consensus that parsers (for some definition of = "parser") need to be able to deal with duplicate names in some manner. = There is rough consensus that 4627bis ought to provide guidance on how = parsers deal with duplicate names. However, there is no one option that = has any consensus; instead, there appears to be acquiescence that a = given parser ought to support one option from a limited set of = documented choices. The most common suggestions -- which appear to = reflect the majority of existing implementations -- far so: >=20 > * report an error in some manner > * report the last value that appears in the JSON text > * report all the values that appear in the JSON text If duplicate names are generally considered a no-no, and given that = they're mostly used for comments (usually with the key "//"), and given = the security risks discussed in the "command":"launch-missiles" thread, = perhaps the best thing to do with the duplicate keys and their values = might be to simply drop them altogether, not throw any errors, not = nothing, just drop them, all of them, including the last one. So missiles won't be launched and comments will vaporize, which is good. --=20 ( Jorge )();= From jorge@jorgechamorro.com Sat Jul 27 15:19: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 4910311E8115 for ; Sat, 27 Jul 2013 15:19:05 -0700 (PDT) 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 zzPLIzV0HefD for ; Sat, 27 Jul 2013 15:18:59 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3496311E8111 for ; Sat, 27 Jul 2013 15:18:59 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id en1so1883396wid.2 for ; Sat, 27 Jul 2013 15:18:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=C6LEDSi2nbED37SeT4T5btUjfTulR6hd1FqebMexafE=; b=kvSgSmcZcviXkX7S5owD8DB/RQFCOBtuzlQ62JiSdQ0xMdwmkSVZ5yBwGdyYwayOVH iSIGMt3RdLD0yJInbzmMscolNvEVO4tqwnw5KOAJq7fn30CsPniTdqFPCTNQ1euk9R0m uj+pCJva0puaa7zwo9pzLgeix49uzaNd0j3/gXpLOFruinWewfF8wrskZ+LjaQZtQxkz wny3ichtd1s/I2WoB2ZXQhFPCJhBLpstu2jzF4p+kEq4KY0hQGnVrDL3OsKOsPQMAN// eLwRjzCV6sTn4lwIEnGo2R6TYHqcccoERoGrQ1FFopjvdhuIz3nDi3mtTddlHi4DbaeC ik1A== X-Received: by 10.180.9.235 with SMTP id d11mr2841842wib.35.1374963538042; Sat, 27 Jul 2013 15:18:58 -0700 (PDT) Received: from [192.168.10.50] (4.Red-83-41-147.dynamicIP.rima-tde.net. [83.41.147.4]) by mx.google.com with ESMTPSA id d8sm13161762wiz.0.2013.07.27.15.18.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jul 2013 15:18:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: Date: Sun, 28 Jul 2013 00:18:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <714E48B2-AA09-432C-93A8-696269390757@jorgechamorro.com> References: <51E4B6AE.4040502@qti.qualcomm.com> To: Matt Miller (mamille2) X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnwZEvLktLMAd+iF4DrgZPi7ifduj7jR7NORf9Hn2TRJB8zaZxHXUvbj6v79HwnPxPAclgt Cc: "json@ietf.org WG" Subject: Re: [Json] Questions regarding duplicate names 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: Sat, 27 Jul 2013 22:19:05 -0000 (re-sending, sorry, attached to the wrong thread) On 27/07/2013, at 22:22, Matt Miller (mamille2) wrote: > Hello all, >=20 > Here is an attempt to summarize responses to the duplicate names = questions. >=20 > The consensus from this thread seems to be that duplicate names within = the same JSON object are not generally desirable. >=20 > There appears to be rough consensus that a generator (for some = definition of "generator") ought to take steps to avoid emitting = duplicate names, but that there exists a non-trivial amount of software = where the prohibition of duplicates cannot be completely enforced. >=20 > There appears to be consensus that parsers (for some definition of = "parser") need to be able to deal with duplicate names in some manner. = There is rough consensus that 4627bis ought to provide guidance on how = parsers deal with duplicate names. However, there is no one option that = has any consensus; instead, there appears to be acquiescence that a = given parser ought to support one option from a limited set of = documented choices. The most common suggestions -- which appear to = reflect the majority of existing implementations -- far so: >=20 > * report an error in some manner > * report the last value that appears in the JSON text > * report all the values that appear in the JSON text If duplicate names are generally considered a no-no, and given that = they're mostly used for comments (usually with the key "//"), and given = the security risks discussed in the "command":"launch-missiles" thread, = perhaps the best thing to do with the duplicate keys and their values = might be to simply drop them altogether, not throw any errors, not = nothing, just drop them, all of them, including the last one. So missiles won't be launched and comments will vaporize, which is good. --=20 ( Jorge )();= From jorge@jorgechamorro.com Sat Jul 27 15:28: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 BDDDC11E8111 for ; Sat, 27 Jul 2013 15:28:19 -0700 (PDT) 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 5+m8mRYaLafs for ; Sat, 27 Jul 2013 15:28:13 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD4021F84F6 for ; Sat, 27 Jul 2013 15:28:13 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id u55so2945692wes.27 for ; Sat, 27 Jul 2013 15:28:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Erq1+LlRXccdF+XFaATdC1QR1Os1L2pOL918I0FglJ8=; b=bPRpam6WF0c+2pP/Qplh7mjUR8QTZlwjCUGx2BQ+k4pSO/db8fyM6blTmqIJI66kje LHj296q2bqEzpDpPtICEChwkhVWu7oRMUQ1CW6STLbAl3/dQHfum/dTTlfdJdWsVTZZ0 xXLkuuQjDzOfTetX334kYFfOY2hQPlLl7cafhMz89bK3FTWhGzjWlnAUtFJtJovqrJ3U 5OAyYprd0ReB/xVEH4sjEdpfBAAZJAC/tsn/VS7NuSERjfBPKiqmWywl3AmOlDQjsOTE Iy7kYbFZ8bt5gHU9QFwhwLI7BBObr/tLzkdmb+Ai3P7gzCtFwkXKYKtkTzFYlQ2Wetm9 B+Qw== X-Received: by 10.194.109.104 with SMTP id hr8mr38447593wjb.32.1374964092244; Sat, 27 Jul 2013 15:28:12 -0700 (PDT) Received: from [192.168.10.50] (4.Red-83-41-147.dynamicIP.rima-tde.net. [83.41.147.4]) by mx.google.com with ESMTPSA id d8sm13194880wiz.0.2013.07.27.15.28.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jul 2013 15:28:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: <714E48B2-AA09-432C-93A8-696269390757@jorgechamorro.com> Date: Sun, 28 Jul 2013 00:28:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E4B6AE.4040502@qti.qualcomm.com> <714E48B2-AA09-432C-93A8-696269390757@jorgechamorro.com> To: Jorge Chamorro X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnU4P730RjqRmhb66zrhbdByrYX0SS4JXY99s9oor/44NuVQqe5W/OfDvzzzLwvawTpIN07 Cc: "json@ietf.org WG" , "Matt Miller \(mamille2\)" Subject: Re: [Json] Questions regarding duplicate names 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: Sat, 27 Jul 2013 22:28:19 -0000 On 28/07/2013, at 00:18, Jorge Chamorro wrote: >=20 > On 27/07/2013, at 22:22, Matt Miller (mamille2) wrote: >>=20 >> * report an error in some manner >> * report the last value that appears in the JSON text >> * report all the values that appear in the JSON text >=20 > If duplicate names are generally considered a no-no, and given that = they're mostly used for comments (usually with the key "//"), and given = the security risks discussed in the "command":"launch-missiles" thread, = perhaps the best thing to do with the duplicate keys and their values = might be to simply drop them altogether, not throw any errors, not = nothing, just drop them, all of them, including the last one. >=20 > So missiles won't be launched and comments will vaporize, which is = good. On the other hand, if this were so, an attacker could *delete* other = keys. --=20 ( Jorge )();= From cowan@ccil.org Sat Jul 27 15:46:28 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 2797C21F995E for ; Sat, 27 Jul 2013 15:46:28 -0700 (PDT) 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 IaVTEmyNMztT for ; Sat, 27 Jul 2013 15:46:23 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFC721F995A for ; Sat, 27 Jul 2013 15:46:22 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1V3DFd-0005Ln-IH; Sat, 27 Jul 2013 18:46:13 -0400 Date: Sat, 27 Jul 2013 18:46:13 -0400 From: John Cowan To: Jorge Chamorro Message-ID: <20130727224613.GE6846@mercury.ccil.org> References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> 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: Vinny A , Stephen Dolan , stefan@drees.name, Markus Lanthaler , "json@ietf.org" Subject: Re: [Json] The names within an object SHOULD be unique. 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: Sat, 27 Jul 2013 22:46:28 -0000 Jorge Chamorro scripsit: > If duplicate names are generally considered a no-no, and given that > they're mostly used for comments (usually with the key "//"), and > given the security risks discussed in the "command":"launch-missiles" > thread, perhaps the best thing to do with the duplicate keys and their > values might be to simply drop them altogether, not throw any errors, > not nothing, just drop them, all of them, including the last one. This ignores a very important reason for not defining what to do with them, which is so that streaming generators and parsers don't have to keep track of what keys they have already processed. -- John Cowan cowan@ccil.org http://ccil.org/~cowan If I have seen farther than others, it is because I am surrounded by dwarves. --Murray Gell-Mann From jhildebr@cisco.com Sat Jul 27 16:22:29 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 B9A9121E8063 for ; Sat, 27 Jul 2013 16:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.682 X-Spam-Level: X-Spam-Status: No, score=-10.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 iv1kirrjJz08 for ; Sat, 27 Jul 2013 16:22:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DEA6D21E8054 for ; Sat, 27 Jul 2013 16:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1473; q=dns/txt; s=iport; t=1374967345; x=1376176945; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JfVxyYMXH4r0BbYA/C1sTLBG6X9cLiMQrqqegUrunJc=; b=V6ez/3AxNYQYag641QSJcnMw1r8W+v3dXOk8IRxutp3cfrYkYhbVaDla FuiPbzKnT4u1LAR05yCIT9FhiocmRJTvcy4pHWymb+Py12YNRaIx1BICF LRPitK+df2KdmtpVaF2eussGQVRuruizot3TuF+yTa6d0Q/QjcjAXNhZK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAOJV9FGtJXHA/2dsb2JhbABbgwY1UL1WgRoWdIIkAQEBBAEBATc0CxIBCBgKFDcLJQIEDgUIiAgMuCUEj0wxB4MWbwOpK4MUgWgHOw X-IronPort-AV: E=Sophos;i="4.89,759,1367971200"; d="scan'208";a="240368094" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 27 Jul 2013 23:22:24 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6RNMOlb025083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Jul 2013 23:22:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.35]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Sat, 27 Jul 2013 18:22:24 -0500 From: "Joe Hildebrand (jhildebr)" To: Jorge Chamorro Thread-Topic: [Json] Questions regarding duplicate names Thread-Index: AQHOgdBKgh653pxNL0igmJOeyMV3Rpl5XlQAgAAgbACAAAKUAIAAMK2A Date: Sat, 27 Jul 2013 23:22:23 +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.6.130613 x-originating-ip: [10.21.79.42] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C02E78372618C40B2FCA9A2D05D3DAB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Matt Miller \(mamille2\)" , "json@ietf.org WG" Subject: Re: [Json] Questions regarding duplicate names 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: Sat, 27 Jul 2013 23:22:29 -0000 The point is, you can't control what the receiver is going to do, so you REALLY SHOULD NOT (see: RFC 6919) send them, or you will have interoperability issues. Nobody should be able to claim that their comments approach is a valid protocol; that's not what "SHOULD" means in RFC 4627 or any other spec that references 2119. On 7/28/13 12:28 AM, "Jorge Chamorro" wrote: >On 28/07/2013, at 00:18, Jorge Chamorro wrote: >>=20 >> On 27/07/2013, at 22:22, Matt Miller (mamille2) wrote: >>>=20 >>> * report an error in some manner >>> * report the last value that appears in the JSON text >>> * report all the values that appear in the JSON text >>=20 >> If duplicate names are generally considered a no-no, and given that >>they're mostly used for comments (usually with the key "//"), and given >>the security risks discussed in the "command":"launch-missiles" thread, >>perhaps the best thing to do with the duplicate keys and their values >>might be to simply drop them altogether, not throw any errors, not >>nothing, just drop them, all of them, including the last one. >>=20 >> So missiles won't be launched and comments will vaporize, which is good. > >On the other hand, if this were so, an attacker could *delete* other keys. >--=20 >( Jorge )(); >_______________________________________________ >json mailing list >json@ietf.org >https://www.ietf.org/mailman/listinfo/json > --=20 Joe Hildebrand From jorge@jorgechamorro.com Sat Jul 27 18:28: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 7A89511E812B for ; Sat, 27 Jul 2013 18:28:24 -0700 (PDT) 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 J4hYzbZm5Xwq for ; Sat, 27 Jul 2013 18:28:18 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4A82711E811F for ; Sat, 27 Jul 2013 18:28:17 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id j17so1400294wiw.7 for ; Sat, 27 Jul 2013 18:28:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=vKGqP0+/VlXmDhG5o1OB7pB3r60MBxkLsAEtsW+qzn8=; b=BFJpAYiIbEewhUZYDPHl0jf7CL8E40/v9653wEVMdm4wiVSKLClDlQaTr7ypp2PoGd R2Vy/lFvCRnU8UHEtDsjjDCVgOgPwnA6JkAkD3dQNtTCut2FBkYOV4fyHIG4ZlG8goNl 3kBLmbFvWfZ/8i/U1gPrhNwNEJICsU+37ZotR2qpp78UEr93OMJsZcfVPzhFwIR7/D90 IS6Ydsv87XfPGw+mXAgAJzg9rq/GQ9kyxkIU/EWaJ9/Aw50+zqBpwPfsGQBuwqzDQjjE dSeAIi6Mw00snPyjIr+WIsv2ahOrLuSNdHOaJpfX8qN7wtzEoRPIy/fpKWb+K1MpclBv PjVw== X-Received: by 10.194.103.73 with SMTP id fu9mr38587637wjb.70.1374974895907; Sat, 27 Jul 2013 18:28:15 -0700 (PDT) Received: from [192.168.10.50] (4.Red-83-41-147.dynamicIP.rima-tde.net. [83.41.147.4]) by mx.google.com with ESMTPSA id n14sm1959223wie.9.2013.07.27.18.28.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jul 2013 18:28:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Jorge Chamorro In-Reply-To: <20130727224613.GE6846@mercury.ccil.org> Date: Sun, 28 Jul 2013 03:28:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51AF8479.5080002@crockford.com> <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <20130727224613.GE6846@mercury.ccil.org> To: John Cowan , "json@ietf.org WG" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQk7CH3ZIgJS9ra2vD/1ket2SASnaZ9gxn9QaHfZx2Lrf22gEHfkkEMqjpHRzBwSMHU9hDma Subject: Re: [Json] The names within an object SHOULD be unique. 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, 28 Jul 2013 01:28:24 -0000 On 28/07/2013, at 00:46, John Cowan wrote: > Jorge Chamorro scripsit: >=20 >> If duplicate names are generally considered a no-no, and given that >> they're mostly used for comments (usually with the key "//"), and >> given the security risks discussed in the "command":"launch-missiles" >> thread, perhaps the best thing to do with the duplicate keys and = their >> values might be to simply drop them altogether, not throw any errors, >> not nothing, just drop them, all of them, including the last one. >=20 > This ignores a very important reason for not defining what to do with = them, > which is so that streaming generators and parsers don't have to keep = track > of what keys they have already processed. Yes, but it's problematic only for the streaming parsers that emit = [key,value] pairs, not for those which emit entire objects. In parsers that emit [key,value] pairs perhaps it doesn't even make = sense to expect this behaviour, probably where it belongs is in the next = layer. --=20 ( Jorge )();= From cowan@ccil.org Sat Jul 27 20:46:08 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 A41F411E8160 for ; Sat, 27 Jul 2013 20:46:08 -0700 (PDT) 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 E1kmpkSeBNvE for ; Sat, 27 Jul 2013 20:46:04 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8490911E8162 for ; Sat, 27 Jul 2013 20:46:03 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1V3Hvl-0000Sf-GI; Sat, 27 Jul 2013 23:46:01 -0400 Date: Sat, 27 Jul 2013 23:46:01 -0400 From: John Cowan To: Jorge Chamorro Message-ID: <20130728034601.GG6846@mercury.ccil.org> References: <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <20130727224613.GE6846@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: "json@ietf.org WG" Subject: Re: [Json] The names within an object SHOULD be unique. 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, 28 Jul 2013 03:46:08 -0000 Jorge Chamorro scripsit: > Yes, but it's problematic only for the streaming parsers that emit > [key,value] pairs, not for those which emit entire objects. In what sense are they streaming parsers, then? The whole idea of a streaming parser is that it passes along the elements of JSON objects, arrays, and perhaps even strings and numbers bit by bit to the invoking application. -- Andrew Watt on Microsoft: John Cowan Never in the field of human computing cowan@ccil.org has so much been paid by so many http://www.ccil.org/~cowan to so few! (pace Winston Churchill) From tbray@textuality.com Sun Jul 28 00:26:03 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 424BF21F996A for ; Sun, 28 Jul 2013 00:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[AWL=1.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 WlL5OrB09JyM for ; Sun, 28 Jul 2013 00:25:54 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCF821F9D69 for ; Sun, 28 Jul 2013 00:25:52 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id pa12so438910veb.16 for ; Sun, 28 Jul 2013 00:25:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=T8YMhHjpGOI57VW2HyVSd8ZVF7x6nR/mWq6rP2yu/wA=; b=QeoWqWw3T4suRKyMfHQ0O7hrtaTUIYFqEeUCRMyLsq1DwvHyduPV62kU1InUn81QNa TIeiQaVV/pY4OLEV7a8PycC7V6WPU32tcqXdNRcmutiNAmI8UoHOkc2FwqDtY1wBDvco vkEhPAwXNJRmN1f5Vqb3dx6wDej50rsXXyv4j3YYwrUHvGZ6ZdfgLD6o9XNjxfJvAa7J a06xksyfwY4mhzIorHR01AxZKu3AEd442jkJL0d4hps/4nQvZSlsrIFnLBjiokw/8ZjK F0VWNoY36KMy+NI7/ODv2l6Yx5LxCs4RpHvgR1kynQdvv8C7lLslmQfuFwumvHxFMmsJ oc3Q== MIME-Version: 1.0 X-Received: by 10.52.182.228 with SMTP id eh4mr15103457vdc.50.1374996351791; Sun, 28 Jul 2013 00:25:51 -0700 (PDT) Received: by 10.220.248.198 with HTTP; Sun, 28 Jul 2013 00:25:51 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <51F22A69.7030503@it.aoyama.ac.jp> Date: Sun, 28 Jul 2013 00:25:51 -0700 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=bcaec54861ec1dcbc304e28d49ca X-Gm-Message-State: ALoCoQlZNGPwzYViJGjAMoAHO0zq52RaV0g3eOfyVnVkXemwdFOLSqElgCQojWKsrlPC7Tj7p9J5 Cc: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 28 Jul 2013 07:26:05 -0000 --bcaec54861ec1dcbc304e28d49ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is really editorial, but could we please say =E2=80=9Cbackslash=E2=80= =9D like normal human beings instead of =E2=80=9Creverse solidus=E2=80=9D? I have no idea = what a solidus is. -T On Sat, Jul 27, 2013 at 1:49 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 7/26/13 9:51 AM, ""Martin J. D=C3=BCrst"" wro= te: > > >Some detailed comments inline: > > OK, I think I got all of your comments included: > > > > """ > 2.5 Strings > > > The representation of strings is similar to conventions used in the C > family of programming languages. A string begins and ends with > quotation marks. All Unicode scalar values may be placed within the > quotation marks except for the characters that must be escaped: > quotation mark, reverse solidus, and the control characters (U+0000 > through U+001F). Note that Unicode code points that are reserved for > UTF-16 surrogates (U+D800 through U+DFFF) are not valid Unicode scalar > values. > > > Any Unicode scalar value may be escaped. If the Unicode scalar value > is in the Basic Multilingual Plane (U+0000 through U+D7FF and U+E000 > through U+FFFF), then it may be represented as a six-character > sequence: a reverse solidus, followed by the lowercase letter u, > followed by four hexadecimal digits that encode the Unicode scalar > value's code point. The hexadecimal letters A though > F can be upper- or lowercase. So, for example, a string containing > only a single reverse solidus character may be represented as > "\u005C". > > Alternatively, there are two-character sequence escape > representations of some popular characters, listed below: > > - \" U+0022 (QUOTATION MARK) > - \\ U+005C (REVERSE SOLIDUS) > - \/ U+002F (SOLIDUS) > - \b U+0008 (BACKSPACE) > - \f U+000C (FORM FEED) > - \n U+000A (LINE FEED) > - \r U+000D (CARRIAGE RETURN) > - \t U+0009 (CHARACTER TABULATION) > > So, for example, a string containing only a single reverse solidus > character may be represented more compactly than "\u005c" as "\\". > > To escape an Unicode scalar value that is not in the Basic Multilingua= l > Plane, the character is represented as a twelve-character sequence, > encoding the UTF-16 surrogate pair that corresponds to the code point > for the Unicode scalar value. So, for example, a string > containing only the G clef character (U+1D11E) may be represented as > "\uD834\uDD1E". > > To compare strings for equality (for example, the uniqueness of names > in an object), escape sequences of any of the previous three kinds MUST > be unescaped, then the strings are compared code point by code point. > > If errors occur in string parsing, such as: > - unescaped surrogate > - unpaired escaped surrogate > - invalid second character in a two-character escape sequence > > implementations MAY make one of several different choices: > - return an error and stop processing. This is RECOMMENDED for > security-sensitve deployments. > - replace the offending code point with U+FFFD (REPLACEMENT CHARACTER). > This approach might be taken for Strings intended for display to > humans. > - keep as much data as possible. For example, some programming > environments tolerate unpaired surrogates in their string > representations, so unpaired surrogates may be retained. > This approach is used by several existing implementations. > > Because there are multiple valid choices for how to process invalid > data, senders SHOULD ensure that their strings are valid according to > the above rules. Existing implementations are strongly encouraged to > be updated to always generate valid strings. Examples of use cases to > test include: > > - string slicing operations that operate on 16-bit code units, rather > than code points, which might generate an unpaired high surrogate > at the beginning or end of the substring > - unpaired surrogates that are tolerated in a given programming language > > New implementations MUST NOT rely on a specific error implementation > choice for interoperability. > > > char =3D unescaped / named-escape / bmp-escape / extended-escape > unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF > named-escape =3D > escape ( > %x22 / ; " quotation mark U+0022 > %x5C / ; \ reverse solidus U+005C > %x2F / ; / solidus U+002F > %x62 / ; b backspace U+0008 > %x66 / ; f form feed U+000C > %x6E / ; n line feed U+000A > %x72 / ; r carriage return U+000D > %x74 ) ; t tab U+0009 > escape =3D %x5C ; \ > bmp-escape =3D escape %x75 ( > not-d-hex 3HEXDIG / > "D" %x30-37 2HEXDIG > ) > not-d-hex =3D DIGIT / "A" / "B" / "C" / "E" / "F" ; hex, except for= D > extended-escape =3D high-surrogate low-surrogate > high-surrogate =3D escape %x75 "D" high-hex 2HEXDIG > high-hex =3D %x38-39 / "A" / "B" > low-surrogate =3D escape %x75 "D" low-hex 2HEXDIG > low-hex =3D "C" / "D" / "E" / "F" > > """ > > > -- > Joe Hildebrand > > > > --bcaec54861ec1dcbc304e28d49ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is really editorial, but could we please say =E2=80= =9Cbackslash=E2=80=9D like normal human beings instead of =E2=80=9Creverse = solidus=E2=80=9D?=C2=A0 I have no idea what a solidus is.=C2=A0 -T


On Sat, Jul 27, 2013 at 1:49 AM, Joe Hildebrand (jhildebr) <jhildebr@cisc= o.com> wrote:
On 7/26/13 9:51 AM, ""Martin J. D=C3=BCrst"= ;" <duerst@it.aoyama.ac.j= p> wrote:

>Some detailed comments inline:

OK, I think I got all of your comments included:



"""
2.5 Strings


The representation of strings is similar to conventions used in the C
=C2=A0 =C2=A0family of programming languages. =C2=A0A string begins and end= s with
=C2=A0 =C2=A0quotation marks. =C2=A0All Unicode scalar values may be placed= within the
=C2=A0 =C2=A0quotation marks except for the characters that must be escaped= :
=C2=A0 =C2=A0quotation mark, reverse solidus, and the control characters (U= +0000
=C2=A0 =C2=A0through U+001F). =C2=A0Note that Unicode code points that are = reserved for
UTF-16 surrogates (U+D800 through U+DFFF) are not valid Unicode scalar
values.


Any Unicode scalar value may be escaped. =C2=A0If the Unicode scalar value<= br> is in the Basic Multilingual Plane (U+0000 through U+D7FF and U+E000
through U+FFFF), then it may be represented as a six-character
sequence: a reverse solidus, followed by the lowercase letter u,
followed by four hexadecimal digits that encode the Unicode scalar
value's code point. =C2=A0The hexadecimal letters A though
=C2=A0 =C2=A0F can be upper- or lowercase. =C2=A0So, for example, a string = containing
=C2=A0 =C2=A0only a single reverse solidus character may be represented as<= br> =C2=A0 =C2=A0"\u005C".

Alternatively, there are two-character sequence escape
=C2=A0 =C2=A0representations of some popular characters, listed below= :

=C2=A0- \" U+0022 (QUOTATION MARK)
=C2=A0- \\ U+005C (REVERSE SOLIDUS)
=C2=A0- \/ U+002F (SOLIDUS)
=C2=A0- \b U+0008 (BACKSPACE)
=C2=A0- \f U+000C (FORM FEED)
=C2=A0- \n U+000A (LINE FEED)
=C2=A0- \r U+000D (CARRIAGE RETURN)
=C2=A0- \t U+0009 (CHARACTER TABULATION)

So, for example, a string containing only a single reverse solidus
character may be represented more compactly than "\u005c" a= s "\\".

=C2=A0 =C2=A0To escape an Unicode scalar value that is not in the Basic Mul= tilingual
=C2=A0 =C2=A0Plane, the character is represented as a twelve-character sequ= ence,
=C2=A0 =C2=A0encoding the UTF-16 surrogate pair that corresponds to the cod= e point
for the Unicode scalar value. =C2=A0So, for example, a string
=C2=A0 =C2=A0containing only the G clef character (U+1D11E) may be represen= ted as
=C2=A0 =C2=A0"\uD834\uDD1E".

To compare strings for equality (for example, the uniqueness of names
in an object), escape sequences of any of the previous three kinds MUST
be unescaped, then the strings are compared code point by code point.=

If errors occur in string parsing, such as:
=C2=A0- unescaped surrogate
=C2=A0- unpaired escaped surrogate
=C2=A0- invalid second character in a two-character escape sequence

implementations MAY make one of several different c= hoices:
=C2=A0- return an error and stop processing. =C2=A0This is RECOMMENDED for<= br> =C2=A0 =C2=A0security-sensitve deployments.
=C2=A0- replace the offending code point with U+FFFD (REPLACEMENT CHARACTER= ).
=C2=A0 =C2=A0This approach might be taken for Strings intended for di= splay to
=C2=A0 =C2=A0humans.
=C2=A0- keep as much data as possible. =C2=A0For example,= some programming
=C2=A0 =C2=A0environments tolerate unpaired surrogates in their strin= g
=C2=A0 =C2=A0representations, so unpaired surrogates may = be retained.
=C2=A0 =C2=A0This approach is used by several existing implementations.

Because there are multiple valid choices for how to= process invalid
data, senders SHOULD ensure that their strings are valid according to
the above rules. =C2=A0Existing implementations are strongly encouraged to<= br> be updated to always generate valid strings. =C2=A0Examples of use cases to=
test include:

=C2=A0- string slicing operations that operate on 16-bit code units, rather=
=C2=A0 =C2=A0than code points, which might generate an unpaired high surrog= ate
=C2=A0 =C2=A0at the beginning or end of the substring
=C2=A0- unpaired surrogates that are tolerated in a given programming= language

New implementations MUST NOT rely on a specific error implementation
choice for interoperability.


=C2=A0 =C2=A0 =C2=A0 char =3D unescaped / named-escape / bmp-escape / exten= ded-escape
=C2=A0 =C2=A0 =C2=A0 unescaped =3D %x20-21 / %x23-5B / %x5D-D7FF / %xE000-1= 0FFFF
=C2=A0 =C2=A0 =C2=A0 named-escape =3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 escape (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x22 / =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0; " =C2=A0 =C2=A0quotation mark =C2=A0U+0022
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x5C / =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0; \ =C2=A0 =C2=A0reverse solidus U+005C
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x2F / =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0; / =C2=A0 =C2=A0solidus =C2=A0 =C2=A0 =C2=A0 =C2=A0 U+002= F
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x62 / =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0; b =C2=A0 =C2=A0backspace =C2=A0 =C2=A0 =C2=A0 U+0008
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x66 / =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0; f =C2=A0 =C2=A0form feed =C2=A0 =C2=A0 =C2=A0 U+000C
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x6E / =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0; n =C2=A0 =C2=A0line feed =C2=A0 =C2=A0 =C2=A0 U+000A
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x72 / =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0; r =C2=A0 =C2=A0carriage return U+000D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x74 ) =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0; t =C2=A0 =C2=A0tab =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 U+0009
=C2=A0 =C2=A0 =C2=A0 escape =3D %x5C =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0; \
=C2=A0 =C2=A0 =C2=A0 bmp-escape =3D escape %x75 (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not-d-hex 3HEXDIG /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "D" %x30-37 2HEX= DIG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 )
=C2=A0 =C2=A0 =C2=A0 not-d-hex =3D DIGIT / "A" / "B" / = "C" / "E" / "F" ; hex, except for D
=C2=A0 =C2=A0 =C2=A0 extended-escape =3D =C2=A0high-surrogate low-surrogate=
=C2=A0 =C2=A0 =C2=A0 high-surrogate =3D escape %x75 "D" high-hex = 2HEXDIG
=C2=A0 =C2=A0 =C2=A0 high-hex =3D %x38-39 / "A" / "B" =C2=A0 =C2=A0 =C2=A0 low-surrogate =3D escape %x75 "D" low-hex 2H= EXDIG
=C2=A0 =C2=A0 =C2=A0 low-hex =3D "C" / "D" / "E&qu= ot; / "F"

"""


--
Joe Hildebrand




--bcaec54861ec1dcbc304e28d49ca-- From cowan@ccil.org Sun Jul 28 00:35:06 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 49E0521F9A87 for ; Sun, 28 Jul 2013 00:35:06 -0700 (PDT) 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 xXLijERX944A for ; Sun, 28 Jul 2013 00:35:02 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id D441921F9CF2 for ; Sun, 28 Jul 2013 00:35:01 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1V3LVH-0005X7-6y; Sun, 28 Jul 2013 03:34:55 -0400 Date: Sun, 28 Jul 2013 03:34:55 -0400 From: John Cowan To: Tim Bray Message-ID: <20130728073455.GO6846@mercury.ccil.org> References: <51F22A69.7030503@it.aoyama.ac.jp> 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: Martin =?iso-8859-1?Q?J=2E_D=FCrst?= , Bjoern Hoehrmann , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 28 Jul 2013 07:35:06 -0000 Tim Bray scripsit: > This is really editorial, but could we please say “backslash†like normal > human beings instead of “reverse solidus� I have no idea what a solidus > is. -T It's a Roman coin, later used as the Latin equivalent of "shilling". Before decimalization the English wrote "two shillings sixpence" as 2/6, where the / was a stylized form of the old long s, for solidi or shillings. The names "solidus" and "reverse solidus" are ISO-speak that Unicode adopted when it merged with ISO 10646. -- We pledge allegiance to the penguin John Cowan and to the intellectual property regime cowan@ccil.org for which he stands, one world under http://www.ccil.org/~cowan Linux, with free music and open source software for all. --Julian Dibbell on Brazil, edited From jhildebr@cisco.com Sun Jul 28 01:01: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 E799F21F9D5E for ; Sun, 28 Jul 2013 01:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.736 X-Spam-Level: X-Spam-Status: No, score=-10.736 tagged_above=-999 required=5 tests=[AWL=-0.138, 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 sBcEQz4cijlR for ; Sun, 28 Jul 2013 01:01:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4532F21F9D54 for ; Sun, 28 Jul 2013 01:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=875; q=dns/txt; s=iport; t=1374998509; x=1376208109; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1WT3voVYrgntfcJzZiI8Wfsn9J/dMmWX7NacUNBkkPQ=; b=g3u8hadcZA4SEPbgFcoUHj9tn6l0OJ/TRCWBqeR1m3WPVsXIiDG0j7Qe G1DLewMs0xKRL4PyhTpmZVNmSH4+EOeG//eD8XPzLmRq8HKk7EU/RzNg1 HweYMJ3+D/cwPsKQ2GdCVAoJGPCLDUm3Hj91V5FG6y2mVL5HH93EkqdDb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8FAErP9FGtJXHB/2dsb2JhbABagwaBBYJIuwqBFxZ0giYBBHkSAQgiViUCBAENBQiICLdyj0wxB4MWbwOIcqA5gxSCKg X-IronPort-AV: E=Sophos;i="4.89,762,1367971200"; d="scan'208";a="240453821" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jul 2013 08:01:48 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6S81jNK028550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Jul 2013 08:01:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.35]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 03:01:44 -0500 From: "Joe Hildebrand (jhildebr)" To: John Cowan , Tim Bray Thread-Topic: [Json] Questions regarding the text model in 4627 Thread-Index: AQHOiJZQiE83XeIGWkix+H3zUQ7zg5l08XsAgABmRICAAFSwAIABP/mAgAHCDgCAAVuOgIAAAomAgAApAwA= Date: Sun, 28 Jul 2013 08:01:44 +0000 Message-ID: In-Reply-To: <20130728073455.GO6846@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.6.130613 x-originating-ip: [10.21.117.211] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5DEF7CBF049E9E44A1AB3ECD5FFF4B93@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= , Bjoern Hoehrmann , "json@ietf.org" Subject: Re: [Json] Questions regarding the text model in 4627 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, 28 Jul 2013 08:01:55 -0000 On 7/28/13 9:34 AM, "John Cowan" wrote: >Tim Bray scripsit: > >> This is really editorial, but could we please say =B3backslash=B2 like >>normal >> human beings instead of =B3reverse solidus=B2? I have no idea what a >>solidus >> is. -T > >It's a Roman coin, later used as the Latin equivalent of "shilling". >Before decimalization the English wrote "two shillings sixpence" as >2/6, where the / was a stylized form of the old long s, for solidi >or shillings. The names "solidus" and "reverse solidus" are ISO-speak >that Unicode adopted when it merged with ISO 10646. I do not care much about how we refer to particular characters. I just copied the canonical name from Unicode. One approach would be to use the correct name in the text, and the informal name in the comments to the ABNF. --=20 Joe Hildebrand From duerst@it.aoyama.ac.jp Sun Jul 28 01:36: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 EF30B21F9D71 for ; Sun, 28 Jul 2013 01:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=-2.175, 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 hVuRP1eIsvme for ; Sun, 28 Jul 2013 01:36:43 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5A50A21F9D8D for ; Sun, 28 Jul 2013 01:36:43 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r6S8aaTq031801; Sun, 28 Jul 2013 17:36:36 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 5f97_41fb_d0b882b2_f760_11e2_8897_001e6722eec2; Sun, 28 Jul 2013 17:36:35 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id EB2A8BF4E2; Sun, 28 Jul 2013 17:34:34 +0900 (JST) Message-ID: <51F4D7F5.9080409@it.aoyama.ac.jp> Date: Sun, 28 Jul 2013 17:36:05 +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: "Matt Miller (mamille2)" References: <51E4B6AE.4040502@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "json@ietf.org WG" Subject: Re: [Json] Questions regarding duplicate names 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, 28 Jul 2013 08:36:49 -0000 Works for me! Regards, Martin. On 2013/07/28 5:22, Matt Miller (mamille2) wrote: > Hello all, > > Here is an attempt to summarize responses to the duplicate names questions. > > The consensus from this thread seems to be that duplicate names within the same JSON object are not generally desirable. > > There appears to be rough consensus that a generator (for some definition of "generator") ought to take steps to avoid emitting duplicate names, but that there exists a non-trivial amount of software where the prohibition of duplicates cannot be completely enforced. > > There appears to be consensus that parsers (for some definition of "parser") need to be able to deal with duplicate names in some manner. There is rough consensus that 4627bis ought to provide guidance on how parsers deal with duplicate names. However, there is no one option that has any consensus; instead, there appears to be acquiescence that a given parser ought to support one option from a limited set of documented choices. The most common suggestions -- which appear to reflect the majority of existing implementations -- far so: > > * report an error in some manner > * report the last value that appears in the JSON text > * report all the values that appear in the JSON text > > > - Paul Hoffman and Matt Miller > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From stefan@drees.name Sun Jul 28 22:24: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 E981F21F9F34 for ; Sun, 28 Jul 2013 22:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_SORBS_WEB=0.619] 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 ji7jGTno6Tuq for ; Sun, 28 Jul 2013 22:24:26 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 95B3B21F9E2A for ; Sun, 28 Jul 2013 22:24:25 -0700 (PDT) Received: from newyork.local.box ([93.129.89.49]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0LoLKj-1URq9r2IxN-00gJeU for ; Mon, 29 Jul 2013 07:24:18 +0200 Message-ID: <51F5FC81.7050501@drees.name> Date: Mon, 29 Jul 2013 07:24:17 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: <51E4B6AE.4040502@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:toFcVlwvyxAOTG5HeaubCugt+VtSdxciZsYkFk/AWn9ttOnk0bZ 4XQRx0OCSSofGkCar001WnmcZEDIMU92wXAGKZjaKAGlsNqEqVIR0OoDmxb6eI5Ml1hA5cG QZOU+M96B9ohfqkCjiehc7UuVgQBrLz/viDYcu3OKJLPek3guZoIqKPOE26SMKvLLYkrk5w fz9ArWjd2Zy0BF8sQK5Jw== Cc: "json@ietf.org WG" Subject: Re: [Json] Questions regarding duplicate names X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 05:24:32 -0000 On 2013-07-27 22:22 +02:00, Matt Miller (mamille2) wrote (on the behalf of Paul Hoffman and Matt Miller): > Hello all, > > Here is an attempt to summarize responses to the duplicate names questions. > > The consensus from this thread seems to be that duplicate names within > the same JSON object are not generally desirable. > > There appears to be rough consensus that a generator (for some > definition of "generator") ought to take steps to avoid emitting > duplicate names, but that there exists a non-trivial amount of software > where the prohibition of duplicates cannot be completely enforced. > > There appears to be consensus that parsers (for some definition of > "parser") need to be able to deal with duplicate names in some manner. > There is rough consensus that 4627bis ought to provide guidance on how > parsers deal with duplicate names. However, there is no one option that > has any consensus; instead, there appears to be acquiescence that a > given parser ought to support one option from a limited set of > documented choices. The most common suggestions -- which appear to > reflect the majority of existing implementations -- far so: > > * report an error in some manner > * report the last value that appears in the JSON text > * report all the values that appear in the JSON text Works for me. Thanks for summarizing, Stefan. > ... From johnl@iecc.com Mon Jul 29 07:29: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 73EE421F9B86 for ; Mon, 29 Jul 2013 07:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.723 X-Spam-Level: X-Spam-Status: No, score=-110.723 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 6Lh5svQlLCDH for ; Mon, 29 Jul 2013 07:29:07 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8B40121F9476 for ; Mon, 29 Jul 2013 07:29:01 -0700 (PDT) Received: (qmail 44158 invoked from network); 29 Jul 2013 14:29:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Jul 2013 14:29:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51f67c2b.xn--hew.k1307; i=johnl@user.iecc.com; bh=Dotek6ReMVS38fjrRAZ/bBlgYGLwWZf5DKz03ywuqLg=; b=uZrLSxrQsJx4JIWpE3tlzUzXoyFDUejqvnazGcOp4fLB/Babp8Ac6pauFMbsPuJ9U/gZENO7tI+ENbaBIk6oCd1sG5jK4nAbkzKE7aUGzh1EEX+7f8/hoCofVyEr+0wBmmi6IyYjOEtBuIatQZ1G7OQWV5Abq2aQEL2QPizjGOddweW/xPRtfCxhlN4b8utNJJULkgz5HLaLlPIWgjn3xZFf/FzfveFXJrqm0fUKSX/cMzFWJABQ2RbaNa/ibpYJ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51f67c2b.xn--hew.k1307; olt=johnl@user.iecc.com; bh=Dotek6ReMVS38fjrRAZ/bBlgYGLwWZf5DKz03ywuqLg=; b=NTAxu+cXijvD/PqWxokqbZ5uePr7RBHQAHKYeDUeq5W01YiILZ3o6RC0rNcRKKeWsYoLW2iYH0kDNVEENyp8gwhewBz7/p4JDGq9cuRmaOAIIqiGn1W0JyW8Icxaqk5qK+DEsHkyO2PMWJXxddSalDI4/fdnUyYkYy+sPc572bAsOm0AVsZ95RHBsZhGvl50UQR0UfbT2QkvyXK5BnEXz/T32Z/xX2Uupichyzv2jIBnFunjU2F3UApOAZFzWQqp Date: 29 Jul 2013 14:28:36 -0000 Message-ID: <20130729142836.3138.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: <51F5FC81.7050501@drees.name> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: stefan@drees.name Subject: Re: [Json] Questions regarding duplicate names 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, 29 Jul 2013 14:29:15 -0000 >> documented choices. The most common suggestions -- which appear to >> reflect the majority of existing implementations -- far so: >> >> * report an error in some manner >> * report the last value that appears in the JSON text >> * report all the values that appear in the JSON text > >Works for me. Thanks for summarizing, Stefan. Looks right to me, too. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From jorge@jorgechamorro.com Tue Jul 30 04:11: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 DE22011E814F for ; Tue, 30 Jul 2013 04:11:30 -0700 (PDT) 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 NqfcIJRVDUHM for ; Tue, 30 Jul 2013 04:11:25 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCFF11E81E4 for ; Tue, 30 Jul 2013 04:11:23 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id u55so5024802wes.27 for ; Tue, 30 Jul 2013 04:11:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=dQ7MGAqm78vXDsekzujrQX+5hnli4NieSDx976Uqg5k=; b=Wa8X0a4EJNoAN/3u+lNE4/ScWJVquj3IBXFS3t9B1AfKMLxA1rOIkylzTJDYFa4SBw sEZA/iBTXYBeGML9mwMPTwfwR6fVSFXYQ9sTouNeYRR6GXzAq4ph9UrYLtr1iOJHmyaK pjdsDWIipv3xL8xMpT+HZdcwuNVUIfjKeApk+88sGV+DjsyBAVJvuKp9pEsuklfXjLRk 4G+8OZBVtQvujO/1jun6tkQHsg/0t9Iv4JRuhxO2slyFM79PId5zr76RH73r8JOOBfFm 9M+7CyMA+wQLBXmsuGEliXi7qQO+0Ayrpe7ivhTj4gECPDATzM9h3dtMQxZYA+vS2ZkC kAaQ== X-Received: by 10.194.95.100 with SMTP id dj4mr25375600wjb.55.1375182682532; Tue, 30 Jul 2013 04:11:22 -0700 (PDT) Received: from [192.168.10.50] (134.Red-88-0-161.dynamicIP.rima-tde.net. [88.0.161.134]) by mx.google.com with ESMTPSA id w4sm27705058wia.9.2013.07.30.04.11.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 04:11:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: <20130728034601.GG6846@mercury.ccil.org> Date: Tue, 30 Jul 2013 13:11:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51b1168c.e686440a.5339.5fc4SMTPIN_ADDED_BROKEN@mx.google.com> <51B1B47C.9060009@drees.name> <51B1E909.2010402@drees.name> <20130727224613.GE6846@mercury.ccil.org> <20130728034601.GG6846@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlRIWKqNKu7ae8v2dxiYw+l27FEaigf5ThUnyj/r/8lK478xeDN2Z7qMX12s0aTWiOIEpmH Cc: "json@ietf.org WG" Subject: Re: [Json] The names within an object SHOULD be unique. 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, 30 Jul 2013 11:11:31 -0000 On 28/07/2013, at 05:46, John Cowan wrote: > Jorge Chamorro scripsit: >=20 >> Yes, but it's problematic only for the streaming parsers that emit >> [key,value] pairs, not for those which emit entire objects. >=20 > In what sense are they streaming parsers, then? The whole idea of a = streaming > parser is that it passes along the elements of JSON objects, arrays, = and > perhaps even strings and numbers bit by bit to the invoking = application. Say you've got a stream (a pipe or a network connection) and a stream of = json-objects arriving through it, you may very well want the parser to = emit entire objects instead of its parts, no? --=20 ( Jorge )();= From jhildebr@cisco.com Tue Jul 30 07:11:52 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 AD88521F9C98 for ; Tue, 30 Jul 2013 07:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.649 X-Spam-Level: X-Spam-Status: No, score=-10.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 EnpIOgjG98Jb for ; Tue, 30 Jul 2013 07:11:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DAEFE21F9C8E for ; Tue, 30 Jul 2013 07:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1229; q=dns/txt; s=iport; t=1375193506; x=1376403106; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wPIy9yspuj5tqyoo5nKIf/E2W4IJvD0WURaCD9cKzCM=; b=Oj0ZTvJQMae4oBqsA4kMNZh6cfC9ptdP8t6Mgy++Eb2wL9wW6OwiVT2+ +B2vC8WJ7Gru1eKmPZIftIKAl33jToJqsmS0YCMXEVDMeIWSuzePlwkru M6VPc0PvhsfEwFPlSsc2Jpm/OABPohQWSQ3WEZKtQ8fUzVy2fZEbNOLCJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAEDJ91GtJXG8/2dsb2JhbABbgwaBBb4TgRwWdIIkAQEBBDo/EgEIGAoUQiUCBAENBQiICLlFj00xB4MYcQOpK4MUgio X-IronPort-AV: E=Sophos;i="4.89,778,1367971200"; d="scan'208";a="241275417" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 30 Jul 2013 14:11:43 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6UEBhke030547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 14:11:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 09:11:43 -0500 From: "Joe Hildebrand (jhildebr)" To: Jorge Chamorro , John Cowan Thread-Topic: [Json] The names within an object SHOULD be unique. Thread-Index: AQHOjRWPznIDsqv3OEu+RBDvEECeupl9uJcA Date: Tue, 30 Jul 2013 14:11:42 +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.6.130613 x-originating-ip: [10.21.75.253] Content-Type: text/plain; charset="us-ascii" Content-ID: <66627F5C792005429441450B182ACB12@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "json@ietf.org WG" Subject: Re: [Json] The names within an object SHOULD be unique. 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, 30 Jul 2013 14:11:52 -0000 On 7/30/13 1:11 PM, "Jorge Chamorro" wrote: >On 28/07/2013, at 05:46, John Cowan wrote: >> Jorge Chamorro scripsit: >>=20 >>> Yes, but it's problematic only for the streaming parsers that emit >>> [key,value] pairs, not for those which emit entire objects. >>=20 >> In what sense are they streaming parsers, then? The whole idea of a >>streaming >> parser is that it passes along the elements of JSON objects, arrays, and >> perhaps even strings and numbers bit by bit to the invoking application. > >Say you've got a stream (a pipe or a network connection) and a stream of >json-objects arriving through it, you may very well want the parser to >emit entire objects instead of its parts, no? I've never seen an implementation that is both streaming and not streaming at the same time. Can you say more about how you'd write the API for that? Better, can you give an example of such an implementation? If you mean an application that takes a stream of complete JSON objects without wrapping them in an array, that problem is likely out of scope, and the processor would act identically to a non-streaming implementation in our existing worldview. --=20 Joe Hildebrand From cowan@ccil.org Tue Jul 30 07:26: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 8115821E80E8 for ; Tue, 30 Jul 2013 07:26:57 -0700 (PDT) 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 f2tNaYIrrLmb for ; Tue, 30 Jul 2013 07:26:51 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 86D0411E80D3 for ; Tue, 30 Jul 2013 07:26:25 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1V4AsZ-0004TR-KH; Tue, 30 Jul 2013 10:26:23 -0400 Date: Tue, 30 Jul 2013 10:26:23 -0400 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20130730142623.GB17809@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: Jorge Chamorro , "json@ietf.org WG" Subject: Re: [Json] The names within an object SHOULD be unique. 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, 30 Jul 2013 14:26:58 -0000 Joe Hildebrand (jhildebr) scripsit: > I've never seen an implementation that is both streaming and > not streaming at the same time. Can you say more about how you'd > write the API for that? Better, can you give an example of such an > implementation? I haven't either, but I could see the uses of an implementation that streamed arrays but not objects (of course, it could hardly stream an array that was within an object). > If you mean an application that takes a stream of complete JSON > objects without wrapping them in an array, that problem is likely out > of scope, and the processor would act identically to a non-streaming > implementation in our existing worldview. +1. I was trying to think how to say that .... -- John Cowan cowan@ccil.org http://ccil.org/~cowan If a soldier is asked why he kills people who have done him no harm, or a terrorist why he kills innocent people with his bombs, they can always reply that war has been declared, and there are no innocent people in an enemy country in wartime. The answer is psychotic, but it is the answer that humanity has given to every act of aggression in history. --Northrop Frye From johnl@iecc.com Tue Jul 30 09:08: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 68FBD11E8103 for ; Tue, 30 Jul 2013 09:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.776 X-Spam-Level: X-Spam-Status: No, score=-110.776 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 xt9Emdv+sOtw for ; Tue, 30 Jul 2013 09:08:44 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4249311E820D for ; Tue, 30 Jul 2013 09:07:43 -0700 (PDT) Received: (qmail 98656 invoked from network); 30 Jul 2013 16:07:42 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Jul 2013 16:07:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51f7e4ce.xn--yuvv84g.k1307; i=johnl@user.iecc.com; bh=WS9FUq4nAlAN2IHOII6DYYQ+wZInxBBVH2fEIk2+IiA=; b=t6EBx3zXMHveFtgxqFvanzEypLoq/ZmgEg3agC4kZDo8AwrFZOt6uYaNjlm+5spjajTfmzO3//5bTCcdOW175xSi4DfpWHe5BmJGqiiC6CkzZWuxz50T/f2tjALSWRyoQAVHF71dWv+kW0QMG0mTF0DHoqPc49fq6WZYjzZQ8rNuFCY1MuT4bEHqLKUwkWK4jq3dOSE36fJZtXIUCtdaP9X5rfCQHnMcexEvKBzm3ouu0cH0wm+4P/90+LlV5U5G DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51f7e4ce.xn--yuvv84g.k1307; olt=johnl@user.iecc.com; bh=WS9FUq4nAlAN2IHOII6DYYQ+wZInxBBVH2fEIk2+IiA=; b=fjXn2fxUwlOhOkrSHCJQtYCvneu4Rxs1I9iRvtAjiwNmd3zx4rVYS9ciqwFgUn3bmg/uPNYzoDEZrc32GHTh5rgZa7zYvPj9uG7IIy+YVRBhPOMOnn4aN+oOb3zPs281Rcj7dGGpMWPy1cv0/WdpMPimyFhJQ4Hy75bCG3CEtm4h8nqMpRfwRa9FC9XPCfiOtBAE2nSZkMIwUsc1GMDtwjGKarCs7qad/bc2+IwtjtH9643OTSMAtAxRsZCxMcvm Date: 30 Jul 2013 16:07:19 -0000 Message-ID: <20130730160719.3203.qmail@joyce.lan> From: "John Levine" To: json@ietf.org In-Reply-To: <20130730142623.GB17809@mercury.ccil.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [Json] fun with streaming, was The names within an object SHOULD be unique. 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, 30 Jul 2013 16:08:51 -0000 >> I've never seen an implementation that is both streaming and >> not streaming at the same time. Can you say more about how you'd >> write the API for that? Better, can you give an example of such an >> implementation? > >I haven't either, but I could see the uses of an implementation that >streamed arrays but not objects (of course, it could hardly stream an >array that was within an object). It has been my impression that the reasons that people use streaming implementations are either that it's a tiny system that doesn't have room to buffer full arrays and full objects, or else it's a realtime application that needs to see the first item in the array or object before the rest of it arrives. I understand that there are plenty of implementations that do not have those constraints, but since there are apparently also plenty of implementations that do have one or both, Paul's short list of possible treatments of duplicate names is the best we can do. From tbray@textuality.com Tue Jul 30 09:43: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 1CDA111E8241 for ; Tue, 30 Jul 2013 09:43:10 -0700 (PDT) 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 L6vpESIMkG9f for ; Tue, 30 Jul 2013 09:43:03 -0700 (PDT) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id A65DB11E8228 for ; Tue, 30 Jul 2013 09:39:39 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id x14so581368vbb.23 for ; Tue, 30 Jul 2013 09:39:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=X0byl0gYe4wRWOLAbHuxixGIXqjoYPvdHotdqxKkTBs=; b=PiEIiFG0JSZXKiRhwpAWD53MNqKcGbGtp2A/xqVfwMlsf0j53ssDXJ+d1PI7zIZ/Sh ZMOejAon7jCHfj+dPsez/5grh854zLnJ1WXw1GqWXW5u0EWDYy4BRzhvQnF/t8mY77z3 cRJjndR2gugqWUIIqgjmnhmD6u96b8xZLQVigeW1Zo+h+o9R/Y+9hX3SHboKOD8y6L3l 28WDv/VB0D8eO/GSwmW28C1wvNJxlVyopxlXL3D7SPNjtp0FsqfgkHJI+qJeh0j+QfIf ZmxSHTSuxhcxPCXruDuR0MO/gF2b2Eb2P4f5sWqq2EB2Cl0zb6j8bSdzyGVCASk6jTTV JLFA== MIME-Version: 1.0 X-Received: by 10.58.85.161 with SMTP id i1mr27054552vez.97.1375202372743; Tue, 30 Jul 2013 09:39:32 -0700 (PDT) Received: by 10.220.248.198 with HTTP; Tue, 30 Jul 2013 09:39:32 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <20130730160719.3203.qmail@joyce.lan> References: <20130730142623.GB17809@mercury.ccil.org> <20130730160719.3203.qmail@joyce.lan> Date: Tue, 30 Jul 2013 09:39:32 -0700 Message-ID: From: Tim Bray To: John Levine Content-Type: multipart/alternative; boundary=047d7b6da6acec080a04e2bd4021 X-Gm-Message-State: ALoCoQn1XgrOUfnRkuGgnHafaNLUWHJhY+owI8FwUdqDdpjuVEd328LWAfLUpL+r5KYwTN9qPp+s Cc: "json@ietf.org" Subject: Re: [Json] fun with streaming, was The names within an object SHOULD be unique. 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, 30 Jul 2013 16:43:11 -0000 --047d7b6da6acec080a04e2bd4021 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 30, 2013 at 9:07 AM, John Levine wrote: > >> I've never seen an implementation ... Better, can you give an example > of such an > >> implementation? > > > >I haven't either, but I could see the uses of an implementation I don=E2=80=99t think =E2=80=9CI could see the uses of=E2=80=9D is a good r= eason for writing an Internet Standard. Once again as with naked surrogates, there=E2=80=99s an invisible class of alleged implementors of JSON sending/receiving code for whom dupe-checking is intractable; except for we haven=E2=80=99t heard from= anyone whose application actually depends on this behavior. Has anyone any personal knowledge of an app whose correct function depends on the use of duplicate keys? -T > that > >streamed arrays but not objects (of course, it could hardly stream an > >array that was within an object). > > It has been my impression that the reasons that people use streaming > implementations are either that it's a tiny system that doesn't have > room to buffer full arrays and full objects, or else it's a realtime > application that needs to see the first item in the array or object > before the rest of it arrives. > > I understand that there are plenty of implementations that do not have > those constraints, but since there are apparently also plenty of > implementations that do have one or both, Paul's short list of > possible treatments of duplicate names is the best we can do. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b6da6acec080a04e2bd4021 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 30, 2013 at 9:07 AM, John Levine <johnl@taugh.c= om> wrote:
>> I've never seen an implementation ...=C2=A0 Better, can you gi= ve an example of such an
>> implementation?
>
>I haven't either, but I could see the uses of an implementation

I don=E2=80=99t think =E2=80=9CI could see th= e uses of=E2=80=9D is a good reason for writing an Internet Standard.=C2=A0= Once again as with naked surrogates, there=E2=80=99s an invisible class of= alleged implementors of JSON sending/receiving code for whom dupe-checking= is intractable; except for we haven=E2=80=99t heard from anyone whose appl= ication actually depends on this behavior.=C2=A0

Has anyone any personal knowledge of an app whose correct fu= nction depends on the use of duplicate keys?=C2=A0 -T

=C2=A0
that
>streamed arrays but not objects (of course, it could hardly stream an >array that was within an object).

It has been my impression that the reasons that people use streaming
implementations are either that it's a tiny system that doesn't hav= e
room to buffer full arrays and full objects, or else it's a realtime application that needs to see the first item in the array or object
before the rest of it arrives.

I understand that there are plenty of implementations that do not have
those constraints, but since there are apparently also plenty of
implementations that do have one or both, Paul's short list of
possible treatments of duplicate names is the best we can do.

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

--047d7b6da6acec080a04e2bd4021-- From nico@cryptonector.com Tue Jul 30 09:55: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 D511311E80EE for ; Tue, 30 Jul 2013 09:55:24 -0700 (PDT) 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=-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 cJUEeT7WbQIz for ; Tue, 30 Jul 2013 09:55:19 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 02EE721F9D34 for ; Tue, 30 Jul 2013 09:55:10 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id E41CB1006E for ; Tue, 30 Jul 2013 09:55:07 -0700 (PDT) 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=0rfYBdTLxW9qmK+DcoBF vp5mSA4=; b=GAbRsK4MVCwJ7tXOO7ybtTSsdzIXvWOtYKPw7HQWHoNI0+JJvhAd o+0oRnGwhtB01dP/D4qEO03012fAeoe3iCX/kmF5nfqgvuVzUxkG9uAIz0+OrDti o1kaIDe4Vf4v+IwUl3LiKcrRbp3IL9eCd8J2G2PecnnWNEDfpevZ6Xk= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id DD7431005D for ; Tue, 30 Jul 2013 09:54:59 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id t57so5305257wes.38 for ; Tue, 30 Jul 2013 09:54:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MSikjiyfQMZYK8ou/JLQuBnCE3+YIGEwOHU8di54Y3Q=; b=ZqEnWJEb9hRcoD0uquDjpCGSG4gKSBK6T/P+aNxc5v2K+j0GtdHaYvro4eTyA311nx bfY32MkxOolIVzhUSXYaMgNV2J+fr+s4qLjK6MU8QUjSDZoZaJS0IRNkqg/T2C3ILLUz WxeiE93Y7HJxHbFYcwLoUL449YMuf34eKl+SjwdL9bsw0CyQzkK6JixKOcL60B4uBvDr rj0baJHaRn7mjgWUBw+Jb5yuAv+D80CRDo7zrOQgpP4IzgPkeMwwDLgywwlTZ2vF3z2c lKxiH6QsVvGUuxgo5tUT1TypLue8ozGfjOK3bimf2Qj+eLK4ACY8wfjqU9JBbuB0rC/O 1noA== MIME-Version: 1.0 X-Received: by 10.180.79.161 with SMTP id k1mr1584559wix.36.1375203294908; Tue, 30 Jul 2013 09:54:54 -0700 (PDT) Received: by 10.216.21.138 with HTTP; Tue, 30 Jul 2013 09:54:54 -0700 (PDT) In-Reply-To: References: <20130730142623.GB17809@mercury.ccil.org> <20130730160719.3203.qmail@joyce.lan> Date: Tue, 30 Jul 2013 11:54:54 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Cc: John Levine , "json@ietf.org" Subject: Re: [Json] fun with streaming, was The names within an object SHOULD be unique. 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, 30 Jul 2013 16:55:26 -0000 On Tue, Jul 30, 2013 at 11:39 AM, Tim Bray wrote: > Has anyone any personal knowledge of an app whose correct function depends > on the use of duplicate keys? -T On was linked earlier, one whose docs explicitly said "JSON supports this, so we use it". I don't mind breaking them. What I do mind is language that leaves streaming implementations in the cold. From sgbeal@googlemail.com Tue Jul 30 09:55: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 DEC9811E81E8 for ; Tue, 30 Jul 2013 09:55:48 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622, 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 4oyZVGRh5NLu for ; Tue, 30 Jul 2013 09:55:46 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 38FEC11E80E6 for ; Tue, 30 Jul 2013 09:55:26 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hq12so3013523wib.2 for ; Tue, 30 Jul 2013 09:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=unOYED8ZdcsxVD7XqFKDneqdr59HXGxQauxLhGnwmZ8=; b=I9jfDfvwD/3Hi8OgJHMjTluoybwrSZBvcSYRzcfMtPUiPaBRSyBqwhEIcC6qMyIKmw s+XcSZcBgZTWCgPwJr7335XmBzheAotZ4hcooqrPpa0bwZylwNYZUgDNxDTrfzGa5Pst eKYhp6StQltRyh4kTL2Bn0F57Vlrup1JERh+nFYJiNFDepfY8LQNx4o0FcdkWOeo4/4T zsBRiHOG2aL12LoixWRGE3/zI2L3IZtDI1g74gkgPdkdg+DuoD6i3zgsb4opmy0IJYq8 9Vs02ChDw2zGiF455QXTmzMVqfe194A5KBMhu7DuVj6cXCJNRtxaoY0Hp6XbIe7/x7I/ Xfiw== MIME-Version: 1.0 X-Received: by 10.194.75.201 with SMTP id e9mr32603943wjw.20.1375203325802; Tue, 30 Jul 2013 09:55:25 -0700 (PDT) Received: by 10.194.192.162 with HTTP; Tue, 30 Jul 2013 09:55:25 -0700 (PDT) In-Reply-To: References: <20130730142623.GB17809@mercury.ccil.org> <20130730160719.3203.qmail@joyce.lan> Date: Tue, 30 Jul 2013 18:55:25 +0200 Message-ID: From: Stephan Beal To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb04efcba7e8904e2bd795f Subject: Re: [Json] fun with streaming, was The names within an object SHOULD be unique. 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, 30 Jul 2013 16:55:52 -0000 --047d7bb04efcba7e8904e2bd795f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jul 30, 2013 at 6:39 PM, Tim Bray wrote: > Standard. Once again as with naked surrogates, there=92s an invisible cl= ass > of alleged implementors of JSON sending/receiving code for whom > dupe-checking is intractable; except for we haven=92t heard from anyone w= hose > application actually depends on this behavior. > i've mentioned before that it's a cost i would be very upset about having to pay. For me it's mostly a matter of principal - i feel strongly that this is a corner case which falls under the "worst practice" category. Use arrays of key/value pairs when dupes are required. Incompatibilities in impls =3D=3D less reliability, and the duplicate keys scenario is _easily_ worked around _within_ a unique-keyed JSON world view, so no changes to JSON are necessary in order to get the effect for those who really need it (which is apparently a minority, if my memory of the list traffic serves me correctly). Has anyone any personal knowledge of an app whose correct function depends > on the use of duplicate keys? -T > Not i. --=20 ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --047d7bb04efcba7e8904e2bd795f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 30, 2013 at 6:39 PM, Tim Bray <tbray@textu= ality.com> wrote:
=
Standard.=A0 Once again as with naked surro= gates, there=92s an invisible class of alleged implementors of JSON sending= /receiving code for whom dupe-checking is intractable; except for we haven= =92t heard from anyone whose application actually depends on this behavior.= =A0

i've men= tioned before that it's a cost i would be very upset about having to pa= y. For me it's mostly a matter of principal - i feel strongly that this= is a corner case which falls under the "worst practice" category= . Use arrays of key/value pairs when dupes are required. Incompatibilities = in impls =3D=3D less reliability, and the duplicate keys scenario is _easil= y_ worked around _within_ a unique-keyed JSON world view, so no changes to = JSON are necessary in order to get the effect for those who really need it = (which is apparently a minority, if my memory of the list traffic serves me= correctly).

Has anyone any personal kn= owledge of an app whose correct function depends on the use of duplicate ke= ys?=A0 -T

Not i.
=

--
----- stephan beal
http://wanderinghorse.ne= t/home/stephan/
--047d7bb04efcba7e8904e2bd795f-- From tsaloranta@gmail.com Tue Jul 30 10:56:38 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 358E311E81E1 for ; Tue, 30 Jul 2013 10:56:38 -0700 (PDT) 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, 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 g55kUtkHDoUQ for ; Tue, 30 Jul 2013 10:56:37 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F3BF611E810B for ; Tue, 30 Jul 2013 10:56:36 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q55so5387761wes.2 for ; Tue, 30 Jul 2013 10:56:36 -0700 (PDT) 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=EXIK3iYLnb5PWYFiFtC4D0x1fqizXF8vQEHf/GQ7nVM=; b=dH6NbM4BHaGzhrBzLXnL/+ClLRzzKB5RR1+k38ApkLL6ehziBQqfzTJccgCTKCumJJ s8fwelG3GlTh6C8KHDLe12TrgSbUjJ9nLAx4O6rs+s6MWuAws0pO9ZCudz8iBPzY4+pe Y+To/i3nJYSfTge6oZe/dL1144csEqYH7DkJxLzQ9klN/s3OqZ+oauNo2hsM7n+ylMQx fnR/bf0axPNLYJubALRnU1iQz5rQHaIPej8TLQQRzJEwIK2lOZHlAI9tLI+oooeZgAy2 LBfoHCQxIFWhvfeebtApt6wxB7v1wgtNcxE98y9lZNrDGfUNe3/ocITXByJsQZwkzM0l jisA== MIME-Version: 1.0 X-Received: by 10.180.19.196 with SMTP id h4mr1734079wie.38.1375206996108; Tue, 30 Jul 2013 10:56:36 -0700 (PDT) Received: by 10.216.233.196 with HTTP; Tue, 30 Jul 2013 10:56:36 -0700 (PDT) In-Reply-To: References: <20130730142623.GB17809@mercury.ccil.org> <20130730160719.3203.qmail@joyce.lan> Date: Tue, 30 Jul 2013 10:56:36 -0700 Message-ID: From: Tatu Saloranta To: Tim Bray Content-Type: multipart/alternative; boundary=bcaec53d55f17ef06a04e2be54be Cc: John Levine , "json@ietf.org" Subject: Re: [Json] fun with streaming, was The names within an object SHOULD be unique. 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, 30 Jul 2013 17:56:38 -0000 --bcaec53d55f17ef06a04e2be54be Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jul 30, 2013 at 9:39 AM, Tim Bray wrote: > On Tue, Jul 30, 2013 at 9:07 AM, John Levine wrote: > >> >> I've never seen an implementation ... Better, can you give an exampl= e >> of such an >> >> >> implementation? >> > >> >I haven't either, but I could see the uses of an implementation >> > > I don=92t think =93I could see the uses of=94 is a good reason for writin= g an > Internet Standard. Once again as with naked surrogates, there=92s an > invisible class of alleged implementors of JSON sending/receiving code fo= r > whom dupe-checking is intractable; except for we haven=92t heard from any= one > whose application actually depends on this behavior. > > Has anyone any personal knowledge of an app whose correct function depend= s > on the use of duplicate keys? -T > > You are conflating the issues here. If you ask whether someone depends on use of duplicate keys, I don't, and have never seen use I consider valid. One mentioned use case for "comments" does not seem valid to me. But your comment on "alleged" intractability is different (and tone unnecessary). This is a common use case for processing large JSON files; either output as JSON arrays, or just sequences of space-separate objects. Typical data sets are log output, processing from map/reduce style jobs and batch jobs. In those cases, object mapper or tree builder can build representation for single object, using streaming parser, only reading that subset of content. Reading the whole data set would be prohibitive and unnecessary. Duplicate name detection at higher level is doable. Doing it at streaming parser level is unnecessary and expensive relative to necessary parts of decoding. Separation between streaming part and higher layers is for good separation of concern, as well as practical matter for reusing components. I use such processing pipelines regularly, and based on number of questions on various forums (Jackson user/dev mailing lists, StackOverflow) it is a common use case. -+ Tatu +- --bcaec53d55f17ef06a04e2be54be Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 30, 2013 at 9:39 AM, Tim Bray <tbray@textu= ality.com> wrote:
On Tue, Jul 30, 2013 at 9:0= 7 AM, John Levine <johnl@taugh.com> wrote:
>> I've never seen an implementation ...=A0 Better, can you give = an example of such an

>> implementation?
>
>I haven't either, but I could see the uses of an implementation

I don=92t think =93I could see the uses= of=94 is a good reason for writing an Internet Standard.=A0 Once again as = with naked surrogates, there=92s an invisible class of alleged implementors= of JSON sending/receiving code for whom dupe-checking is intractable; exce= pt for we haven=92t heard from anyone whose application actually depends on= this behavior.=A0

Has anyone any personal knowledge of an app whose correct fu= nction depends on the use of duplicate keys?=A0 -T


You are conflating the issues here.=

If you ask whether someone depends on use of duplicate keys,= I don't, and have never seen use I consider valid. One mentioned use c= ase for "comments" does not seem valid to me.

But your com= ment on "alleged" intractability is different (and tone unnecessa= ry).

This is a common use case for processing large JSON files; either outpu= t as JSON arrays, or just sequences of space-separate objects. Typical data= sets are log output, processing from map/reduce style jobs and batch jobs.=

In those cases, object mapper or tree builder can build representation = for single object, using streaming parser, only reading that subset of cont= ent.
Reading the whole data set would be prohibitive and unnecessary. Duplicate name detection at higher level is doable. Doing it at streaming p= arser level is unnecessary and expensive relative to necessary parts of dec= oding.
Separation between streaming part and higher layers is= for good separation of concern, as well as practical matter for reusing co= mponents.

I use such processing pipelines regularly, and based on numb= er of questions on various forums (Jackson user/dev mailing lists, StackOve= rflow) it is a common use case.

-+ Tatu +-

--bcaec53d55f17ef06a04e2be54be-- From jorge@jorgechamorro.com Tue Jul 30 11:13: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 8579E11E8108 for ; Tue, 30 Jul 2013 11:13:31 -0700 (PDT) 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 n8ko3-4yIHLB for ; Tue, 30 Jul 2013 11:13:26 -0700 (PDT) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1D411E80F3 for ; Tue, 30 Jul 2013 11:13:25 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w60so5499524wes.29 for ; Tue, 30 Jul 2013 11:13:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mSkg0Qj6fiQhqjW6Zn5Y+OSG5zxahHqf4W3KLoQhdOg=; b=aUzVOLnWEBfQiJS8BdH4OSQEgfYdkAQ6KOZAGTOBIKDKodAIckcziCu2iJ0wMyaiun kgvWODUb36ez++LqMlsn0p2b+EPFXMt0To9UiItVAOuFAWzNIHsvuL2Yi6NMtSC311WH e+f2gYDB4u5DI8G7Z+96p+zk0qs27nCaccV2qAn7lHrCw7QdqaO5yFSOzhqQzKs8/j1u mqzq5HstJUFAxftfPFoxIF6/7Ftc/z5vPZfUYgxZWltwI8z1QuBwDrGopWelMbDZFqgH c7lHrw/Ca6+RdB9faCb9mNRsdE93NKwyc1eJDYGDuXV80bTH6ShZdfJM4dOS2TwH1NQ0 VivQ== X-Received: by 10.180.160.165 with SMTP id xl5mr1784281wib.46.1375208005088; Tue, 30 Jul 2013 11:13:25 -0700 (PDT) Received: from [192.168.10.50] (134.Red-88-0-161.dynamicIP.rima-tde.net. [88.0.161.134]) by mx.google.com with ESMTPSA id s19sm30204219wik.11.2013.07.30.11.13.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 11:13:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: Date: Tue, 30 Jul 2013 20:13:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5CA3F8DE-40FD-4B0E-B60F-7120E5127622@jorgechamorro.com> References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkbl8QK7LTVh0hzDlRba+gjnBDhgS/maSIuTFyRRJpkulylFgVi4M8IWmYkalDIOH3rznhG Cc: John Cowan , "json@ietf.org WG" Subject: Re: [Json] The names within an object SHOULD be unique. 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, 30 Jul 2013 18:13:31 -0000 On 30/07/2013, at 16:11, Joe Hildebrand (jhildebr) wrote: > On 7/30/13 1:11 PM, "Jorge Chamorro" wrote: >=20 >> On 28/07/2013, at 05:46, John Cowan wrote: >>> Jorge Chamorro scripsit: >>>=20 >>>> Yes, but it's problematic only for the streaming parsers that emit >>>> [key,value] pairs, not for those which emit entire objects. >>>=20 >>> In what sense are they streaming parsers, then? The whole idea of a >>> streaming >>> parser is that it passes along the elements of JSON objects, arrays, = and >>> perhaps even strings and numbers bit by bit to the invoking = application. >>=20 >> Say you've got a stream (a pipe or a network connection) and a stream = of >> json-objects arriving through it, you may very well want the parser = to >> emit entire objects instead of its parts, no? >=20 > I've never seen an implementation that is both streaming and not = streaming > at the same time. Can you say more about how you'd write the API for > that? Easy: parser=3D CreateStreamingParser(stream, listener); :-) Whenever the parser's got a complete json-object, it simply calls = listener(JSON.parse(json-object)); > Better, can you give an example of such an implementation? There's a bunch, most use a delimiter (say \0) as a chunks boundary = marker so that they can be stateless. But some aren't stateless: = There's also node.js' fork(), where communication between parents and = children happens via "messages" that a are json.strigify()ed objects, = via a pipe or a network connection. The thing is, a streaming parser is one whose *input* is a stream, isn't = it? > If you mean an application that takes a stream of complete JSON = objects > without wrapping them in an array, that problem is likely out of = scope, > and the processor would act identically to a non-streaming = implementation > in our existing worldview. That's why I said that duplicate keys complicate only those parsers that = emit parts as soon as they arrive. --=20 ( Jorge )(); From tsaloranta@gmail.com Tue Jul 30 11:14: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 AE19211E8108 for ; Tue, 30 Jul 2013 11:14:00 -0700 (PDT) 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, 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 5WJ8XFELj+91 for ; Tue, 30 Jul 2013 11:13:59 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 195A711E80F3 for ; Tue, 30 Jul 2013 11:13:58 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id j17so4096019wiw.13 for ; Tue, 30 Jul 2013 11:13:58 -0700 (PDT) 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=B8OqryX8yeUsQcKCoolCAfmRZMLXmnmPAzc2EYmUkqE=; b=F2v6HUesuRPoJieAsYV6fg1jdm/IoV6LARTrIphreQDKgLfd1UWg9csc0lfgTPwk+R JBxSzyFUmaz2yDt61rFdYGUubepHRAmakL3Bk54z8BgDzc4ba9+Im535Qs78wFE5TY5i TMc/GK9HR3qzAgdKFlStnWjobB2SpXtnhfv748vGNny5sAC/oHMGDpQ9/U0sRlJnqqTm 34GYn8NHo3f5l08mObP0UA3WCanHvJuyKDOhkw4h4hN+XdfbvFd7+/II7Rg0QgIc39CN oJx987P09ci8TI51mo2QPaax11QkgsjCKAZZD31b3ndOXLNao+jMgs0iV/ENFgDGfeHT rugw== MIME-Version: 1.0 X-Received: by 10.180.20.116 with SMTP id m20mr1786540wie.46.1375208038172; Tue, 30 Jul 2013 11:13:58 -0700 (PDT) Received: by 10.216.233.196 with HTTP; Tue, 30 Jul 2013 11:13:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jul 2013 11:13:58 -0700 Message-ID: From: Tatu Saloranta To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=bcaec53f2e319b8db404e2be92a7 Cc: Jorge Chamorro , John Cowan , "json@ietf.org WG" Subject: Re: [Json] The names within an object SHOULD be unique. 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, 30 Jul 2013 18:14:00 -0000 --bcaec53f2e319b8db404e2be92a7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 30, 2013 at 7:11 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 7/30/13 1:11 PM, "Jorge Chamorro" wrote: > > >On 28/07/2013, at 05:46, John Cowan wrote: > >> Jorge Chamorro scripsit: > >> > >>> Yes, but it's problematic only for the streaming parsers that emit > >>> [key,value] pairs, not for those which emit entire objects. > >> > >> In what sense are they streaming parsers, then? The whole idea of a > >>streaming > >> parser is that it passes along the elements of JSON objects, arrays, and > >> perhaps even strings and numbers bit by bit to the invoking application. > > > >Say you've got a stream (a pipe or a network connection) and a stream of > >json-objects arriving through it, you may very well want the parser to > >emit entire objects instead of its parts, no? > > I've never seen an implementation that is both streaming and not streaming > at the same time. Can you say more about how you'd write the API for > that? Better, can you give an example of such an implementation > I do not know if this is what was meant, but there is an obvious ways to combine streaming parser with object binding (and by object binding I mean both binding to host language types as well as tree representations). It is what many Java JSON parsers do; Jackson, Gson, and Genson at least. Data binding component takes a streaming parser through which it can iterate over JSON tokens. Data binder simply reads enough tokens to build specific object indicate by the first token: if it is START_OBJECT, it will consume up to until matching END_OBJECT. Similarly for other types (for scalars single token is value). But application can also iterate over tokens directly, instead of passing it to data binder. If content is, for example, long array of objects, it would read START_ARRAY and first START_OBJECT, then start calling data binder. Here's an example (not optimal, but functional) of using streaming and data-binding modes, in complementary way http://stackoverflow.com/questions/15688951/combining-jackson-objectmapper-and-stream-parsing Apologies if this is obvious -- I assumed this was common knowledge but perhaps it is not. -+ Tatu +- --bcaec53f2e319b8db404e2be92a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 30, 2013 at 7:11 AM, Joe Hildebrand (jhildebr)= <jhildebr@cisco.com> wrote:
=
On 7/30= /13 1:11 PM, "Jorge Chamorro" <jorge@jorgechamorro.com> wrote:

>On 28/07/2013, at 05:46, John Cowan wrote:
>> Jorge Chamorro scripsit:
>>
>>> Yes, but it's problematic only for the streaming parsers t= hat emit
>>> [key,value] pairs, not for those which emit entire objects. >>
>> In what sense are they streaming parsers, then? =A0The whole idea = of a
>>streaming
>> parser is that it passes along the elements of JSON objects, array= s, and
>> perhaps even strings and numbers bit by bit to the invoking applic= ation.
>
>Say you've got a stream (a pipe or a network connection) and a stre= am of
>json-objects arriving through it, you may very well want the parser to<= br> >emit entire objects instead of its parts, no?

I've never seen an implementation that is both streaming and not = streaming
at the same time. =A0Can you say more about how you'd write the API for=
that? =A0Better, can you give an example of such an implementation

I do not know if this is what was meant, but th= ere is an obvious ways to combine streaming parser with object binding (and= by object binding I mean both binding to host language types as well as tr= ee representations).
It is what many Java JSON parsers do; Jackson, Gson, and Genson at least.

Data binding component takes a streaming parser through wh= ich it can iterate over JSON tokens. Data binder simply reads enough tokens= to build specific object indicate by the first token: if it is START_OBJEC= T, it will consume up to until matching END_OBJECT. Similarly for other typ= es (for scalars single token is value).

But application can also iterate over tokens dire= ctly, instead of passing it to data binder. If content is, for example, lon= g array of objects, it would read START_ARRAY and first START_OBJECT, then = start calling data binder.

Here's an example (not optimal, but functiona= l) of using streaming and data-binding modes, in complementary way

<= a href=3D"http://stackoverflow.com/questions/15688951/combining-jackson-obj= ectmapper-and-stream-parsing">http://stackoverflow.com/questions/15688951/c= ombining-jackson-objectmapper-and-stream-parsing

Apologies if this is obvious -- I assumed this wa= s common knowledge but perhaps it is not.

-+ T= atu +-

--bcaec53f2e319b8db404e2be92a7-- From jorge@jorgechamorro.com Tue Jul 30 11:54: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 AA3BB21E80A3 for ; Tue, 30 Jul 2013 11:54:07 -0700 (PDT) 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 5zz7LxBxwKTR for ; Tue, 30 Jul 2013 11:54:01 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 97E4221E80B7 for ; Tue, 30 Jul 2013 11:54:01 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q55so5450705wes.16 for ; Tue, 30 Jul 2013 11:53:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=PKWriji3o54452rnzjYz4Q0MXti8IMZ9GCTykXRTMYw=; b=FWAvp1CNpgwAKwG403Q94LhSB69muQnl6Z+IJYm0HhTGig6XI4H0QIGwF/RNDIPWbC 6mwnWOYjbD7RvkR6vRBffwcibS9harufRlrhGeciAGXFQ10vSR1HWAVWA8yWnjCpgFwl 8CEVZDzDgRuIkh4XHJRM65LJ1wjwXvs4AajvNyqwt9Vro5SJjRuAa9qeWDcKcKAjQxkn 7TWTkmnz9XdKfBkG5mM0jBwnPbif/pA+JsLMjTNnHwcVkqw5j+WofKrVtmmvuHvc5M+2 Qv1MkXDyagk+/2RixxCxaORxM/9P0L2cb9zlZJslfNPyk0abZJOxWWX/AJaSEL/fDHWa uULg== X-Received: by 10.194.190.201 with SMTP id gs9mr6424430wjc.82.1375210439458; Tue, 30 Jul 2013 11:53:59 -0700 (PDT) Received: from [192.168.10.50] (134.Red-88-0-161.dynamicIP.rima-tde.net. [88.0.161.134]) by mx.google.com with ESMTPSA id fb2sm30459171wic.4.2013.07.30.11.53.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 11:53:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jorge Chamorro In-Reply-To: <20130730160719.3203.qmail@joyce.lan> Date: Tue, 30 Jul 2013 20:53:57 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2F68E911-7D17-4FCE-9381-9974248A351C@jorgechamorro.com> References: <20130730160719.3203.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmRyYWiD0v/9gFtFsYb+7dz6KAU3Myie+lZB7/9TRyRmKwRgd9TAkt1HTmlFiTGm632CZPa Cc: json@ietf.org Subject: Re: [Json] fun with streaming, was The names within an object SHOULD be unique. 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, 30 Jul 2013 18:54:07 -0000 On 30/07/2013, at 18:07, John Levine wrote: > > > It has been my impression that the reasons that people use streaming > implementations are either that it's a tiny system that doesn't have > room to buffer full arrays and full objects, or else it's a realtime > application that needs to see the first item in the array or object > before the rest of it arrives. Or because the *input* is a *stream* not a string. -- ( Jorge )(); From johnl@taugh.com Tue Jul 30 14:10: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 3C56611E81FD for ; Tue, 30 Jul 2013 14:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7Zmsx3pmBl+8 for ; Tue, 30 Jul 2013 14:10:42 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 37D7411E81E3 for ; Tue, 30 Jul 2013 14:10:41 -0700 (PDT) Received: (qmail 70303 invoked from network); 30 Jul 2013 21:10:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=1129e.51f82bd0.k1307; bh=ejTGaQHKazDNAoJDjf7D5xdtP5YPPWQGU2pyddQo7Qo=; b=qZAtJeMI5bQZiEUuqzIvb62vojRsu4YzcbpddTe8dlty72rqDSFNP6MvKEGEpWAAxjlAGn52Z3Q/W8zN+DMW79BxqjnoAJ2/HoSsPQigtgT0gVP7g+H0DGX5iPxMqrGc0YgeppOkkvalyLojHl1vZNnKUoJZqeZuVCKio4sKPpAcsfQ43AzjNAfcUQZE1jbirdYedy1S5JedbJ0bNV0vnBla/zc/q3pJgxZ3LajiHrvNfo0z2RN5sOMyxxIU51M9 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=1129e.51f82bd0.k1307; bh=ejTGaQHKazDNAoJDjf7D5xdtP5YPPWQGU2pyddQo7Qo=; b=iqrh4/BG07Qv3xiH3LwFZ//IWajPICxWm+DyRXGlzIexMzSyWARBLIqdgPc32JamOW/+lTwHuSL5n+USMzQeBj4k2cMPYARhUmWvTy7Z73cZavKKQvHgiyl0rOaQXkYCASPM+JPU1ndrNiFq5V0OHsbFILjgaBma7Fh942qVRJWC3l2RUOz2aR6EocywnjqCfeEcdkGX4jZYERqBhmkJhNz7fI0HfZBye+40tlUq0pCwNWs+F2DmxGc8BN9qOwxD Received: (ofmipd 127.0.0.1); 30 Jul 2013 21:10:18 -0000 Date: 30 Jul 2013 23:10:40 +0200 Message-ID: From: "John R Levine" To: "Nico Williams" In-Reply-To: References: <20130730142623.GB17809@mercury.ccil.org> <20130730160719.3203.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "json@ietf.org" Subject: Re: [Json] fun with streaming, was The names within an object SHOULD be unique. 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, 30 Jul 2013 21:10:43 -0000 >> Has anyone any personal knowledge of an app whose correct function depends >> on the use of duplicate keys? -T > > On was linked earlier, one whose docs explicitly said "JSON supports > this, so we use it". I don't mind breaking them. What I do mind is > language that leaves streaming implementations in the cold. Seems like we're talking past each other again. We all agree that duplicate keys suck, but since they have been observed in the wild, we ask a parser to document what it does with them, from the list of options mentioned before. I think that's both all we can ask, and it's plenty. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From presnick@qti.qualcomm.com Wed Jul 31 02: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 2FDB621F9E73 for ; Wed, 31 Jul 2013 02:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=0.396, 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 cRdObiLR9xG8 for ; Wed, 31 Jul 2013 02:15:49 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id F041A21F9A3C for ; Wed, 31 Jul 2013 02:11:12 -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=1375261872; x=1406797872; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=K1x/6/Rnd5Q1GS8COXvadWyWVpneAb0par26K+1A6cA=; b=Ihr1RE93HJXDVStJMXa/hBWbkXyyH9UQBVwJjP4yeBa6s2ErjhmEfR6u 8YJknDGsVNKIJ0fmbvlDpMFjI8+ZqpjEIpi+N0t09ZHK73y/a+x1ib34D DIUaWDgqUQA1fwKb/+ZHBgsT5G91hvqWg0iRTL7lq1iIoVIaYtd+pwZV7 c=; X-IronPort-AV: E=Sophos;i="4.89,785,1367996400"; d="scan'208";a="48635297" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 31 Jul 2013 02:11:11 -0700 Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Jul 2013 02:11:11 -0700 Received: from dhcp-45fa.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 02:11:10 -0700 Message-ID: <51F8D4AC.7080301@qti.qualcomm.com> Date: Wed, 31 Jul 2013 11:11:08 +0200 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: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [Json] Some thoughts on the "text model" discussion 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, 31 Jul 2013 09:15:56 -0000 Like Matt said of the duplicate names discussion, I think we do appear to be converging (albeit more slowly) on a couple of possible outcomes in the discussion of the text model. I'll leave it to the chairs to truly summarize conclusions, but I did want to make a couple of observations that I hope can hone in on a few of those conclusions: - People did quickly slide from my more overarching question about what makes up a JSON entity to the specific question about JSON strings in particular. Though clearly my aim was to inform the issue of strings, I was hoping we could come up with a more general principle. In the end, I think we made some good progress on figuring out those general principles. - The discussion at the beginning regarding "a JSON object" vs. "a JSON text" was very revealing to me because it leads me to believe that nowhere do we have a general concept of a "JSON entity" aside from it encoding or representation in memory. I think that has made some of the discussion more difficult, but my sense is that we now share a more general view of what such a thing might be. This leads to another point: - The use of the terms "JSON parser" and "JSON generator" is often conflated with things that I would refer to as a "JSON lexer" on the parsing end of things and an "JSON encoder" or maybe a "JSON token producer" on the generator end of things. That is, when I think of a "JSON parser", I think of something that understands the semantics of the JSON entity it is creating out of the JSON text it is parsing, and conversely a "JSON generator" knows about the semantics of the JSON entity it is turning into a JSON text from some in-memory representation. Some of the difficulty in the conversation is that we know of pieces of code that don't know about the semantics and therefore don't "know" whether they are dealing with Unicode characters or just a series of Unicode scalar values. (This caused similar confusions in the duplicate names discussion.) Requirements on things that have to know the semantics are different than the requirements on things that are simply lexers or encoders. How we explain that (and what language we use for it) in the documents is independent of the point that they are different requirements. For each of these three items, I think if we end up with some explanatory text in the documents that helps make the appropriate distinctions (and note that I am being purposely agnostic on what the WG should say about each of them), I think that would help the clarity and implementability of the spec. I'll leave it to the chairs to decide where to take the discussion from here. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478