From nobody Tue Dec 2 09:58:26 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AD51A1BFB for ; Tue, 2 Dec 2014 09:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9Wv5GhlCxao for ; Tue, 2 Dec 2014 09:58:23 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F621A1BBD for ; Tue, 2 Dec 2014 09:58:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1116; q=dns/txt; s=iport; t=1417543103; x=1418752703; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=b5Vm2SoLVM489W0fOl+iDnOYwzZ7sDR956F40G6d6Os=; b=Gcf0qYsnxedXTPgkL4pQW24KufFqBOnc2G3LsyFVmbyvZtrOcvXhUTzU xuS4ET4a1TJB5rd4zpDsKIG6yZNLmhwS95r3emQU2EEUQEcCfVWhNMq73 ECrI91VvEOHkXNX/BlCWpwZWGDF3ryUvO9fNlDBWPgJl1JOA0ok96wUpH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAAD9fVStJA2L/2dsb2JhbABbgwdSWQSDAcQDh00WAQEBAQF9hCxVNgIFFgsCCwMCAQIBSw0IAQGIPLBej0WWXAEBAQEGAQEBAQEZBIErkkCBUwWLAYoehmeHRo1bggQegXlPgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413244800"; d="scan'208";a="101973692" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP; 02 Dec 2014 17:58:22 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sB2HwMpc030579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Dec 2014 17:58:22 GMT Received: from [10.129.24.46] (10.129.24.46) by xhc-rcd-x07.cisco.com (173.37.183.81) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Dec 2014 11:58:21 -0600 Message-ID: <547DFDBF.3040408@cisco.com> Date: Tue, 2 Dec 2014 10:58:23 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.129.24.46] Archived-At: http://mailarchive.ietf.org/arch/msg/json/CH6Hh5Pcc5zNlyeCwI1iEIU_bqc Subject: [Json] Closing out I-JSON Issues from the AD X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 17:58:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, With the publication of draft-ietf-json-i-json-04, many of the outstanding concerns from our AD have been addressed. However, there are two issues from his original list that deserve more discussion: one on Numbers and one on Software Behavior. We'll be starting two separate threads presently to go over these issues. Once there is consensus on these issues and any needed updates published, we will request the IESG publish I-JSON. Thank you, - --=20 - - m&m Matt Miller -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUff2/AAoJEDWi+S0W7cO1q50H/1pV9CgebX609MGj3W0sDCyH 03/fR7z+l+xjA6lFQOkSZIfKA1aoQ+5nXmwaoe3AJD0eeaXCUqCCF3srJUxg5inD Qh9g+MgvCN13ZCsiJBbaoaHToUkXvO9lbmwR0nAdLcxX4ru+nCW2KTqOvZHE1yL+ H3KcUZxX/oTJW9q3KRZOmXDB/6B/O3ZL2NgpHnlRpUNbHtzSlZJWavQSiEZoWqaB vAs8WKGflI55qap8nP1Kz9V/eHJw3EkbkoMcM7PmwqqedN8/Qtl0tn+E+fy2R2xE TEfrMZ+JeYXdZjR0pErnogtSn1PtqHWlAaxaXvO/NGgnGfVzgbxTaqEeK+apD0I=3D =3D6rvw -----END PGP SIGNATURE----- From nobody Tue Dec 2 10:00:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E221A6FAD for ; Tue, 2 Dec 2014 10:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQwQMOYew1il for ; Tue, 2 Dec 2014 10:00:17 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E5A1A6F59 for ; Tue, 2 Dec 2014 10:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2290; q=dns/txt; s=iport; t=1417543216; x=1418752816; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=zrkv4DtUA2aONJumtIm8lqzwGG2kaCNS77PrIfoGqxU=; b=EYhK2AaACWGKGKt3WjPR5OQKpPDUqu2s8qVs7i5FbLgJVy/T7o5BdWRI uTwUFiKapjazJxLfH7JSjOt/+AhnaraMe7pTum5vXcYrh4p75d8+jUixE EyHtPAkcuT69AIupDOaKXEmrGGf1bGxpcz27MmTjIO4nSr7o4XsBZkg3F 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFALf9fVStJA2N/2dsb2JhbABbgwdSWQSDAcQDh00WAQEBAQF9hCwPAUU2AgUWCwILAwIBAgFLDQgBAYg8sDqPRZZcAQEBBwEBAQEBGQSBK5JAgVMFiwGKHoZnh0aNW4IEHoF5T4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.07,502,1413244800"; d="scan'208";a="376935157" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP; 02 Dec 2014 18:00:15 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sB2I0Fem009950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Dec 2014 18:00:15 GMT Received: from [10.129.24.46] (10.129.24.46) by xhc-rcd-x07.cisco.com (173.37.183.81) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Dec 2014 12:00:15 -0600 Message-ID: <547DFE31.6030507@cisco.com> Date: Tue, 2 Dec 2014 11:00:17 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.46] Archived-At: http://mailarchive.ietf.org/arch/msg/json/NuBn6JEiTOISMgLjQTrrwpLNOmM Subject: [Json] I-JSON Outstanding AD Issues: Software Behavior X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:00:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, In evaluating draft-ietf-json-i-json-03, our AD raised a number of concerns. While most have been addressed in -04, some of the issues regarding numbers where left unclear. One issue is the phrase "MUST NOT trust nor act on" in section 3. Software Behavior; our AD believes placing this constraint onto consumers is too onerous. The text in question is: When software reads data which it expects to be an I-JSON message, but the data violates one of the MUST constraints in the previous section (for example, contains an object with a duplicate key, or a UTF-8 encoding error), that software MUST NOT trust nor act on the content of the message. The suggested change is: A major advantage of using I-JSON is that receivers can avoid ambiguous semantics in the JSON messages it receives. This allows receivers to reject or otherwise disregard messages which do not conform to the requirements in this document for I-JSON messages. Protocols that use I-JSON message can be written so that receiving implementation are required to reject (or, as in the case of security protocols, not trust) messages that do not satisfy the constraints of I-JSON. This concern (and its suggested change) garnered no discussion whatsoever. The questions to the Working Group is: 1) Is this suggested change acceptable, and the current text *NOT* acceptable? 2) Is the current text acceptable, and the suggested change *NOT* acceptable? 3) Is either text equally acceptable? 4) If neither sets of text are acceptable, what specific text would be? Thank you, - -- - - m&m Matt Miller -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUff4wAAoJEDWi+S0W7cO18ToIAK8p5yOhp/3DvwP3zCli6LqG 5x4YCxyUMxg0xsfdEt8mk3WGST6gXgVivPlFO/bqjoKJtyMcBz0OcaM/n5JBB0lx OMF+x/OSmxt1kv0q5tsBca3pAZuNvJ+BIDJ/ezqKxlJyLoxIq/6aeolaAOqCGjbK d2Vgi9q3aSNbZrMdgvJ6OKJHs3cl5wQ6KN5z8gOHG+bPvuxGzTpkIAZa2VX1jtKw RHyH8FKnnaumU49pIUbiIY0e8+MwIt+23HBV6mtEHZ1AvmZPt30Zay0fJeOsHUfA 41wxrtwm8eiseQmbHHnOsEeOOFQSNdNGjeIZnZDYk0nCiEnkf9kbGRdvSrSy7QI= =/DcS -----END PGP SIGNATURE----- From nobody Tue Dec 2 10:01:30 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393FB1A6F27 for ; Tue, 2 Dec 2014 10:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjWkJOvVXX6I for ; Tue, 2 Dec 2014 10:01:26 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11CB1A1BFB for ; Tue, 2 Dec 2014 10:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2648; q=dns/txt; s=iport; t=1417543285; x=1418752885; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=iXxR3Dti1jZhr2RIrxr/CNmo3aCQBBW/DIvavP2kJTU=; b=VJ0uql7NANEN0MI2cDRxNtMdvZrN9ODpgGqgGayd9rwZ6CRf5gG/LsNh br4NtUzpEJb4nXVcR3ftloF2QqLPQUtn+xEKY1XhcMGqE54SMQM9uydIj nbJ1ucVrnUsfChjM3D5v17/m0owB0s3RaF69lx1RJL3j1Wlou7yWDUjx4 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFACf+fVStJA2E/2dsb2JhbABbgwdSWQSDAcQDh00WAQEBAQF9hCwPAUU2AgUWCwILAwIBAgFLDQgBAYg8sDuPRZZcAQEBBwEBAQEBGQSBK5JAgVMFiwGKHoZnh0aNW4IEHoF5T4EEBjyBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413244800"; d="scan'208";a="101972974" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP; 02 Dec 2014 18:01:24 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB2I1Oo2008831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Dec 2014 18:01:24 GMT Received: from [10.129.24.46] (10.129.24.46) by xhc-rcd-x07.cisco.com (173.37.183.81) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Dec 2014 12:01:23 -0600 Message-ID: <547DFE75.8080903@cisco.com> Date: Tue, 2 Dec 2014 11:01:25 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF JSON WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.46] Archived-At: http://mailarchive.ietf.org/arch/msg/json/MJEZTfbHWnAO4VmboRUmOnHGPpk Subject: [Json] I-JSON Outstanding AD Issues: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 18:01:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, In evaluating draft-ietf-json-i-json-03, our AD raised a number of concerns. While most have been addressed in -04, some of the issues regarding numbers where left unclear. One issue is the use of "MUST NOT expect" (which is now "cannot expect" in -04) and "MUST NOT assume" in Section 2.2. Numbers; our AD believes the current text is not direct enough guidance for implementers. The text in question is: Software which implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used. Implementations which generate I-JSON messages MUST NOT assume that receiving implementations can process numeric values with greater magnitude or precision than provided by those numbers. I-JSON messages SHOULD NOT include numbers which express greater magnitude or precision than an IEEE 754 double precision number provides, for example 1E400 or 3.141592653589793238462643383279. In particular, an I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications which require the exact interchange of numbers with greater magnitude or precision (one example would be 64-bit integers), it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. While there was much discussion, there is no clear consensus from the previous round of discussion. This issue still needs some resolution, however. To that end, the questions to the Working Group are: 1) Is the current text acceptable? 2) If the current text is *NOT* acceptable, is changing "MUST NOT assume" and "MUST NOT expect" to "cannot assume" and "cannot expect" (respectively) acceptable? 3) None of the above are acceptable, If what specific text would be? Thank you, - -- - - m&m Matt Miller -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUff51AAoJEDWi+S0W7cO1Zb4H/RD01n6gdunhtU4m8t60vU62 TuY93PJ0XgXWHu0UkE8Kc3+VTDsg2GxegKloLsXqNzbPt3OMa3DivBhTPADI88AK y1hMELlOOPk6Ie8GNMaDx52DIkiolApIZdDrPGUZTG95SvmqIc6sCr4BH7EDZptW 7to74d+rhKGK689lM9p8XZ6m5t9B9m4gKcyrIWv6UqnRGU2b1onFKf4izD/EJpah bXaac6qB79pDzsqFTLCALdMrtoYJtmoS1dP8V7a7FDaRoWkRF7iLHLTKN6ZKmuXN tXzU8uFela6OsImfl0X7E5PLzy+6c0DGO1EhOeGzmI9pYnL8XbLACwdTI8aXU98= =GJUY -----END PGP SIGNATURE----- From nobody Tue Dec 2 13:07:10 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706491A8740 for ; Tue, 2 Dec 2014 13:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1macvi4laOl for ; Tue, 2 Dec 2014 13:07:03 -0800 (PST) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC771A7013 for ; Tue, 2 Dec 2014 13:06:26 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id r10so13973683pdi.13 for ; Tue, 02 Dec 2014 13:06:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=QZ501V0h5n+HVBlU0KKhPP4pxB3GhhL0q4k2VvBujvk=; b=TCBpjNR0W4k/cXEFXAEdtDvE2/Nejv2CAi6UJ891f34HC3lQjgZXHFgLCBGY93l5Ne qnFUF6O/hWrZs4KrsmvYUx9VKCRPLKOa4zbDFqhCwdcYbZZd69fI/8rXyP6AnD1bNKpF 8TqM5T12zqH3loMXmP0XLu/8csaQiLfwdMol5s6tJBhg2YRopWwM3HUcLcd/RGXcn6XF EATKv+tRUj3WUjj+52WotvQjpNkKgdxV/fUKbtcKbJU14kJojmjpnsGBW2Cusyged4rf XffZ6/k6reTvz3NbzNhkswyyUVsKbDv2+ZEDiy3fY4kcUg8in7HCjnrp6l7gQCUELavb 5cBg== X-Gm-Message-State: ALoCoQntjLivEvvrMx6sFzF+ifMypDsZ92cFgH+wcD0zrWKYvBfCcRkGaSSvADNGuW5NGUOPEgAi MIME-Version: 1.0 X-Received: by 10.68.216.167 with SMTP id or7mr9226300pbc.166.1417554386174; Tue, 02 Dec 2014 13:06:26 -0800 (PST) Received: by 10.66.135.164 with HTTP; Tue, 2 Dec 2014 13:06:26 -0800 (PST) X-Originating-IP: [2001:500:4:15:3998:ec3b:3bac:18a8] Date: Tue, 2 Dec 2014 16:06:26 -0500 Message-ID: From: Andrew Newton To: JSON WG Content-Type: multipart/alternative; boundary=e89a8f3b5588a35c960509421997 Archived-At: http://mailarchive.ietf.org/arch/msg/json/r7R7IrPMMI8rWdlezEdIPq2cT3c Subject: [Json] JCR -04 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 21:07:07 -0000 --e89a8f3b5588a35c960509421997 Content-Type: text/plain; charset=UTF-8 Based on the discussion that took place here, JCR has been updated to -04. It includes syntax changes and a revised ABNF. Name: draft-newton-json-content-rules Revision: 04 Title: A Language for Rules Describing JSON Content Document date: 2014-12-02 Group: Individual Submission Pages: 28 URL: http://www.ietf.org/internet-drafts/draft-newton-json-content-rules-04.txt Status: https://datatracker.ietf.org/doc/draft-newton-json-content-rules/ Htmlized: http://tools.ietf.org/html/draft-newton-json-content-rules-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-newton-json-content-rules-04 Also, a proof-of-concept JCR parser is here: http://stash-projects.arin.net/projects/JCR/repos/jcr-validator/browse -andy --e89a8f3b5588a35c960509421997 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Based on the discussion that took place here, JCR has= been updated to -04.
It includes syntax changes and a revised AB= NF.

Name: draft-newton-json-content-rules
Revision: 04
Title: A Language for Rules Describing JSON Co= ntent
Document date: <= /span>2014-12-02
Group: Individual Submission
Pages: 28
=

Also, a proof-of-concept JCR parser is h= ere:

-andy
--e89a8f3b5588a35c960509421997-- From nobody Tue Dec 2 22:21:35 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70461A00AE for ; Tue, 2 Dec 2014 22:21:33 -0800 (PST) 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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G06PYjJz7sb9 for ; Tue, 2 Dec 2014 22:21:32 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CF61A00AD for ; Tue, 2 Dec 2014 22:21:32 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id w7so11896012lbi.1 for ; Tue, 02 Dec 2014 22:21:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fGKuPcAUB41MleJCk4a7q9IaHMnMQXKptU7mDfRNaeE=; b=ZdRk3tZk+pi8Y3pxJ0ZoUV754UciZKJn2vWX2ugJ0znZ4Uve22GtZYYgOL70A3FBkc 2AFlZ33Z7r25cYql7AQVwketkw/tbghNdcZvdLFonMt+X5ng9vVE14S3TJz+YF4D93Ko K2Pd7Cg7tRN3kMRgXgVjodKCNJcoPWfQsNwCQQ8JANkuT3xTg9iWAju3Q4Ec2hChd0aP BsbRNlRS/w2lxESJRpdVMRr4rtwx7iBqmjVG3tG5IDnCH8PIbOL6NBEmScUJyuAZkBe+ FuKdEC7sxOKmBKbYWtMTlAuZ0dKPOv5H8o86BUvw9gXXzxXVZCKqk4dvgaRtemNGK8K8 H/0g== X-Gm-Message-State: ALoCoQlrWK02+kqQNAWHTIhmj8U2aWvFRtdpOPRdo7vQ9U2A57dq4jfk8r12iW9uTcwNfEEJTqWT X-Received: by 10.152.234.169 with SMTP id uf9mr2672219lac.86.1417587690511; Tue, 02 Dec 2014 22:21:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.2.143 with HTTP; Tue, 2 Dec 2014 22:21:10 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <547DFE75.8080903@cisco.com> References: <547DFE75.8080903@cisco.com> From: Tim Bray Date: Tue, 2 Dec 2014 22:21:10 -0800 Message-ID: To: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= Content-Type: multipart/alternative; boundary=001a11336fa0bb314d050949dad7 Archived-At: http://mailarchive.ietf.org/arch/msg/json/PCbc1qTJQjVYqhnW-QhzijNd8oQ Cc: IETF JSON WG Subject: Re: [Json] I-JSON Outstanding AD Issues: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 06:21:34 -0000 --001a11336fa0bb314d050949dad7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 2, 2014 at 10:01 AM, =E2=8C=98 Matt Miller = wrote: > =E2=80=8B=E2=80=8B > To that end, the questions to the Working Group are: > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > 1) Is the current text acceptable? > =E2=80=8BEither =E2=80=9Ccannot=E2=80=9D or =E2=80=9CMUST NOT=E2=80=9D is p= erfectly acceptable, and I think arguing over this choice is not a productive use of our time. =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > 3) None of the above are acceptable, If what specific text would be? > > > > Thank you, > > - -- > - - m&m > > Matt Miller > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJUff51AAoJEDWi+S0W7cO1Zb4H/RD01n6gdunhtU4m8t60vU62 > TuY93PJ0XgXWHu0UkE8Kc3+VTDsg2GxegKloLsXqNzbPt3OMa3DivBhTPADI88AK > y1hMELlOOPk6Ie8GNMaDx52DIkiolApIZdDrPGUZTG95SvmqIc6sCr4BH7EDZptW > 7to74d+rhKGK689lM9p8XZ6m5t9B9m4gKcyrIWv6UqnRGU2b1onFKf4izD/EJpah > bXaac6qB79pDzsqFTLCALdMrtoYJtmoS1dP8V7a7FDaRoWkRF7iLHLTKN6ZKmuXN > tXzU8uFela6OsImfl0X7E5PLzy+6c0DGO1EhOeGzmI9pYnL8XbLACwdTI8aXU98=3D > =3DGJUY > -----END PGP SIGNATURE----- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11336fa0bb314d050949dad7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Tue, Dec 2, 2014 at 10:01 AM, =E2=8C=98 Matt Miller <<= a href=3D"mailto:mamille2@cisco.com" target=3D"_blank">mamille2@cisco.com> wrote:
=E2=80=8B=E2=80=8B
To that end, th= e questions to the Working Group are:
=E2= =80=8B=E2=80=8B

=E2= =80=8B=E2=80=8B
1) Is the current text acceptable?

=E2= =80=8BEither =E2=80=9Ccannot=E2=80=9D or =E2=80=9CMUST NOT=E2=80=9D is perf= ectly acceptable, and I think arguing over this choice is not a productive = use of our time.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80= =8B


=E2=80=8B=E2=80=8B
=C2=A0


3) None of the above are acceptable, If what specific text would be?



Thank you,

- --
- - m&m

Matt Miller
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org

iQEcBAEBCgAGBQJUff51AAoJEDWi+S0W7cO1Zb4H/RD01n6gdunhtU4m8t60vU62
TuY93PJ0XgXWHu0UkE8Kc3+VTDsg2GxegKloLsXqNzbPt3OMa3DivBhTPADI88AK
y1hMELlOOPk6Ie8GNMaDx52DIkiolApIZdDrPGUZTG95SvmqIc6sCr4BH7EDZptW
7to74d+rhKGK689lM9p8XZ6m5t9B9m4gKcyrIWv6UqnRGU2b1onFKf4izD/EJpah
bXaac6qB79pDzsqFTLCALdMrtoYJtmoS1dP8V7a7FDaRoWkRF7iLHLTKN6ZKmuXN
tXzU8uFela6OsImfl0X7E5PLzy+6c0DGO1EhOeGzmI9pYnL8XbLACwdTI8aXU98=3D
=3DGJUY
-----END PGP SIGNATURE-----

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



--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--001a11336fa0bb314d050949dad7-- From nobody Tue Dec 2 22:22:57 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418981A00B5 for ; Tue, 2 Dec 2014 22:22:55 -0800 (PST) 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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MNGsd5yMe7M for ; Tue, 2 Dec 2014 22:22:53 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112C11A00AE for ; Tue, 2 Dec 2014 22:22:53 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id p9so11958648lbv.35 for ; Tue, 02 Dec 2014 22:22:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+WatKk08ITrbYAVgQ+0K5HjK8cCVsioRrkWt7/GOg+E=; b=BkLdW28ANnvUbWDpQ4m8pJLEtRBw7Sa+ytxAMFvIjyzK0dH4Ri+F+aQrZoHGZkbiU6 x6bNGZq2AMO0SCCrmW7yOZSzreQHqiW4lcvLUPVs2Fn2bQccrm2TApXdyrZzH/Y5lneU YE4TOx5Ho2UkMxEsIlPa6GKL0TdCA1p8/yPKgtTaOUjpGtUu6OR0JnpiPyXiaWvfp4PX oMRgYX7zwa6a1CXR58i85i9SAZtl9pvMJW3b1trA2S2Hbq+/v3uCEx6BzXQeCdZMAYkl P3ViIqah6LjzYMipHY1kN7Eblnaxnav9BkFYwGoHi9gUSnoLg2QlYnnzopgGQ8XmefI9 iGCg== X-Gm-Message-State: ALoCoQlM85gXYT+jLkuIo7sXIFO+M9Le/4Oh9HANMyi3NtT6pCK001To5MMDxEVlD5cPZSnXGjRZ X-Received: by 10.112.201.226 with SMTP id kd2mr2672464lbc.98.1417587771611; Tue, 02 Dec 2014 22:22:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.2.143 with HTTP; Tue, 2 Dec 2014 22:22:31 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <547DFE31.6030507@cisco.com> References: <547DFE31.6030507@cisco.com> From: Tim Bray Date: Tue, 2 Dec 2014 22:22:31 -0800 Message-ID: To: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= Content-Type: multipart/alternative; boundary=001a11c37eb490b17c050949dfd2 Archived-At: http://mailarchive.ietf.org/arch/msg/json/jhw-Qb0K1BmswT23T30jvmBchGM Cc: IETF JSON WG Subject: Re: [Json] I-JSON Outstanding AD Issues: Software Behavior X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 06:22:55 -0000 --001a11c37eb490b17c050949dfd2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99t know how this slipped through the cracks. I can live with = either but I think the proposed change is a substantial improvement and we should adopt it. On Tue, Dec 2, 2014 at 10:00 AM, =E2=8C=98 Matt Miller = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello all, > > In evaluating draft-ietf-json-i-json-03, our AD raised a number of > concerns. While most have been addressed in -04, some of the issues > regarding numbers where left unclear. One issue is the phrase "MUST > NOT trust nor act on" in section 3. Software Behavior; our AD believes > placing this constraint onto consumers is too onerous. > > The text in question is: > > When software reads data which it expects to be an I-JSON message, > but the data violates one of the MUST constraints in the previous > section (for example, contains an object with a duplicate key, or a > UTF-8 encoding error), that software MUST NOT trust nor act on the > content of the message. > > The suggested change is: > > A major advantage of using I-JSON is that receivers can avoid > ambiguous semantics in the JSON messages it receives. This allows > receivers to reject or otherwise disregard messages which do not > conform to the requirements in this document for I-JSON messages. > Protocols that use I-JSON message can be written so that receiving > implementation are required to reject (or, as in the case of security > protocols, not trust) messages that do not satisfy the constraints of > I-JSON. > > > This concern (and its suggested change) garnered no discussion whatsoever= . > > The questions to the Working Group is: > > > 1) Is this suggested change acceptable, and the current text *NOT* > acceptable? > > > 2) Is the current text acceptable, and the suggested change *NOT* > acceptable? > > > 3) Is either text equally acceptable? > > > 4) If neither sets of text are acceptable, what specific text would be? > > > > Thank you, > > - -- > - - m&m > > Matt Miller > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJUff4wAAoJEDWi+S0W7cO18ToIAK8p5yOhp/3DvwP3zCli6LqG > 5x4YCxyUMxg0xsfdEt8mk3WGST6gXgVivPlFO/bqjoKJtyMcBz0OcaM/n5JBB0lx > OMF+x/OSmxt1kv0q5tsBca3pAZuNvJ+BIDJ/ezqKxlJyLoxIq/6aeolaAOqCGjbK > d2Vgi9q3aSNbZrMdgvJ6OKJHs3cl5wQ6KN5z8gOHG+bPvuxGzTpkIAZa2VX1jtKw > RHyH8FKnnaumU49pIUbiIY0e8+MwIt+23HBV6mtEHZ1AvmZPt30Zay0fJeOsHUfA > 41wxrtwm8eiseQmbHHnOsEeOOFQSNdNGjeIZnZDYk0nCiEnkf9kbGRdvSrSy7QI=3D > =3D/DcS > -----END PGP SIGNATURE----- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c37eb490b17c050949dfd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I d= on=E2=80=99t know how this slipped through the cracks.=C2=A0 I can live wit= h either but I think the proposed change is a substantial improvement and w= e should adopt it. =C2=A0

On Tue, Dec 2, 2014 at 10:00 AM, =E2=8C=98 Matt Miller = <mamille2@cisco.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello all,

In evaluating draft-ietf-json-i-json-03, our AD raised a number of
concerns.=C2=A0 While most have been addressed in -04, some of the issues regarding numbers where left unclear.=C2=A0 One issue is the phrase "M= UST
NOT trust nor act on" in section 3. Software Behavior; our AD believes=
placing this constraint onto consumers is too onerous.

The text in question is:

=C2=A0 =C2=A0When software reads data which it expects to be an I-JSON mess= age,
=C2=A0 =C2=A0but the data violates one of the MUST constraints in the previ= ous
=C2=A0 =C2=A0section (for example, contains an object with a duplicate key,= or a
=C2=A0 =C2=A0UTF-8 encoding error), that software MUST NOT trust nor act on= the
=C2=A0 =C2=A0content of the message.

The suggested change is:

=C2=A0 =C2=A0A major advantage of using I-JSON is that receivers can avoid<= br> =C2=A0 =C2=A0ambiguous semantics in the JSON messages it receives. This all= ows
=C2=A0 =C2=A0receivers to reject or otherwise disregard messages which do n= ot
=C2=A0 =C2=A0conform to the requirements in this document for I-JSON messag= es.
=C2=A0 =C2=A0Protocols that use I-JSON message can be written so that recei= ving
=C2=A0 =C2=A0implementation are required to reject (or, as in the case of s= ecurity
=C2=A0 =C2=A0protocols, not trust) messages that do not satisfy the constra= ints of
=C2=A0 =C2=A0I-JSON.


This concern (and its suggested change) garnered no discussion whatsoever.<= br>
The questions to the Working Group is:


1) Is this suggested change acceptable, and the current text *NOT*
acceptable?


2) Is the current text acceptable, and the suggested change *NOT*
acceptable?


3) Is either text equally acceptable?


4) If neither sets of text are acceptable, what specific text would be?



Thank you,

- --
- - m&m

Matt Miller
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org

iQEcBAEBCgAGBQJUff4wAAoJEDWi+S0W7cO18ToIAK8p5yOhp/3DvwP3zCli6LqG
5x4YCxyUMxg0xsfdEt8mk3WGST6gXgVivPlFO/bqjoKJtyMcBz0OcaM/n5JBB0lx
OMF+x/OSmxt1kv0q5tsBca3pAZuNvJ+BIDJ/ezqKxlJyLoxIq/6aeolaAOqCGjbK
d2Vgi9q3aSNbZrMdgvJ6OKJHs3cl5wQ6KN5z8gOHG+bPvuxGzTpkIAZa2VX1jtKw
RHyH8FKnnaumU49pIUbiIY0e8+MwIt+23HBV6mtEHZ1AvmZPt30Zay0fJeOsHUfA
41wxrtwm8eiseQmbHHnOsEeOOFQSNdNGjeIZnZDYk0nCiEnkf9kbGRdvSrSy7QI=3D
=3D/DcS
-----END PGP SIGNATURE-----

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



--
- Tim Bray (If you=E2=80=99d lik= e to send me a private message, see https://keybase.io/timbray)
--001a11c37eb490b17c050949dfd2-- From nobody Tue Dec 2 22:26:38 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F751A00BE for ; Tue, 2 Dec 2014 22:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ourhhwY7nHQn for ; Tue, 2 Dec 2014 22:26:35 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF121A00B6 for ; Tue, 2 Dec 2014 22:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sB36QUCo002862; Wed, 3 Dec 2014 07:26:30 +0100 (CET) Received: from [192.168.217.149] (p54890BB5.dip0.t-ipconnect.de [84.137.11.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3jsqvT6xYrz4p68; Wed, 3 Dec 2014 07:26:29 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Carsten Bormann In-Reply-To: Date: Wed, 3 Dec 2014 07:26:28 +0100 X-Mao-Original-Outgoing-Id: 439280788.441262-c8fa28332611e59afcc82efe494428bc Content-Transfer-Encoding: quoted-printable Message-Id: <0F050F48-C1E7-4C3B-8785-645CF93002FF@tzi.org> References: To: Andrew Newton X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/g6mWMw6Z8-rsyc2IbQjMCZ6rYf4 Cc: JSON WG Subject: Re: [Json] JCR -04 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 06:26:36 -0000 Thanks for getting rid of the alternative syntax, and for reinstating = the ABNF. I=E2=80=99m not a big fan of the new name =E2=80=9Cpedantic=E2=80=9D. = You don=E2=80=99t have to be pedantic to want to close a specific = structure to future extension. Calling these structures =E2=80=9Cclosed=E2= =80=9D is probably closer (Java fans will want to call them =E2=80=9Cfinal= =E2=80=9D :-). (The text for language-compatible-members still uses the name = "ignore-unknown-members=E2=80=9D. I don=E2=80=99t like that concept too much, anyway=E2=80=A6 Too many = languages with different rules to choose from.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 2 23:00:23 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02BC1A00F5 for ; Tue, 2 Dec 2014 23:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKfdmnlBW04E for ; Tue, 2 Dec 2014 23:00:16 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id B45621A00E4 for ; Tue, 2 Dec 2014 23:00:16 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id EBE7032E55E; Wed, 3 Dec 2014 15:59:30 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 2d67_76e3_93bf779c_6434_4823_8ce1_6298f2509b9d; Wed, 03 Dec 2014 15:59:30 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 4CDEDC0008; Wed, 3 Dec 2014 15:59:30 +0900 (JST) Message-ID: <547EB4D0.8010901@it.aoyama.ac.jp> Date: Wed, 03 Dec 2014 15:59:28 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= , IETF JSON WG References: <547DFE31.6030507@cisco.com> In-Reply-To: <547DFE31.6030507@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/MCdrxwWmxpkGVVfVqnZ7-ekXnaE Subject: Re: [Json] I-JSON Outstanding AD Issues: Software Behavior X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 07:00:21 -0000 I agree with Tim: Go with the new text. Regards, Martin. On 2014/12/03 03:00, =E2=8C=98 Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello all, > > In evaluating draft-ietf-json-i-json-03, our AD raised a number of > concerns. While most have been addressed in -04, some of the issues > regarding numbers where left unclear. One issue is the phrase "MUST > NOT trust nor act on" in section 3. Software Behavior; our AD believes > placing this constraint onto consumers is too onerous. > > The text in question is: > > When software reads data which it expects to be an I-JSON message, > but the data violates one of the MUST constraints in the previous > section (for example, contains an object with a duplicate key, or a > UTF-8 encoding error), that software MUST NOT trust nor act on the > content of the message. > > The suggested change is: > > A major advantage of using I-JSON is that receivers can avoid > ambiguous semantics in the JSON messages it receives. This allows > receivers to reject or otherwise disregard messages which do not > conform to the requirements in this document for I-JSON messages. > Protocols that use I-JSON message can be written so that receiving > implementation are required to reject (or, as in the case of securi= ty > protocols, not trust) messages that do not satisfy the constraints = of > I-JSON. > > > This concern (and its suggested change) garnered no discussion whatsoev= er. > > The questions to the Working Group is: > > > 1) Is this suggested change acceptable, and the current text *NOT* > acceptable? > > > 2) Is the current text acceptable, and the suggested change *NOT* > acceptable? > > > 3) Is either text equally acceptable? > > > 4) If neither sets of text are acceptable, what specific text would be? > > > > Thank you, > > - -- > - - m&m > > Matt Miller > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJUff4wAAoJEDWi+S0W7cO18ToIAK8p5yOhp/3DvwP3zCli6LqG > 5x4YCxyUMxg0xsfdEt8mk3WGST6gXgVivPlFO/bqjoKJtyMcBz0OcaM/n5JBB0lx > OMF+x/OSmxt1kv0q5tsBca3pAZuNvJ+BIDJ/ezqKxlJyLoxIq/6aeolaAOqCGjbK > d2Vgi9q3aSNbZrMdgvJ6OKJHs3cl5wQ6KN5z8gOHG+bPvuxGzTpkIAZa2VX1jtKw > RHyH8FKnnaumU49pIUbiIY0e8+MwIt+23HBV6mtEHZ1AvmZPt30Zay0fJeOsHUfA > 41wxrtwm8eiseQmbHHnOsEeOOFQSNdNGjeIZnZDYk0nCiEnkf9kbGRdvSrSy7QI=3D > =3D/DcS > -----END PGP SIGNATURE----- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Wed Dec 3 00:45:38 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009991A016C for ; Wed, 3 Dec 2014 00:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwGBbdpluxiL for ; Wed, 3 Dec 2014 00:45:35 -0800 (PST) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844281A01D8 for ; Wed, 3 Dec 2014 00:45:35 -0800 (PST) Received: from 217-162-186-63.dynamic.hispeed.ch ([217.162.186.63] helo=dretair11.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Xw5Yz-0007k0-EN; Wed, 03 Dec 2014 00:45:35 -0800 Message-ID: <547ECDA9.2060702@berkeley.edu> Date: Wed, 03 Dec 2014 09:45:29 +0100 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andrew Newton , JSON WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/khG_m-sLHlKwT3mAYWrnqlSNlPQ Subject: Re: [Json] JCR -04 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 08:45:37 -0000 hello andrew. On 2014-12-02, 22:06, Andrew Newton wrote: > Based on the discussion that took place here, JCR has been updated to -04. > It includes syntax changes and a revised ABNF. > > Name:draft-newton-json-content-rules > Revision:04 > Title:A Language for Rules Describing JSON Content > Document date:2014-12-02 > Group:Individual Submission > Htmlized: http://tools.ietf.org/html/draft-newton-json-content-rules-04 some reference to JSON Schema probably would be helpful. as there is no formal spec (i guess), pointing to the URI http://json-schema.org/ might be the best thing that's possible. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From nobody Wed Dec 3 07:58:25 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0E31A1B38 for ; Wed, 3 Dec 2014 07:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIEHv29vlo8r for ; Wed, 3 Dec 2014 07:58:21 -0800 (PST) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AFD1A1B48 for ; Wed, 3 Dec 2014 07:58:14 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id ft15so15714432pdb.32 for ; Wed, 03 Dec 2014 07:58:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TMRRFPLE7+bGzV7nngz5ZbKQXTJXCV9WixHXkRHtlMY=; b=Lj10IROuZB1gvJ+SFj8rny73d+qqK8fU4lGd0kmTOD14QmLGq7RAnWqCDJ5u0XoN3E xmdNf9Smky19LEexh6b1CnHDKE2P60AzoVBh5aZwMQ1Gc5rIj5D1Q4H6brMqfDXKdfLj GystKAGb+O4IsVttm+c/iVe2nzQJKYb+z/2KepTXEUGrSzyuVknXOZj8bwLn+GY/rMfK oN3UtzVT2vbHwFJNu9/N7YlKm64/neCcF6j109YDuZ1FLOspL9Ncf7rTExaVLfr2pVJu WerjDZ4BhFGPmjKqesc8JqiDt1GnSYSi4iyOuxwGBE7L1BCwqS5c8RQPVr2DOTstILzT CzLA== X-Gm-Message-State: ALoCoQk9/BG/q3GubhkO4IMewYkTzRLxRiUCpQGz9uCDuJeCihws/Ru1cBR/i4imawbi9NlfXz1y MIME-Version: 1.0 X-Received: by 10.66.235.135 with SMTP id um7mr10020757pac.94.1417622294492; Wed, 03 Dec 2014 07:58:14 -0800 (PST) Received: by 10.66.135.164 with HTTP; Wed, 3 Dec 2014 07:58:14 -0800 (PST) X-Originating-IP: [2001:500:4:15:b10c:222c:c6a4:bfaa] In-Reply-To: <0F050F48-C1E7-4C3B-8785-645CF93002FF@tzi.org> References: <0F050F48-C1E7-4C3B-8785-645CF93002FF@tzi.org> Date: Wed, 3 Dec 2014 10:58:14 -0500 Message-ID: From: Andrew Newton To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a113811404a1128050951e928 Archived-At: http://mailarchive.ietf.org/arch/msg/json/ytqelNWOIuHD0ZSMGuZKS83K0Jo Cc: JSON WG Subject: Re: [Json] JCR -04 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 15:58:23 -0000 --001a113811404a1128050951e928 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 3, 2014 at 1:26 AM, Carsten Bormann wrote: > Thanks for getting rid of the alternative syntax, and for reinstating the > ABNF. > > I=E2=80=99m not a big fan of the new name =E2=80=9Cpedantic=E2=80=9D. Yo= u don=E2=80=99t have to be > pedantic to want to close a specific structure to future extension. > Calling these structures =E2=80=9Cclosed=E2=80=9D is probably closer (Jav= a fans will want > to call them =E2=80=9Cfinal=E2=80=9D :-). > > I don't have a strong opinion on the name. "closed-rules" is fine by me. > (The text for language-compatible-members still uses the name > "ignore-unknown-members=E2=80=9D. > I don=E2=80=99t like that concept too much, anyway=E2=80=A6 Too many lan= guages with > different rules to choose from.) > > Well, it will not be possible for every programming language under the sun, but it is possible to get the most widely used ones that have dynamic methods and variables. -andy --001a113811404a1128050951e928 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 3, 2014 at 1:26 AM, Carsten Bormann <<= a href=3D"mailto:cabo@tzi.org" target=3D"_blank">cabo@tzi.org> wrote:
Thanks for getting rid of the al= ternative syntax, and for reinstating the ABNF.

I=E2=80=99m not a big fan of the new name =E2=80=9Cpedantic=E2=80=9D.=C2=A0= You don=E2=80=99t have to be pedantic to want to close a specific structur= e to future extension.=C2=A0 Calling these structures =E2=80=9Cclosed=E2=80= =9D is probably closer (Java fans will want to call them =E2=80=9Cfinal=E2= =80=9D :-).


I don't have a strong opinion on t= he name. "closed-rules" is fine by me.
=C2=A0
(The text for language-compatible-members still uses the name "ignore-= unknown-members=E2=80=9D.
I don=E2=80=99t like that concept too much, anyway=E2=80=A6=C2=A0 Too many = languages with different rules to choose from.)


Well, it will not b= e possible for every programming language under the sun, but it is possible= to get the most widely used ones that have dynamic methods and variables.<= /div>

-andy<= /div>
--001a113811404a1128050951e928-- From nobody Wed Dec 3 07:59:09 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039C71A1B9B for ; Wed, 3 Dec 2014 07:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdbA_DWK82fP for ; Wed, 3 Dec 2014 07:59:02 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD57D1A1BAA for ; Wed, 3 Dec 2014 07:59:01 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id ey11so15878245pad.24 for ; Wed, 03 Dec 2014 07:59:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m7cLI+xl+7sS99PGKTlHzUSuSE1snMMX2r+z+Q9JDoc=; b=ARLl0A9wEqw1leb8eOr/RFg5QYpLl5YzSGbfYYzhSOoRegqarq4/Bdvziu8syM815M 2sBHCT+RWUuXOmyUQ8u5EZfvtK1jiWZE0nM7WLyhsN8xNrB+NDPjS3zkG1Laq3aP4J9I E7czVSQpzskWsUWgd6+LZa42eTFT/mz30eMaGz9ioNmJa0YnG9C5XqKgNfrywxIkXbiW X6yO5RcPtxxxu7XmWz/5pLLh3j147hjekEPCS8z4ZszV1AaTxiQP3RCShzbRLanEYEnu 5npvyopunxIyBet6Qvx+GvHzUte+JGBf1gvazAJxXTCDNYGc8gPB4ItZ/dafXOI0fCpP v82Q== X-Gm-Message-State: ALoCoQko6Mba3oHwi2NcGkkNQFl+wJDCRARlgr2aWzmLyqruBc5NAeoHL4trqWda6xLF3VfVSHbN MIME-Version: 1.0 X-Received: by 10.69.25.35 with SMTP id in3mr11968272pbd.63.1417622341554; Wed, 03 Dec 2014 07:59:01 -0800 (PST) Received: by 10.66.135.164 with HTTP; Wed, 3 Dec 2014 07:59:01 -0800 (PST) X-Originating-IP: [2001:500:4:15:b10c:222c:c6a4:bfaa] In-Reply-To: <547ECDA9.2060702@berkeley.edu> References: <547ECDA9.2060702@berkeley.edu> Date: Wed, 3 Dec 2014 10:59:01 -0500 Message-ID: From: Andrew Newton To: Erik Wilde Content-Type: multipart/alternative; boundary=001a1134b822182dd4050951ecc9 Archived-At: http://mailarchive.ietf.org/arch/msg/json/gC2NlKkryYNu4nA7gQTJNat4e4w Cc: JSON WG Subject: Re: [Json] JCR -04 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 15:59:04 -0000 --001a1134b822182dd4050951ecc9 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 3, 2014 at 3:45 AM, Erik Wilde wrote: > some reference to JSON Schema probably would be helpful. as there is no > formal spec (i guess), pointing to the URI http://json-schema.org/ might > be the best thing that's possible. > I can do that. -andy --001a1134b822182dd4050951ecc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Dec 3, 2014 at 3:45 AM, Erik Wilde <dret@berkeley.edu> wrote:
some reference to JSON Schema probably would be h= elpful. as there is no formal spec (i guess), pointing to the URI http://json-schema.org/ = might be the best thing that's possible.

I = can do that.

-andy
--001a1134b822182dd4050951ecc9-- From nobody Wed Dec 3 16:11:39 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D171ACF6E for ; Wed, 3 Dec 2014 16:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnFxUijuA-BV for ; Wed, 3 Dec 2014 16:10:54 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id A24E71ACF76 for ; Wed, 3 Dec 2014 16:10:47 -0800 (PST) X-IronPort-AV: E=Sophos; i="5.07,511,1413205200"; d="scan'208,217"; a="56368247" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 04 Dec 2014 10:49:40 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7641"; a="261075957" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipccvi.tcif.telstra.com.au with ESMTP; 04 Dec 2014 11:10:46 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Thu, 4 Dec 2014 11:10:45 +1100 From: "Manger, James" To: "json@ietf.org" Date: Thu, 4 Dec 2014 11:10:45 +1100 Thread-Topic: JCR comments Thread-Index: AdAPVr+CEd/jm+XcQl+njnt4O0/Blg== Message-ID: <255B9BB34FB7D647A506DC292726F6E127D4EF1E60@WSMSG3153V.srv.dir.telstra.com> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E127D4EF1E60WSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/NV528qeM9H1dEwbES7WVThy81bw Subject: [Json] JCR comments X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 00:10:58 -0000 --_000_255B9BB34FB7D647A506DC292726F6E127D4EF1E60WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JSON Content Rules (JCR) look pretty good. I have some comments on draft-ne= wton-json-content-rules-04: 1. It is not quite right to say rules describe a particular JSON value. Rul= es describe a range of possible values; any particular values matches (or n= ot) a given rule. Suggestion for section 1: Change "Figure 2 is an example of this language describing the JSON of Figu= re 1." To "As an example, the JSON in Figure 1 matches the rules written in this l= anguage in Figure 2." 2. Change "100" to 100 (change string to number) in Figure 3 and A.2. 3. Section 3.1.1. There is no such thing as "the minimum number value possi= ble to represent in JSON", nor any maximum (even if the 64-bit float range = is a common implementation limit). Change the last 2 sentences of 3.1.1 to = "If the minimum or maximum is not given then there is no limit in the corre= sponding direction." 4. Section 3.1.2: Change "prepending a URI template" to "appending a URI te= mplate". 5. Most of the string rules (ip4, ip6, fqdn, idn, date-time, full-date, fu= ll-time, email, phone, base64) should be provided as examples of rules that= are likely to be commonly useful, instead of making these specific syntaxe= s first-class citizens in the language. C.f. Some of the common ABNF rules = (ALPHA, DIGIT, HEXDIG). They can probably be defined using the string /rege= x/ construct. The spec could go on to say that these common rule names can be used withou= t needing an explicit # include line. 6. 'base64' is not precise enough. The "normal" base64 alphabet and the URL= -safe variant are both widely used, often omitting any "=3D" padding, somet= imes allowing whitespace. One common 'base64' rule name defined in this spe= c should probably allow all those possibilities, even though a particular p= rotocol that describes its messages with JCR may only allow a subset. 7. What sort of regex is expected? Probably need a reference. 8. The ABNF in section 5 hints that \/ and \\ are used to escape / and \ in= a regex. Should state that explicitly in section 3.1.2. 9. Update RFC4627 references to RFC7159 in lots of places. 10. Section 3.5 has the following example, but no "&" semantics are defined= . I think this functionality was dropped so drop the example as well. the_children { first_two_children & second_two_children } 11. Section 4.2 mentions "# ignore-unknown-members", but I suspect that has= been replaced by "# pedantic". 12. To write a rule requiring a specific JSON value you need to enclose the= value in < >, eg version "v" <1>. It would be a bit nicer if you could use= JSON values directly (at least for primitives values), ie omit the < > bra= ckets. 13. In the last paragraph of 3.4: Change "The following example defines an array with an infinite number of c= hild_value defined strings". To "The following example defines an array that can have any number of chil= d_value items". 14. 'uri' can be followed by a template, not just a URI. In the section 5 A= BNF: Change "uri-type =3D "uri" [ URI ] ; URI defined in RFC 3986". To "uri-type =3D "uri" [ URI-Template ] ; URI-Template defined i= n RFC 6570". 15. I would be tempted to use 'true / false', instead of 'boolean'. Though = I think the current syntax only allows '' as an alternative. 16. Why are "1" and "0" explicitly listed in the enum-items ABNF? Drop them= . Drop "integer" as well from enum-items as it is a subset of "float" that = is already included. 17. '/' would be a more intuitive separator of enum items than whitespace. = '/' is used to separate alternative types in JCR and in ABNF. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E127D4EF1E60WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JSON Content Rul= es (JCR) look pretty good. I have some comments on draft-newton-json-conten= t-rules-04:

 

1. It is not quite right to say rules describe a particular J= SON value. Rules describe a range of possible values; any particular values= matches (or not) a given rule.

Suggesti= on for section 1:

Change “Figure 2= is an example of this language describing the JSON of Figure 1.”

To “As an example, the JSON in Figure= 1 matches the rules written in this language in Figure 2.”

 

2. Chan= ge "100" to 100 (change string to number) in Figure 3 and A.2.

 

= 3. Section 3.1.1. There is no such thing as “the minimum number value= possible to represent in JSON”, nor any maximum (even if the 64-bit = float range is a common implementation limit). Change the last 2 sentences = of 3.1.1 to “If the minimum or maximum is not given then there is no = limit in the corresponding direction.”

 

4. Section 3.1.2: Change = 220;prepending a URI template” to “appending a URI templateR= 21;.

 

5. Most of the string rules  (ip4, ip6, fqdn, idn, date-time, f= ull-date, full-time, email, phone, base64) should be provided as examples o= f rules that are likely to be commonly useful, instead of making these spec= ific syntaxes first-class citizens in the language. C.f. Some of the common= ABNF rules (ALPHA, DIGIT, HEXDIG). They can probably be defined using the = string /regex/ construct.

The spec could= go on to say that these common rule names can be used without needing an e= xplicit # include line.

 

6. ‘base64’ is not precise enough. Th= e “normal” base64 alphabet and the URL-safe variant are both wi= dely used, often omitting any “=3D” padding, sometimes allowing= whitespace. One common ‘base64’ rule name defined in this spec= should probably allow all those possibilities, even though a particular pr= otocol that describes its messages with JCR may only allow a subset.

 

7. W= hat sort of regex is expected? Probably need a reference.

 

8. The ABNF in = section 5 hints that \/ and \\ are used to escape / and \ in a regex. Shoul= d state that explicitly in section 3.1.2.

 

9. Update RFC4627 references to= RFC7159 in lots of places.

 <= /o:p>

10. Section 3.5 has the following example, bu= t no “&” semantics are defined. I think this functionality = was dropped so drop the example as well.

  the_children { first_two_children & second_two_children }<= /o:p>

 

11.= Section 4.2 mentions “# ignore-unknown-members”, but I suspect= that has been replaced by “# pedantic”.

 

12. To write a rule = requiring a specific JSON value you need to enclose the value in < >,= eg version "v" <1>. It would be a bit nicer if you could u= se JSON values directly (at least for primitives values), ie omit the < = > brackets.

 

13. In the last paragraph of 3.4:

Change “The following example defines an array with an i= nfinite number of child_value defined strings”.

To “The following example defines an array that can hav= e any number of child_value items”.

 

14. ‘uri’ can be fo= llowed by a template, not just a URI. In the section 5 ABNF:

=

Change “uri-type     &n= bsp;  =3D "uri"     [ URI ] ; URI define= d in RFC 3986”.

To “uri-type=         =3D "uri"  &= nbsp;  [ URI-Template ] ; URI-Template defined in RFC 6570”.

 

1= 5. I would be tempted to use ‘true / false’, instead of ‘= boolean’. Though I think the current syntax only allows ‘<tr= ue false>’ as an alternative.

<= o:p> 

16. Why are “1” and &#= 8220;0” explicitly listed in the enum-items ABNF? Drop them. Drop = 220;integer” as well from enum-items as it is a subset of “floa= t” that is already included.

=  

17. ‘/’ would be a more in= tuitive separator of enum items than whitespace. ‘/’ is used to= separate alternative types in JCR and in ABNF.

 

--

James Manger

 

= --_000_255B9BB34FB7D647A506DC292726F6E127D4EF1E60WSMSG3153Vsrv_-- From nobody Thu Dec 4 12:38:56 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5251B1A1A3A for ; Thu, 4 Dec 2014 12:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCEbvtKTWnLy for ; Thu, 4 Dec 2014 12:38:48 -0800 (PST) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB2F1A1BE0 for ; Thu, 4 Dec 2014 12:38:46 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id ft15so18076082pdb.8 for ; Thu, 04 Dec 2014 12:38:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Vn/PrBsLg2r83pHpQ/Ntq8B+ojFIVMjWIFc5rhLGr+I=; b=Sgr/q8meY/pSv7SwrmqI8ZWZpPTLbPRstOqR9vmnhOgvfJlh/Ap7l3YMUxYfSx4SFR bkBf3b1wBVBFkn8KRBwK2OJ9Ly4uix8yqO3PeSi2+xwkMy2D+RAQAcgAztVyK6XT5sio BDvW+Ar8GBEDf+tzn7ZxQXzsze4HAQrclMlQXVtKYHiFSZeN9/ekEnpvAHUkArODSwcF fdz46N//8wT6PcmdTazf2xI743O38sQJkVgb7Y2X59FZ9X3oLGuXTYlSvqTbyCAjfR9A oyeFcyTpPMLHFqsWb6AjxLefPEH4vDAA/RDf2z213X8NUzSSHJiYiKR/hFE1/Q35Y7ky PWJQ== X-Gm-Message-State: ALoCoQlqIGwPGh2kK0EcCBTAzAA36r1xSz+p4ZPgLqwl3rFBbOtPQqrPKXbp/w765cGCIUwFzhqL MIME-Version: 1.0 X-Received: by 10.68.220.137 with SMTP id pw9mr19038689pbc.146.1417725526525; Thu, 04 Dec 2014 12:38:46 -0800 (PST) Received: by 10.66.135.164 with HTTP; Thu, 4 Dec 2014 12:38:46 -0800 (PST) X-Originating-IP: [2001:500:4:15:a0b6:a642:cc93:b368] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127D4EF1E60@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E127D4EF1E60@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 4 Dec 2014 15:38:46 -0500 Message-ID: From: Andrew Newton To: "Manger, James" Content-Type: multipart/alternative; boundary=047d7b2edecb65e325050969f234 Archived-At: http://mailarchive.ietf.org/arch/msg/json/jfuWDXOC_C7LTWDZoyAlJ7wkQ7w Cc: "json@ietf.org" Subject: Re: [Json] JCR comments X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 20:38:50 -0000 --047d7b2edecb65e325050969f234 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James, Great review. My comments are in-line: On Wed, Dec 3, 2014 at 7:10 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > > > > 5. Most of the string rules (ip4, ip6, fqdn, idn, date-time, full-date, > full-time, email, phone, base64) should be provided as examples of rules > that are likely to be commonly useful, instead of making these specific > syntaxes first-class citizens in the language. C.f. Some of the common AB= NF > rules (ALPHA, DIGIT, HEXDIG). They can probably be defined using the stri= ng > /regex/ construct. > > The spec could go on to say that these common rule names can be used > without needing an explicit # include line. > I had a phone call with Gearing Luff of the JSON Schema project, and type extensibility was one of the discussion topics. I want to look at how they are doing it and determine if there is a compatible way of referencing types. And the reason for doing so is that JCR might make a good "front-end" for JSON Schema. Or in other words, a compact syntax compatible with JSON Schema. > 12. To write a rule requiring a specific JSON value you need to enclose > the value in < >, eg version "v" <1>. It would be a bit nicer if you coul= d > use JSON values directly (at least for primitives values), ie omit the < = > > brackets. > > Interesting. Along with item 17, it might be possible to drop the < > altogether. Let me play with that. > 15. I would be tempted to use =E2=80=98true / false=E2=80=99, instead of = =E2=80=98boolean=E2=80=99. Though > I think the current syntax only allows =E2=80=98=E2=80=99 as = an alternative. > > > > 16. Why are =E2=80=9C1=E2=80=9D and =E2=80=9C0=E2=80=9D explicitly listed= in the enum-items ABNF? Drop > them. Drop =E2=80=9Cinteger=E2=80=9D as well from enum-items as it is a s= ubset of =E2=80=9Cfloat=E2=80=9D > that is already included. > > > > 17. =E2=80=98/=E2=80=99 would be a more intuitive separator of enum items= than whitespace. > =E2=80=98/=E2=80=99 is used to separate alternative types in JCR and in A= BNF. > Great idea. I'll look into this. It certainly simplifies the syntax for enums. -andy --047d7b2edecb65e325050969f234 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi James,

Great review. My comments are in-line:

On Wed, Dec 3, 2014 at 7:10= PM, Manger, James <James.H.Manger@team.telstra.com><= /span> wrote:


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=C2=A0

5. Most of the string rules =C2=A0(ip4, ip6, fqdn, idn, date-time, full-da= te, full-time, email, phone, base64) should be provided as examples of rule= s that are likely to be commonly useful, instead of making these specific s= yntaxes first-class citizens in the language. C.f. Some of the common ABNF = rules (ALPHA, DIGIT, HEXDIG). They can probably be defined using the string= /regex/ construct.

The spec could = go on to say that these common rule names can be used without needing an ex= plicit # include line.


I had a ph= one call with Gearing Luff of the JSON Schema project, and type extensibili= ty was one of the discussion topics. I want to look at how they are doing i= t and determine if there is a compatible way of referencing types.

And the reason for doing so is that JCR might make a good = "front-end" for JSON Schema. Or in other words, a compact syntax = compatible with JSON Schema.
=C2=A0

12. To write a rule requiring a specific JSON value you need to enclo= se the value in < >, eg version "v" <1>. It would be = a bit nicer if you could use JSON values directly (at least for primitives = values), ie omit the < > brackets.

Interesting. Along with item 17, it might be possible to drop t= he < > altogether. Let me play with that.
=C2=A0

15. I would be tempted to use =E2=80=98true / fals= e=E2=80=99, instead of =E2=80=98boolean=E2=80=99. Though I think the curren= t syntax only allows =E2=80=98<true false>=E2=80=99 as an alternative= .

=C2=A0=

16. Why are =E2=80=9C1=E2=80=9D and =E2= =80=9C0=E2=80=9D explicitly listed in the enum-items ABNF? Drop them. Drop = =E2=80=9Cinteger=E2=80=9D as well from enum-items as it is a subset of =E2= =80=9Cfloat=E2=80=9D that is already included.

=C2=A0

17. =E2=80=98/= =E2=80=99 would be a more intuitive separator of enum items than whitespace= . =E2=80=98/=E2=80=99 is used to separate alternative types in JCR and in A= BNF.


Great idea. I'll look in= to this. It certainly simplifies the syntax for enums.

=
-andy=C2=A0
--047d7b2edecb65e325050969f234-- From nobody Fri Dec 5 00:10:58 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B776F1AC44D; Fri, 5 Dec 2014 00:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyW2HAtd8OYS; Fri, 5 Dec 2014 00:10:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D9A1ACD90; Fri, 5 Dec 2014 00:10:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205081038.23692.7613.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 00:10:38 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/BKWUFesnRpP3nssZ4N4BsiWYUcU Cc: iesg-secretary@ietf.org Subject: [Json] Last Call Expired: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 08:10:55 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Fri Dec 5 07:08:32 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3401A8955; Fri, 5 Dec 2014 06:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USK0svTp-G2O; Fri, 5 Dec 2014 06:51:28 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6A51A1A82; Fri, 5 Dec 2014 06:51:27 -0800 (PST) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB5EpMpv013195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 09:51:24 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sB5EpMpv013195 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1417791085; bh=QtOiH3zxcmCAaHQpGuBC2bdnMCE=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=co7ncblM4tBYnvoIjV/1wsymr2xl5I0GdPdqEKuyF5FSZNd647ISA4D0MqK7zF/Q0 svvJeA64iPU8zPQ1EtAxNEl6flw58LuJkz9qYAO929ixne4rUmnEDdoP7ZbggEefrg g9qFBaab217JtbIeZdxzuOOpyEYQeHlUBaMQ1rS0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sB5EpMpv013195 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Fri, 5 Dec 2014 09:50:41 -0500 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB5Ep5WI008457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 09:51:05 -0500 Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub12.corp.emc.com (10.254.92.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 5 Dec 2014 09:51:05 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.125]) by MXHUB206.corp.emc.com ([fe80::843c:2a27:6ea:5f63%12]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 09:51:05 -0500 From: "Black, David" To: "nico@cryptonector.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 Thread-Index: AdAQmuBgzIEwbXsVSl+UfPcrbL3cqw== Date: Fri, 5 Dec 2014 14:51:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.72] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: GIS Solicitation, DLM_1, public, Resumes Archived-At: http://mailarchive.ietf.org/arch/msg/json/tJjQYddzybN8152jnmrVymewx50 X-Mailman-Approved-At: Fri, 05 Dec 2014 07:08:30 -0800 Cc: "Black, David" , "ietf@ietf.org" , "json@ietf.org" Subject: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 14:51:31 -0000 This is a combined Gen-ART and OPS-Dir review. Boilerplate for both follow= s ... I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at: . Please resolve these comments along with any other Last Call comments you may receive. I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any ot= her last call comments. Document: draft-ietf-json-text-sequence-09 Reviewer: David Black Review Date: Dec 5, 2014 IETF LC End Date: Dec 5, 2014 IESG Telechat date: Dec 18, 2014 Summary: This draft is on the right track, but has open issues described in the review. This draft specifies a format that packs multiple JSON texts into a single string. The ASCII RS (0x1E) character is used to separate texts, and a linefeed is appended to each text to ensure that a complete text always ends with a whitespace character. All of the open issues are minor - the most important ones center on treatment of incomplete JSON texts - that appears to be an afterthought in this draft and needs more attention. I also found a couple of minor issues in the Security and IANA Considerations sections, both of which are almost nits. Major issues: None. Minor issues: [A] Section 2.1: If parsing of such an octet string as a JSON text fails, the parser SHOULD nonetheless continue parsing the remainder of the sequence. That's not quite right - there are two levels of parsing, JSON sequence parsing and JSON text parsing of each text in the sequence, both of which might be implemented in a single-pass parser. For such an implementation, the above sentence could be (mis-)read to imply that the JSON text parse should resume from the point at which it failed, which would be silly (although I've seen heroic PL/1 parsers do exactly that). Instead, the parse needs to skip ahead to the next RS, ignoring the rest of the JSON text that failed to parse. I suggest: If parsing of such an octet string as a JSON text fails, and the octet string is followed by an RS octet, the parser SHOULD nonetheless skip ahead to that RS octet and continue parsing the remainder of the sequence from there. That also covers the case where there is nothing more to parse after the JSON text that caused the parse failure. [B] Section 2.3: Is incremental parsing of a JSON text within a sequence allowed, or is the parser required to not produce any results until the parse of the entire text is successful? I'd expect that incremental parsing is ok (so results may be produced from a text that ultimately fails to parse), and I think that's worth stating. [C] Section 2.4: Parsers MUST check that any JSON texts that are a top-level number include JSON whitespace ("ws" ABNF rule from [RFC7159]) after the number, otherwise the JSON-text may have been truncated. That reference to the "ws" rule doesn't get the job done because that rule allows a match to no characters - it's of the form ws =3D *( ... ) where ... is the list of whitespace characters. What's needed here is a rule of the form vws =3D 1*( ...) to force there to be at least one whitespace character, but see the next issue for a better way to deal with this topic by pulling the appended LF into the sequence parse instead of the text parse. [D] I wonder whether the possibility of incomplete texts ought to be encoded into the parsing rules to directly catch JSON texts that must be incomplete because the last character is not LF, e.g.: JSON-sequence =3D *(1*RS (possible-JSON / truncated-JSON / empty-JSON)= ) RS =3D %x1E; "record separator" (RS), see RFC20 possible-JSON =3D 1*(not-RS) LF ; attempt to parse as UTF-8-encoded ; JSON text (see RFC7159) truncated-JSON =3D *(not-RS) not-LFRS); truncated, don't attempt ; to parse as JSON text empty-JSON =3D LF ; only the LF appended by the encoder, nothing to pa= rse not-RS =3D %x00-1D / %x1F-FF; any octet other than RS not-LFRS =3D %x00-09/ %x1B-1D / %x1F-FF; any octet other than RS or LF Note that this won't detect all incomplete JSON texts, because LF is allowe= d within a JSON text (and this should be stated). [E] Section 3 - Security Considerations Incomplete and malformed JSON texts can be used to attack JSON parsers - that should be pointed out, as I don't see that in RFC 7159's security considerations and incomplete texts are a relevant consideration for this draft. [F] Section 4 - IANA Considerations Security considerations: See , Section 3. Interoperability considerations: Described herein. Published specification: . Applications that use this media type: is likely to support this format>. Replace all three instances of the angle bracketed text. The first two instances should be RFC references (e.g., RFC XXXX) w/a note to the RFC Editor to insert the number of the RFC when published. The third instance should be resolved now, or could have an RFC Editor note added indicating that the author will resolve that during Authors 48 hours. Nits/editorial comments: idnits didn't like the reference to RFC 20 for ASCII: ** Downref: Normative reference to an Unknown state RFC: RFC 20 RFC 5234 (ABNF) uses this, which looks like a better reference: [US-ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- Most of these questions are n/a because this draft describes a format that will be used in other protocols to which RFC 5706's concerns would app= ly. A.1.4 Have the Requirements on other protocols and functional components been discussed? The specification of the interaction of the JSON sequence parser with the JSON text parser is not as clear as it should be for incomplete or malforme= d JSON texts. See Minor Issues [A]-[E] above. A.1.8 Are there fault or threshold conditions that should be reported? Yes, incomplete JSON texts - this is covered in sections 2.3 and 2.4.=20 Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Fri Dec 5 13:03:00 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED07C1A1ADC for ; Fri, 5 Dec 2014 13:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nl7tLTtpTQfq for ; Fri, 5 Dec 2014 13:02:57 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638131ACDC6 for ; Fri, 5 Dec 2014 13:02:53 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id u10so1218754lbd.17 for ; Fri, 05 Dec 2014 13:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=qQ8dpbClOgB/WzvqOvMNK4ED39150zVvUG02ff1d6qM=; b=dF+D6ZtWfWNLAU5pJmep2NWUfTDlRJddJMfN31c087ZI5iDOOXIFkRYfL7OW0N8vF6 gjU6MvkjkPwBDbsaDLwsAygDN+H91Qa7NsrYUjIjS82ijOlpZrk0NPQGLf0LNNxAg7IF TbNscNpDWx0BekK3sZhcm26rX8BeHYYbq6OzaUNqGJjYwE/OxYNWW2NwRwnHGih7Q2dq XuDMem2NHxpZEYHzZ14qV+qHt91SGIdGkDCuDzXgOdQ6WmlcDCNrZVJt0YKq3ObUiUKg gRRJsA3JO9PoidNPB5+aVTrmJezTo9uHwFLSSG3InOu6XipmzwB0aPA8Wg3dLBGNUXjx EN3g== MIME-Version: 1.0 X-Received: by 10.112.170.36 with SMTP id aj4mr4748328lbc.3.1417813371920; Fri, 05 Dec 2014 13:02:51 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.168 with HTTP; Fri, 5 Dec 2014 13:02:51 -0800 (PST) Date: Fri, 5 Dec 2014 16:02:51 -0500 X-Google-Sender-Auth: d5eLXK_mjd2o727dN51WgZ-SypA Message-ID: From: Barry Leiba To: draft-ietf-json-text-sequence.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/json/FVEghwQ_QSttPHC27WcKPUF7KcY Cc: "json@ietf.org" Subject: [Json] Media type registration in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 21:02:58 -0000 While I wait for Pete to finish things up with this document and get it into IESG Evaluation, and while there's still time before the telechat date: The media type registration in the document, bog-standard though it might be, does not have a complete registration template: it's missing everything after "applications that use this media type", including contact information, author, and change controller. Perhaps IANA will assume that the other missing information is meant to be blank, but those are necessary; and anyway, the template should be complete. Also, RFC 6838 strongly recommends review of all registration requests on the list, and that wasn't done for this. Given that IETF-stream registrations do not get formal expert review, I very strongly prefer that that recommendation be heeded. Please use this time to post this document's name and the (complete) registration template to that list and see if there are any comments. Barry From nobody Fri Dec 5 14:39:07 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67ED1A6F99; Fri, 5 Dec 2014 14:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CsT0TwVdu3O; Fri, 5 Dec 2014 14:38:56 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DB21A1EF6; Fri, 5 Dec 2014 14:38:55 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id h15so60844igd.14 for ; Fri, 05 Dec 2014 14:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8QFAlZzL/C/3jl5vq+PeS0aV5LP75YlaNvL78wknyFU=; b=0xEfcWoR8K98kmFo5V54rQCQw7AOnl/pEGLSjnWMtio1l7cFKQUvKY2+XAh02rJSyR yKkcIImQ6ZXMDJSHiMIS/mcO5NY3ezypOXdY8znw+cmF/R3ccpcegqHd4qo9ao4tqnGc DiW1r8+9x7MukT4mKxPFyA8zhnfiH7EH65nF+2lKaQuZfzK+Qo/8/TwB8DKChfWk7Z1H VGPhnOV+rS2pAQs3Kw7gMezZBuv2vcfua6b09mJyfjasO55NVEwJmAsQQzcaiRyfCDjT hWpZUsGkTznkjnfMcjp5CbukpE0WyvdptRL6c8ym+RCAbadNVaTPX3tcSL5IdKcElWv4 JFew== MIME-Version: 1.0 X-Received: by 10.42.206.4 with SMTP id fs4mr17593728icb.90.1417819134821; Fri, 05 Dec 2014 14:38:54 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.173.83 with HTTP; Fri, 5 Dec 2014 14:38:54 -0800 (PST) In-Reply-To: References: Date: Fri, 5 Dec 2014 17:38:54 -0500 X-Google-Sender-Auth: JGyiYebMi3vwa75QgBoDENYjXfg Message-ID: From: Barry Leiba To: "Black, David" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/pBJiDodE2Ybrc8_6Po-JS2iQkJk Cc: "nico@cryptonector.com" , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "ops-dir@ietf.org" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 22:38:57 -0000 Hi, David. One note on your review: > idnits didn't like the reference to RFC 20 for ASCII: > > ** Downref: Normative reference to an Unknown state RFC: RFC 20 > > RFC 5234 (ABNF) uses this, which looks like a better reference: > > [US-ASCII] American National Standards Institute, "Coded Character > Set -- 7-bit American Standard Code for Information > Interchange", ANSI X3.4, 1986. Except that (1) many IETF documents do use RFC 20 and (2) the RFC 20 reference is not for ASCII: it's for RS, the Record Separator character, which is explained in RFC 20, Section 5.2. Barry From nobody Fri Dec 5 14:54:42 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBBD1A6FE1; Fri, 5 Dec 2014 14:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rngXEcAx3tKO; Fri, 5 Dec 2014 14:54:32 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D382E1A6FB1; Fri, 5 Dec 2014 14:54:31 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB5MsQGE005637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 17:54:27 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sB5MsQGE005637 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1417820067; bh=w9Dv69NKxX0hJbBP3DPj4aUc/Ug=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Ud0g0eBVyOpYnFW8JKx7PaDkAaDFVHQGAM6dpgDZYDnF0OZAzzyLktm4afFziEwMq ub4EwNEWmen3DYtx3w9dCqxcEv9TNVKs/b6z7zvxDsC1GcWmgWwzvF8/sVRPmc7tRV 0NziYu39IUo+4d4Gg3Mh/QX7iSVf52+oAnf2Slw4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sB5MsQGE005637 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 5 Dec 2014 17:53:22 -0500 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB5Ms5Xq028142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 17:54:05 -0500 Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub28.corp.emc.com (10.254.110.184) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 5 Dec 2014 17:54:05 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.125]) by MXHUB206.corp.emc.com ([fe80::843c:2a27:6ea:5f63%12]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 17:54:04 -0500 From: "Black, David" To: Barry Leiba Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 Thread-Index: AdAQmuBgzIEwbXsVSl+UfPcrbL3cqwAa0gUAAAoCu6A= Date: Fri, 5 Dec 2014 22:54:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/json/4o-UDOKdyucHVuHYv0DKLeASye0 Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "nico@cryptonector.com" , "Black, David" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 22:54:34 -0000 T2ssIGl0IGlzIGEgbml0LCBhcyBpcyBtdWNoIG9mIHdoYXQgaWRuaXRzIHByb2R1Y2VzIDstKS4N CkkgaGF2ZSBubyBwcm9ibGVtIGlnbm9yaW5nIGlkbml0cyBvbiB0aGlzIG9uZSAuLi4NCg0KVGhh bmtzLA0KLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGJh cnJ5bGVpYmEubWFpbGluZy5saXN0c0BnbWFpbC5jb20NCj4gW21haWx0bzpiYXJyeWxlaWJhLm1h aWxpbmcubGlzdHNAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQmFycnkgTGVpYmENCj4gU2VudDog RnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCA1OjM5IFBNDQo+IFRvOiBCbGFjaywgRGF2aWQNCj4g Q2M6IG5pY29AY3J5cHRvbmVjdG9yLmNvbTsgR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtIChnZW4t YXJ0QGlldGYub3JnKTsgb3BzLQ0KPiBkaXJAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGpzb25A aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IEdlbi1BUlQgYW5kIE9QUy1EaXIgcmV2aWV3IG9mIGRy YWZ0LWlldGYtanNvbi10ZXh0LXNlcXVlbmNlLTA5DQo+IA0KPiBIaSwgRGF2aWQuICBPbmUgbm90 ZSBvbiB5b3VyIHJldmlldzoNCj4gDQo+ID4gaWRuaXRzIGRpZG4ndCBsaWtlIHRoZSByZWZlcmVu Y2UgdG8gUkZDIDIwIGZvciBBU0NJSToNCj4gPg0KPiA+ICAgKiogRG93bnJlZjogTm9ybWF0aXZl IHJlZmVyZW5jZSB0byBhbiBVbmtub3duIHN0YXRlIFJGQzogUkZDICAgMjANCj4gPg0KPiA+IFJG QyA1MjM0IChBQk5GKSB1c2VzIHRoaXMsIHdoaWNoIGxvb2tzIGxpa2UgYSBiZXR0ZXIgcmVmZXJl bmNlOg0KPiA+DQo+ID4gICAgW1VTLUFTQ0lJXSAgQW1lcmljYW4gTmF0aW9uYWwgU3RhbmRhcmRz IEluc3RpdHV0ZSwgIkNvZGVkIENoYXJhY3Rlcg0KPiA+ICAgICAgICAgICAgICAgIFNldCAtLSA3 LWJpdCBBbWVyaWNhbiBTdGFuZGFyZCBDb2RlIGZvciBJbmZvcm1hdGlvbg0KPiA+ICAgICAgICAg ICAgICAgIEludGVyY2hhbmdlIiwgQU5TSSBYMy40LCAxOTg2Lg0KPiANCj4gRXhjZXB0IHRoYXQg KDEpIG1hbnkgSUVURiBkb2N1bWVudHMgZG8gdXNlIFJGQyAyMCBhbmQgKDIpIHRoZSBSRkMgMjAN Cj4gcmVmZXJlbmNlIGlzIG5vdCBmb3IgQVNDSUk6IGl0J3MgZm9yIFJTLCB0aGUgUmVjb3JkIFNl cGFyYXRvcg0KPiBjaGFyYWN0ZXIsIHdoaWNoIGlzIGV4cGxhaW5lZCBpbiBSRkMgMjAsIFNlY3Rp b24gNS4yLg0KPiANCj4gQmFycnkNCg== From nobody Sat Dec 6 19:36:37 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C481A1BD6 for ; Sat, 6 Dec 2014 19:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmhWmZdqAfSJ for ; Sat, 6 Dec 2014 19:36:35 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9991A1A3E for ; Sat, 6 Dec 2014 19:36:35 -0800 (PST) Received: from [10.118.131.151] (d1-4-13-143-118-on-nets.com [118.143.13.4] (may be forged)) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sB73aTMd077919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Dec 2014 20:36:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host d1-4-13-143-118-on-nets.com [118.143.13.4] (may be forged) claimed to be [10.118.131.151] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: Date: Sun, 7 Dec 2014 11:36:28 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2C77F14B-0D13-49D2-A303-7900E6795CE7@vpnc.org> References: To: draft-ietf-json-text-sequence.all@tools.ietf.org X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/eJasW4jvzDGZbLATs_yPQsFfmxE Cc: Barry Leiba , "json@ietf.org" Subject: Re: [Json] Media type registration in draft-ietf-json-text-sequence X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 03:36:36 -0000 On Dec 6, 2014, at 5:02 AM, Barry Leiba wrote: > While I wait for Pete to finish things up with this document and get > it into IESG Evaluation, and while there's still time before the > telechat date: >=20 > The media type registration in the document, bog-standard though it > might be, does not have a complete registration template: it's missing > everything after "applications that use this media type", including > contact information, author, and change controller. Perhaps IANA will > assume that the other missing information is meant to be blank, but > those are necessary; and anyway, the template should be complete. Major whoopsie on that. Nico: please assume we need a new draft with the = full template, and fill that in. Then... > Also, RFC 6838 strongly recommends review of all registration requests > on the list, and that wasn't done for this. > Given that IETF-stream registrations do not get formal expert review, > I very strongly prefer that that recommendation be heeded. Please use > this time to post this document's name and the (complete) registration > template to that list and see if there are any comments. Nico: please do send the full registration (what you have in the -09, = plus the rest of the fields) to the media-types list, because a = last-minute complaint from them during IESG review will make things drag = out unnecessarily. --Paul Hoffman= From nobody Sun Dec 7 05:02:16 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D391A6F0E; Sun, 7 Dec 2014 01:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EFztIV0SLBV; Sun, 7 Dec 2014 01:40:46 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A14D1A1EED; Sun, 7 Dec 2014 01:40:46 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::1953:222f:c738:98bf] (unknown [IPv6:2a02:80:3ffc:0:1953:222f:c738:98bf]) by mail.frobbit.se (Postfix) with ESMTPSA id A980E2037E; Sun, 7 Dec 2014 10:40:44 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FA1E5871-D734-4B59-A023-3F6646C9ED4C"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: Date: Sun, 7 Dec 2014 10:40:43 +0100 Message-Id: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> References: To: "Black, David" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/zTQFIBsE5-feWlHR3bnjdM_NioM X-Mailman-Approved-At: Sun, 07 Dec 2014 05:02:14 -0800 Cc: Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "ops-dir@ietf.org" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 09:40:49 -0000 --Apple-Mail=_FA1E5871-D734-4B59-A023-3F6646C9ED4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 All, Many definitions in this document have been specified in the form of 1:1 = mappings of Unicode code points to single bytes. This include the record = separator and for example definitions of the string "false" in the form = of five octets. This is ok if the encoding used for Unicode is UTF-8, and indeed it says = that the parser should try to parse the string as if it is a UTF-8 = sequence of characters. But it also reference RFC7159, which doesn't require UTF-8 but instead = for some weird reason also allow other encodings of Unicode text. And on = top of that it says Byte Order Mark is not allowed. This together implies that first of all this draft might not lead to = stable implementations, secondly one can not store in JSON strings that = include the Byte Order Mark, and there are other unspecified situations. Or, in short, weaknesses, as I see it, in RFC7159 are made even more = weak and potentially dangerous with draft-ietf-json-text-sequence. Yes, I and others should probably not have let RFC7159 through, because = there might be where the bugs are. Suggestion: this draft, draft-ietf-json-text-sequence, should say = explicitly that the only "profile" of RFC7159 that is allowed is UTF-8. = That should be a MUST. Reminder for the IETF: having "or" statements is not recommended at all = when talking about these kind of things, and RFC7159 include at least = one "or" too many. The recommendation from IETF is to use UTF-8 encoding = for Unicode (when serializing text). Patrik > On 5 dec 2014, at 15:51, Black, David wrote: >=20 > This is a combined Gen-ART and OPS-Dir review. Boilerplate for both = follows ... >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at: >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > I have reviewed this document as part of the Operational directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These comments > were written primarily for the benefit of the operational area = directors. > Document editors and WG chairs should treat these comments just like = any other > last call comments. >=20 > Document: draft-ietf-json-text-sequence-09 > Reviewer: David Black > Review Date: Dec 5, 2014 > IETF LC End Date: Dec 5, 2014 > IESG Telechat date: Dec 18, 2014 >=20 > Summary: This draft is on the right track, but has open issues > described in the review. >=20 > This draft specifies a format that packs multiple JSON texts into a > single string. The ASCII RS (0x1E) character is used to separate = texts, > and a linefeed is appended to each text to ensure that a complete text > always ends with a whitespace character. >=20 > All of the open issues are minor - the most important ones center on > treatment of incomplete JSON texts - that appears to be an = afterthought > in this draft and needs more attention. I also found a couple of > minor issues in the Security and IANA Considerations sections, both of > which are almost nits. >=20 > Major issues: None. >=20 > Minor issues: >=20 > [A] Section 2.1: >=20 > If parsing of such an octet string as a JSON text fails, the parser > SHOULD nonetheless continue parsing the remainder of the sequence. >=20 > That's not quite right - there are two levels of parsing, JSON > sequence parsing and JSON text parsing of each text in the sequence, > both of which might be implemented in a single-pass parser. For such = an > implementation, the above sentence could be (mis-)read to imply that = the > JSON text parse should resume from the point at which it failed, which > would be silly (although I've seen heroic PL/1 parsers do exactly = that). > Instead, the parse needs to skip ahead to the next RS, ignoring the = rest > of the JSON text that failed to parse. I suggest: >=20 > If parsing of such an octet string as a JSON text fails, and the > octet string is followed by an RS octet, the parser > SHOULD nonetheless skip ahead to that RS octet and continue parsing > the remainder of the sequence from there. >=20 > That also covers the case where there is nothing more to parse after = the > JSON text that caused the parse failure. >=20 > [B] Section 2.3: >=20 > Is incremental parsing of a JSON text within a sequence allowed, or > is the parser required to not produce any results until the parse of > the entire text is successful? I'd expect that incremental parsing > is ok (so results may be produced from a text that ultimately fails > to parse), and I think that's worth stating. >=20 > [C] Section 2.4: >=20 > Parsers MUST check that any JSON texts that are a top-level number > include JSON whitespace ("ws" ABNF rule from [RFC7159]) after the > number, otherwise the JSON-text may have been truncated. >=20 > That reference to the "ws" rule doesn't get the job done because that > rule allows a match to no characters - it's of the form ws =3D *( ... = ) > where ... is the list of whitespace characters. What's needed here is > a rule of the form vws =3D 1*( ...) to force there to be at least one > whitespace character, but see the next issue for a better way to deal > with this topic by pulling the appended LF into the sequence parse > instead of the text parse. >=20 > [D] I wonder whether the possibility of incomplete texts ought to be > encoded into the parsing rules to directly catch JSON texts that must > be incomplete because the last character is not LF, e.g.: >=20 > JSON-sequence =3D *(1*RS (possible-JSON / truncated-JSON / = empty-JSON)) > RS =3D %x1E; "record separator" (RS), see RFC20 > possible-JSON =3D 1*(not-RS) LF ; attempt to parse as = UTF-8-encoded > ; JSON text (see RFC7159) > truncated-JSON =3D *(not-RS) not-LFRS); truncated, don't attempt > ; to parse as JSON text > empty-JSON =3D LF ; only the LF appended by the encoder, nothing = to parse >=20 > not-RS =3D %x00-1D / %x1F-FF; any octet other than RS > not-LFRS =3D %x00-09/ %x1B-1D / %x1F-FF; any octet other than RS = or LF >=20 > Note that this won't detect all incomplete JSON texts, because LF is = allowed > within a JSON text (and this should be stated). >=20 > [E] Section 3 - Security Considerations >=20 > Incomplete and malformed JSON texts can be used to attack JSON parsers = - > that should be pointed out, as I don't see that in RFC 7159's security > considerations and incomplete texts are a relevant consideration for > this draft. >=20 > [F] Section 4 - IANA Considerations >=20 > Security considerations: See , > Section 3. >=20 > Interoperability considerations: Described herein. >=20 > Published specification: . >=20 > Applications that use this media type: is likely to support this format>. >=20 > Replace all three instances of the angle bracketed text. The first = two > instances should be RFC references (e.g., RFC XXXX) w/a note to the = RFC > Editor to insert the number of the RFC when published. The third = instance > should be resolved now, or could have an RFC Editor note added = indicating > that the author will resolve that during Authors 48 hours. >=20 > Nits/editorial comments: >=20 > idnits didn't like the reference to RFC 20 for ASCII: >=20 > ** Downref: Normative reference to an Unknown state RFC: RFC 20 >=20 > RFC 5234 (ABNF) uses this, which looks like a better reference: >=20 > [US-ASCII] American National Standards Institute, "Coded Character > Set -- 7-bit American Standard Code for Information > Interchange", ANSI X3.4, 1986. >=20 > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- >=20 > Most of these questions are n/a because this draft describes a format > that will be used in other protocols to which RFC 5706's concerns = would apply. >=20 > A.1.4 Have the Requirements on other protocols and functional > components been discussed? >=20 > The specification of the interaction of the JSON sequence parser with = the > JSON text parser is not as clear as it should be for incomplete or = malformed > JSON texts. See Minor Issues [A]-[E] above. >=20 > A.1.8 Are there fault or threshold conditions that should be = reported? >=20 > Yes, incomplete JSON texts - this is covered in sections 2.3 and 2.4. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 --Apple-Mail=_FA1E5871-D734-4B59-A023-3F6646C9ED4C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUhCCcrMabGguI180RAsiXAJ44FJE0xEXpEthtI1PCBiWZFHeJFACglmZ6 PEH9lz3xHty17MFrWmczUQ8= =HOKJ -----END PGP SIGNATURE----- --Apple-Mail=_FA1E5871-D734-4B59-A023-3F6646C9ED4C-- From nobody Sun Dec 7 08:41:35 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66DD1A19F4; Sun, 7 Dec 2014 08:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TbVzgPO_-Gr; Sun, 7 Dec 2014 08:41:25 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACD51A0161; Sun, 7 Dec 2014 08:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1417970486; x=1449506486; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=C/7vXT6l442LN0vtb42WZ3Y/mDIx0+AvF94j6l7cSbc=; b=J+pWBIPhF4gotKD7XNm59BHyEyqQ8pwq77UU4YZ5XFnOBDwTWJcw2/RD LmnztV0bl+HM+1WGLQwQPurghFPVyfl/bCq/594VzdJR5YdRHxGkIGPR4 MlUk5xMFQZfQQ/+rBf3LCNeA7YC7lF5VIWnLERWXr/HwXWmPDC/KzkJJY k=; X-IronPort-AV: E=McAfee;i="5600,1067,7644"; a="79637204" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 07 Dec 2014 08:41:25 -0800 X-IronPort-AV: E=Sophos;i="5.07,533,1413270000"; d="scan'208";a="31204858" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Dec 2014 08:41:24 -0800 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 7 Dec 2014 08:41:03 -0800 Message-ID: <5484831C.7090506@qti.qualcomm.com> Date: Sun, 7 Dec 2014 10:41:00 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/json/XAPkuMoPeIfmcCOr6VYzDivuUW8 Cc: "ietf@ietf.org" , "Black, David" , "ops-dir@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 16:41:27 -0000 On 12/5/14 4:38 PM, Barry Leiba wrote: > Hi, David. One note on your review: > > >> idnits didn't like the reference to RFC 20 for ASCII: >> >> ** Downref: Normative reference to an Unknown state RFC: RFC 20 >> >> RFC 5234 (ABNF) uses this, which looks like a better reference: >> >> [US-ASCII] American National Standards Institute, "Coded Character >> Set -- 7-bit American Standard Code for Information >> Interchange", ANSI X3.4, 1986. >> > Except that (1) many IETF documents do use RFC 20 and (2) the RFC 20 > reference is not for ASCII: it's for RS, the Record Separator > character, which is explained in RFC 20, Section 5.2. > And as per BCP97, RFC 3967, section 3, this downref was specifically called out in the Last Call for this document. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Dec 7 10:05:37 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8259F1A87EB; Sun, 7 Dec 2014 10:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhjrcTkBeRnj; Sun, 7 Dec 2014 10:05:34 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F051A87EA; Sun, 7 Dec 2014 10:05:34 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XxgD2-0008WE-9i; Sun, 07 Dec 2014 13:05:28 -0500 Date: Sun, 7 Dec 2014 13:05:28 -0500 From: John Cowan To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20141207180528.GA1116@mercury.ccil.org> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/jUEPy46IVZlcIguo9lx08njnfkY Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 18:05:35 -0000 Patrik Fältström scripsit: > But it also reference RFC7159, which doesn't require UTF-8 but instead > for some weird reason also allow other encodings of Unicode text. And > on top of that it says Byte Order Mark is not allowed. 7159 was meant to tighten the wording of 4627, not to impose additional constraints on it. For that, see the I-JSON draft. > This together implies that first of all this draft might not lead to > stable implementations, secondly one can not store in JSON strings > that include the Byte Order Mark, and there are other unspecified > situations. If by that you mean that a JSON string may not contain U+FEFF, that is incorrect, for U+FEFF is recognized as a BOM only when placed at the beginning of an entity body, whereas an entity body in JSON format can begin only with [ or { classically, or by extension with [0-9"tfn]. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org 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 nobody Sun Dec 7 10:55:50 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B885A1A0097; Sun, 7 Dec 2014 10:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEyt_iceUtXt; Sun, 7 Dec 2014 10:55:45 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DDBB1A0087; Sun, 7 Dec 2014 10:55:45 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::2959:e46f:9292:ec55] (unknown [IPv6:2a02:80:3ffc:0:2959:e46f:9292:ec55]) by mail.frobbit.se (Postfix) with ESMTPSA id 4CAEE22C69; Sun, 7 Dec 2014 19:55:42 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1E8D1AD8-5BD3-466B-BCE6-8C9E53B771D1"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20141207180528.GA1116@mercury.ccil.org> Date: Sun, 7 Dec 2014 19:55:41 +0100 Message-Id: References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/luuYPWuvgiEO60XGVIgc93faNsw Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 18:55:46 -0000 --Apple-Mail=_1E8D1AD8-5BD3-466B-BCE6-8C9E53B771D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > On 7 dec 2014, at 19:05, John Cowan wrote: >=20 > Patrik F=E4ltstr=F6m scripsit: >=20 >> But it also reference RFC7159, which doesn't require UTF-8 but = instead >> for some weird reason also allow other encodings of Unicode text. And >> on top of that it says Byte Order Mark is not allowed. >=20 > 7159 was meant to tighten the wording of 4627, not to impose = additional > constraints on it. For that, see the I-JSON draft. The problem I have is that 7159 is not tight enough as it allows other = encodings than UTF-8, which in turn make the encoding not work very well = as this draft take for granted each one of the separator characters is = one byte each. I.e. the way I read draft-ietf-json-text-sequence (and I might be = wrong), you have specific octet values that act as separators. That only = works if the encoding is UTF-8. See Figure 1: > possible-JSON =3D 1*(not-RS); attempt to parse as UTF-8-encoded > ; JSON text (see RFC7159) Now, if this is NOT UTF-8, then this might be pretty bad situation. What I am saying is that I would like this draft to explicitly say that = the only profile of RFC7159 that can be used is when UTF-8 is in use, = i.e. somewhere something like "The encoding MUST be UTF-8, although = RFC7159 also allow other encodings, like UTF-16." Then in the security = considerations section that "RFC7159 do allow not only UTF-8 encoding = but also for example UTF-16, which MIGHT create problems for a parser, = all depending on what data is serialized." I.e. I want this draft to be even more tight than RFC7159. Let me ask it this way: is there any reason to allow other encodings = than UTF-8? If so, how do you handle the encoding of the separators? >> This together implies that first of all this draft might not lead to >> stable implementations, secondly one can not store in JSON strings >> that include the Byte Order Mark, and there are other unspecified >> situations. >=20 > If by that you mean that a JSON string may not contain U+FEFF, that is > incorrect, for U+FEFF is recognized as a BOM only when placed at the > beginning of an entity body, whereas an entity body in JSON format can > begin only with [ or { classically, or by extension with [0-9"tfn]. Ok, so what you say is that a string in an attribute value in the JSON = blob can still start with U+FEFF? If so, good, and my apologies for not understanding this at my read of = the text. Patrik --Apple-Mail=_1E8D1AD8-5BD3-466B-BCE6-8C9E53B771D1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUhKKtrMabGguI180RAncpAJ9XK3mFBMiPwQ8rDAh1rgnxEENfngCeNHr2 EsA/bCLYZPmPwPzZ2a768yw= =/AAc -----END PGP SIGNATURE----- --Apple-Mail=_1E8D1AD8-5BD3-466B-BCE6-8C9E53B771D1-- From nobody Sun Dec 7 13:08:07 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63251A008C; Sun, 7 Dec 2014 13:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-8DqJTPw1-b; Sun, 7 Dec 2014 13:07:59 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B1D1A8938; Sun, 7 Dec 2014 13:07:59 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Xxj3a-0005Aw-G2; Sun, 07 Dec 2014 16:07:54 -0500 Date: Sun, 7 Dec 2014 16:07:54 -0500 From: John Cowan To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20141207210754.GA18507@mercury.ccil.org> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/nQdZ2HJKn8c1bjeD8KfImmsBuiw Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 21:08:01 -0000 Patrik Fältström scripsit: > I.e. the way I read draft-ietf-json-text-sequence (and I might be > wrong), you have specific octet values that act as separators. That > only works if the encoding is UTF-8. This is a binary representation which has embedded JSON texts represented in UTF-8. Since the first character in a JSON text is necessarily in the ASCII repertoire, it is not possible to parse a UTF-16 or UTF-32 JSON text as UTF-8 and come out with valid JSON. However, I grant that mentioning UTF-8 only in an ABNF comment is not really prominent enough. Proposed wording change: For: In prose: a series of octet strings, each containing any octet other than a record separator (RS) (0x1E) [RFC0020], all octet strings separated from each other by RS octets. Each octet string in the sequence is to be parsed as a JSON text. read: In prose: a series of octet strings, each containing any octet other than a record separator (RS) (0x1E) [RFC0020], all octet strings separated from each other by RS octets. Each octet string in the sequence is to be parsed as a JSON text in UTF-8 encoding. and add a suitable reference to UTF-8. > Ok, so what you say is that a string in an attribute value in the JSON > blob can still start with U+FEFF? Just so. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org As we all know, civil libertarians are not the friskiest group around -- comes from forever being on the qui vive for the sound of jack-booted fascism coming down the pike. --Molly Ivins From nobody Sun Dec 7 19:00:11 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C2B1A1B62; Sun, 7 Dec 2014 19:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnuVhbgE42-R; Sun, 7 Dec 2014 19:00:07 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD4D1A1B16; Sun, 7 Dec 2014 19:00:06 -0800 (PST) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB82xvdF021565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Dec 2014 21:59:57 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sB82xvdF021565 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418007598; bh=D+rgBB5uY3r8UMx/q7V4iYhv0cs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=VfBJdC2RMfMO6AShmGycx8XDc+wCOiXbgr0GzUHWDX0lkpUknMEY2+GyxXAW4Hki0 iTtOSPgkjqizgcRhiZk0xRlrdFpwa0DZLQTyojLAMd8TaTyBu9Cxjnq3hc8bak4o+3 f8ImY7MSrYQe8HDpSCCkoz1rGXpWr6FycJwFOFBM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sB82xvdF021565 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Sun, 7 Dec 2014 21:59:42 -0500 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB82xiFX017119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Dec 2014 21:59:45 -0500 Received: from MXHUB207.corp.emc.com (10.253.68.33) by mxhub26.corp.emc.com (10.254.110.182) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sun, 7 Dec 2014 21:59:44 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.125]) by MXHUB207.corp.emc.com ([fe80::f91d:58b1:27db:6e6c%12]) with mapi id 14.03.0195.001; Sun, 7 Dec 2014 21:59:44 -0500 From: "Black, David" To: John Cowan , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Thread-Topic: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 Thread-Index: AdAQmuBgzIEwbXsVSl+UfPcrbL3cqwBkObmAABGg0QAAAcD5gAAEnhwAAAF+vvA= Date: Mon, 8 Dec 2014 02:59:44 +0000 Message-ID: References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> In-Reply-To: <20141207210754.GA18507@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.60.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/json/TE9TkS-oyBfRJmZPm35ibR8qk_k Cc: Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" , "ietf@ietf.org" , "ops-dir@ietf.org" , "json@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 03:00:09 -0000 I agree with Patrik - this draft assumes UTF-8 encoding and should state that requirement explicitly. John's proposed text change below is in section 2.1 for the decoder; the encoder text in section 2.2 needs a corresponding change: OLD In prose: any number of JSON texts, each preceded by one ASCII RS character and each followed by a line feed (LF). NEW In prose: any number of JSON texts encoded as UTF-8, each preceded by one ASCII RS character and each followed by a line feed (LF). Thanks, --David > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan > Sent: Sunday, December 07, 2014 4:08 PM > To: Patrik F=E4ltstr=F6m > Cc: Black, David; Nico Williams; General Area Review Team (gen-art@ietf.o= rg); > json@ietf.org; ops-dir@ietf.org; ietf@ietf.org > Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text- > sequence-09 >=20 > Patrik F=E4ltstr=F6m scripsit: >=20 > > I.e. the way I read draft-ietf-json-text-sequence (and I might be > > wrong), you have specific octet values that act as separators. That > > only works if the encoding is UTF-8. >=20 > This is a binary representation which has embedded JSON texts represented > in UTF-8. Since the first character in a JSON text is necessarily in > the ASCII repertoire, it is not possible to parse a UTF-16 or UTF-32 > JSON text as UTF-8 and come out with valid JSON. >=20 > However, I grant that mentioning UTF-8 only in an ABNF comment is not > really prominent enough. Proposed wording change: >=20 > For: >=20 > In prose: a series of octet strings, each containing any octet other > than a record separator (RS) (0x1E) [RFC0020], all octet strings > separated from each other by RS octets. Each octet string in the > sequence is to be parsed as a JSON text. >=20 > read: >=20 > In prose: a series of octet strings, each containing any octet other > than a record separator (RS) (0x1E) [RFC0020], all octet strings > separated from each other by RS octets. Each octet string in the > sequence is to be parsed as a JSON text in UTF-8 encoding. >=20 > and add a suitable reference to UTF-8. >=20 > > Ok, so what you say is that a string in an attribute value in the JSON > > blob can still start with U+FEFF? >=20 > Just so. >=20 >=20 > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > As we all know, civil libertarians are not the friskiest group around -- > comes from forever being on the qui vive for the sound of jack-booted > fascism coming down the pike. --Molly Ivins From nobody Sun Dec 7 21:42:44 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52171A6F0B; Sun, 7 Dec 2014 21:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8v7NOvnfSbs; Sun, 7 Dec 2014 21:42:34 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0781A6EFB; Sun, 7 Dec 2014 21:42:34 -0800 (PST) Received: from [192.168.1.83] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 9C9472033F; Mon, 8 Dec 2014 06:42:32 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2BF39DFA-E834-4C16-9342-0057BA5E36FC"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20141207210754.GA18507@mercury.ccil.org> Date: Mon, 8 Dec 2014 06:42:32 +0100 Message-Id: <743CABB8-9BDB-4144-BD96-2D3A79BF0450@frobbit.se> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/weAuXwlNBa9QZf56nbdVsEhp1rE Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 05:42:36 -0000 --Apple-Mail=_2BF39DFA-E834-4C16-9342-0057BA5E36FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > On 7 dec 2014, at 22:07, John Cowan wrote: >=20 > Patrik F=E4ltstr=F6m scripsit: >=20 >> I.e. the way I read draft-ietf-json-text-sequence (and I might be >> wrong), you have specific octet values that act as separators. That >> only works if the encoding is UTF-8. >=20 > This is a binary representation which has embedded JSON texts = represented > in UTF-8. Since the first character in a JSON text is necessarily in > the ASCII repertoire, it is not possible to parse a UTF-16 or UTF-32 > JSON text as UTF-8 and come out with valid JSON. My point is that if you talk about what specific characters or reference = RFC20 or what not, then you only get RS if you use UTF-8 encoding. If = you use UTF-16, then you neither have RS as one octet (0x1E), nor is RS = the only character that do have 0x1E as one of the octets. I think the problem is that I do not know what "octet string" is. You = either have UTF-8 encoded Unicode strings, or... ;-) In this case, you = have a series of UTF-8 encoded Unicode Strings, right? Separated by the = octet 0x1E, which happen to also be a correctly encoded Unicode = character -- the Information Separator Two. This implies the whole thing = is a UTF-8 encoded text that is to be parsed like this: possible-JSON =3D 1*(not-RS); UTF-8-encoded JSON text ; (as specified in RFC7159, but only UTF-8 allowed) I.e. the blob, to be compliant with this document, MUST be UTF-8 encoded = JSON. Right? > However, I grant that mentioning UTF-8 only in an ABNF comment is not > really prominent enough. Proposed wording change: >=20 > For: >=20 > In prose: a series of octet strings, each containing any octet other > than a record separator (RS) (0x1E) [RFC0020], all octet strings > separated from each other by RS octets. Each octet string in the > sequence is to be parsed as a JSON text. >=20 > read: >=20 > In prose: a series of octet strings, each containing any octet other > than a record separator (RS) (0x1E) [RFC0020], all octet strings > separated from each other by RS octets. Each octet string in the > sequence is to be parsed as a JSON text in UTF-8 encoding. >=20 > and add a suitable reference to UTF-8. I would say that what you have said above is: This specifies a series of UTF-8 encoded Unicode strings. Each to be = interpreted as JSON text. The strings are separated by the octet 0x1E = (which is UTF-8 encoding of the Unicode Character U+001E - INFORMATION = SEPARATOR TWO). This character because of this must be escaped, for = example by using \u001E notation, if it exists in an attribute value. >> Ok, so what you say is that a string in an attribute value in the = JSON >> blob can still start with U+FEFF? >=20 > Just so. Good. Patrik --Apple-Mail=_2BF39DFA-E834-4C16-9342-0057BA5E36FC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUhTpIrMabGguI180RAo3uAJ9XErfk6+DvYbKke7LScVQHQk9lhACfSYCF EEaG6QYafs8Nz0WYzdMPXTo= =PLUL -----END PGP SIGNATURE----- --Apple-Mail=_2BF39DFA-E834-4C16-9342-0057BA5E36FC-- From nobody Sun Dec 7 21:44:40 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9691A6F1D; Sun, 7 Dec 2014 21:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVfvuhEW9UnH; Sun, 7 Dec 2014 21:44:38 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFAA81A6EFB; Sun, 7 Dec 2014 21:44:37 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::2959:e46f:9292:ec55] (unknown [IPv6:2a02:80:3ffc:0:2959:e46f:9292:ec55]) by mail.frobbit.se (Postfix) with ESMTPSA id 44DB82039F; Mon, 8 Dec 2014 06:44:36 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A46FD08D-EA74-4775-8A33-033366F1DE29"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: Date: Mon, 8 Dec 2014 06:44:35 +0100 Message-Id: <12AE30EF-529A-4B47-A40C-A2E0EE5A6317@frobbit.se> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> To: "Black, David" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/Hj2rFwL2uyvgu3OTW6HE0dvjKr4 Cc: "General Area Review Team \(gen-art@ietf.org\)" , John Cowan , "ietf@ietf.org" , "ops-dir@ietf.org" , "json@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 05:44:39 -0000 --Apple-Mail=_A46FD08D-EA74-4775-8A33-033366F1DE29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > On 8 dec 2014, at 03:59, Black, David wrote: >=20 > OLD > In prose: any number of JSON texts, each preceded by one ASCII RS > character and each followed by a line feed (LF). > NEW > In prose: any number of JSON texts encoded as UTF-8, each preceded > by one ASCII RS character and each followed by a line feed (LF). >=20 My point is that you do not have to talk about ASCII RS. You can as well = talk about the UTF-8 encoding of the unicode character INFORMATION = SEPARATOR TWO, U+001E. Much cleaner. Just say it must be UTF-8 encoded text, done. Patrik --Apple-Mail=_A46FD08D-EA74-4775-8A33-033366F1DE29 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUhTrDrMabGguI180RAoPgAJ9GS3zmuhcpTrDgeC2WLyeQP/G7ogCfc/2W zTHmHyGcjPzyPfMr2aPUUcI= =g7kt -----END PGP SIGNATURE----- --Apple-Mail=_A46FD08D-EA74-4775-8A33-033366F1DE29-- From nobody Sun Dec 7 23:38:29 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FE81A6FDF for ; Sun, 7 Dec 2014 23:38:23 -0800 (PST) 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=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC557SiIwNoh for ; Sun, 7 Dec 2014 23:38:21 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E891A6FE5 for ; Sun, 7 Dec 2014 23:38:20 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so1777280lbg.33 for ; Sun, 07 Dec 2014 23:38:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Eu8MGAAXN7p/g4d6hphqkDAomZgdIzMlT8FNZzD+nXA=; b=H/lr58TDWud+5D+aVaA+0kiz1F15tkQ8/wHc+lbRkzNW6WsuIq7rLs7McrSLuxn471 O5oF1QvKuKFD3J9xKXUje6Vokd58LSQI+xkebJNOT137ic605EzVsU8/XixHODdQrXD2 TeiEQ4GFJV7HdDra7175H9NFsIC7chdDQHtmKU+cdwAXK/QlpsUChg9XDT1MfdAh/mHP RTqgu4IP3ICoYb2FhtH8CsVLAiqSN9HNkNK5aEF0d11l+VAX5tFOexalmhpIBEHDRcIg edHR/fGJmfmwY5rfWY1Icguk1OAJPCGDpSiBdXB/7w11Dv0W6Jw+A8NRgC1ZgbS8voWK jCvg== X-Gm-Message-State: ALoCoQlASMgsHpIhnt/WWFckvBi5e4z2FB/hg8qXuz068P5LpWuaSBgqdxtrcbXx3K3GhHLtV3Lv X-Received: by 10.112.16.39 with SMTP id c7mr14776978lbd.19.1418024298824; Sun, 07 Dec 2014 23:38:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.2.212 with HTTP; Sun, 7 Dec 2014 23:37:58 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <12AE30EF-529A-4B47-A40C-A2E0EE5A6317@frobbit.se> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> <12AE30EF-529A-4B47-A40C-A2E0EE5A6317@frobbit.se> From: Tim Bray Date: Sun, 7 Dec 2014 23:37:58 -0800 Message-ID: To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Content-Type: multipart/alternative; boundary=001a11c3c78e9d59ae0509af82ad Archived-At: http://mailarchive.ietf.org/arch/msg/json/JjdX03WCvmt8vhTNb-zx4a7lfgs Cc: "ops-dir@ietf.org" , John Cowan , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 07:38:23 -0000 --001a11c3c78e9d59ae0509af82ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree 100% that the fact that JSON Text Sequences MUST BE UTF-8 should be highlighted. Both the ASCII and Unicode names of 30/0x1e/00011110 should, for completeness, be provided. It would be inappropriate to omit ASCII, because we picked 0x1e because of its ASCII name. On Sun, Dec 7, 2014 at 9:44 PM, Patrik F=C3=A4ltstr=C3=B6m = wrote: > > > On 8 dec 2014, at 03:59, Black, David wrote: > > > > OLD > > In prose: any number of JSON texts, each preceded by one ASCII RS > > character and each followed by a line feed (LF). > > NEW > > In prose: any number of JSON texts encoded as UTF-8, each preceded > > by one ASCII RS character and each followed by a line feed (LF). > > > > My point is that you do not have to talk about ASCII RS. You can as well > talk about the UTF-8 encoding of the unicode character INFORMATION > SEPARATOR TWO, U+001E. Much cleaner. > > Just say it must be UTF-8 encoded text, done. > > Patrik > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c3c78e9d59ae0509af82ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I a= gree 100% that the fact that JSON Text Sequences MUST BE UTF-8 should be hi= ghlighted.=C2=A0 Both the ASCII and Unicode names of 30/0x1e/00011110 shoul= d, for completeness, be provided.=C2=A0 It would be inappropriate to omit A= SCII, because we picked 0x1e because of its ASCII name.

On Sun, Dec 7, 2014 at 9:= 44 PM, Patrik F=C3=A4ltstr=C3=B6m <paf@frobbit.se> wrote:

> On 8 dec 2014, at 03:59, Black, David <david.black@emc.com> wrote:
>
> OLD
>=C2=A0 =C2=A0In prose: any number of JSON texts, each preceded by one A= SCII RS
>=C2=A0 =C2=A0character and each followed by a line feed (LF).
> NEW
>=C2=A0 =C2=A0In prose: any number of JSON texts encoded as UTF-8, each = preceded
>=C2=A0 =C2=A0by one ASCII RS character and each followed by a line feed= (LF).
>

My point is that you do not have to talk about ASCII RS. You can as well ta= lk about the UTF-8 encoding of the unicode character INFORMATION SEPARATOR = TWO, U+001E. Much cleaner.

Just say it must be UTF-8 encoded text, done.

=C2=A0 =C2=A0Patrik


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




--
- Tim Bray (If you=E2=80=99d l= ike to send me a private message, see https://keybase.io/timbray)
--001a11c3c78e9d59ae0509af82ad-- From nobody Sun Dec 7 23:48:21 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EA91A6FF9; Sun, 7 Dec 2014 23:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv6sJQdi9QIs; Sun, 7 Dec 2014 23:48:10 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02821A1A9B; Sun, 7 Dec 2014 23:48:10 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::22] (unknown [IPv6:2a02:80:3ffc::22]) by mail.frobbit.se (Postfix) with ESMTPSA id 10B40202B8; Mon, 8 Dec 2014 08:48:09 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0589C141-61FB-4151-A814-0A3968E0EA25"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: Date: Mon, 8 Dec 2014 08:48:08 +0100 Message-Id: References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> <12AE30EF-529A-4B47-A40C-A2E0EE5A6317@frobbit.se> To: Tim Bray X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/_U0OFMM541uy8T1wmTkx6wP078U Cc: "ops-dir@ietf.org" , John Cowan , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 07:48:13 -0000 --Apple-Mail=_0589C141-61FB-4151-A814-0A3968E0EA25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW, I think this is a good view. I just felt that given the other = discussion about RFC20, you do not HAVE TO talk about ASCII or the name = of the code point in the standard. Sure, that is the reason you picked = U+001E, but that is more a nice story ;-) It was not my intention to say that you should not talk about ASCII. Patrik > On 8 Dec 2014, at 08:37, Tim Bray wrote: >=20 > I agree 100% that the fact that JSON Text Sequences MUST BE UTF-8 = should be highlighted. Both the ASCII and Unicode names of = 30/0x1e/00011110 should, for completeness, be provided. It would be = inappropriate to omit ASCII, because we picked 0x1e because of its ASCII = name. >=20 > On Sun, Dec 7, 2014 at 9:44 PM, Patrik F=C3=A4ltstr=C3=B6m = wrote: >=20 > > On 8 dec 2014, at 03:59, Black, David wrote: > > > > OLD > > In prose: any number of JSON texts, each preceded by one ASCII RS > > character and each followed by a line feed (LF). > > NEW > > In prose: any number of JSON texts encoded as UTF-8, each preceded > > by one ASCII RS character and each followed by a line feed (LF). > > >=20 > My point is that you do not have to talk about ASCII RS. You can as = well talk about the UTF-8 encoding of the unicode character INFORMATION = SEPARATOR TWO, U+001E. Much cleaner. >=20 > Just say it must be UTF-8 encoded text, done. >=20 > Patrik >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 >=20 >=20 >=20 > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see = https://keybase.io/timbray) --Apple-Mail=_0589C141-61FB-4151-A814-0A3968E0EA25 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlSFV7gACgkQrMabGguI183GEgCfWZTGUZrd8CHwyDhLadXJcjKW MVgAoI5SwkfWqt9EmB+adZ9wIuk78DBd =MD+f -----END PGP SIGNATURE----- --Apple-Mail=_0589C141-61FB-4151-A814-0A3968E0EA25-- From nobody Mon Dec 8 19:31:06 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65591A0242; Mon, 8 Dec 2014 19:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0B8mgjodxI2; Mon, 8 Dec 2014 19:31:00 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A3AAA1A013B; Mon, 8 Dec 2014 19:31:00 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 385DAB805B; Mon, 8 Dec 2014 19:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=0JxJJXJyzYnY0481yhf2d4om7os=; b=YswAceYbEi8 xC2eKo6YVFOFlH+90GfM0oW62jxm/0lwb91d/lT5F7uszY9+EQQlG3VAhiscPoRh pAjK0IHeHAm8TW7n0pAolOlEzrf8EEXiaFTen8OGnp0FX+AhdXlb/wrzmk/lDTfM EFyGAbbQdJJ3se8m4z6o7x/LhuSaXKSI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id 96DF6B8057; Mon, 8 Dec 2014 19:30:59 -0800 (PST) Date: Mon, 8 Dec 2014 21:30:57 -0600 From: Nico Williams To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20141209033052.GA11221@localhost> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/OF3cIG9ltvWUY2_YCrtNG6UmIVQ Cc: "ops-dir@ietf.org" , John Cowan , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 03:31:01 -0000 [I've been traveling, please excuse my late responses.] On Sun, Dec 07, 2014 at 07:55:41PM +0100, Patrik F=E4ltstr=F6m wrote: > > On 7 dec 2014, at 19:05, John Cowan wrote: > > Patrik F=E4ltstr=F6m scripsit: > >=20 > >> But it also reference RFC7159, which doesn't require UTF-8 but inste= ad > >> for some weird reason also allow other encodings of Unicode text. An= d > >> on top of that it says Byte Order Mark is not allowed. > >=20 > > 7159 was meant to tighten the wording of 4627, not to impose addition= al > > constraints on it. For that, see the I-JSON draft. >=20 > The problem I have is that 7159 is not tight enough as it allows other > encodings than UTF-8, which in turn make the encoding not work very > well as this draft take for granted each one of the separator > characters is one byte each. >=20 > I.e. the way I read draft-ietf-json-text-sequence (and I might be > wrong), you have specific octet values that act as separators. That > only works if the encoding is UTF-8. Right. I'll add text to section 2.2 saying that the JSON texts have to be encoded in UTF-8. > See Figure 1: >=20 > > possible-JSON =3D 1*(not-RS); attempt to parse as UTF-8-encoded > > ; JSON text (see RFC7159) >=20 > Now, if this is NOT UTF-8, then this might be pretty bad situation. Well, you can always fuzz test a parser... :) But yes, the encoder should use UTF-8. > What I am saying is that I would like this draft to explicitly say > that the only profile of RFC7159 that can be used is when UTF-8 is in > use, i.e. somewhere something like "The encoding MUST be UTF-8, > although RFC7159 also allow other encodings, like UTF-16." Then in the > security considerations section that "RFC7159 do allow not only UTF-8 > encoding but also for example UTF-16, which MIGHT create problems for > a parser, all depending on what data is serialized." >=20 > I.e. I want this draft to be even more tight than RFC7159. I agree with this. This was always my intent (as in: I never intended to support UTF-16 or UTF-32, say, or any other UTF, in any implementation of mine). And I agree that this format doesn't work with UTF-16 or UTF-32 EVEN IF the UTF were part of the MIME type and UTF-specific multi-byte separators were used: because at least for log-type applications where atomicity of writes is in question multi-byte separators won't do. Nico --=20 From nobody Mon Dec 8 19:37:18 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5111A013B; Mon, 8 Dec 2014 19:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIT2PbKPYrtZ; Mon, 8 Dec 2014 19:37:14 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3445B1A0077; Mon, 8 Dec 2014 19:37:14 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 17ECA20046913; Mon, 8 Dec 2014 19:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=9sZ6lMPDHJh0+T 4nQ0up+sTHO1M=; b=V5UBC/Xlbk2+71BAD/tUjppndjSiqtCNMkUOVGt9B2R/I7 WUfHzf4Gi3muMOZVsWlQV6WEVQCBCLsP+vAA+l0JTSUWm5uHvZ6XOXsc0xV4Rk/S yW0L6+XyEJO4/iJ9a4+NeqjMGLIamzRZVcqnqjHVdiKTRRa3Lhr+Hl0pOROZo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 7C9EA20046912; Mon, 8 Dec 2014 19:37:13 -0800 (PST) Date: Mon, 8 Dec 2014 21:37:13 -0600 From: Nico Williams To: John Cowan Message-ID: <20141209033708.GB11221@localhost> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141207210754.GA18507@mercury.ccil.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/o2Z35eIFnjxQq9TwE51e7dd2MXo Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 03:37:17 -0000 On Sun, Dec 07, 2014 at 04:07:54PM -0500, John Cowan wrote: > However, I grant that mentioning UTF-8 only in an ABNF comment is not > really prominent enough. Proposed wording change: > > For: > > In prose: a series of octet strings, each containing any octet other > than a record separator (RS) (0x1E) [RFC0020], all octet strings > separated from each other by RS octets. Each octet string in the > sequence is to be parsed as a JSON text. > > read: > > In prose: a series of octet strings, each containing any octet other > than a record separator (RS) (0x1E) [RFC0020], all octet strings > separated from each other by RS octets. Each octet string in the > sequence is to be parsed as a JSON text in UTF-8 encoding. Agreed. And a corresponding change to section 2.2, which will now read: In prose: any number of JSON texts, each encoded in UTF-8, each preceded by one ASCII RS character, and each followed by a line feed (LF). Since RS ... > and add a suitable reference to UTF-8. Oh, eh, RFC7159 lacked such a thing. At least this one should be non-controversial: RFC3629. (Right? :) Nico -- From nobody Mon Dec 8 19:42:07 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1943D1A1A73; Mon, 8 Dec 2014 19:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pttzPtYMnZyQ; Mon, 8 Dec 2014 19:42:00 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7682E1A1A6A; Mon, 8 Dec 2014 19:42:00 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 4EAE620047B84; Mon, 8 Dec 2014 19:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=PzUb4DFGp5D/F7 x0n5deBuUOInI=; b=noIijZjScN3kKTuVbEeGiXTcC9ZpgCdwDVSdNPVuX2QuA0 wlc512+UfIthAUNztisvM7QCq6aR4Ji+tz+BZBfPU4cWjUbbtQSOnMDZ2uOCinJY +FKjAOR2TS40XEeGbB6YtpOt7h3ko/NwtWqWIW8XgmVJudf7ShrosSyZpPzRs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id A25E220047B82; Mon, 8 Dec 2014 19:41:59 -0800 (PST) Date: Mon, 8 Dec 2014 21:41:59 -0600 From: Nico Williams To: Tim Bray Message-ID: <20141209034154.GC11221@localhost> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> <12AE30EF-529A-4B47-A40C-A2E0EE5A6317@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/m7qY1bZNgDrAEdbu24GdxLiB1-c Cc: "ops-dir@ietf.org" , John Cowan , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 03:42:01 -0000 On Sun, Dec 07, 2014 at 11:37:58PM -0800, Tim Bray wrote: > I agree 100% that the fact that JSON Text Sequences MUST BE UTF-8 should be > highlighted. Both the ASCII and Unicode names of 30/0x1e/00011110 should, > for completeness, be provided. It would be inappropriate to omit ASCII, > because we picked 0x1e because of its ASCII name. Good point. (It's "Unicode Character 'INFORMATION SEPARATOR TWO' (U+001E)".) From nobody Mon Dec 8 20:19:52 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3578E1A020A; Mon, 8 Dec 2014 20:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnQ6Sf8QGxvZ; Mon, 8 Dec 2014 20:19:43 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 75C1B1A0072; Mon, 8 Dec 2014 20:19:43 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 2DC5A1DE05D; Mon, 8 Dec 2014 20:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=AqeKLmnyOkR+C0 5nggSHCQnP4l4=; b=icmpI65EjUdMoZNJKs5Prp6kb2UOUuohvemc1HpA9nxL7v tC65lnS26KCK6RRp6eto3wjj9aqBlekkbOq4QepfY4R332kaOJ/EHN43HMiIaLpt N2sYLySBVqlvDirGXPFj5KxwOGHQVjOzwQ6THI42t91mB8NsvPuZDIe8bHPGA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id A45F31DE058; Mon, 8 Dec 2014 20:19:42 -0800 (PST) Date: Mon, 8 Dec 2014 22:19:42 -0600 From: Nico Williams To: "Black, David" Message-ID: <20141209041937.GD11221@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/gdIQM5HXLRKw1DqkRmhjvDWSLUk Cc: "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "ops-dir@ietf.org" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 04:19:45 -0000 On Fri, Dec 05, 2014 at 02:51:04PM +0000, Black, David wrote: > This is a combined Gen-ART and OPS-Dir review. Boilerplate for both follows ... Thanks you. > Minor issues: > > [A] Section 2.1: > > If parsing of such an octet string as a JSON text fails, the parser > SHOULD nonetheless continue parsing the remainder of the sequence. > > That's not quite right - there are two levels of parsing, JSON > sequence parsing and JSON text parsing of each text in the sequence, > both of which might be implemented in a single-pass parser. For such an > implementation, the above sentence could be (mis-)read to imply that the > JSON text parse should resume from the point at which it failed, which > would be silly (although I've seen heroic PL/1 parsers do exactly that). > Instead, the parse needs to skip ahead to the next RS, ignoring the rest > of the JSON text that failed to parse. I suggest: Good point. > If parsing of such an octet string as a JSON text fails, and the > octet string is followed by an RS octet, the parser > SHOULD nonetheless skip ahead to that RS octet and continue parsing > the remainder of the sequence from there. That's a weird way of saying that, wherever the JSON text parse fails, the sequence parser should then seek forward until the next RS-valued byte. But it works for me; I'll take it. > [B] Section 2.3: > > Is incremental parsing of a JSON text within a sequence allowed, or > is the parser required to not produce any results until the parse of > the entire text is successful? I'd expect that incremental parsing > is ok (so results may be produced from a text that ultimately fails > to parse), and I think that's worth stating. It's permitted, of course, with the caveat that all incremental parsers have: the parse can ultimately fail. I'll add this note: Incremental JSON text parsers may be used, though of course failure to parse a given text may result after first producing some incremental parse results. to section 2.3. > [C] Section 2.4: > > Parsers MUST check that any JSON texts that are a top-level number > include JSON whitespace ("ws" ABNF rule from [RFC7159]) after the > number, otherwise the JSON-text may have been truncated. > > That reference to the "ws" rule doesn't get the job done because that > rule allows a match to no characters - it's of the form ws = *( ... ) > where ... is the list of whitespace characters. What's needed here is > a rule of the form vws = 1*( ...) to force there to be at least one > whitespace character, but see the next issue for a better way to deal > with this topic by pulling the appended LF into the sequence parse > instead of the text parse. I'd wanted to not have to list the characters that are considered whitespace. I agree that the "ws" rule is not appropriate though. > [D] I wonder whether the possibility of incomplete texts ought to be > encoded into the parsing rules to directly catch JSON texts that must > be incomplete because the last character is not LF, e.g.: A missing terminating LF is not a problem for strings, arrays, or objects. I seem to recall that we did discuss this. We could require that such texts fail to parse, but perhaps the more important thing is to require common parser behavior as to such truncations. You ABNF proposal is certainly more strict than the one in the I-D. I'm neutral as to whether this form or the one in the I-D (with the ws issue fixed) is better. The stricter form is clearly easier to talk about, therefore preferable, but it will mean discarding texts where only that terminating LF is truncated. One problem we get into with your ABNF is that RFC5234 does not discuss greediness (this came up on the list). But this can be noted (see below). One nice thing about the stricter rules is that we need not discuss top-level numbers (or booleans, or null) with normative text, just note them. > JSON-sequence = *(1*RS (possible-JSON / truncated-JSON / empty-JSON)) > RS = %x1E; "record separator" (RS), see RFC20 > possible-JSON = 1*(not-RS) LF ; attempt to parse as UTF-8-encoded > ; JSON text (see RFC7159) > truncated-JSON = *(not-RS) not-LFRS); truncated, don't attempt > ; to parse as JSON text > empty-JSON = LF ; only the LF appended by the encoder, nothing to parse > > not-RS = %x00-1D / %x1F-FF; any octet other than RS > not-LFRS = %x00-09/ %x1B-1D / %x1F-FF; any octet other than RS or LF > > Note that this won't detect all incomplete JSON texts, because LF is allowed > within a JSON text (and this should be stated). It will if ABNF matching is greedy and possible-JSON is defined as possible-JSON = 1*( 1*(not-RS) LF); ... Advice as to which form to take? > [E] Section 3 - Security Considerations > > Incomplete and malformed JSON texts can be used to attack JSON parsers - > that should be pointed out, as I don't see that in RFC 7159's security > considerations and incomplete texts are a relevant consideration for > this draft. And surely also for RFC7159. Besides requiring that they fail to parse (and the note about incremental parsing), are there any other missing considerations? Ah yes, smuggling of data in sequences where parsers will ignore without warning any octet strings that fail to parse as JSON texts. Proposed text: As usual, parsers must operate on as-good-as untrusted input. This means that parsers must fail gracefully in the face of malicious inputs. Note that incremental parsers can produce partial results and later indicate failure to parse the remainder of a text. Note that texts that fail to parse and are ignored can be used to smuggle data past sequence parsers that don't warn about JSON text failures. > [F] Section 4 - IANA Considerations > > Security considerations: See , > Section 3. > > Interoperability considerations: Described herein. > > Published specification: . > > Applications that use this media type: is likely to support this format>. > > Replace all three instances of the angle bracketed text. The first two > instances should be RFC references (e.g., RFC XXXX) w/a note to the RFC > Editor to insert the number of the RFC when published. The third instance > should be resolved now, or could have an RFC Editor note added indicating > that the author will resolve that during Authors 48 hours. Sure. > Nits/editorial comments: > > idnits didn't like the reference to RFC 20 for ASCII: > > ** Downref: Normative reference to an Unknown state RFC: RFC 20 Is this resolved by now? I can always reference only Unicode. Thanks for your excellent review, Nico -- From nobody Mon Dec 8 20:20:54 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC41A0072; Mon, 8 Dec 2014 20:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67xRY35DK-PE; Mon, 8 Dec 2014 20:20:38 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F1B1A020A; Mon, 8 Dec 2014 20:20:30 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XyCHh-0007vT-98; Mon, 08 Dec 2014 23:20:25 -0500 Date: Mon, 8 Dec 2014 23:20:25 -0500 From: John Cowan To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20141209042024.GC4701@mercury.ccil.org> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> <743CABB8-9BDB-4144-BD96-2D3A79BF0450@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <743CABB8-9BDB-4144-BD96-2D3A79BF0450@frobbit.se> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/wiVJORbhLxBMpwu3T0PpI3MGajE Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 04:20:41 -0000 Patrik Fältström scripsit: > This implies the whole thing is a UTF-8 encoded text that is to be > parsed like this: No, this is a misunderstanding. There is no requirement that the sequence *as a whole* is well-formed UTF-8 text. For example, if the first JSON text is written only in part for whatever reason (system crash, etc.) to a log file, the next process can write a 0x1E byte and carry on. > I.e. the blob, to be compliant with this document, MUST be UTF-8 encoded JSON. The possible-JSON part is either UTF-8 encoded JSON or it's arbitrary junk. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Said Agatha Christie / To E. Philips Oppenheim "Who is this Hemingway? / Who is this Proust? Who is this Vladimir / Whatchamacallum, This neopostrealist / Rabble?" she groused. --George Starbuck, Pith and Vinegar From nobody Mon Dec 8 20:27:39 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369BB1A0167; Mon, 8 Dec 2014 20:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx-p7mBwZySs; Mon, 8 Dec 2014 20:27:29 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD4F1A0072; Mon, 8 Dec 2014 20:27:29 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 6A96136006D; Mon, 8 Dec 2014 20:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=wBiil3JLBUjz5g95CQo/7ZY9b8g=; b=we2WMyFcL1a LgQg2Bkpa/7h4aEzFJ88aU7T44u4VNd0QUwznNJTZ6U7SJ2S+Uh5uDFSFuuYGeFE p57SRbi+lP3V9SsiD+6w82nJV4EQa6xR/o41w61VVC7mbgfufT1C1RrXWyUKFb7j 4+gaM4lpEh7aYO2X0ips1+1HnmT1jURg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id C6F5D36006B; Mon, 8 Dec 2014 20:27:28 -0800 (PST) Date: Mon, 8 Dec 2014 22:27:13 -0600 From: Nico Williams To: John Cowan Message-ID: <20141209042708.GF11221@localhost> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> <743CABB8-9BDB-4144-BD96-2D3A79BF0450@frobbit.se> <20141209042024.GC4701@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20141209042024.GC4701@mercury.ccil.org> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/48Z9Uc8WESKFKJGff2X1afAVaXE Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 04:27:30 -0000 On Mon, Dec 08, 2014 at 11:20:25PM -0500, John Cowan wrote: > Patrik F=E4ltstr=F6m scripsit: > > This implies the whole thing is a UTF-8 encoded text that is to be > > parsed like this: >=20 > No, this is a misunderstanding. There is no requirement that the seque= nce > *as a whole* is well-formed UTF-8 text. For example, if the first JSON > text is written only in part for whatever reason (system crash, etc.) t= o > a log file, the next process can write a 0x1E byte and carry on. Correct. But we're splitting hairs: arbitrary octet strings (but for 0x1E) can be attempted to be parsed, though only those that are valid JSON texts encoded in UTF-8 should be accepted. The encoder, of course, must produce UTF-8. Nico --=20 From nobody Mon Dec 8 20:36:59 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E1E1A0282 for ; Mon, 8 Dec 2014 20:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_avyuFVmg5l for ; Mon, 8 Dec 2014 20:36:57 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8A91A0072 for ; Mon, 8 Dec 2014 20:36:57 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 4BDD827BC061; Mon, 8 Dec 2014 20:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=n9AjGlB2xWP+W2 n9Bjrp7+du/oI=; b=yk18KSzN++fc9+gruKE+dj16sGOrqoE2bfmTZBK5TGfn+0 voV6E1FS8T075ykqFa1ShKBrzeewRfkUP0KHz9D3kYirU1FWljvngSW7ynFqkBlb w12OaZpR4O1aByWFQ3vqFc9DOHKGiNl8GUt8WjOFIqhXXIp0cmO+20FdpSQGs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 037AA27BC05D; Mon, 8 Dec 2014 20:36:56 -0800 (PST) Date: Mon, 8 Dec 2014 22:36:56 -0600 From: Nico Williams To: Pete Resnick Message-ID: <20141209043651.GG11221@localhost> References: <5443F661.5090404@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5443F661.5090404@qti.qualcomm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/DNhFuczFO3SbNe5i8HVuoe6v_ME Cc: "json@ietf.org" Subject: Re: [Json] AD Evaluation of draft-ietf-json-text-sequence-07 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 04:36:58 -0000 On Sun, Oct 19, 2014 at 12:35:29PM -0500, Pete Resnick wrote: > Just a nit here: it seems to me "can" is better than "should" here. > > the parser SHOULD report such failures so that applications may > terminate processing if desired. > > That's not an appropriate use of SHOULD. Reporting errors up the > application stack isn't part of interoperability. Instead, how > about: "however, applications might wish to terminate processing in > this case, so it is useful for parsers to report JSON-text parsing > failures to the application." It might be useful from a security point of view, since incomplete/ invalid texts could otherwise be used to smuggle data past a simple checker that merely parses (but does not re-encode) a sequence. Perhaps this should be worded as "SHOULD provide an option for warning about incomplete or invalid JSON texts in the sequence"? Nico -- From nobody Mon Dec 8 20:38:59 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FB21A0282 for ; Mon, 8 Dec 2014 20:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMOf7jS-TjSh for ; Mon, 8 Dec 2014 20:38:58 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1213C1A0072 for ; Mon, 8 Dec 2014 20:38:58 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id E8D9A1DE05D; Mon, 8 Dec 2014 20:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=VS4DPb/GyzOGcf xUBC5RPGsCI0M=; b=aba+4YltEuLkcT3TALW1EndGp3cqtRdew+Ma0Ouq/Xz13M ce4WZ8FyRidfrrzGcwONCIrGAoGm8d/SksPJxdUbQPWbVyvs2NfzDr/aCjzoY665 psdbBXuN3NgxNmVpkUPGhWwIrAzm+L9VS9xXqkjkDNX5ydYdk+P+KbbLzw2Xo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id 9D8231DE058; Mon, 8 Dec 2014 20:38:57 -0800 (PST) Date: Mon, 8 Dec 2014 22:38:57 -0600 From: Nico Williams To: Pete Resnick Message-ID: <20141209043852.GH11221@localhost> References: <20141027071225.1240.9252.idtracker@ietfa.amsl.com> <546F5A3D.5050006@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546F5A3D.5050006@qti.qualcomm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/R142OyzxPR82Ph6G2YUJ3rgpZnk Cc: "json@ietf.org" Subject: Re: [Json] I-D Action: draft-ietf-json-text-sequence-09.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 04:38:58 -0000 On Fri, Nov 21, 2014 at 09:29:01AM -0600, Pete Resnick wrote: > I've requested Last Call for this document, but do note that the > 2119isms that I thought we agreed to either didn't get changed, or > got changed in the opposite direction: > > 2.1: 2/SHOULD/can > 2.3: s/SHOULD NOT/need not Continuing to parse is kinda the point though... I don't understand why this change would be good. > 2.4: s/MAY/can Would recommending an option to report on incomplete/invalid texts be OK? > You also changed "MUST drop" to "MUST NOT report", which seems > undesirable to me. Ooops, yeah, that's worse. From nobody Mon Dec 8 21:03:47 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B1A1A1B5A; Mon, 8 Dec 2014 21:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfgQxoNppNwO; Mon, 8 Dec 2014 21:03:35 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E411A06E9; Mon, 8 Dec 2014 21:03:34 -0800 (PST) Received: from [172.18.207.145] (w193-11-200-250.eduroam.sunet.se [193.11.200.250]) by mail.frobbit.se (Postfix) with ESMTPSA id 238E023014; Tue, 9 Dec 2014 06:03:33 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_704705D7-D039-4388-A0D3-70944458C9F0"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20141209033708.GB11221@localhost> Date: Tue, 9 Dec 2014 06:03:33 +0100 Message-Id: References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> <20141209033708.GB11221@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/y7ldOWRx0NRdKDH8ng-uGRuQcHo Cc: "ops-dir@ietf.org" , John Cowan , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 05:03:38 -0000 --Apple-Mail=_704705D7-D039-4388-A0D3-70944458C9F0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 9 dec 2014, at 04:37, Nico Williams wrote: > >> and add a suitable reference to UTF-8. > > Oh, eh, RFC7159 lacked such a thing. At least this one should be > non-controversial: RFC3629. (Right? :) Yes, correct. Patrik --Apple-Mail=_704705D7-D039-4388-A0D3-70944458C9F0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUhoKlrMabGguI180RAp+ZAKCKeJP1tGtS2C5dRDyQTBuYjZTWPwCfVIqf cOjLJLdNzNOKP0oXAFA4PNg= =rLOK -----END PGP SIGNATURE----- --Apple-Mail=_704705D7-D039-4388-A0D3-70944458C9F0-- From nobody Mon Dec 8 21:12:09 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1081A00F7; Mon, 8 Dec 2014 21:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMmteyFPOiaA; Mon, 8 Dec 2014 21:11:59 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3991A1B98; Mon, 8 Dec 2014 21:11:39 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 15E0B286059; Mon, 8 Dec 2014 21:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=eUjyO4AjvS/jcYel108DvFQngFc=; b=VLy1/eKmpYw J/jH52PVK3TMJSI/kC4IO60SrQ0r+O9ItZ052YdufQM/X2WMT903IS+BRb8P2fqO wNcjs4YkMhWqIRU9u6IChxIG9gPBtxMxuN7QR38qKs5y+PYGC3f2JrTC9yVOppF4 BHYkZyb9tmU2MlYFTK+Cn8llxTF8pF8Y= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPA id 56F92286058; Mon, 8 Dec 2014 21:11:38 -0800 (PST) Date: Mon, 8 Dec 2014 23:11:37 -0600 From: Nico Williams To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20141209051133.GK11221@localhost> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> <20141209033708.GB11221@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/q0NAyVS93wcD5U098qbtFhCUjIg Cc: "ops-dir@ietf.org" , John Cowan , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 05:12:00 -0000 On Tue, Dec 09, 2014 at 06:03:33AM +0100, Patrik F=E4ltstr=F6m wrote: >=20 > > On 9 dec 2014, at 04:37, Nico Williams wrote: > >=20 > >> and add a suitable reference to UTF-8. > >=20 > > Oh, eh, RFC7159 lacked such a thing. At least this one should be > > non-controversial: RFC3629. (Right? :) >=20 > Yes, correct. I received one off-list response that RFC3629 would be inappropriate because Unicode is a versioned standard. But here we want a UTF, not all of Unicode, and surely UTF-8 is stable. Nico --=20 From nobody Mon Dec 8 23:09:49 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BEB1A006F; Mon, 8 Dec 2014 23:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGEKZVE_wcSF; Mon, 8 Dec 2014 23:09:38 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id F12E01A014C; Mon, 8 Dec 2014 23:09:37 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id B38F132E54B; Tue, 9 Dec 2014 16:08:52 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 34c8_3461_bee77f4a_e870_469d_abe2_401655513995; Tue, 09 Dec 2014 16:08:52 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 05FDBBF544; Tue, 9 Dec 2014 16:08:52 +0900 (JST) Message-ID: <5486A002.4000708@it.aoyama.ac.jp> Date: Tue, 09 Dec 2014 16:08:50 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Nico Williams , =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ry?= =?UTF-8?B?w7Zt?= References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> <20141209033708.GB11221@localhost> <20141209051133.GK11221@localhost> In-Reply-To: <20141209051133.GK11221@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/OGTq5Y5ZeXR9yXDzWpmbvf2T8UM Cc: "ops-dir@ietf.org" , John Cowan , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "Black, David" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 07:09:40 -0000 On 2014/12/09 14:11, Nico Williams wrote: > On Tue, Dec 09, 2014 at 06:03:33AM +0100, Patrik F=C3=A4ltstr=C3=B6m wr= ote: >> >>> On 9 dec 2014, at 04:37, Nico Williams wrote: >>> >>>> and add a suitable reference to UTF-8. >>> >>> Oh, eh, RFC7159 lacked such a thing. At least this one should be >>> non-controversial: RFC3629. (Right? :) >> >> Yes, correct. > > I received one off-list response that RFC3629 would be inappropriate > because Unicode is a versioned standard. But here we want a UTF, not > all of Unicode, and surely UTF-8 is stable. Yes indeed. Regards, Martin. From nobody Mon Dec 8 23:33:04 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FBC1A1AF2; Mon, 8 Dec 2014 23:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB0lZrO6cNlG; Mon, 8 Dec 2014 23:32:58 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975D31A1A5A; Mon, 8 Dec 2014 23:32:58 -0800 (PST) Received: from [IPv6:2a01:3f0:1::54bb:e9b8:bb7a:6625] (unknown [IPv6:2a01:3f0:1:0:54bb:e9b8:bb7a:6625]) by mail.frobbit.se (Postfix) with ESMTPSA id C924222838; Tue, 9 Dec 2014 08:32:56 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BC350A97-B2BF-4AC0-8ECB-C7F5DAFFB649"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20141209042024.GC4701@mercury.ccil.org> Date: Tue, 9 Dec 2014 08:32:15 +0100 Message-Id: <19101548-ACC7-4D5F-9F82-C1BD4736FBC2@frobbit.se> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> <743CABB8-9BDB-4144-BD96-2D3A79BF0450@frobbit.se> <20141209042024.GC4701@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/2-IDD4zibfwf9GDUSi_xtigBfvU Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 07:32:59 -0000 --Apple-Mail=_BC350A97-B2BF-4AC0-8ECB-C7F5DAFFB649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > On 9 dec 2014, at 05:20, John Cowan wrote: >=20 > Patrik F=E4ltstr=F6m scripsit: >=20 >> This implies the whole thing is a UTF-8 encoded text that is to be >> parsed like this: >=20 > No, this is a misunderstanding. There is no requirement that the = sequence > *as a whole* is well-formed UTF-8 text. For example, if the first = JSON > text is written only in part for whatever reason (system crash, etc.) = to > a log file, the next process can write a 0x1E byte and carry on. Ok, fair. Then I think the draft itself should state this in one way or another. = If nothing else the text you wrote here or a version of it is to go into = the security considerations section. Patrik --Apple-Mail=_BC350A97-B2BF-4AC0-8ECB-C7F5DAFFB649 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUhqWBrMabGguI180RArwyAKCRVX66aUCIppLm/ZKYJ6Qg6xu+xgCaAvLp bI/sHWrdmuJxFJzAvxpHND0= =uwLS -----END PGP SIGNATURE----- --Apple-Mail=_BC350A97-B2BF-4AC0-8ECB-C7F5DAFFB649-- From nobody Tue Dec 9 04:46:45 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BFA1A0362; Tue, 9 Dec 2014 04:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUJNgNVni7it; Tue, 9 Dec 2014 04:46:39 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7F81A0248; Tue, 9 Dec 2014 04:46:39 -0800 (PST) Received: from dyn-fg122.sth.netnod.se (dyn-fg122.sth.netnod.se [77.72.226.122]) by mail.frobbit.se (Postfix) with ESMTPSA id 91A77230BC; Tue, 9 Dec 2014 13:46:37 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2481DB87-72C7-49B4-A484-F1580CDE074B"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20141209051133.GK11221@localhost> Date: Tue, 9 Dec 2014 13:46:36 +0100 Message-Id: <5648AF40-5E6E-45EB-B65D-3EA01EA9F24E@frobbit.se> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> <20141209033708.GB11221@localhost> <20141209051133.GK11221@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/HHFpp8OzkS4In69WYnYCh8YMKTE Cc: "ops-dir@ietf.org" , John Cowan , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "Black, David" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 12:46:41 -0000 --Apple-Mail=_2481DB87-72C7-49B4-A484-F1580CDE074B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > On 9 dec 2014, at 06:11, Nico Williams wrote: >=20 > I received one off-list response that RFC3629 would be inappropriate > because Unicode is a versioned standard. But here we want a UTF, not > all of Unicode, and surely UTF-8 is stable. RFC3629 has no limitation based on Unicode version. The limitation is = that it only defines UTF-8 for the UTF-16 accessible range, = U+0000..U+10FFFF. Patrik --Apple-Mail=_2481DB87-72C7-49B4-A484-F1580CDE074B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUhu8trMabGguI180RAj2AAJ4oC+HT/ux2YnrTF5kw3SRv9VMKFACdEbLO zFi9i0aP3oCSBK89IPselSM= =tDC4 -----END PGP SIGNATURE----- --Apple-Mail=_2481DB87-72C7-49B4-A484-F1580CDE074B-- From nobody Tue Dec 9 08:41:40 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7178D1A888F; Tue, 9 Dec 2014 08:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zd4W4eDJQLhH; Tue, 9 Dec 2014 08:41:34 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CB91A8771; Tue, 9 Dec 2014 08:41:34 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB9GfQhr000700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 11:41:30 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sB9GfQhr000700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418143290; bh=giCA+1hbWXOuFGzEJkaHqhXQ5/4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=TTttxe/GVOIdWijUZ3AY5g+Ijefzx8U/usSkJS9Ayj3Mk8/d+1vNbyAlJ+wRHEoCf +1G7yCukxN1NhpQOGtjMan/MuJ8IORSPGAZIPoaV8CPImjiMEXfGQzJSnCDBTbRS34 S3dJNJ9i44Kl/XT36/Qo3iDL1G+qQ/4dlGHioLpo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sB9GfQhr000700 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd56.lss.emc.com (RSA Interceptor); Tue, 9 Dec 2014 11:40:27 -0500 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB9GfDhc028857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 11:41:14 -0500 Received: from MXHUB209.corp.emc.com (10.253.68.35) by mxhub31.corp.emc.com (128.222.70.171) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 9 Dec 2014 11:41:13 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB209.corp.emc.com ([10.253.68.35]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 11:41:13 -0500 From: "Black, David" To: Nico Williams Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 Thread-Index: AdAQmuBgzIEwbXsVSl+UfPcrbL3cqwC9mNEAAAwOi4A= Date: Tue, 9 Dec 2014 16:41:12 +0000 Message-ID: References: <20141209041937.GD11221@localhost> In-Reply-To: <20141209041937.GD11221@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: http://mailarchive.ietf.org/arch/msg/json/MHUS_LWmDHoVZoe_uLGrU-uNUHg Cc: "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "ops-dir@ietf.org" , "Black, David" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 16:41:38 -0000 Nico, Thanks for the comprehensive response. I've excerpted a few things for further comment - I'm fine with the proposed actions for anything not mentioned here. [A] JSON text parse failures > > If parsing of such an octet string as a JSON text fails, and the > > octet string is followed by an RS octet, the parser > > SHOULD nonetheless skip ahead to that RS octet and continue parsing > > the remainder of the sequence from there. >=20 > That's a weird way of saying that, wherever the JSON text parse fails, > the sequence parser should then seek forward until the next RS-valued > byte. But it works for me; I'll take it. Your alternative wording "whenever the JSON text parse fails, ..." is fine. [D] Truncation > A missing terminating LF is not a problem for strings, arrays, or > objects. I seem to recall that we did discuss this. We could require > that such texts fail to parse, but perhaps the more important thing is > to require common parser behavior as to such truncations. >=20 > You ABNF proposal is certainly more strict than the one in the I-D. I'm > neutral as to whether this form or the one in the I-D (with the ws issue > fixed) is better. The stricter form is clearly easier to talk about, > therefore preferable, but it will mean discarding texts where only that > terminating LF is truncated. I concur with both of the above paragraphs - my preference is to detect incomplete JSON texts at the sequence level via the missing LF rather than special-casing numbers and relying on failed JSON parses for everything els= e. In general, earlier detection of errors increases the options for dealing with them. Once the incomplete text is detected, a JSON parse could be attempted, with the JSON parser knowing that the text is incomplete (e.g., text may fail to parse, a number at the end of the text must not be produced as an incremental parse result). I'll defer to the WG on whether/how to expand the decoder ABNF to better detect incomplete texts and how to deal with any incomplete texts that are detected. As for RFC 20 ... > > Nits/editorial comments: > > > > idnits didn't like the reference to RFC 20 for ASCII: > > > > ** Downref: Normative reference to an Unknown state RFC: RFC 20 >=20 > Is this resolved by now? I can always reference only Unicode. Keep the RFC 20 reference - I have no problem with it. Moreover, as a result of all the hubbub around this nit, the IESG has issued a Last Call to reclassify RFC 20 as an Internet Standard ... so that this never arises again ... http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13546.html Thanks, --David > -----Original Message----- > From: Nico Williams [mailto:nico@cryptonector.com] > Sent: Monday, December 08, 2014 11:20 PM > To: Black, David > Cc: General Area Review Team (gen-art@ietf.org); ops-dir@ietf.org; > ietf@ietf.org; json@ietf.org > Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-= 09 >=20 > On Fri, Dec 05, 2014 at 02:51:04PM +0000, Black, David wrote: > > This is a combined Gen-ART and OPS-Dir review. Boilerplate for both fo= llows > ... >=20 > Thanks you. >=20 > > Minor issues: > > > > [A] Section 2.1: > > > > If parsing of such an octet string as a JSON text fails, the parser > > SHOULD nonetheless continue parsing the remainder of the sequence. > > > > That's not quite right - there are two levels of parsing, JSON > > sequence parsing and JSON text parsing of each text in the sequence, > > both of which might be implemented in a single-pass parser. For such a= n > > implementation, the above sentence could be (mis-)read to imply that th= e > > JSON text parse should resume from the point at which it failed, which > > would be silly (although I've seen heroic PL/1 parsers do exactly that)= . > > Instead, the parse needs to skip ahead to the next RS, ignoring the res= t > > of the JSON text that failed to parse. I suggest: >=20 > Good point. >=20 > > If parsing of such an octet string as a JSON text fails, and the > > octet string is followed by an RS octet, the parser > > SHOULD nonetheless skip ahead to that RS octet and continue parsing > > the remainder of the sequence from there. >=20 > That's a weird way of saying that, wherever the JSON text parse fails, > the sequence parser should then seek forward until the next RS-valued > byte. But it works for me; I'll take it. >=20 > > [B] Section 2.3: > > > > Is incremental parsing of a JSON text within a sequence allowed, or > > is the parser required to not produce any results until the parse of > > the entire text is successful? I'd expect that incremental parsing > > is ok (so results may be produced from a text that ultimately fails > > to parse), and I think that's worth stating. >=20 > It's permitted, of course, with the caveat that all incremental parsers > have: the parse can ultimately fail. I'll add this note: >=20 > Incremental JSON text parsers may be used, though of course failure > to parse a given text may result after first producing some > incremental parse results. >=20 > to section 2.3. >=20 > > [C] Section 2.4: > > > > Parsers MUST check that any JSON texts that are a top-level number > > include JSON whitespace ("ws" ABNF rule from [RFC7159]) after the > > number, otherwise the JSON-text may have been truncated. > > > > That reference to the "ws" rule doesn't get the job done because that > > rule allows a match to no characters - it's of the form ws =3D *( ... ) > > where ... is the list of whitespace characters. What's needed here is > > a rule of the form vws =3D 1*( ...) to force there to be at least one > > whitespace character, but see the next issue for a better way to deal > > with this topic by pulling the appended LF into the sequence parse > > instead of the text parse. >=20 > I'd wanted to not have to list the characters that are considered > whitespace. I agree that the "ws" rule is not appropriate though. >=20 > > [D] I wonder whether the possibility of incomplete texts ought to be > > encoded into the parsing rules to directly catch JSON texts that must > > be incomplete because the last character is not LF, e.g.: >=20 > A missing terminating LF is not a problem for strings, arrays, or > objects. I seem to recall that we did discuss this. We could require > that such texts fail to parse, but perhaps the more important thing is > to require common parser behavior as to such truncations. >=20 > You ABNF proposal is certainly more strict than the one in the I-D. I'm > neutral as to whether this form or the one in the I-D (with the ws issue > fixed) is better. The stricter form is clearly easier to talk about, > therefore preferable, but it will mean discarding texts where only that > terminating LF is truncated. >=20 > One problem we get into with your ABNF is that RFC5234 does not discuss > greediness (this came up on the list). But this can be noted (see > below). >=20 > One nice thing about the stricter rules is that we need not discuss > top-level numbers (or booleans, or null) with normative text, just note > them. >=20 > > JSON-sequence =3D *(1*RS (possible-JSON / truncated-JSON / empty-J= SON)) > > RS =3D %x1E; "record separator" (RS), see RFC20 > > possible-JSON =3D 1*(not-RS) LF ; attempt to parse as UTF-8-encode= d > > ; JSON text (see RFC7159) > > truncated-JSON =3D *(not-RS) not-LFRS); truncated, don't attempt > > ; to parse as JSON text > > empty-JSON =3D LF ; only the LF appended by the encoder, nothing t= o parse > > > > not-RS =3D %x00-1D / %x1F-FF; any octet other than RS > > not-LFRS =3D %x00-09/ %x1B-1D / %x1F-FF; any octet other than RS o= r LF > > > > Note that this won't detect all incomplete JSON texts, because LF is al= lowed > > within a JSON text (and this should be stated). >=20 > It will if ABNF matching is greedy and possible-JSON is defined as >=20 > possible-JSON =3D 1*( 1*(not-RS) LF); ... >=20 > Advice as to which form to take? >=20 > > [E] Section 3 - Security Considerations > > > > Incomplete and malformed JSON texts can be used to attack JSON parsers = - > > that should be pointed out, as I don't see that in RFC 7159's security > > considerations and incomplete texts are a relevant consideration for > > this draft. >=20 > And surely also for RFC7159. Besides requiring that they fail to parse > (and the note about incremental parsing), are there any other missing > considerations? Ah yes, smuggling of data in sequences where parsers > will ignore without warning any octet strings that fail to parse as JSON > texts. >=20 > Proposed text: >=20 > As usual, parsers must operate on as-good-as untrusted input. This > means that parsers must fail gracefully in the face of malicious > inputs. Note that incremental parsers can produce partial results and > later indicate failure to parse the remainder of a text. Note that > texts that fail to parse and are ignored can be used to smuggle data > past sequence parsers that don't warn about JSON text failures. >=20 > > [F] Section 4 - IANA Considerations > > > > Security considerations: See , > > Section 3. > > > > Interoperability considerations: Described herein. > > > > Published specification: . > > > > Applications that use this media type: > is likely to support this format>. > > > > Replace all three instances of the angle bracketed text. The first two > > instances should be RFC references (e.g., RFC XXXX) w/a note to the RFC > > Editor to insert the number of the RFC when published. The third insta= nce > > should be resolved now, or could have an RFC Editor note added indicati= ng > > that the author will resolve that during Authors 48 hours. >=20 > Sure. >=20 > > Nits/editorial comments: > > > > idnits didn't like the reference to RFC 20 for ASCII: > > > > ** Downref: Normative reference to an Unknown state RFC: RFC 20 >=20 > Is this resolved by now? I can always reference only Unicode. >=20 > Thanks for your excellent review, >=20 > Nico > -- From nobody Tue Dec 9 09:18:45 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AB41A89A4; Tue, 9 Dec 2014 09:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNmQZOawagkm; Tue, 9 Dec 2014 09:18:42 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB381A8984; Tue, 9 Dec 2014 09:17:30 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 3927F20046B15; Tue, 9 Dec 2014 09:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=4pfVbFRe6rXtQ1 hTscWy8uJnYcY=; b=K1knMO/JW/yJEKIhl2Nlv9H+/uACtSw72vLz2yEDEdhUZn ohzTPdpIORzXoSy3uXcMpoKReoQ9vUajKfXeCk1AKVJUd6oGrANxe1DWH5hqYrxR O9IT4q8xEmlQwirMyIcv63p/wsipCCGODbJPDI9WXFa0Qi2zi3yM9Es4JRLV8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPA id B05792004692F; Tue, 9 Dec 2014 09:17:29 -0800 (PST) Date: Tue, 9 Dec 2014 11:17:29 -0600 From: Nico Williams To: "Black, David" Message-ID: <20141209171724.GB12979@localhost> References: <20141209041937.GD11221@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/87exEu5IVIuGkZyvgOR_Qyro45Y Cc: "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "ops-dir@ietf.org" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 17:18:43 -0000 On Tue, Dec 09, 2014 at 04:41:12PM +0000, Black, David wrote: > [A] JSON text parse failures > > [...] > > Your alternative wording "whenever the JSON text parse fails, ..." is fine. OK. > [D] Truncation > > > A missing terminating LF is not a problem for strings, arrays, or > > objects. I seem to recall that we did discuss this. We could require > > that such texts fail to parse, but perhaps the more important thing is > > to require common parser behavior as to such truncations. > > > > You ABNF proposal is certainly more strict than the one in the I-D. I'm > > neutral as to whether this form or the one in the I-D (with the ws issue > > fixed) is better. The stricter form is clearly easier to talk about, > > therefore preferable, but it will mean discarding texts where only that > > terminating LF is truncated. > > I concur with both of the above paragraphs - my preference is to detect > incomplete JSON texts at the sequence level via the missing LF rather than > special-casing numbers and relying on failed JSON parses for everything else. > In general, earlier detection of errors increases the options for dealing > with them. And, of course, a streaming/incremental parsers might well output all there is to output when only the last LF is missing but the top-level value was properly delimited anyways. So it's kinda difficult to get a fool-proof requirement that the trailing LF must be present. Your review comments included adding this note about incremental parsing. There's a conflict here between the two comments that had not been apparent to me last night. I now think that fixing the ws problem is the best way forward. > Once the incomplete text is detected, a JSON parse could be attempted, > with the JSON parser knowing that the text is incomplete (e.g., text > may fail to parse, a number at the end of the text must not be produced > as an incremental parse result). That's so for non-incremental parsers. (Or when buffering the complete text instead of handling incrementally, even though one has an incremental parser.) Consider one implementation I'm familiar with. Its JSON text parser is incremental (but not streaming), so it produces outputs with no need for extra whitespace when the input text is a string, array, or object, but for top-level numbers, booleans, and null, it needs to either read one more byte or reach EOF before it will output them. So I think we really do need to say something about top-level numbers (and true, false, and null), namely: that they must be delimited by whitespace, that '1234' is not a valid sequence element because the number may have been truncated. (Ditto 'true', since the intended text could have been 'trueish', which is invalid of course, but still.) > As for RFC 20 ... > > > Is this resolved by now? I can always reference only Unicode. > > Keep the RFC 20 reference - I have no problem with it. Moreover, as a > result of all the hubbub around this nit, the IESG has issued a Last Call > to reclassify RFC 20 as an Internet Standard ... so that this never > arises again ... Yes, I noticed. I expect the IETF LC will pass for that. Thanks, Nico -- From nobody Tue Dec 9 10:50:11 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F6D1A87A4; Tue, 9 Dec 2014 10:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFQgaYrY1dpu; Tue, 9 Dec 2014 10:50:02 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5355C1A87A0; Tue, 9 Dec 2014 10:50:02 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB9Inug3007160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 13:49:57 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sB9Inug3007160 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418150998; bh=bpDpvap9x9a4I4NHz70/L1Odr9E=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Pocdg/P6pIddxl4Qk0ekoPjuANt3OsKiScztQVe+Je8W/1m77ZbAohvUgZ0MvJmSb Tij/06xZsXNmMSRLkEgyR7LWWJv/6fT42GFdScvo4H+do6twW30/ZHdPlqeX1Ure11 a1BmTJtarXYEVROeIyJBVnGAnlgOWfke1X1tWVFA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sB9Inug3007160 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor); Tue, 9 Dec 2014 13:49:38 -0500 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB9InbDe029478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 13:49:37 -0500 Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub22.corp.emc.com (128.222.70.134) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 9 Dec 2014 13:49:37 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB206.corp.emc.com ([10.253.68.32]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 13:49:36 -0500 From: "Black, David" To: Nico Williams Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 Thread-Index: AdAQmuBgzIEwbXsVSl+UfPcrbL3cqwC9mNEAAAwOi4AADxtigAAJ/Ceg Date: Tue, 9 Dec 2014 18:49:35 +0000 Message-ID: References: <20141209041937.GD11221@localhost> <20141209171724.GB12979@localhost> In-Reply-To: <20141209171724.GB12979@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/json/-SO2T_kbPiCo-0AaCnrvoKOkHYk Cc: "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "ops-dir@ietf.org" , "Black, David" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 18:50:05 -0000 > So I think we really do need to say something about top-level numbers > (and true, false, and null), namely: that they must be delimited by > whitespace, that '1234' is not a valid sequence element because > the number may have been truncated. (Ditto 'true', since the > intended text could have been 'trueish', which is invalid of course, but > still.) That would be more robust, as then all JSON texts in a sequence have delimiters and absence of the closing delimiter clearly indicates truncation. Thanks, --David > -----Original Message----- > From: Nico Williams [mailto:nico@cryptonector.com] > Sent: Tuesday, December 09, 2014 12:17 PM > To: Black, David > Cc: General Area Review Team (gen-art@ietf.org); ops-dir@ietf.org; > ietf@ietf.org; json@ietf.org > Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-= 09 >=20 > On Tue, Dec 09, 2014 at 04:41:12PM +0000, Black, David wrote: > > [A] JSON text parse failures > > > [...] > > > > Your alternative wording "whenever the JSON text parse fails, ..." is f= ine. >=20 > OK. >=20 > > [D] Truncation > > > > > A missing terminating LF is not a problem for strings, arrays, or > > > objects. I seem to recall that we did discuss this. We could requir= e > > > that such texts fail to parse, but perhaps the more important thing i= s > > > to require common parser behavior as to such truncations. > > > > > > You ABNF proposal is certainly more strict than the one in the I-D. = I'm > > > neutral as to whether this form or the one in the I-D (with the ws is= sue > > > fixed) is better. The stricter form is clearly easier to talk about, > > > therefore preferable, but it will mean discarding texts where only th= at > > > terminating LF is truncated. > > > > I concur with both of the above paragraphs - my preference is to detect > > incomplete JSON texts at the sequence level via the missing LF rather t= han > > special-casing numbers and relying on failed JSON parses for everything > else. > > In general, earlier detection of errors increases the options for deali= ng > > with them. >=20 > And, of course, a streaming/incremental parsers might well output all > there is to output when only the last LF is missing but the top-level > value was properly delimited anyways. So it's kinda difficult to get a > fool-proof requirement that the trailing LF must be present. >=20 > Your review comments included adding this note about incremental > parsing. There's a conflict here between the two comments that had not > been apparent to me last night. I now think that fixing the ws problem > is the best way forward. >=20 > > Once the incomplete text is detected, a JSON parse could be attempted, > > with the JSON parser knowing that the text is incomplete (e.g., text > > may fail to parse, a number at the end of the text must not be produced > > as an incremental parse result). >=20 > That's so for non-incremental parsers. (Or when buffering the complete > text instead of handling incrementally, even though one has an > incremental parser.) >=20 > Consider one implementation I'm familiar with. Its JSON text parser is > incremental (but not streaming), so it produces outputs with no need for > extra whitespace when the input text is a string, array, or object, but > for top-level numbers, booleans, and null, it needs to either read one > more byte or reach EOF before it will output them. >=20 > So I think we really do need to say something about top-level numbers > (and true, false, and null), namely: that they must be delimited by > whitespace, that '1234' is not a valid sequence element because > the number may have been truncated. (Ditto 'true', since the > intended text could have been 'trueish', which is invalid of course, but > still.) >=20 > > As for RFC 20 ... > > > > > Is this resolved by now? I can always reference only Unicode. > > > > Keep the RFC 20 reference - I have no problem with it. Moreover, as a > > result of all the hubbub around this nit, the IESG has issued a Last Ca= ll > > to reclassify RFC 20 as an Internet Standard ... so that this never > > arises again ... >=20 > Yes, I noticed. I expect the IETF LC will pass for that. >=20 > Thanks, >=20 > Nico > -- From nobody Tue Dec 9 16:49:38 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A8B1A036E; Tue, 9 Dec 2014 16:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V64SvlCabmRD; Tue, 9 Dec 2014 16:49:31 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9841A0250; Tue, 9 Dec 2014 16:49:31 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 2EF7654073; Tue, 9 Dec 2014 16:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=QXU4anaun3buWh TGG/Zp2prDsHE=; b=SbqLjCTjKtd2wAONvEmgOAmJ2dbhnekyDgrfE2R9jdUnhj 7mws2X33fKzJPpAAoYQbVmieraJGqGXEa+OQ1OoJesQ7tXitj033Za2I+Oonf4nA lSTVQeiNnrOpXEd+gxFMfgRlvfodkeNFqlZMWA8eVVPlGBHQ/9ekHYv9MbqSU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id ADF9354058; Tue, 9 Dec 2014 16:49:30 -0800 (PST) Date: Tue, 9 Dec 2014 18:49:30 -0600 From: Nico Williams To: "Black, David" Message-ID: <20141210004925.GQ12979@localhost> References: <20141209041937.GD11221@localhost> <20141209171724.GB12979@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/J1g1VBewV9KBGtxQCy1LXcQ4vnc Cc: "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "ops-dir@ietf.org" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 00:49:32 -0000 On Tue, Dec 09, 2014 at 06:49:35PM +0000, Black, David wrote: > > So I think we really do need to say something about top-level numbers > > (and true, false, and null), namely: that they must be delimited by > > whitespace, that '1234' is not a valid sequence element because > > the number may have been truncated. (Ditto 'true', since the > > intended text could have been 'trueish', which is invalid of course, but > > still.) > > That would be more robust, as then all JSON texts in a sequence have > delimiters and absence of the closing delimiter clearly indicates > truncation. OK. New section 2.4 text: While objects, arrays, and strings are self-delimited in JSON texts, numbers, and the values 'true', 'false', and 'null' are not. Only whitespace can delimit the latter four kinds of values. Parsers MUST check that any JSON texts that are a top-level number, or which might be 'true', 'false', or 'null' include JSON whitespace (at least one byte matching the "ws" ABNF rule from RFC7159) after that value, otherwise the JSON-text may have been truncated. Note that the LF following each JSON text matches the "ws" ABNF rule. Parsers MUST drop JSON-text sequence elements consisting of non-self-delimited top-level values that may have been truncated (that are not delimited by whitespace). Parsers can report such texts as warnings (including, optionally, the parsed text and/or the original octet string). For example, '123' might have been intended to carry the top-level number 123.4, but must have been truncated. Similarly, 'true' might have been intended to carry the invalid text 'trueish'. 'truefales' is not two top-level values, 'true', and 'false'; it is simply not a valid JSON text. This is the only place where the ws rule comes up, so merely saying "at least one byte matching" it should suffice. I'm also adding this following the above, based on your comment about incremental parsers: Implementations may produce a value when parsing '"foo"' because their JSON text parser might be able to consume bytes incrementally, and since the JSON text in this case is a self-delimiting top-level value, the parser can produce the result without consuming an additional byte. Such implementations should skip to the next RS byte, possibly reporting any intervening non-whitespace bytes. (yes, I think this should be a 'should', not a 'SHOULD'). Nico -- From nobody Tue Dec 9 17:06:26 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967571A0162; Tue, 9 Dec 2014 17:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIXMibxzigcY; Tue, 9 Dec 2014 17:06:19 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDDD1A0366; Tue, 9 Dec 2014 17:06:15 -0800 (PST) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id EC9D220047B8D; Tue, 9 Dec 2014 17:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=zA5U7/mm8iEKj5 qb+KNwk8uwssk=; b=nEFGFzmCeG7q1sUTrsQ4A4MJJRFCCo1tNKOUmkUUDpmgbF Cz7iyROUMi11msnVHGMPAWBzJz002rXaTVnAwsoA3Hoy9Fp1uOfVAvc3OCi8Dxqz rLzc60kONRFkT5khjtamA/w5CGMvCgzhbae68r1yeksmocWwdKHFTUddVhm/s= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id 6C9CE20047B89; Tue, 9 Dec 2014 17:06:14 -0800 (PST) Date: Tue, 9 Dec 2014 19:06:13 -0600 From: Nico Williams To: Matthew Kerwin Message-ID: <20141210010608.GR12979@localhost> References: <20141209041937.GD11221@localhost> <20141209171724.GB12979@localhost> <20141210004925.GQ12979@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/70ZCq-MlP4UGNG01dkR0zlHFbKU Cc: "General Area Review Team \(gen-art@ietf.org\)" , "ietf@ietf.org" , "ops-dir@ietf.org" , "json@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 01:06:20 -0000 On Wed, Dec 10, 2014 at 10:52:22AM +1000, Matthew Kerwin wrote: > On 10 December 2014 at 10:49, Nico Williams wrote: > > (yes, I think this should be a 'should', not a 'SHOULD'). > > Not an 'ought to'? I'll take that. From nobody Tue Dec 9 18:39:23 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BDA1A036E; Tue, 9 Dec 2014 16:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Nw-56jyKOSj; Tue, 9 Dec 2014 16:52:23 -0800 (PST) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E453A1A0250; Tue, 9 Dec 2014 16:52:22 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id i8so1406558qcq.39 for ; Tue, 09 Dec 2014 16:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IAr4DihUJ7AQrV/5HSVg4ha6SUxzhH8qEGMQgn5DLnA=; b=guf66gJwUy2/udDBxNULC2MWlVR4hvG7i+uHjRbwoox+buzP0K5NeOP9Ih6k/Cu1c+ mW6uV3ncZWqXelWdKtIiNC//QUZAHiamCySacXe9Kkwy50e5GXGDuHojHUXybtPazKFV R2xp5Xh1HYDxSS6UuVtcRyCKXeZNqP93c4A7/vjEbCac+w/Gbe8CQszs9GK91jTk5iDG Cktf7aAzUaXEKyQSfo39i7teL5Ib43QBTFlkKJuU0BcTQEJKwPlaIR6++YxvpXKxnuf8 r9HJu3cObOLLnuiAwtV/gTrukt1FxrlvffuzvgApCKbiqBn6CnfNNoubY/Qk7/ZPd58P Lpsw== MIME-Version: 1.0 X-Received: by 10.140.106.35 with SMTP id d32mr2864633qgf.48.1418172742173; Tue, 09 Dec 2014 16:52:22 -0800 (PST) Sender: phluid61@gmail.com Received: by 10.140.86.163 with HTTP; Tue, 9 Dec 2014 16:52:22 -0800 (PST) In-Reply-To: <20141210004925.GQ12979@localhost> References: <20141209041937.GD11221@localhost> <20141209171724.GB12979@localhost> <20141210004925.GQ12979@localhost> Date: Wed, 10 Dec 2014 10:52:22 +1000 X-Google-Sender-Auth: koIG0QtbE1HIGVuTC4AVB7CRnVc Message-ID: From: Matthew Kerwin To: Nico Williams Content-Type: multipart/alternative; boundary=001a113b45588709380509d21217 Archived-At: http://mailarchive.ietf.org/arch/msg/json/lPzChLu3CoGdW1anOTXvUvxFgao X-Mailman-Approved-At: Tue, 09 Dec 2014 18:39:21 -0800 Cc: "General Area Review Team \(gen-art@ietf.org\)" , "ietf@ietf.org" , "ops-dir@ietf.org" , "json@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 00:52:25 -0000 --001a113b45588709380509d21217 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10 December 2014 at 10:49, Nico Williams wrote: > > (yes, I think this should be a 'should', not a 'SHOULD'). > > =E2=80=8BNot an 'ought to'?=E2=80=8B --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113b45588709380509d21217 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113b45588709380509d21217-- From nobody Tue Dec 9 18:53:12 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DCC1A88BF; Tue, 9 Dec 2014 18:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyYz2hnkMb9V; Tue, 9 Dec 2014 18:53:01 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E0D1A1AA2; Tue, 9 Dec 2014 18:53:00 -0800 (PST) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBA2quPA015199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 21:52:57 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sBA2quPA015199 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418179977; bh=krAw9SrMi3DtJ1IgEIGa0pJt1/E=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bMFqKYCXDGkKkYOHeemX9yfuIl8jPyM22aA/lUG5ecoVgVTjZdCPq9oYwDr0qfWTQ lkoClmVGHz94PZHfYxEsM0P/y3EaOKe5RcWjOgJm3KcunQc3J/1dRTGxFb0B1rY4Ul 9d/l6yAJrWOFzHLWxn/TaR8zI86HfU74RYWtDWHM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sBA2quPA015199 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 9 Dec 2014 21:52:36 -0500 Received: from mxhub38.corp.emc.com (mxhub38.corp.emc.com [128.222.70.105]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBA2qZnU007446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 21:52:36 -0500 Received: from MXHUB210.corp.emc.com (10.253.68.36) by mxhub38.corp.emc.com (128.222.70.105) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 9 Dec 2014 21:52:35 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB210.corp.emc.com ([10.253.68.36]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 21:52:35 -0500 From: "Black, David" To: Nico Williams Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 Thread-Index: AdAQmuBgzIEwbXsVSl+UfPcrbL3cqwC9mNEAAAwOi4AADxtigAAJ/CegAAXNMQAABlY1sA== Date: Wed, 10 Dec 2014 02:52:34 +0000 Message-ID: References: <20141209041937.GD11221@localhost> <20141209171724.GB12979@localhost> <20141210004925.GQ12979@localhost> In-Reply-To: <20141210004925.GQ12979@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.61.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/json/pun7rcu1OEeOc7xkaschKlJD-jo Cc: "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "ops-dir@ietf.org" , "Black, David" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 02:53:03 -0000 This looks good, and the explanation of what's going on (numbers, 'true', 'false' and 'null' lack delimiters) is a useful addition. One small nit: 'truefales' is not two top-level values, 'true', and 'false'; it is simply not a valid JSON text. truefales -> truefalse Thanks, --David =20 > On Tue, Dec 09, 2014 at 06:49:35PM +0000, Black, David wrote: > > > So I think we really do need to say something about top-level numbers > > > (and true, false, and null), namely: that they must be delimited by > > > whitespace, that '1234' is not a valid sequence element becau= se > > > the number may have been truncated. (Ditto 'true', since the > > > intended text could have been 'trueish', which is invalid of course, = but > > > still.) > > > > That would be more robust, as then all JSON texts in a sequence have > > delimiters and absence of the closing delimiter clearly indicates > > truncation. >=20 > OK. >=20 > New section 2.4 text: >=20 > While objects, arrays, and strings are self-delimited in JSON texts, > numbers, and the values 'true', 'false', and 'null' are not. Only > whitespace can delimit the latter four kinds of values. >=20 > Parsers MUST check that any JSON texts that are a top-level number, > or which might be 'true', 'false', or 'null' include JSON whitespace > (at least one byte matching the "ws" ABNF rule from RFC7159) after > that value, otherwise the JSON-text may have been truncated. Note > that the LF following each JSON text matches the "ws" ABNF rule. >=20 > Parsers MUST drop JSON-text sequence elements consisting of > non-self-delimited top-level values that may have been truncated > (that are not delimited by whitespace). Parsers can report such > texts as warnings (including, optionally, the parsed text and/or the > original octet string). >=20 > For example, '123' might have been intended to carry the > top-level number 123.4, but must have been truncated. Similarly, > 'true' might have been intended to carry the invalid text > 'trueish'. 'truefales' is not two top-level values, 'true', > and 'false'; it is simply not a valid JSON text. >=20 > This is the only place where the ws rule comes up, so merely saying "at > least one byte matching" it should suffice. >=20 > I'm also adding this following the above, based on your comment about > incremental parsers: >=20 > Implementations may produce a value when parsing '"foo"' > because their JSON text parser might be able to consume bytes > incrementally, and since the JSON text in this case is a > self-delimiting top-level value, the parser can produce the result > without consuming an additional byte. Such implementations should > skip to the next RS byte, possibly reporting any intervening > non-whitespace bytes. >=20 > (yes, I think this should be a 'should', not a 'SHOULD'). >=20 > Nico > -- From nobody Tue Dec 9 21:41:00 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902DF1A020A; Tue, 9 Dec 2014 21:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ImyqbffazqV; Tue, 9 Dec 2014 21:40:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0289E1A1B87; Tue, 9 Dec 2014 21:40:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210054053.3923.27217.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 21:40:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/cVDT9YNHurePJChV5c-rDk1pbC0 Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-text-sequence-10.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 05:40:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JavaScript Object Notation Working Group of the IETF. Title : JavaScript Object Notation (JSON) Text Sequences Author : Nicolas Williams Filename : draft-ietf-json-text-sequence-10.txt Pages : 11 Date : 2014-12-09 Abstract: This document describes the JSON text sequence format and associated media type, "application/json-seq". A JSON text sequence consists of any number of JSON texts, each prefix by an Record Separator (U+001E), and each ending with a newline character (U+000A). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-text-sequence-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 9 21:41:03 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FA81A1B8A for ; Tue, 9 Dec 2014 21:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZaYfc_EoTNO; Tue, 9 Dec 2014 21:40:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3989C1A1B8C; Tue, 9 Dec 2014 21:40:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210054053.3923.54191.idtracker@ietfa.amsl.com> Date: Tue, 09 Dec 2014 21:40:53 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/qvh3pZ7M_6TbHqFCYUnQu_MrZFA Subject: [Json] New Version Notification - draft-ietf-json-text-sequence-10.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 05:40:59 -0000 A new version (-10) has been submitted for draft-ietf-json-text-sequence: http://www.ietf.org/internet-drafts/draft-ietf-json-text-sequence-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Dec 10 07:51:52 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16ED91A700D; Wed, 10 Dec 2014 07:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUaJbUy7Qh0l; Wed, 10 Dec 2014 07:51:44 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963DA1A6F62; Wed, 10 Dec 2014 07:51:22 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBAFpHCr021357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2014 10:51:18 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sBAFpHCr021357 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418226679; bh=kfVk5a74dQv3bvjWg9zQ1XefvVI=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=iqgvmIvO3lbyeNnmMrz0Izzqyjob3s9MHG2x53REIPkrBK8ioDD5pyfzXYr5KjSAv BWdaFHksCbWyXnB/5K/GhjYv/Q/k9u8JlhkGd7AGU+C0FkKDU89oC2P877gmJrPDYs mEOZEtmHbPz8aNsrxq2DZD3Oe377TnyXGZJk2/xc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sBAFpHCr021357 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd51.lss.emc.com (RSA Interceptor); Wed, 10 Dec 2014 10:51:07 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBAFp6Nq009661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Dec 2014 10:51:06 -0500 Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub13.corp.emc.com (128.222.70.234) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 10 Dec 2014 10:51:06 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB206.corp.emc.com ([10.253.68.32]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 10:51:05 -0500 From: "Black, David" To: "nico@cryptonector.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 Thread-Index: AdAUkROzD04JM08VQjyyKTYMqQun9A== Date: Wed, 10 Dec 2014 15:51:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.76] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: GIS Solicitation, DLM_1, public, Resumes Archived-At: http://mailarchive.ietf.org/arch/msg/json/H61UTTtBdXAte1t9KnBCtgHyA6U Cc: "Black, David" , "ietf@ietf.org" , "json@ietf.org" Subject: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 15:51:48 -0000 The -10 version of this draft resolves items [A]-[E] from the Gen-ART and OPS-Dir review of -09, and the IESG is in the process of resolving the (silly) idnits complaint about RFC 20 being a possible downref. For item [D], a different approach was taken instead of modifying the ABNF - the resulting new Section 2.4 is a definite improvement to the draft, and is significantly clearer than the modified ABNF would have been. Nicely done. Item [F] about the text in the IANA Considerations (Section 4) remains open - if the intent is to not deal with replacing that text until after IESG approval, an RFC Editor Note to that effect should be added to Section 4. I have an additional editorial concern - given all the discussion about UTF-8, it would be good for the draft to make it clear early on=20 that JSON text sequences are UTF-8 only. Here are some suggested changes. Abstract: This document describes the JSON text sequence format and associated media type, "application/json-seq". A JSON text sequence consists of any number of JSON texts, each prefix by an Record Separator (U+001E), and each ending with a newline character (U+000A). "any number of JSON texts" -> "any number of UTF-8 encoded JSON texts" It also looks like ASCII names for RS and LF are being mixed w/Unicode codepoints in the second sentence in the abstract. I'm not sure that's a good thing to do, especially as the body of the draft refers to RS and LF as being ASCII. Here are a couple of changes that would remedy this: "an Record Separator (U+001E)" -> "an ASCII Record Separator (0x1E)" "a newline character (U+000A)" -> "an ASCII newline character (0x0A)" Section 2 JSON Text Sequence Format: I suggest adding this sentence as a separate paragraph at the end of this section (i.e., just before Section 2.1): JSON text sequences MUST use UTF-8 encoding; other encodings of JSON (i.e., UTF-16 and UTF-32) MUST NOT be used. Aside from item [F], all of the above are editorial suggestions, but I think making this clear early in the draft will help avoid potential implementer confusion. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, December 05, 2014 9:51 AM > To: nico@cryptonector.com; General Area Review Team (gen-art@ietf.org); o= ps- > dir@ietf.org > Cc: ietf@ietf.org; json@ietf.org; Black, David > Subject: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 >=20 > This is a combined Gen-ART and OPS-Dir review. Boilerplate for both foll= ows > ... >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at: >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > I have reviewed this document as part of the Operational directorate's on= going > effort to review all IETF documents being processed by the IESG. These > comments > were written primarily for the benefit of the operational area directors. > Document editors and WG chairs should treat these comments just like any = other > last call comments. >=20 > Document: draft-ietf-json-text-sequence-09 > Reviewer: David Black > Review Date: Dec 5, 2014 > IETF LC End Date: Dec 5, 2014 > IESG Telechat date: Dec 18, 2014 >=20 > Summary: This draft is on the right track, but has open issues > described in the review. >=20 > This draft specifies a format that packs multiple JSON texts into a > single string. The ASCII RS (0x1E) character is used to separate texts, > and a linefeed is appended to each text to ensure that a complete text > always ends with a whitespace character. >=20 > All of the open issues are minor - the most important ones center on > treatment of incomplete JSON texts - that appears to be an afterthought > in this draft and needs more attention. I also found a couple of > minor issues in the Security and IANA Considerations sections, both of > which are almost nits. >=20 > Major issues: None. >=20 > Minor issues: >=20 > [A] Section 2.1: >=20 > If parsing of such an octet string as a JSON text fails, the parser > SHOULD nonetheless continue parsing the remainder of the sequence. >=20 > That's not quite right - there are two levels of parsing, JSON > sequence parsing and JSON text parsing of each text in the sequence, > both of which might be implemented in a single-pass parser. For such an > implementation, the above sentence could be (mis-)read to imply that the > JSON text parse should resume from the point at which it failed, which > would be silly (although I've seen heroic PL/1 parsers do exactly that). > Instead, the parse needs to skip ahead to the next RS, ignoring the rest > of the JSON text that failed to parse. I suggest: >=20 > If parsing of such an octet string as a JSON text fails, and the > octet string is followed by an RS octet, the parser > SHOULD nonetheless skip ahead to that RS octet and continue parsing > the remainder of the sequence from there. >=20 > That also covers the case where there is nothing more to parse after the > JSON text that caused the parse failure. >=20 > [B] Section 2.3: >=20 > Is incremental parsing of a JSON text within a sequence allowed, or > is the parser required to not produce any results until the parse of > the entire text is successful? I'd expect that incremental parsing > is ok (so results may be produced from a text that ultimately fails > to parse), and I think that's worth stating. >=20 > [C] Section 2.4: >=20 > Parsers MUST check that any JSON texts that are a top-level number > include JSON whitespace ("ws" ABNF rule from [RFC7159]) after the > number, otherwise the JSON-text may have been truncated. >=20 > That reference to the "ws" rule doesn't get the job done because that > rule allows a match to no characters - it's of the form ws =3D *( ... ) > where ... is the list of whitespace characters. What's needed here is > a rule of the form vws =3D 1*( ...) to force there to be at least one > whitespace character, but see the next issue for a better way to deal > with this topic by pulling the appended LF into the sequence parse > instead of the text parse. >=20 > [D] I wonder whether the possibility of incomplete texts ought to be > encoded into the parsing rules to directly catch JSON texts that must > be incomplete because the last character is not LF, e.g.: >=20 > JSON-sequence =3D *(1*RS (possible-JSON / truncated-JSON / empty-JSO= N)) > RS =3D %x1E; "record separator" (RS), see RFC20 > possible-JSON =3D 1*(not-RS) LF ; attempt to parse as UTF-8-encoded > ; JSON text (see RFC7159) > truncated-JSON =3D *(not-RS) not-LFRS); truncated, don't attempt > ; to parse as JSON text > empty-JSON =3D LF ; only the LF appended by the encoder, nothing to = parse >=20 > not-RS =3D %x00-1D / %x1F-FF; any octet other than RS > not-LFRS =3D %x00-09/ %x1B-1D / %x1F-FF; any octet other than RS or = LF >=20 > Note that this won't detect all incomplete JSON texts, because LF is allo= wed > within a JSON text (and this should be stated). >=20 > [E] Section 3 - Security Considerations >=20 > Incomplete and malformed JSON texts can be used to attack JSON parsers - > that should be pointed out, as I don't see that in RFC 7159's security > considerations and incomplete texts are a relevant consideration for > this draft. >=20 > [F] Section 4 - IANA Considerations >=20 > Security considerations: See , > Section 3. >=20 > Interoperability considerations: Described herein. >=20 > Published specification: . >=20 > Applications that use this media type: is likely to support this format>. >=20 > Replace all three instances of the angle bracketed text. The first two > instances should be RFC references (e.g., RFC XXXX) w/a note to the RFC > Editor to insert the number of the RFC when published. The third instanc= e > should be resolved now, or could have an RFC Editor note added indicating > that the author will resolve that during Authors 48 hours. >=20 > Nits/editorial comments: >=20 > idnits didn't like the reference to RFC 20 for ASCII: >=20 > ** Downref: Normative reference to an Unknown state RFC: RFC 20 >=20 > RFC 5234 (ABNF) uses this, which looks like a better reference: >=20 > [US-ASCII] American National Standards Institute, "Coded Character > Set -- 7-bit American Standard Code for Information > Interchange", ANSI X3.4, 1986. >=20 > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- >=20 > Most of these questions are n/a because this draft describes a format > that will be used in other protocols to which RFC 5706's concerns would a= pply. >=20 > A.1.4 Have the Requirements on other protocols and functional > components been discussed? >=20 > The specification of the interaction of the JSON sequence parser with the > JSON text parser is not as clear as it should be for incomplete or malfor= med > JSON texts. See Minor Issues [A]-[E] above. >=20 > A.1.8 Are there fault or threshold conditions that should be reported? >=20 > Yes, incomplete JSON texts - this is covered in sections 2.3 and 2.4. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From nobody Wed Dec 10 17:19:59 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CB41A1AC1; Wed, 10 Dec 2014 17:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-JCMkrJ-zwh; Wed, 10 Dec 2014 17:19:56 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBADD1A1AB6; Wed, 10 Dec 2014 17:19:55 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XysQ3-0001r6-SR; Wed, 10 Dec 2014 20:19:51 -0500 Date: Wed, 10 Dec 2014 20:19:51 -0500 From: John Cowan To: "Black, David" Message-ID: <20141211011951.GC5272@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 Archived-At: http://mailarchive.ietf.org/arch/msg/json/CbWuxCMQTP2lsJNqM5InBzNwgsc Cc: "nico@cryptonector.com" , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "ops-dir@ietf.org" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 01:19:58 -0000 Black, David scripsit: > "a newline character (U+000A)" -> "an ASCII newline character (0x0A)" That should be "an ASCII Line Feed character". RFC 20 says that the Line Feed character may have a New Line [sic] *function*. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org I am expressing my opinion. When my honorable and gallant friend is called, he will express his opinion. This is the process which we call Debate. --Winston Churchill From nobody Wed Dec 10 17:31:51 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD311A6F03; Wed, 10 Dec 2014 17:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVEx8D8w_P9k; Wed, 10 Dec 2014 17:31:44 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503AC1A1B4B; Wed, 10 Dec 2014 17:31:44 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XysbR-0002dE-5K; Wed, 10 Dec 2014 20:31:37 -0500 Date: Wed, 10 Dec 2014 20:31:37 -0500 From: John Cowan To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20141211013136.GD5272@mercury.ccil.org> References: <89601952-AA04-44EE-A6DA-E76D0AB07C21@frobbit.se> <20141207180528.GA1116@mercury.ccil.org> <20141207210754.GA18507@mercury.ccil.org> <20141209033708.GB11221@localhost> <20141209051133.GK11221@localhost> <5648AF40-5E6E-45EB-B65D-3EA01EA9F24E@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5648AF40-5E6E-45EB-B65D-3EA01EA9F24E@frobbit.se> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/wdDlq2hAF0Vs4xTopYVkm165-sM Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , Nico Williams , "Black, David" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 01:31:46 -0000 Patrik Fältström scripsit: > RFC3629 has no limitation based on Unicode version. The limitation > is that it only defines UTF-8 for the UTF-16 accessible range, > U+0000..U+10FFFF. That is the complete Unicode range. There are no Unicode scalar values above U+10FFFF and never will be (as distinct from Unicode scalar values that are not, or not yet, assigned to characters). So that is no limitation at all. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Let's face it: software is crap. Feature-laden and bloated, written under tremendous time-pressure, often by incapable coders, using dangerous languages and inadequate tools, trying to connect to heaps of broken or obsolete protocols, implemented equally insufficiently, running on unpredictable hardware -- we are all more than used to brokenness. --Felix Winkelmann From nobody Thu Dec 11 10:29:53 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9B61A8775; Thu, 11 Dec 2014 10:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4Mi58pibuLw; Thu, 11 Dec 2014 10:29:35 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F17C1A87EF; Thu, 11 Dec 2014 10:29:25 -0800 (PST) Received: from [10.20.30.90] (142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBBITGOl096071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 11:29:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: Date: Thu, 11 Dec 2014 10:29:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> References: To: "Black, David" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/e6DWKqipXWiwpwABRNQuLTFLbmw Cc: Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , "ops-dir@ietf.org" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:29:44 -0000 Thanks for the followup comments on -10. In general, I think they are = fine, and Nico could put out a -11 before IESG telechat review. See = below. On Dec 10, 2014, at 7:51 AM, Black, David wrote: > The -10 version of this draft resolves items [A]-[E] from the > Gen-ART and OPS-Dir review of -09, and the IESG is in the process of > resolving the (silly) idnits complaint about RFC 20 being a possible > downref. >=20 > For item [D], a different approach was taken instead of modifying > the ABNF - the resulting new Section 2.4 is a definite improvement > to the draft, and is significantly clearer than the modified ABNF > would have been. Nicely done. >=20 > Item [F] about the text in the IANA Considerations > (Section 4) remains open - if the intent is to not deal with replacing > that text until after IESG approval, an RFC Editor Note to that effect > should be added to Section 4. David: I disagree with the need for this change. The RFC Editor can = interpret the current wording just fine. > I have an additional editorial concern - given all the discussion = about > UTF-8, it would be good for the draft to make it clear early on=20 > that JSON text sequences are UTF-8 only. Here are some suggested = changes. >=20 > Abstract: >=20 > This document describes the JSON text sequence format and associated > media type, "application/json-seq". A JSON text sequence consists = of > any number of JSON texts, each prefix by an Record Separator > (U+001E), and each ending with a newline character (U+000A). >=20 > "any number of JSON texts" -> "any number of UTF-8 encoded JSON texts" This change concerns me, because it sounds like a JSON text sequence = could consist of JSON texts encoded in UTF-8 and other encodings. I = would instead prefer "any number of JSON texts, all encoded in UTF-8,". I also just now noticed that there is a typo in the abstract: it should = say "each prefix*ed*".=20 > It also looks like ASCII names for RS and LF are being mixed w/Unicode > codepoints in the second sentence in the abstract. I'm not sure = that's > a good thing to do, especially as the body of the draft refers to RS = and > LF as being ASCII. Here are a couple of changes that would remedy = this: >=20 > "an Record Separator (U+001E)" -> "an ASCII Record Separator (0x1E)" > "a newline character (U+000A)" -> "an ASCII newline character = (0x0A)" With John Cowan's change ("an ASCII Line Feed character (0x1E)" instead = of "an ASCII Record Separator (0x1E)"), that would indeed be clearer. > Section 2 JSON Text Sequence Format: >=20 > I suggest adding this sentence as a separate paragraph at the end of = this > section (i.e., just before Section 2.1): >=20 > JSON text sequences MUST use UTF-8 encoding; other encodings of JSON > (i.e., UTF-16 and UTF-32) MUST NOT be used. >=20 That seems like a good clarifying addition as well. Nico: could you issue a -11 with the above changes? --Paul Hoffman From nobody Thu Dec 11 11:07:52 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD721ACF82; Thu, 11 Dec 2014 11:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAZhY75hdkWk; Thu, 11 Dec 2014 11:07:46 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467431ACF81; Thu, 11 Dec 2014 11:07:46 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBBJ7eL2010952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 14:07:41 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sBBJ7eL2010952 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418324862; bh=Z/sV2BtCi97Nf2KOFsEQL9XTUyc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=WtgsMh1UmiWpj0jLQc7XNqqC/Qd1wX4r27gUL6FXnog9AIuqLmtf90U9GLClSxZHU 4pNSBG/mTyy0QADEMu7U3FlhZ2zmfyAKmlQDlJHPwm9jiUtqMVaFfHBgGWhJ8GRpZB p3GIlVboCDHhLYRKaFA61q94w0E+5KH6324gJSS8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com sBBJ7eL2010952 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd56.lss.emc.com (RSA Interceptor); Thu, 11 Dec 2014 14:06:37 -0500 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBBJ7Rta016891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 14:07:27 -0500 Received: from MXHUB102.corp.emc.com (10.253.58.15) by mxhub33.corp.emc.com (10.254.93.81) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 11 Dec 2014 14:07:26 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB102.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 14:07:26 -0500 From: "Black, David" To: Paul Hoffman Thread-Topic: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 Thread-Index: AdAUkROzD04JM08VQjyyKTYMqQun9ABCTOkAAAlX8QA= Date: Thu, 11 Dec 2014 19:07:25 +0000 Message-ID: References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> In-Reply-To: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/json/f2r3OpgWZE6L2dvtx9CPjnk2s3s Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , Nico Williams , "Black, David" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 19:07:49 -0000 All of this is fine, with the correction below (looks like a copy/paste problem), and a -11 would be a fine thing to put out w/these changes. Thanks, --David > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Thursday, December 11, 2014 1:29 PM > To: Black, David > Cc: Nico Williams; General Area Review Team (gen-art@ietf.org); ops- > dir@ietf.org; ietf@ietf.org; json@ietf.org > Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text- > sequence-10 >=20 > >=20 > Thanks for the followup comments on -10. In general, I think they are fin= e, > and Nico could put out a -11 before IESG telechat review. See below. >=20 > On Dec 10, 2014, at 7:51 AM, Black, David wrote: > > The -10 version of this draft resolves items [A]-[E] from the > > Gen-ART and OPS-Dir review of -09, and the IESG is in the process of > > resolving the (silly) idnits complaint about RFC 20 being a possible > > downref. > > > > For item [D], a different approach was taken instead of modifying > > the ABNF - the resulting new Section 2.4 is a definite improvement > > to the draft, and is significantly clearer than the modified ABNF > > would have been. Nicely done. > > > > Item [F] about the text in the IANA Considerations > > (Section 4) remains open - if the intent is to not deal with replacing > > that text until after IESG approval, an RFC Editor Note to that effect > > should be added to Section 4. >=20 > David: I disagree with the need for this change. The RFC Editor can inter= pret > the current wording just fine. Ok. > > I have an additional editorial concern - given all the discussion about > > UTF-8, it would be good for the draft to make it clear early on > > that JSON text sequences are UTF-8 only. Here are some suggested chang= es. > > > > Abstract: > > > > This document describes the JSON text sequence format and associated > > media type, "application/json-seq". A JSON text sequence consists of > > any number of JSON texts, each prefix by an Record Separator > > (U+001E), and each ending with a newline character (U+000A). > > > > "any number of JSON texts" -> "any number of UTF-8 encoded JSON texts" >=20 > This change concerns me, because it sounds like a JSON text sequence coul= d > consist of JSON texts encoded in UTF-8 and other encodings. I would inste= ad > prefer "any number of JSON texts, all encoded in UTF-8,". Ok. > I also just now noticed that there is a typo in the abstract: it should s= ay > "each prefix*ed*". >=20 > > It also looks like ASCII names for RS and LF are being mixed w/Unicode > > codepoints in the second sentence in the abstract. I'm not sure that's > > a good thing to do, especially as the body of the draft refers to RS an= d > > LF as being ASCII. Here are a couple of changes that would remedy this= : > > > > "an Record Separator (U+001E)" -> "an ASCII Record Separator (0x1E)" > > "a newline character (U+000A)" -> "an ASCII newline character (0x0A)" >=20 > With John Cowan's change ("an ASCII Line Feed character (0x1E)" instead o= f "an > ASCII Record Separator (0x1E)"), that would indeed be clearer. I'm sure Paul meant to write: ("an ASCII Line Feed character (0x0A)" instead of "an ASCII newline character (0x0A)"). >=20 > > Section 2 JSON Text Sequence Format: > > > > I suggest adding this sentence as a separate paragraph at the end of th= is > > section (i.e., just before Section 2.1): > > > > JSON text sequences MUST use UTF-8 encoding; other encodings of JSON > > (i.e., UTF-16 and UTF-32) MUST NOT be used. > > >=20 > That seems like a good clarifying addition as well. >=20 > Nico: could you issue a -11 with the above changes? >=20 > --Paul Hoffman From nobody Thu Dec 11 11:55:53 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193D51A00D1; Thu, 11 Dec 2014 11:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLhvXHbz6vgk; Thu, 11 Dec 2014 11:55:49 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1615A1A1AA7; Thu, 11 Dec 2014 11:55:49 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id D01F31B4058; Thu, 11 Dec 2014 11:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=+u0Q+EnImNEvp6 NzbjLQYk48C2A=; b=sMmGDKFa+MUIJsJk0P2j3RecuwT/X6UM7FZ09MLxTp+Ftq AUAz4gMKRy8BSAN7B0gCHpW3aJtA1uQrnTamBM0Rxl3Z5Qo7EBHLClTB0BFjtf08 qYzB6x5640ehaX6w3lanfM0tpj9fEyRbqsf5rlgDdHjst5tEK1lYWLfNKk9sQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id 3A52C1B4057; Thu, 11 Dec 2014 11:55:48 -0800 (PST) Date: Thu, 11 Dec 2014 13:55:47 -0600 From: Nico Williams To: Paul Hoffman Message-ID: <20141211195542.GE3448@localhost> References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/ItHZUBTzTfRxSW9BB5Wis0AntF8 Cc: "Black, David" , "json@ietf.org" , "ops-dir@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 19:55:50 -0000 I'll submit a -11 ASAP. From nobody Thu Dec 11 14:47:00 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0930D1A8A4C; Thu, 11 Dec 2014 14:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ-guEOTTqm2; Thu, 11 Dec 2014 14:46:52 -0800 (PST) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 23C061A8A42; Thu, 11 Dec 2014 14:46:52 -0800 (PST) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id DF18120058D87; Thu, 11 Dec 2014 14:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=cmtOL8YDvgP0jx CQqDKgbitJJcQ=; b=RjV+M+LgM4H0PEhdzya/ErwfycRRsd1YCtgy4C81dsQbDm Bm6zwnm6tFGtsEMFdG5O3g5n4+RaniJiTCxUWOeXMekfVcvHxrYhKc38AHTLHRLw OfgWF44JJ6i53SBSeqApPOdHZIadH3UzPeEZYYux4TjL1yE2k5d5yNaHWdWXE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id 5C13420058D85; Thu, 11 Dec 2014 14:46:51 -0800 (PST) Date: Thu, 11 Dec 2014 16:46:50 -0600 From: Nico Williams To: Paul Hoffman Message-ID: <20141211224646.GJ3448@localhost> References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/CbakwsUU9aGc8rNV7Bb9iVF1IwM Cc: "Black, David" , "json@ietf.org" , "ops-dir@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "ietf@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 22:46:53 -0000 On Thu, Dec 11, 2014 at 10:29:16AM -0800, Paul Hoffman wrote: > > > Item [F] about the text in the IANA Considerations > > (Section 4) remains open - if the intent is to not deal with replacing > > that text until after IESG approval, an RFC Editor Note to that effect > > should be added to Section 4. > > David: I disagree with the need for this change. The RFC Editor can > interpret the current wording just fine. I'll leave them as-is then. > > I have an additional editorial concern - given all the discussion about > > UTF-8, it would be good for the draft to make it clear early on > > that JSON text sequences are UTF-8 only. Here are some suggested changes. > > > > Abstract: > > > > This document describes the JSON text sequence format and associated > > media type, "application/json-seq". A JSON text sequence consists of > > any number of JSON texts, each prefix by an Record Separator > > (U+001E), and each ending with a newline character (U+000A). > > > > "any number of JSON texts" -> "any number of UTF-8 encoded JSON texts" > > This change concerns me, because it sounds like a JSON text sequence > could consist of JSON texts encoded in UTF-8 and other encodings. I > would instead prefer "any number of JSON texts, all encoded in > UTF-8,". I'll take this. > I also just now noticed that there is a typo in the abstract: it > should say "each prefix*ed*". Fixed. > > It also looks like ASCII names for RS and LF are being mixed w/Unicode > > codepoints in the second sentence in the abstract. I'm not sure that's > > a good thing to do, especially as the body of the draft refers to RS and > > LF as being ASCII. Here are a couple of changes that would remedy this: > > > > "an Record Separator (U+001E)" -> "an ASCII Record Separator (0x1E)" > > "a newline character (U+000A)" -> "an ASCII newline character (0x0A)" > > With John Cowan's change ("an ASCII Line Feed character (0x1E)" > instead of "an ASCII Record Separator (0x1E)"), that would indeed be > clearer. OK. > > Section 2 JSON Text Sequence Format: > > > > I suggest adding this sentence as a separate paragraph at the end of this > > section (i.e., just before Section 2.1): > > > > JSON text sequences MUST use UTF-8 encoding; other encodings of JSON > > (i.e., UTF-16 and UTF-32) MUST NOT be used. > > That seems like a good clarifying addition as well. > > Nico: could you issue a -11 with the above changes? I'll confirm the posting seconds from sending this. From nobody Thu Dec 11 14:47:24 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FC31A8AC4; Thu, 11 Dec 2014 14:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z744X5E-URtj; Thu, 11 Dec 2014 14:47:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4521A8A52; Thu, 11 Dec 2014 14:47:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141211224716.25689.92582.idtracker@ietfa.amsl.com> Date: Thu, 11 Dec 2014 14:47:16 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/JfLpHck9HBXZR1Hh2Z-N4V4v-7A Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-text-sequence-11.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 22:47:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JavaScript Object Notation Working Group of the IETF. Title : JavaScript Object Notation (JSON) Text Sequences Author : Nicolas Williams Filename : draft-ietf-json-text-sequence-11.txt Pages : 11 Date : 2014-12-11 Abstract: This document describes the JSON text sequence format and associated media type, "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x1E). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-text-sequence-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 11 14:47:32 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1121A8AB8 for ; Thu, 11 Dec 2014 14:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoJaLFxsonkb; Thu, 11 Dec 2014 14:47:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B891A8AC0; Thu, 11 Dec 2014 14:47:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org, presnick@qti.qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141211224716.25689.47061.idtracker@ietfa.amsl.com> Date: Thu, 11 Dec 2014 14:47:16 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/JkKdSqRlPNfPF0DqW6Ko_keC6ik Subject: [Json] New Version Notification - draft-ietf-json-text-sequence-11.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 22:47:28 -0000 A new version (-11) has been submitted for draft-ietf-json-text-sequence: http://www.ietf.org/internet-drafts/draft-ietf-json-text-sequence-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Dec 11 14:51:04 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BADC1A1AA9; Thu, 11 Dec 2014 14:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXPIuJCJwOUH; Thu, 11 Dec 2014 14:50:57 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 12C611A1BE7; Thu, 11 Dec 2014 14:50:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,560,1413205200"; d="scan'208";a="244462961" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 12 Dec 2014 09:33:35 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7649"; a="272030039" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccni.tcif.telstra.com.au with ESMTP; 12 Dec 2014 09:50:55 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Fri, 12 Dec 2014 09:50:54 +1100 From: "Manger, James" To: Paul Hoffman , "Black, David" Date: Fri, 12 Dec 2014 09:50:53 +1100 Thread-Topic: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 Thread-Index: AdAVcISxcnpMG8jxQPeI/97Mvi/nSAAIbWiw Message-ID: <255B9BB34FB7D647A506DC292726F6E127D5708376@WSMSG3153V.srv.dir.telstra.com> References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> In-Reply-To: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/plPUb3c9wAQXy_eANQKCoCcdXLw Cc: Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" , "ietf@ietf.org" , "ops-dir@ietf.org" , "json@ietf.org" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 22:50:59 -0000 >> Abstract: >>=20 >> This document describes the JSON text sequence format and associated >> media type, "application/json-seq". A JSON text sequence consists of >> any number of JSON texts, each prefix by an Record Separator >> (U+001E), and each ending with a newline character (U+000A). >>=20 >> "any number of JSON texts" -> "any number of UTF-8 encoded JSON texts" >This change concerns me, because it sounds like a JSON text sequence could= consist of JSON texts encoded in UTF-8 and other encodings. I would instea= d prefer "any number of JSON texts, all encoded in UTF-8,". >> It also looks like ASCII names for RS and LF are being mixed w/Unicode=20 >> codepoints in the second sentence in the abstract. I'm not sure=20 >> that's a good thing to do, especially as the body of the draft refers=20 >> to RS and LF as being ASCII. Here are a couple of changes that would re= medy this: >>=20 >> "an Record Separator (U+001E)" -> "an ASCII Record Separator (0x1E)" >> "a newline character (U+000A)" -> "an ASCII newline character (0x0A)" >With John Cowan's change ("an ASCII Line Feed character (0x1E)" instead of= "an ASCII Record Separator (0x1E)"), that would indeed be clearer. Please no. That would give an even worse mix of UTF-8 and ASCII, bytes and = characters, in the 1 sentence. ".. any number of JSON texts, all encoded in UTF-8, each prefixed by an A= SCII Record Separator (0x1E) .." How about: "A JSON text sequence consists of any number of JSON texts, each prefixed by a Record Separator (U+001E) character, and each suffixed by an End of Line (U+000A) character. It is UTF-8 encoded." Say "Information Separator Two (U+001E)" if you really want to be pure. Mention in the body that "Record Separator" and "Information Separator Two"= are the ASCII and Unicode names for the same character (as are "Line Feed"= and "End of Line"), which is why RS and LF are used as ABNF names. P.S. The spec still defines the same ABNF names twice (RS, JSON-sequence): = once as bytes; once as Unicode scalars. Yuck. Just give them different name= s. -- James Manger From nobody Thu Dec 11 15:05:08 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF531A8A52; Thu, 11 Dec 2014 15:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xDmVFlMp3Iz; Thu, 11 Dec 2014 15:04:57 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523401A8A14; Thu, 11 Dec 2014 15:04:57 -0800 (PST) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBBN4raF022545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 18:04:54 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sBBN4raF022545 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418339094; bh=7u7Mg+qCVioVzu7T7HAYhKHeno0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=N/SkPD2/THKhZlFLYj3GXa5i9ckg7nvBjGlM5EiPwrGI1ELsug/aVD6PAT/6UEAFc HRIP54pnPz0AebDxnPKhNvQd4A+6W46qAv6HTR4nFNYjWbiBTfenBUDka9EQDyWV+L qePACoDGhGLNRg4+dL+Vmx85W0eCD8DlX5r0u4OI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sBBN4raF022545 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd53.lss.emc.com (RSA Interceptor); Thu, 11 Dec 2014 18:03:22 -0500 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBBN4bNQ000930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 18:04:38 -0500 Received: from MXHUB105.corp.emc.com (10.253.50.22) by mxhub19.corp.emc.com (10.254.93.48) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 11 Dec 2014 18:04:37 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB105.corp.emc.com ([10.253.50.22]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 18:04:37 -0500 From: "Black, David" To: "Manger, James" , Paul Hoffman Thread-Topic: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 Thread-Index: AdAUkROzD04JM08VQjyyKTYMqQun9ABCTOkAAAkjCYAACi5ckA== Date: Thu, 11 Dec 2014 23:04:36 +0000 Message-ID: References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> <255B9BB34FB7D647A506DC292726F6E127D5708376@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127D5708376@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/json/rRZjqWbFKNQjYk5xUMm8DWKVTOs Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , Nico Williams , "Black, David" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 23:05:00 -0000 I'm not concerned about this - the draft is UTF-8-only (it now explicitly forbids UTF-16 and UTF-32) and is written on the assumption that it's commo= n knowledge that 7-bit ASCII (as octets with zero in the most significant bit= ) is a UTF-8 subset. Thanks, --David > -----Original Message----- > From: Manger, James [mailto:James.H.Manger@team.telstra.com] > Sent: Thursday, December 11, 2014 5:51 PM > To: Paul Hoffman; Black, David > Cc: Nico Williams; General Area Review Team (gen-art@ietf.org); json@ietf= .org; > ops-dir@ietf.org; ietf@ietf.org > Subject: RE: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text- > sequence-10 >=20 > >> Abstract: > >> > >> This document describes the JSON text sequence format and associated > >> media type, "application/json-seq". A JSON text sequence consists o= f > >> any number of JSON texts, each prefix by an Record Separator > >> (U+001E), and each ending with a newline character (U+000A). > >> > >> "any number of JSON texts" -> "any number of UTF-8 encoded JSON texts" >=20 > >This change concerns me, because it sounds like a JSON text sequence cou= ld > consist of JSON texts encoded in UTF-8 and other encodings. I would inste= ad > prefer "any number of JSON texts, all encoded in UTF-8,". >=20 > >> It also looks like ASCII names for RS and LF are being mixed w/Unicode > >> codepoints in the second sentence in the abstract. I'm not sure > >> that's a good thing to do, especially as the body of the draft refers > >> to RS and LF as being ASCII. Here are a couple of changes that would > remedy this: > >> > >> "an Record Separator (U+001E)" -> "an ASCII Record Separator (0x1E)" > >> "a newline character (U+000A)" -> "an ASCII newline character (0x0A)= " >=20 > >With John Cowan's change ("an ASCII Line Feed character (0x1E)" instead = of > "an ASCII Record Separator (0x1E)"), that would indeed be clearer. >=20 >=20 > Please no. That would give an even worse mix of UTF-8 and ASCII, bytes an= d > characters, in the 1 sentence. >=20 > ".. any number of JSON texts, all encoded in UTF-8, each prefixed by an > ASCII Record Separator (0x1E) .." >=20 > How about: >=20 > "A JSON text sequence consists of any number of JSON texts, > each prefixed by a Record Separator (U+001E) character, and > each suffixed by an End of Line (U+000A) character. It is > UTF-8 encoded." >=20 > Say "Information Separator Two (U+001E)" if you really want to be pure. >=20 > Mention in the body that "Record Separator" and "Information Separator Tw= o" > are the ASCII and Unicode names for the same character (as are "Line Feed= " and > "End of Line"), which is why RS and LF are used as ABNF names. >=20 > P.S. The spec still defines the same ABNF names twice (RS, JSON-sequence)= : > once as bytes; once as Unicode scalars. Yuck. Just give them different na= mes. >=20 > -- > James Manger From nobody Thu Dec 11 15:06:26 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3113F1A8A1E; Thu, 11 Dec 2014 15:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbY7dAD1MYCH; Thu, 11 Dec 2014 15:06:08 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8C28A1A8A57; Thu, 11 Dec 2014 15:05:49 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 6DC1E20046913; Thu, 11 Dec 2014 15:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=E/XzlG3EcP5KVZ 1dJL9VK1XUghY=; b=P/LQZuOi/OXgeWX6iaQGjIGju/mRyM5awEOJPk8L7O7Z5o YA7fxlJd8D2DaFL23vqlSfeMXyismHpYkxVeF5/nt2Reqt5erdJerUJU+6sDOMAb yUDYql7aWJg2ZpaThat62R+MPBMXuseD0vN742F1lMmHFI+6IjBzL+lLsmy2M= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id D459B2004CA3D; Thu, 11 Dec 2014 15:05:48 -0800 (PST) Date: Thu, 11 Dec 2014 17:05:48 -0600 From: Nico Williams To: "Manger, James" Message-ID: <20141211230334.GK3448@localhost> References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> <255B9BB34FB7D647A506DC292726F6E127D5708376@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127D5708376@WSMSG3153V.srv.dir.telstra.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/ItHZa3aO8kzN_NCc7GRyAi6IomE Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , Paul Hoffman , "json@ietf.org" , "Black, David" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 23:06:09 -0000 On Fri, Dec 12, 2014 at 09:50:53AM +1100, Manger, James wrote: > >With John Cowan's change ("an ASCII Line Feed character (0x1E)" > >instead of "an ASCII Record Separator (0x1E)"), that would indeed be > >clearer. > > Please no. That would give an even worse mix of UTF-8 and ASCII, bytes > and characters, in the 1 sentence. Well, I just submitted -11 :( But I don't think it's a problem, really. UTF-8 is a superset of ASCII. > P.S. The spec still defines the same ABNF names twice (RS, > JSON-sequence): once as bytes; once as Unicode scalars. Yuck. Just > give them different names. They're two different sets of rules, yes. If people want me to, I'll rename one of them. Nico -- From nobody Thu Dec 11 15:11:47 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7051A8A1E; Thu, 11 Dec 2014 15:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAWG3HwzZCc3; Thu, 11 Dec 2014 15:11:37 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2EC1A1B8E; Thu, 11 Dec 2014 15:11:35 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBBNBVlg025860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 18:11:32 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sBBNBVlg025860 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418339492; bh=Nf+bWzB+0fjl5YvSehaGBCHk9eI=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ASEM0eQO6wJWGi3hn4XxVWSG3lizVUhiPttBlzHV1WWlTtTLbjZlZv9eZbJm8yk1u befTEhj9NLAosmjPIH+mR3NPHloK53gOBjxtALXRD1+u3DFOGkVvyjD89PlexNuHPB YGX32SCn6e44UIXTo6vTMUsMfMbEnaYQERncyp0Y= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com sBBNBVlg025860 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd03.lss.emc.com (RSA Interceptor); Thu, 11 Dec 2014 18:11:16 -0500 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBBNBHYI027579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 18:11:18 -0500 Received: from MXHUB205.corp.emc.com (10.253.68.31) by mxhub40.corp.emc.com (128.222.70.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 11 Dec 2014 18:11:17 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB205.corp.emc.com ([10.253.68.31]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 18:11:17 -0500 From: "Black, David" To: "nico@cryptonector.com" , "General Area Review Team (gen-art@ietf.org)" , "ops-dir@ietf.org" Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-11 Thread-Index: AdAVl8OWG4D/BbcFTwGu/5Ojd3i0AQ== Date: Thu, 11 Dec 2014 23:11:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.76] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: GIS Solicitation, DLM_1, public, Resumes Archived-At: http://mailarchive.ietf.org/arch/msg/json/1aLooi7bSgR7XIg_jk42Hp-VcMM Cc: "Black, David" , "ietf@ietf.org" , "json@ietf.org" Subject: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-11 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 23:11:41 -0000 And the -11 version resolves everything else, plus picks up improved versions of the editorial clarifications; -11 is Ready for RFC publication. Many thanks for the timely responses. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Wednesday, December 10, 2014 10:51 AM > To: nico@cryptonector.com; General Area Review Team (gen-art@ietf.org); o= ps- > dir@ietf.org > Cc: ietf@ietf.org; json@ietf.org; Black, David > Subject: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 >=20 > The -10 version of this draft resolves items [A]-[E] from the > Gen-ART and OPS-Dir review of -09, and the IESG is in the process of > resolving the (silly) idnits complaint about RFC 20 being a possible > downref. >=20 > For item [D], a different approach was taken instead of modifying > the ABNF - the resulting new Section 2.4 is a definite improvement > to the draft, and is significantly clearer than the modified ABNF > would have been. Nicely done. >=20 > Item [F] about the text in the IANA Considerations > (Section 4) remains open - if the intent is to not deal with replacing > that text until after IESG approval, an RFC Editor Note to that effect > should be added to Section 4. >=20 > I have an additional editorial concern - given all the discussion about > UTF-8, it would be good for the draft to make it clear early on > that JSON text sequences are UTF-8 only. Here are some suggested changes= . >=20 > Abstract: >=20 > This document describes the JSON text sequence format and associated > media type, "application/json-seq". A JSON text sequence consists of > any number of JSON texts, each prefix by an Record Separator > (U+001E), and each ending with a newline character (U+000A). >=20 > "any number of JSON texts" -> "any number of UTF-8 encoded JSON texts" >=20 > It also looks like ASCII names for RS and LF are being mixed w/Unicode > codepoints in the second sentence in the abstract. I'm not sure that's > a good thing to do, especially as the body of the draft refers to RS and > LF as being ASCII. Here are a couple of changes that would remedy this: >=20 > "an Record Separator (U+001E)" -> "an ASCII Record Separator (0x1E)" > "a newline character (U+000A)" -> "an ASCII newline character (0x0A)" >=20 > Section 2 JSON Text Sequence Format: >=20 > I suggest adding this sentence as a separate paragraph at the end of this > section (i.e., just before Section 2.1): >=20 > JSON text sequences MUST use UTF-8 encoding; other encodings of JSON > (i.e., UTF-16 and UTF-32) MUST NOT be used. >=20 > Aside from item [F], all of the above are editorial suggestions, but I > think making this clear early in the draft will help avoid potential > implementer confusion. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Black, David > > Sent: Friday, December 05, 2014 9:51 AM > > To: nico@cryptonector.com; General Area Review Team (gen-art@ietf.org);= ops- > > dir@ietf.org > > Cc: ietf@ietf.org; json@ietf.org; Black, David > > Subject: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09 > > > > This is a combined Gen-ART and OPS-Dir review. Boilerplate for both fo= llows > > ... > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at: > > > > . > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > I have reviewed this document as part of the Operational directorate's > ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments > > were written primarily for the benefit of the operational area director= s. > > Document editors and WG chairs should treat these comments just like an= y > other > > last call comments. > > > > Document: draft-ietf-json-text-sequence-09 > > Reviewer: David Black > > Review Date: Dec 5, 2014 > > IETF LC End Date: Dec 5, 2014 > > IESG Telechat date: Dec 18, 2014 > > > > Summary: This draft is on the right track, but has open issues > > described in the review. > > > > This draft specifies a format that packs multiple JSON texts into a > > single string. The ASCII RS (0x1E) character is used to separate texts= , > > and a linefeed is appended to each text to ensure that a complete text > > always ends with a whitespace character. > > > > All of the open issues are minor - the most important ones center on > > treatment of incomplete JSON texts - that appears to be an afterthought > > in this draft and needs more attention. I also found a couple of > > minor issues in the Security and IANA Considerations sections, both of > > which are almost nits. > > > > Major issues: None. > > > > Minor issues: > > > > [A] Section 2.1: > > > > If parsing of such an octet string as a JSON text fails, the parser > > SHOULD nonetheless continue parsing the remainder of the sequence. > > > > That's not quite right - there are two levels of parsing, JSON > > sequence parsing and JSON text parsing of each text in the sequence, > > both of which might be implemented in a single-pass parser. For such a= n > > implementation, the above sentence could be (mis-)read to imply that th= e > > JSON text parse should resume from the point at which it failed, which > > would be silly (although I've seen heroic PL/1 parsers do exactly that)= . > > Instead, the parse needs to skip ahead to the next RS, ignoring the res= t > > of the JSON text that failed to parse. I suggest: > > > > If parsing of such an octet string as a JSON text fails, and the > > octet string is followed by an RS octet, the parser > > SHOULD nonetheless skip ahead to that RS octet and continue parsing > > the remainder of the sequence from there. > > > > That also covers the case where there is nothing more to parse after th= e > > JSON text that caused the parse failure. > > > > [B] Section 2.3: > > > > Is incremental parsing of a JSON text within a sequence allowed, or > > is the parser required to not produce any results until the parse of > > the entire text is successful? I'd expect that incremental parsing > > is ok (so results may be produced from a text that ultimately fails > > to parse), and I think that's worth stating. > > > > [C] Section 2.4: > > > > Parsers MUST check that any JSON texts that are a top-level number > > include JSON whitespace ("ws" ABNF rule from [RFC7159]) after the > > number, otherwise the JSON-text may have been truncated. > > > > That reference to the "ws" rule doesn't get the job done because that > > rule allows a match to no characters - it's of the form ws =3D *( ... ) > > where ... is the list of whitespace characters. What's needed here is > > a rule of the form vws =3D 1*( ...) to force there to be at least one > > whitespace character, but see the next issue for a better way to deal > > with this topic by pulling the appended LF into the sequence parse > > instead of the text parse. > > > > [D] I wonder whether the possibility of incomplete texts ought to be > > encoded into the parsing rules to directly catch JSON texts that must > > be incomplete because the last character is not LF, e.g.: > > > > JSON-sequence =3D *(1*RS (possible-JSON / truncated-JSON / empty-J= SON)) > > RS =3D %x1E; "record separator" (RS), see RFC20 > > possible-JSON =3D 1*(not-RS) LF ; attempt to parse as UTF-8-encode= d > > ; JSON text (see RFC7159) > > truncated-JSON =3D *(not-RS) not-LFRS); truncated, don't attempt > > ; to parse as JSON text > > empty-JSON =3D LF ; only the LF appended by the encoder, nothing t= o parse > > > > not-RS =3D %x00-1D / %x1F-FF; any octet other than RS > > not-LFRS =3D %x00-09/ %x1B-1D / %x1F-FF; any octet other than RS o= r LF > > > > Note that this won't detect all incomplete JSON texts, because LF is al= lowed > > within a JSON text (and this should be stated). > > > > [E] Section 3 - Security Considerations > > > > Incomplete and malformed JSON texts can be used to attack JSON parsers = - > > that should be pointed out, as I don't see that in RFC 7159's security > > considerations and incomplete texts are a relevant consideration for > > this draft. > > > > [F] Section 4 - IANA Considerations > > > > Security considerations: See , > > Section 3. > > > > Interoperability considerations: Described herein. > > > > Published specification: . > > > > Applications that use this media type: > is likely to support this format>. > > > > Replace all three instances of the angle bracketed text. The first two > > instances should be RFC references (e.g., RFC XXXX) w/a note to the RFC > > Editor to insert the number of the RFC when published. The third insta= nce > > should be resolved now, or could have an RFC Editor note added indicati= ng > > that the author will resolve that during Authors 48 hours. > > > > Nits/editorial comments: > > > > idnits didn't like the reference to RFC 20 for ASCII: > > > > ** Downref: Normative reference to an Unknown state RFC: RFC 20 > > > > RFC 5234 (ABNF) uses this, which looks like a better reference: > > > > [US-ASCII] American National Standards Institute, "Coded Character > > Set -- 7-bit American Standard Code for Information > > Interchange", ANSI X3.4, 1986. > > > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > > > Most of these questions are n/a because this draft describes a format > > that will be used in other protocols to which RFC 5706's concerns would > apply. > > > > A.1.4 Have the Requirements on other protocols and functional > > components been discussed? > > > > The specification of the interaction of the JSON sequence parser with t= he > > JSON text parser is not as clear as it should be for incomplete or malf= ormed > > JSON texts. See Minor Issues [A]-[E] above. > > > > A.1.8 Are there fault or threshold conditions that should be reported= ? > > > > Yes, incomplete JSON texts - this is covered in sections 2.3 and 2.4. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- From nobody Thu Dec 11 17:04:30 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39E11A1A2D; Thu, 11 Dec 2014 17:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsN4eQyKv3hf; Thu, 11 Dec 2014 17:04:23 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5354C1A6FCA; Thu, 11 Dec 2014 17:04:23 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XzEeY-00051h-Oh; Thu, 11 Dec 2014 20:04:18 -0500 Date: Thu, 11 Dec 2014 20:04:18 -0500 From: John Cowan To: Paul Hoffman Message-ID: <20141212010418.GJ5272@mercury.ccil.org> References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/8erbdZTBho6h10TdruIqDNBLUGA Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , "json@ietf.org" , Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 01:04:27 -0000 Paul Hoffman scripsit: > > JSON text sequences MUST use UTF-8 encoding; other encodings of JSON > > (i.e., UTF-16 and UTF-32) MUST NOT be used. > > > > That seems like a good clarifying addition as well. I continue to think this is a bad idea. In particular, you cannot claim that because a text sequence entity body is not valid UTF-8, that it is not a valid JSON text sequence; as I explained before, the JSON texts may be truncated or otherwise damaged such that they contain only part of a UTF-8-encoded character. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! --Joyce, Ulysses, "Oxen of the Sun" From nobody Thu Dec 11 17:12:27 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230941A1B25; Thu, 11 Dec 2014 17:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaMvHoMOGzNC; Thu, 11 Dec 2014 17:12:17 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557F21A00C3; Thu, 11 Dec 2014 17:12:17 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XzEm8-0005Te-AQ; Thu, 11 Dec 2014 20:12:08 -0500 Date: Thu, 11 Dec 2014 20:12:08 -0500 From: John Cowan To: "Manger, James" Message-ID: <20141212011208.GK5272@mercury.ccil.org> References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> <255B9BB34FB7D647A506DC292726F6E127D5708376@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255B9BB34FB7D647A506DC292726F6E127D5708376@WSMSG3153V.srv.dir.telstra.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/sumY1RV7EpKz6P3MzwiHwwYKk-Y Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , Paul Hoffman , "json@ietf.org" , Nico Williams , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 01:12:19 -0000 Manger, James scripsit: > How about: > > "A JSON text sequence consists of any number of JSON texts, > each prefixed by a Record Separator (U+001E) character, and > each suffixed by an End of Line (U+000A) character. It is > UTF-8 encoded." > > Say "Information Separator Two (U+001E)" if you really want to be pure. The trouble with that is that U+001E has no official Unicode name or function; those come from ISO 6429, which is incorporated (in relevant part) into US-ASCII, which is described in RFC 20. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org To say that Bilbo's breath was taken away is no description at all. There are no words left to express his staggerment, since Men changed the language that they learned of elves in the days when all the world was wonderful. --The Hobbit From nobody Thu Dec 11 17:23:25 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B131A90F9; Thu, 11 Dec 2014 17:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaQNyzoOjbL1; Thu, 11 Dec 2014 17:22:59 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E475A1A90DB; Thu, 11 Dec 2014 17:22:54 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBC1Mneu022385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 20:22:50 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com sBC1Mneu022385 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418347371; bh=WNRAZZNWG0k7+W2QOQGa4kCxyM8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=M8RHaMO5h8X3UdpPqPsaWU5DzHygCKV0t1T8AThCp5oRBO2172UBcx+4ySN+nPc8Y DvLTPeu2GA6AN9DxFmqGiUukWxfaVrdaxxVv+UTZsn8nmfjHBPchNeVUFzcDgcGirg zDVExmwLLhhaer7UEvwM+PTNSRv1xyGxLYgKkIy0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com sBC1Mneu022385 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor); Thu, 11 Dec 2014 20:22:34 -0500 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBC1MYk2024255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 20:22:34 -0500 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub22.corp.emc.com (128.222.70.134) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 11 Dec 2014 20:22:34 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 20:22:34 -0500 From: "Black, David" To: John Cowan , Paul Hoffman Thread-Topic: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 Thread-Index: AdAUkROzD04JM08VQjyyKTYMqQun9ABCTOkAAA3L4AAACehr4A== Date: Fri, 12 Dec 2014 01:22:33 +0000 Message-ID: References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> <20141212010418.GJ5272@mercury.ccil.org> In-Reply-To: <20141212010418.GJ5272@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/json/XYfKqky_rtv7F2gpI1Qa2jhRhhs Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "json@ietf.org" , Nico Williams , "Black, David" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 01:23:03 -0000 If we're going to split hairs, "MUST use UTF-8 encoding" does not imply "MUST be valid UTF-8" (e.g., courtesy of truncation in the middle of a Unicode character) - the latter is a stricter requirement, and is not what I suggested. Thanks, --David > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan > Sent: Thursday, December 11, 2014 8:04 PM > To: Paul Hoffman > Cc: Black, David; Nico Williams; General Area Review Team (gen-art@ietf.o= rg); > json@ietf.org; ops-dir@ietf.org; ietf@ietf.org > Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text- > sequence-10 >=20 > Paul Hoffman scripsit: >=20 > > > JSON text sequences MUST use UTF-8 encoding; other encodings of JSO= N > > > (i.e., UTF-16 and UTF-32) MUST NOT be used. > > > > > > > That seems like a good clarifying addition as well. >=20 > I continue to think this is a bad idea. In particular, you cannot claim > that because a text sequence entity body is not valid UTF-8, that it is > not a valid JSON text sequence; as I explained before, the JSON texts > may be truncated or otherwise damaged such that they contain only part > of a UTF-8-encoded character. >=20 > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. > Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) > Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoop= sa! > --Joyce, Ulysses, "Oxen of the Sun" From nobody Thu Dec 11 17:38:10 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC6B1A90F9; Thu, 11 Dec 2014 17:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5K0Jj-mlQ0FO; Thu, 11 Dec 2014 17:37:56 -0800 (PST) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8991D1A1A2D; Thu, 11 Dec 2014 17:37:56 -0800 (PST) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 564B920058D84; Thu, 11 Dec 2014 17:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=k26i47o/seoDqv QTCN4SedvdzOA=; b=ZrIiIDZn0bdIOaImkLokanZJzFPGtpSefGGJhi3IN522Mz iyscA/u/f5G5koJwrAVKAFf8GFwEGmZ9JsptyZlZSzJQQgA1SlxiGZp6HeoipREi Ul3GxGpNu6UjqKVqxaMEw5z9gCbmF81hgpR3l9CQnjYtZ/L6d6p8zjxp5GtEg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id BCA6A20058D80; Thu, 11 Dec 2014 17:37:55 -0800 (PST) Date: Thu, 11 Dec 2014 19:37:55 -0600 From: Nico Williams To: John Cowan Message-ID: <20141212013750.GM3448@localhost> References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> <20141212010418.GJ5272@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141212010418.GJ5272@mercury.ccil.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/aONuOrZHxNtSg43f3Vapn55WvV8 Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , Paul Hoffman , "json@ietf.org" , "Black, David" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 01:38:01 -0000 On Thu, Dec 11, 2014 at 08:04:18PM -0500, John Cowan wrote: > Paul Hoffman scripsit: > > > > JSON text sequences MUST use UTF-8 encoding; other encodings of JSON > > > (i.e., UTF-16 and UTF-32) MUST NOT be used. > > > > That seems like a good clarifying addition as well. > > I continue to think this is a bad idea. In particular, you cannot claim What is? > that because a text sequence entity body is not valid UTF-8, that it is > not a valid JSON text sequence; as I explained before, the JSON texts > may be truncated or otherwise damaged such that they contain only part > of a UTF-8-encoded character. RS cannot accidentally result from truncating a multi-byte UTF-8 encoded codepoint. Nico -- From nobody Thu Dec 11 17:41:47 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8F61A90F9; Thu, 11 Dec 2014 17:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnGuf8XfYB_G; Thu, 11 Dec 2014 17:41:43 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639181A88AD; Thu, 11 Dec 2014 17:41:43 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1XzFEi-0007LC-Qj; Thu, 11 Dec 2014 20:41:40 -0500 Date: Thu, 11 Dec 2014 20:41:40 -0500 From: John Cowan To: Nico Williams Message-ID: <20141212014140.GM5272@mercury.ccil.org> References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> <20141212010418.GJ5272@mercury.ccil.org> <20141212013750.GM3448@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141212013750.GM3448@localhost> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/FPNvYsTQB5nI-fPWKTFm8kZdluU Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , Paul Hoffman , "json@ietf.org" , "Black, David" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 01:41:44 -0000 Nico Williams scripsit: > RS cannot accidentally result from truncating a multi-byte UTF-8 > encoded codepoint. I realize that. But because such truncations are possible, we can't assert that a well-formed JSON text sequence is necessarily well-formed UTF-8 as a whole. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Objective consideration of contemporary phenomena compel the conclusion that optimum or inadequate performance in the trend of competitive activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be taken into account. --Ecclesiastes 9:11, Orwell/Brown version From nobody Thu Dec 11 19:22:49 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D171AC3D1; Thu, 11 Dec 2014 19:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj4KEAIklUi0; Thu, 11 Dec 2014 19:22:42 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7E71AC3CC; Thu, 11 Dec 2014 19:22:42 -0800 (PST) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id E23C14012D68E; Thu, 11 Dec 2014 19:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=v1i+LNGcPeSnii neXm1Zg9jGJzU=; b=mK3xvigsBVrXRoGcXMmNsPoaEakXcXs9He+D7RXc+aol5V NZSvta5Bms8+ASmvHXqkUO5N0/nvEFIJp++rUAqyFWiir8tXwWIu63dOEHMZVYUH k3W+WtmTZgr/wzU1N0xGedQQXzqEl0UVtCrv0XQf+S+BoK3Wvt6UtuzU6iPvs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPA id 4C2A94012D68C; Thu, 11 Dec 2014 19:22:41 -0800 (PST) Date: Thu, 11 Dec 2014 21:22:40 -0600 From: Nico Williams To: John Cowan Message-ID: <20141212032236.GN3448@localhost> References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> <20141212010418.GJ5272@mercury.ccil.org> <20141212013750.GM3448@localhost> <20141212014140.GM5272@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141212014140.GM5272@mercury.ccil.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/EPI0ARYM28v8U5uixz3XGVjlJI8 Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , Paul Hoffman , "json@ietf.org" , "Black, David" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 03:22:44 -0000 On Thu, Dec 11, 2014 at 08:41:40PM -0500, John Cowan wrote: > Nico Williams scripsit: > > > RS cannot accidentally result from truncating a multi-byte UTF-8 > > encoded codepoint. > > I realize that. But because such truncations are possible, we can't > assert that a well-formed JSON text sequence is necessarily well-formed > UTF-8 as a whole. Oh, I see what you're saying, you're objecting to the sentence that David wanted added to section 2, before 2.1. We could prefix "Well-formed " to that sentence and make this concern go away :) From nobody Fri Dec 12 09:43:29 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E471A1AE8 for ; Fri, 12 Dec 2014 09:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtmcLhCj107o; Fri, 12 Dec 2014 09:43:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9E91A710D; Fri, 12 Dec 2014 09:43:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212174327.20389.19773.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 09:43:27 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/05iQzBf82ppkvVY5hgE9DkSMag8 Subject: [Json] ID Tracker State Update Notice: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 17:43:28 -0000 IESG state changed to IESG Evaluation from Waiting for Writeup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ From nobody Fri Dec 12 14:06:33 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651FC1ACFF5 for ; Fri, 12 Dec 2014 14:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nogeg54WtTwG; Fri, 12 Dec 2014 14:06:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDFD1A0387; Fri, 12 Dec 2014 14:06:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212220629.15594.9342.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 14:06:29 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/GJkDjWUKgPqwzJzpLpTSDDchAb4 Subject: [Json] ID Tracker State Update Notice: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 22:06:31 -0000 IANA review state changed to IANA OK - Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ From nobody Fri Dec 12 23:02:37 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2573C1AC3E5; Fri, 12 Dec 2014 23:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaLDisa-Gkc5; Fri, 12 Dec 2014 23:02:29 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51AE91AC3DF; Fri, 12 Dec 2014 23:02:29 -0800 (PST) Received: from [192.168.1.83] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id A6E8022EAF; Sat, 13 Dec 2014 08:02:26 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_64B49D58-F28D-40FC-9AC4-78D8B9EC82B1"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20141212011208.GK5272@mercury.ccil.org> Date: Sat, 13 Dec 2014 08:02:26 +0100 Message-Id: References: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org> <255B9BB34FB7D647A506DC292726F6E127D5708376@WSMSG3153V.srv.dir.telstra.com> <20141212011208.GK5272@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/hUMPqoPUE4Q9sC-1KKi_MgDysCM Cc: "ops-dir@ietf.org" , "ietf@ietf.org" , "Black, David" , Paul Hoffman , "json@ietf.org" , "Manger, James" , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 07:02:32 -0000 --Apple-Mail=_64B49D58-F28D-40FC-9AC4-78D8B9EC82B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 12 dec 2014, at 02:12, John Cowan wrote: >=20 > Manger, James scripsit: >=20 >> How about: >>=20 >> "A JSON text sequence consists of any number of JSON texts, >> each prefixed by a Record Separator (U+001E) character, and >> each suffixed by an End of Line (U+000A) character. It is >> UTF-8 encoded." >>=20 >> Say "Information Separator Two (U+001E)" if you really want to be = pure. >=20 > The trouble with that is that U+001E has no official Unicode name or > function; those come from ISO 6429, which is incorporated (in relevant > part) into US-ASCII, which is described in RFC 20. Although it does not have a Unicode Name, the alias is as close as we = can get, which is "INFORMATION SEPARATOR TWO": # grep ^001E UnicodeData.txt 001E;;Cc;0;B;;;;;N;INFORMATION SEPARATOR TWO;;;; # So I suggest to use that. It is I think wrong to say "Record Separator" and then still reference = the Unicode Tables. Alternatively one just write (and make it more clear how this works, and = this is my understanding): > A JSON text sequence consists of any number of JSON texts, each = prefixed by U+001E character and each suffixed by U+000A. The JSON texts = as well as the whole JSON text sequence is encoded in UTF-8 although any = JSON text might be truncated and because of that not a valid UTF-8 = sequence. Any occurance of the UTF-8 encoding of U+001E (the byte 0x1E) = is to be viewed as the first byte before each JSON text, and occurrance = of the byte 0x0A is to be viewed as the first byte after a complete JSON = text. If the JSON text is truncated, the 0x0A byte will not be present. I.e. the grammar is sort of (before coffee in the morning): sequence :=3D 0x1E text text :=3D complete-text | truncated-text complete-text :=3D proper-UTF8 0x0A truncated-text :=3D proper-UTF8 broken-UTF8 proper-UTF8 :=3D "" | "a sequence of bytes, possible to parse as a = series of UTF8 encoded Unicode characters" broken-UTF8 :=3D "a sequence of bytes not possible to parse as a UTF8 = encoded unicode character" Patrik --Apple-Mail=_64B49D58-F28D-40FC-9AC4-78D8B9EC82B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUi+SCrMabGguI180RAnV3AJ46tO+Sc5MChPQ+NjJvVm+PTgl70gCfcBI2 c32ncImhLlEUEOkB/PbP5IA= =Vstt -----END PGP SIGNATURE----- --Apple-Mail=_64B49D58-F28D-40FC-9AC4-78D8B9EC82B1-- From nobody Sat Dec 13 08:46:47 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF8D1A1A30; Sat, 13 Dec 2014 08:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-eoRtwdyIgI; Sat, 13 Dec 2014 08:46:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D71011A1A07; Sat, 13 Dec 2014 08:46:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141213164641.30100.14864.idtracker@ietfa.amsl.com> Date: Sat, 13 Dec 2014 08:46:41 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/5lQQm2AynSQOQiDxKZihjmx220U Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org Subject: [Json] Barry Leiba's Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 16:46:43 -0000 Barry Leiba has entered the following ballot position for draft-ietf-json-text-sequence-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I've asked that the media type registration request be posted to the media-types@iana.org list for comment, and we're still awaiting that... but Paul has asked Nico to do that, and I'm confident that all will work out. I'll clear this when the request has been posted and there's been some time for comment. From nobody Mon Dec 15 00:23:57 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589B41A1A48; Mon, 15 Dec 2014 00:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KiZiBnGHQc5; Mon, 15 Dec 2014 00:23:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C26DF1A1A46; Mon, 15 Dec 2014 00:23:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141215082349.8827.28625.idtracker@ietfa.amsl.com> Date: Mon, 15 Dec 2014 00:23:49 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/3vx_OqHdx5uUYJJxx7wJKFYjDQM Cc: draft-ietf-json-text-sequence@tools.ietf.org, david.black@emc.com, json-chairs@tools.ietf.org, json@ietf.org Subject: [Json] Benoit Claise's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 08:23:51 -0000 Benoit Claise has entered the following ballot position for draft-ietf-json-text-sequence-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing the OPS-DIR review in a timely manner. From nobody Mon Dec 15 05:52:26 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0071A6FDE; Mon, 15 Dec 2014 05:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqUGicQJUqzc; Mon, 15 Dec 2014 05:52:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 176181A6FD8; Mon, 15 Dec 2014 05:52:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141215135220.10274.94846.idtracker@ietfa.amsl.com> Date: Mon, 15 Dec 2014 05:52:20 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/hVnbu9SG6VbNv4ON9rNrVn9r-8E Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org Subject: [Json] Stephen Farrell's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 13:52:22 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-json-text-sequence-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - abstract: 2nd 0x1E should be 0x0A I guess. That really needs fixing so could well be a DISCUSS but is probably so obvious it'll happen without that:-) But let me know if you prefer this be a DISCUSS for tracking purposes. - 2.1 doesn't say anything about 0x00 which often creates security issues. Worth a note? Not sure myself. - 2.2: thanks for the ctrl-^ info - that's good. Would it be worth adding that in e.g. vim/vi you should precede that ctrl-^ with ctrl-v so as to get the right value into your file? - 2.3: I think SHOULD NOT abort is too strong - did the wg consider saying they SHOULD or MAY abort and giving the log example as a counter example? It just seems safer to me if the default behaviour is to abort. However, I'm not that certain of this point, so this isn't a discuss. - section 3: 2nd sentence, I think what you really should be saying is that parsing one of these does not necessarily give you a good input to a MAC or signature verification process as you might or might not still have canonicalisation issues. - section 3: I think you ought mention the potential here for careless code to be vulnerable to buffer overruns. We've seen that too often to ignore it I'd argue. - Most of the above plus a few others are also noted in the secdir review [1]. I'm sure the author/shepherd/AD will engage with the reviewer there too. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05300.html From nobody Mon Dec 15 13:18:58 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0E51A8ABB; Mon, 15 Dec 2014 13:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5kI5Iss3fQn; Mon, 15 Dec 2014 13:18:15 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0A11A8AB6; Mon, 15 Dec 2014 13:18:15 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id vb8so19799450obc.0 for ; Mon, 15 Dec 2014 13:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :date:message-id:references:cc:in-reply-to:to; bh=vU8QOf/Mn2dOCX61d9U3rS4dkZ+xZm6tm4z7oeIgaBk=; b=d/YY+TPPIpWSq5unreweB+3GiLrNiSDC6h6x4Bu6hz9c3LkKvp26xc+Wz8ETccOgtm AdaNaK62g00aSVgUl6sYyld52bnx1vDe/V98zAXHy0Q45tEAkGCz9c8uP3cerGnpJn05 zhNxYNgtCWPRz568mugwzYndo3r2CWvA1iTnCijiscGGhZpLCHgUKDCS5jeeQmvxG5Dw rwuso6CqX+DsJ8tE4n5GEfQ6IAQB/uB6yWxiMJPfmAqC1a8k9qaeCF7q4yEvTff4vELn sEnoLurRN/YmYMRNtbctud9MNWTdRV7iJ/DxxlNER8HTIf5hn0epq126OS4IlZjqHXzP c5PQ== X-Received: by 10.182.79.41 with SMTP id g9mr19949107obx.14.1418678294771; Mon, 15 Dec 2014 13:18:14 -0800 (PST) Received: from [10.182.35.190] (mobile-166-172-123-134.mycingular.net. [166.172.123.134]) by mx.google.com with ESMTPSA id rm7sm5189754obc.14.2014.12.15.13.18.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 13:18:13 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Mon, 15 Dec 2014 21:15:04 +0000 Message-Id: References: <20141215135220.10274.94846.idtracker@ietfa.amsl.com> In-Reply-To: <20141215135220.10274.94846.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: iPhone Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/json/RJEuz0psXOKvy6QoQ1pAIqbF5kY X-Mailman-Approved-At: Mon, 15 Dec 2014 13:18:56 -0800 Cc: "json-chairs@tools.ietf.org" , "draft-ietf-json-text-sequence@tools.ietf.org" , The IESG , "json@ietf.org" Subject: Re: [Json] Stephen Farrell's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 21:18:17 -0000 Thanks, Stephen. If this gets marked as update needed, I'll make sure all the comments are ad= dressed before it proceeds. I think the author is motivated to do this quic= kly. Thanks, Kathleen=20 Sent from my iPhone > On Dec 15, 2014, at 1:52 PM, "Stephen Farrell" = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-json-text-sequence-11: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 >=20 > - abstract: 2nd 0x1E should be 0x0A I guess. That really > needs fixing so could well be a DISCUSS but is probably > so obvious it'll happen without that:-) But let me know > if you prefer this be a DISCUSS for tracking purposes. >=20 > - 2.1 doesn't say anything about 0x00 which often creates > security issues. Worth a note? Not sure myself.=20 >=20 > - 2.2: thanks for the ctrl-^ info - that's good. Would it be > worth adding that in e.g. vim/vi you should precede that > ctrl-^ with ctrl-v so as to get the right value into your > file? >=20 > - 2.3: I think SHOULD NOT abort is too strong - did the wg > consider saying they SHOULD or MAY abort and giving the log > example as a counter example? It just seems safer to me if > the default behaviour is to abort. However, I'm not that > certain of this point, so this isn't a discuss. >=20 > - section 3: 2nd sentence, I think what you really should be > saying is that parsing one of these does not necessarily give > you a good input to a MAC or signature verification process > as you might or might not still have canonicalisation issues.=20 >=20 > - section 3: I think you ought mention the potential here for > careless code to be vulnerable to buffer overruns. We've seen > that too often to ignore it I'd argue. >=20 > - Most of the above plus a few others are also noted in > the secdir review [1]. I'm sure the author/shepherd/AD=20 > will engage with the reviewer there too.=20 >=20 > [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05300.html >=20 >=20 From nobody Mon Dec 15 13:52:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C1D1A0077; Mon, 15 Dec 2014 13:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQE4KNIGSo3c; Mon, 15 Dec 2014 13:51:59 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00491A006F; Mon, 15 Dec 2014 13:51:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1418680319; x=1450216319; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=E6P/ujg/JzITQAydnsMbphxxObdQ60VYX8wur7F64AA=; b=Mg7gi6CpwzgVCdBGy0yfqgMrFwShu1pobALEMhw0sVkyKFIoVLbA/to7 3RBa1eKkq22Q9MpZX5+c4eaQXu1oA+rHYyoZrSH9PS3KDcsePMti9w2SV 22SPvbr9xwP+kN1wP1W3gM2CuxOZbNd8ULOqaqg6QnnFpBxV0yGLxpekp Y=; X-IronPort-AV: E=McAfee;i="5600,1067,7653"; a="80837384" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Dec 2014 13:51:58 -0800 X-IronPort-AV: E=Sophos;i="5.07,581,1413270000"; d="scan'208";a="772219125" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Dec 2014 13:51:57 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 15 Dec 2014 13:51:51 -0800 Message-ID: <548F57E9.8080307@qti.qualcomm.com> Date: Mon, 15 Dec 2014 15:51:37 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Kathleen Moriarty References: <20141215135220.10274.94846.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/json/EyLMpyipOXpyfHwLFagXYXBOfSs Cc: "draft-ietf-json-text-sequence@tools.ietf.org" , "json@ietf.org" , "json-chairs@tools.ietf.org" , The IESG , Stephen Farrell Subject: Re: [Json] Stephen Farrell's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 21:52:01 -0000 On 12/15/14 3:15 PM, Kathleen Moriarty wrote: > If this gets marked as update needed, I'll make sure all the comments are addressed before it proceeds. I think the author is motivated to do this quickly. > Kathleen, much as I would be delighted for you to make sure all the comments are addressed, I think you are confusing this document with draft-joseffson. :-) (How amusing that we have draft-ietf-json..., draft-ietf-jose..., and draft-joseffson..., all on the same telechat.) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Mon Dec 15 15:27:12 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307A51A88C6; Mon, 15 Dec 2014 15:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7eLSMiCgYO5; Mon, 15 Dec 2014 15:26:59 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEDE1A896E; Mon, 15 Dec 2014 15:26:43 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 491D42006D309; Mon, 15 Dec 2014 15:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=GKiCqGuvRPHkGs cgUOgEj1jSLIA=; b=JoV+m57KAqsvtbmCP/f2Wa7cwXOAsC+C8VmjF9KSf8cbD5 JspcVlOvwmeWiqG0A+bJshuhgA8EfCKcHWdCIzfwH6s5MJvj0uubNIBrS7abTSTq srDTJKGrgRu8+r2oT7BmK0vfaqAjzUiAdgjCGPqbHP4naWcSCDO0bRmJX51/4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id BDA702006D30A; Mon, 15 Dec 2014 15:26:42 -0800 (PST) Date: Mon, 15 Dec 2014 17:26:42 -0600 From: Nico Williams To: Stephen Farrell Message-ID: <20141215232638.GO3241@localhost> References: <20141215135220.10274.94846.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141215135220.10274.94846.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/nTtN4VpFUotez5ONyZstjPe5Zy4 Cc: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Stephen Farrell's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:27:01 -0000 On Mon, Dec 15, 2014 at 05:52:20AM -0800, Stephen Farrell wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - abstract: 2nd 0x1E should be 0x0A I guess. That really > needs fixing so could well be a DISCUSS but is probably > so obvious it'll happen without that:-) But let me know > if you prefer this be a DISCUSS for tracking purposes. Will fix after the telechat. > - 2.1 doesn't say anything about 0x00 which often creates > security issues. Worth a note? Not sure myself. Not sure. We could list all the byte values that are not permitted, but yes, NUL is the most interesting one as far as security bugs go. > - 2.2: thanks for the ctrl-^ info - that's good. Would it be > worth adding that in e.g. vim/vi you should precede that > ctrl-^ with ctrl-v so as to get the right value into your > file? Sure. > - 2.3: I think SHOULD NOT abort is too strong - did the wg > consider saying they SHOULD or MAY abort and giving the log > example as a counter example? It just seems safer to me if > the default behaviour is to abort. However, I'm not that > certain of this point, so this isn't a discuss. Pete Resnick also wants this to not be "SHOULD NOT". It should be fine to make it OPTIONAL to continue (though it's desirable for some apps). > - section 3: 2nd sentence, I think what you really should be > saying is that parsing one of these does not necessarily give > you a good input to a MAC or signature verification process > as you might or might not still have canonicalisation issues. That's... not what I was trying to say, though I agree that there is no canonical form for this format, just as there isn't for JSON itself (why doesn't RFC7159 say this? oh well). > - section 3: I think you ought mention the potential here for > careless code to be vulnerable to buffer overruns. We've seen > that too often to ignore it I'd argue. Well, I didn't want to list all of those sorts of bugs. It should suffice to say that the input is as good as untrusted. If there's boilerplate for all the types of bugs worth mentioning, let me know. (If there isn't then maybe there should be. In any case, it's not just buffer overflows. There could be integer overflows, double frees and other dangling pointer dereferencing, null pointer dereferencing, and other bugs.) > - Most of the above plus a few others are also noted in > the secdir review [1]. I'm sure the author/shepherd/AD > will engage with the reviewer there too. > > [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05300.html I'll respond to that separately. Thanks, Nico -- From nobody Mon Dec 15 15:29:43 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FFB1A6F8B; Mon, 15 Dec 2014 15:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RBdr9B98EAr; Mon, 15 Dec 2014 15:29:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BB51A8F4B; Mon, 15 Dec 2014 15:28:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3B22FBE8B; Mon, 15 Dec 2014 23:28:55 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1gfPO0Ak_rG; Mon, 15 Dec 2014 23:28:54 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.41.48.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1D08FBE8A; Mon, 15 Dec 2014 23:28:54 +0000 (GMT) Message-ID: <548F6EB5.3020904@cs.tcd.ie> Date: Mon, 15 Dec 2014 23:28:53 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Nico Williams References: <20141215135220.10274.94846.idtracker@ietfa.amsl.com> <20141215232638.GO3241@localhost> In-Reply-To: <20141215232638.GO3241@localhost> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/23rPhvq10i132zUYcXBkX5KxJMI Cc: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Stephen Farrell's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:29:20 -0000 All good, just on this bit... On 15/12/14 23:26, Nico Williams wrote: > If there's boilerplate for all the types of bugs worth mentioning, let > me know. (If there isn't then maybe there should be. In any case, it's > not just buffer overflows. There could be integer overflows, double > frees and other dangling pointer dereferencing, null pointer > dereferencing, and other bugs.) Sadly not that I know of. If you happen to know of a victim^H^H^H^H^Hvolunteer do let me know:-) S. From nobody Mon Dec 15 15:29:45 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5258C1A899C; Mon, 15 Dec 2014 15:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA4OgRJSLPr3; Mon, 15 Dec 2014 15:29:14 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4361A8F4C; Mon, 15 Dec 2014 15:29:00 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id q108so7259079qgd.6 for ; Mon, 15 Dec 2014 15:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DXdu44B5cdmYGGJfLFrfAc5p9zcR4uEKRKs9z1UEz2g=; b=EgMIjNNTBm9F8jspAWmwnNGXbKAozSVUywsgsZC/bnB8ZHzdGnP6Xwp9w1h1+VhgDy yUFdt/u/sMyGor8EOxd3cms7U5TPDkmpRrp8FAQrDUdqGsyTheeQsMfoW2HW/FIGziFj sVxVY7B3JS8NipXtclhIHA+bnZTIPnMpd4nM9MOsQsLcyR8zERRJYsDAW33iVW7ZM07z g8Qj0uAfPz1VYEnH6pr91DWZ8ZybCcbX1pZ1Kzxv9BpxUKZ+E8hxZHNpDwSdjx69BeEj XAhNiWAkvZd5mtm0fHNSOcvenGb8keL8Jpf9OCixtcTRkvOR3FczRm9msqS6KDYzm/aP Tdbg== X-Received: by 10.140.102.13 with SMTP id v13mr39372317qge.68.1418686139784; Mon, 15 Dec 2014 15:28:59 -0800 (PST) Received: from [10.29.73.232] (mobile-166-172-058-168.mycingular.net. [166.172.58.168]) by mx.google.com with ESMTPSA id t5sm11999671qge.16.2014.12.15.15.28.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 15:28:58 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <548F57E9.8080307@qti.qualcomm.com> Date: Mon, 15 Dec 2014 23:28:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0894E0ED-E5D5-4F55-A99B-E3567A07F1B8@gmail.com> References: <20141215135220.10274.94846.idtracker@ietfa.amsl.com> <548F57E9.8080307@qti.qualcomm.com> To: Pete Resnick Archived-At: http://mailarchive.ietf.org/arch/msg/json/rgmpdw3Al5hS8SS970x6yL2MD3M Cc: "json-chairs@tools.ietf.org" , Stephen Farrell , "draft-ietf-json-text-sequence@tools.ietf.org" , The IESG , "json@ietf.org" Subject: Re: [Json] Stephen Farrell's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 23:29:21 -0000 Sorry, I'll go back to being on vacation now :-) Sent from my iPhone > On Dec 15, 2014, at 9:51 PM, Pete Resnick wrot= e: >=20 >> On 12/15/14 3:15 PM, Kathleen Moriarty wrote: >> If this gets marked as update needed, I'll make sure all the comments are= addressed before it proceeds. I think the author is motivated to do this q= uickly. >=20 > Kathleen, much as I would be delighted for you to make sure all the commen= ts are addressed, I think you are confusing this document with draft-joseffs= on. :-) (How amusing that we have draft-ietf-json..., draft-ietf-jose..., an= d draft-joseffson..., all on the same telechat.) >=20 > pr >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 From nobody Mon Dec 15 16:10:59 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FBB1A9060; Mon, 15 Dec 2014 16:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FPnVab3pwFD; Mon, 15 Dec 2014 16:10:35 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB8A1A8F3C; Mon, 15 Dec 2014 16:10:31 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Y0fia-0004kt-T2; Mon, 15 Dec 2014 19:10:24 -0500 Date: Mon, 15 Dec 2014 19:10:24 -0500 From: John Cowan To: Stephen Farrell Message-ID: <20141216001024.GB17490@mercury.ccil.org> References: <20141215135220.10274.94846.idtracker@ietfa.amsl.com> <20141215232638.GO3241@localhost> <548F6EB5.3020904@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548F6EB5.3020904@cs.tcd.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/FUlpdfNO8g6CAdrpzzKzg02ixLI Cc: draft-ietf-json-text-sequence@tools.ietf.org, Nico Williams , json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Stephen Farrell's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 00:10:43 -0000 Stephen Farrell scripsit: > Sadly not that I know of. If you happen to know of a > victim^H^H^H^H^Hvolunteer do let me know:-) Since someday it may happen that a victim must be found, I've got a little list, I've got a little list .... -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton From nobody Tue Dec 16 06:21:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384B21A1B5F; Tue, 16 Dec 2014 06:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfT9OQuXc7B8; Tue, 16 Dec 2014 06:20:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A734A1A1B6E; Tue, 16 Dec 2014 06:20:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141216142046.764.43871.idtracker@ietfa.amsl.com> Date: Tue, 16 Dec 2014 06:20:46 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/yWpKD2FMH615JZO4L0dQjWp8kGY Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org Subject: [Json] Ted Lemon's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 14:20:50 -0000 Ted Lemon has entered the following ballot position for draft-ietf-json-text-sequence-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not going to raise this as a DISCUSS because I'm on vacation and can't respond, but I am a bit concerned by the following text in the document: Multiple consecutive RS octets do not denote empty sequence elements between them, and can be ignored. The concern I have is that this document appears to suggest that a large dataset can be transferred as a series of json text sequences. But nowhere in the document (that I noticed) is it explained how each chunk of text is identified. It could be that they do not need to be identified: that each chunk stands alone. But suppose you are transferring array elements, rather than database tuples. In order to avoid a mis-count, it would have to be the case that each tuple contains the index of the array element that it represents. I suspect that the intention is actually that these sequences never be used this way, but it would be nice to state that explicitly, e.g. something like this: This document does not define a mechanism for reliably identifying text sequence by position (for example, when sending individual elements of an array as unique text sequences. Each json text sequence should therefore contain sufficient information that it is meaningful regardless of the order in which it appears in a stream of text sequences. From nobody Tue Dec 16 16:10:25 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C791A0387; Tue, 16 Dec 2014 16:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocCjxa2JOTX3; Tue, 16 Dec 2014 16:10:11 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5281E1A026F; Tue, 16 Dec 2014 16:10:10 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Y12Bo-0007CH-Jr; Tue, 16 Dec 2014 19:10:04 -0500 Date: Tue, 16 Dec 2014 19:10:04 -0500 From: John Cowan To: Ted Lemon Message-ID: <20141217001004.GA27047@mercury.ccil.org> References: <20141216142046.764.43871.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141216142046.764.43871.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/lg38J7FPY5ibord1ywaSNwzWnV4 Cc: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 00:10:23 -0000 Ted Lemon scripsit: > This document does not define a mechanism for reliably identifying > text sequence by position (for example, when sending individual > elements of an array as unique text sequences. Each json text > sequence should therefore contain sufficient information that > it is meaningful regardless of the order in which it appears > in a stream of text sequences. The second sentence does not follow from the first. It is perfectly possible to have an ordered list without the ability to reference a particular member of the list by an index number. A physical example would be a large book without printed page numbers. It is clear which page follows which, even though it is hard to figure out which page is the 500th. I recommend therefore dropping the second sentence. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org O beautiful for patriot's dream that sees beyond the years Thine alabaster cities gleam undimmed by human tears! America! America! God mend thine every flaw, Confirm thy soul in self-control, thy liberty in law! --one of the verses not usually taught in U.S. schools From nobody Tue Dec 16 16:28:58 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09FF1A19EC; Tue, 16 Dec 2014 16:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngJF9KkPrSFO; Tue, 16 Dec 2014 16:28:48 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 62DFA1A07BD; Tue, 16 Dec 2014 16:28:48 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 04C1A678063; Tue, 16 Dec 2014 16:28:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Dq6oU9Xzvbrnui yCH72dFdaG/kU=; b=suiBc6FHeIMfE1k5mPx/fDpJA0A9JlcXpcLXtsKLSxu6FR LiptOy+F1jUSK+MnNIYiEoxLTc3dKVn60bK2gKsyl8vRbLBU+SEAsldInJ/kBY5W G943dgimGAEB2x2it48h4HFmeUPnwVRtOOCuK57v4JHOsBfoZQPpaZ7MalYYo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 7FD5C678058; Tue, 16 Dec 2014 16:28:47 -0800 (PST) Date: Tue, 16 Dec 2014 18:28:47 -0600 From: Nico Williams To: Ted Lemon Message-ID: <20141217002842.GQ3241@localhost> References: <20141216142046.764.43871.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141216142046.764.43871.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/OJFYvh4aQ7O-v4NSg6VvtNJxEGo Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 00:28:50 -0000 On Tue, Dec 16, 2014 at 06:20:46AM -0800, Ted Lemon wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Multiple consecutive RS octets do not denote empty sequence elements > between them, and can be ignored. > > The concern I have is that this document appears to suggest that a large > dataset can be transferred as a series of json text sequences. But > nowhere in the document (that I noticed) is it explained how each chunk > of text is identified. It could be that they do not need to be > identified: that each chunk stands alone. But suppose you are > transferring array elements, rather than database tuples. In order to > avoid a mis-count, it would have to be the case that each tuple contains > the index of the array element that it represents. > > I suspect that the intention is actually that these sequences never be > used this way, but it would be nice to state that explicitly, e.g. The intention is that they not be emitted, but that they [optionally] be tolerated at parse time. > something like this: > > This document does not define a mechanism for reliably identifying > text sequence by position (for example, when sending individual > elements of an array as unique text sequences. [...] Well, yes, nor does it support random access. I would have thought this too obvious to mention. I probably did :) > [...]. Each json text > sequence should therefore contain sufficient information that > it is meaningful regardless of the order in which it appears > in a stream of text sequences. Whether or not the sequence elements should contain such information really depends on the application. I wouldn't want to say "should", not even distinguished from RFC2119 SHOULD. I'd be fine with this reworded to say that "applications may want to ...". Alternatively applications using this format should (perhaps even SHOULD, though this would really be a recommendation for application *designers*, not implementors) indicate whether truncated (which would include 'missing') texts should yield a fatal sequence parse error. Nico -- From nobody Tue Dec 16 18:53:38 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90ABB1A1A20; Tue, 16 Dec 2014 18:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pTy7NuU3QSC; Tue, 16 Dec 2014 18:53:32 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD73D1A0248; Tue, 16 Dec 2014 18:53:32 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id ECD62DA00D2; Wed, 17 Dec 2014 02:53:31 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 417E253E084; Tue, 16 Dec 2014 18:53:02 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 16 Dec 2014 18:53:02 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <20141217001004.GA27047@mercury.ccil.org> Date: Tue, 16 Dec 2014 21:52:55 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <29CB5A07-1DD4-4822-82E7-8DF1EF926043@nominum.com> References: <20141216142046.764.43871.idtracker@ietfa.amsl.com> <20141217001004.GA27047@mercury.ccil.org> To: John Cowan X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/json/c-UvK58uBa-4bb9gktEqdAcAvZ8 Cc: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 02:53:34 -0000 On Dec 16, 2014, at 7:10 PM, John Cowan wrote: > The second sentence does not follow from the first. It is perfectly > possible to have an ordered list without the ability to reference a > particular member of the list by an index number. A physical example > would be a large book without printed page numbers. It is clear which > page follows which, even though it is hard to figure out which page is > the 500th. Sure, but if a page is missing that's kind of a problem. In the case = of a log entry, the entry does contain all the information that the user = needs. It doesn't need an index, because log entries are ordered but = not indexed. Presumably the log entry has a timestamp, which is = sufficient to determine its ordering. I think you can make the case = that the text I suggested doesn't make this clear, so it might be good = to adjust it to make it clearer, but I am not quite on board with just = deleting the text entirely (although since it's a comment you are free = to do anything or nothing in response to the comment). From nobody Wed Dec 17 06:35:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A895E1A8A61; Wed, 17 Dec 2014 06:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZEndXiQFCTr; Wed, 17 Dec 2014 06:35:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6984D1A8547; Wed, 17 Dec 2014 06:35:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> Date: Wed, 17 Dec 2014 06:35:17 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/GZXboQhqc6Uj3SVpBc2mJwhIqZI Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org Subject: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 14:35:18 -0000 Richard Barnes has entered the following ballot position for draft-ietf-json-text-sequence-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 2.4.: The logic for having a terminator character here seems pretty fishy to me. Can you explain the scenario in which this setup actually results in truncated texts being detected? What is the piece of software that recognizes the truncation and chooses to omit the terminator? It seems like in the obvious design (source of JSON texts feeding into sequence encoder), you just end up with (RS LF) anyway. In order for this not to be the case, you need to have something in front of the sequence encoder that recognizes truncation and signals it to the encoder Section 2.4.: If you're going to have a terminator character, why 0x0A in particular? That character is valid in JSON texts, so using that as a terminator requires special processing on the JSON texts. As with the above, this seems to require an architecture in which the source of JSON texts cannot be independent of the sequence encoder (which kind of defeats the purpose of this supposedly lightweight sequence encoding). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2.2.: "textm" From nobody Wed Dec 17 07:58:53 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CCE1A88CF; Wed, 17 Dec 2014 07:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MamJ6FMU31I; Wed, 17 Dec 2014 07:58:50 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 647A41A1B8E; Wed, 17 Dec 2014 07:58:50 -0800 (PST) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 2ACC12005D00C; Wed, 17 Dec 2014 07:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=UzSav3yeIxgvTM VTU8+0vVa/CFg=; b=g646YwlILaN3bMKURqhJITzHtSnfRujmSLxrDA0yv7ZDP8 KIQkRpq11weV1QWBUKPJtDsMXYRd6CFuOdYEZ3S4e6Pivk1f/u76wKbSEnhoKAre 8Xptl/Avg/VT0H1Bsj+HipcNKDji/rNb2cGfBw6CQjIW4PsJDY+TAsFb5faEQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id A8D472005D00B; Wed, 17 Dec 2014 07:58:49 -0800 (PST) Date: Wed, 17 Dec 2014 09:58:49 -0600 From: Nico Williams To: Richard Barnes Message-ID: <20141217155844.GS3241@localhost> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/FHNaRex8zTy12se8PLhZ2TTfHrA Cc: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:58:51 -0000 On Wed, Dec 17, 2014 at 06:35:17AM -0800, Richard Barnes wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 2.4.: The logic for having a terminator character here seems > pretty fishy to me. Can you explain the scenario in which this setup > actually results in truncated texts being detected? What is the piece of Loggers that write(), possibly using O_APPEND. There's no guarantee under POSIX that any or all bytes written will reach stable storage, but whatever bytes do reach stable storage will be from the beginning of the buffer towards the end. (There was a commit in the Linux kernel recently, perhaps a year ago, that enabled posting SIGKILL to a process writing to a file with O_APPEND. The signal will interrupt the writer at a block boundary offset in the file being written. Other circumstances where one can expect similar behavior on other operating systems includes ENOSPC.) > software that recognizes the truncation and chooses to omit the > terminator? It seems like in the obvious design (source of JSON texts None. > feeding into sequence encoder), you just end up with (RS > LF) anyway. In order for this not to be the case, you need to have Not if the writer does a single write() or writev() to write the RS, the text, and the LF. And not even if it does multiple writes with a lock and dies in the middle of writing any one of those things. > something in front of the sequence encoder that recognizes truncation and > signals it to the encoder The idea is that the sequence encoder is also invoking the JSON text encoder, rather than operating on already-encoded JSON texts. > Section 2.4.: If you're going to have a terminator character, why 0x0A in > particular? That character is valid in JSON texts, so using that as a > terminator requires special processing on the JSON texts. As with the It's not that special, since you can scan for RS bytes and check that byte preceding the next RS is LF (or other ws; truncation isn't necessarily a problem, just truncation that leaves you with an ambiguous text). > above, this seems to require an architecture in which the source of JSON > texts cannot be independent of the sequence encoder (which kind of > defeats the purpose of this supposedly lightweight sequence encoding). I don't think this is true. One could simply bracket already-encoded texts with RS/LF -- the sequence encoder might not be certain that the texts are properly formed, but assuming that they are then the bracketing is sufficient. But yes, the design in mind is that the sequence encoder also invokes the JSON text encoder. Nico -- From nobody Wed Dec 17 10:25:19 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D191A1EF2; Wed, 17 Dec 2014 10:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOizDaYRxCGb; Wed, 17 Dec 2014 10:25:16 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B84571A1B75; Wed, 17 Dec 2014 10:25:16 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 4F89967C078; Wed, 17 Dec 2014 10:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=+xzHMa8WbpWe/w ms8Gx3EAZ7Ipc=; b=lQqI3JFmObRnZ29jceRjf85TtavepIGXs307D5krRfLIZO Gn8yuknPFCM5tu1tFvNr71OdeUiQKJ7ukaXkO72YxHR4B7jkvRQwRbUZ+tfswW5I g1elM/bkVLNkxNuxkGrSPokfq0aKIewp7wXyKKnr5ZPYnaLiPRyRiYQVlENns= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPA id AB73F67C074; Wed, 17 Dec 2014 10:25:15 -0800 (PST) Date: Wed, 17 Dec 2014 12:25:15 -0600 From: Nico Williams To: Ted Lemon Message-ID: <20141217182509.GZ3241@localhost> References: <20141216142046.764.43871.idtracker@ietfa.amsl.com> <20141217001004.GA27047@mercury.ccil.org> <29CB5A07-1DD4-4822-82E7-8DF1EF926043@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29CB5A07-1DD4-4822-82E7-8DF1EF926043@nominum.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/z8y5nupFf_DUPj3Sveu-DPFkFms Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, John Cowan , The IESG , json@ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 18:25:17 -0000 On Tue, Dec 16, 2014 at 09:52:55PM -0500, Ted Lemon wrote: > On Dec 16, 2014, at 7:10 PM, John Cowan wrote: > > The second sentence does not follow from the first. It is perfectly > > possible to have an ordered list without the ability to reference a > > particular member of the list by an index number. A physical example > > would be a large book without printed page numbers. It is clear which > > page follows which, even though it is hard to figure out which page is > > the 500th. > > Sure, but if a page is missing that's kind of a problem. In the case > of a log entry, the entry does contain all the information that the > user needs. It doesn't need an index, because log entries are > ordered but not indexed. Presumably the log entry has a timestamp, > which is sufficient to determine its ordering. I think you can make > the case that the text I suggested doesn't make this clear, so it > might be good to adjust it to make it clearer, but I am not quite on > board with just deleting the text entirely (although since it's a > comment you are free to do anything or nothing in response to the > comment). For a database application returning an indefinite number of rows, each as a JSON text in a JSON text sequence, there should be no concern about truncation of middle elements... ... unless the sequence encoder is not encoding (or validating) the sequence elements. In which case the sequence encoder should terminate the sequence at the first invalid text and signal an error. Truncation should only come up in logging applications. Nico -- From nobody Wed Dec 17 10:34:56 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED0D1A1B75; Wed, 17 Dec 2014 10:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8-f1aNo5iiC; Wed, 17 Dec 2014 10:34:54 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F2F1A1B16; Wed, 17 Dec 2014 10:34:54 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 91AB7DA00FB; Wed, 17 Dec 2014 18:34:57 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B7CB853E081; Wed, 17 Dec 2014 10:34:23 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Dec 2014 10:34:23 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <20141217182509.GZ3241@localhost> Date: Wed, 17 Dec 2014 13:34:05 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20141216142046.764.43871.idtracker@ietfa.amsl.com> <20141217001004.GA27047@mercury.ccil.org> <29CB5A07-1DD4-4822-82E7-8DF1EF926043@nominum.com> <20141217182509.GZ3241@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/json/ZJchMoeqTs7xRI4JJ39Vrnc1cEU Cc: John Cowan , json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 18:34:55 -0000 On Dec 17, 2014, at 1:25 PM, Nico Williams = wrote: > For a database application returning an indefinite number of rows, = each > as a JSON text in a JSON text sequence, there should be no concern = about > truncation of middle elements... >=20 > ... unless the sequence encoder is not encoding (or validating) the > sequence elements. In which case the sequence encoder should = terminate > the sequence at the first invalid text and signal an error. >=20 > Truncation should only come up in logging applications. If you want me to say I'm happy, you have to talk about this in the = document. If you don't care about me saying I'm happy, then there's no = need to explain things like this to me--I do understand the permutations = that might occur here. You don't have a required action item here = based on my comment unless your AD decides that you do. :) From nobody Wed Dec 17 10:58:45 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84FE1A3BA9; Wed, 17 Dec 2014 10:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5E9_XEN1BZR; Wed, 17 Dec 2014 10:58:43 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 25AE11A1B19; Wed, 17 Dec 2014 10:58:43 -0800 (PST) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 08AD52004CA3D; Wed, 17 Dec 2014 10:58:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=4PbE/TarS5nQQH arOtlAbmMpHsY=; b=RKostb9nhu/B3xfa/y6wAoVHSsZwrodOSV9MphJhTRSgV7 tm8hBH2r2oxNQan8qj97icHWWpf7pfMWIDh6t3osQMYm/wrsblO4SAFkxWTjfTVM q+N36fZQiWDPAkqCuWvKQidFqnsUD/YPFveaBbqnPPCkWv68IPxpj1BSF3Gaw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 72F8520046912; Wed, 17 Dec 2014 10:58:42 -0800 (PST) Date: Wed, 17 Dec 2014 12:58:41 -0600 From: Nico Williams To: Ted Lemon Message-ID: <20141217185835.GB3241@localhost> References: <20141216142046.764.43871.idtracker@ietfa.amsl.com> <20141217001004.GA27047@mercury.ccil.org> <29CB5A07-1DD4-4822-82E7-8DF1EF926043@nominum.com> <20141217182509.GZ3241@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/FO85x4WmRlQInetMQfGjiUq_Hqk Cc: John Cowan , json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 18:58:44 -0000 On Wed, Dec 17, 2014 at 01:34:05PM -0500, Ted Lemon wrote: > On Dec 17, 2014, at 1:25 PM, Nico Williams wrote: > > For a database application returning an indefinite number of rows, each > > as a JSON text in a JSON text sequence, there should be no concern about > > truncation of middle elements... > > > > ... unless the sequence encoder is not encoding (or validating) the > > sequence elements. In which case the sequence encoder should terminate > > the sequence at the first invalid text and signal an error. > > > > Truncation should only come up in logging applications. > > If you want me to say I'm happy, you have to talk about this in the > document. If you don't care about me saying I'm happy, then there's > no need to explain things like this to me--I do understand the > permutations that might occur here. You don't have a required action > item here based on my comment unless your AD decides that you do. :) I want you to be happy. I'll propose some text this afternoon. From nobody Wed Dec 17 11:09:20 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F8E1A1BC4; Wed, 17 Dec 2014 11:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvbFizeHaY28; Wed, 17 Dec 2014 11:09:15 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBE01A1B9C; Wed, 17 Dec 2014 11:09:15 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id CC6B2DA010A; Wed, 17 Dec 2014 19:09:18 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id C69E453E084; Wed, 17 Dec 2014 11:08:44 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Dec 2014 11:08:44 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <20141217185835.GB3241@localhost> Date: Wed, 17 Dec 2014 14:08:25 -0500 Content-Transfer-Encoding: 7bit Message-ID: <12574BD3-BBF1-4631-BDD9-AB89703E08F2@nominum.com> References: <20141216142046.764.43871.idtracker@ietfa.amsl.com> <20141217001004.GA27047@mercury.ccil.org> <29CB5A07-1DD4-4822-82E7-8DF1EF926043@nominum.com> <20141217182509.GZ3241@localhost> <20141217185835.GB3241@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/json/vVh1oAwXbwmgBGKYQAKbTA_OJdI Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, John Cowan , The IESG , json@ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:09:16 -0000 On Dec 17, 2014, at 1:58 PM, Nico Williams wrote: > I want you to be happy. I'll propose some text this afternoon. Thanks! From nobody Wed Dec 17 14:30:16 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E501A8736 for ; Wed, 17 Dec 2014 14:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAxmi3bH4Q-g for ; Wed, 17 Dec 2014 14:30:11 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF0E1A7008 for ; Wed, 17 Dec 2014 14:30:08 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so12780lbv.11 for ; Wed, 17 Dec 2014 14:30:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LpqDh2wR/z7UOn30V1V1YUnl4LfYgndhbUFiwthcFQQ=; b=AxBFxQ7RnJnYHGyoNyzZOns6/hxuStRGSgID2dPburvdoz0Y8JPaqODeICdpSMyxf8 N+37T1/XMKq+fg0k/95rG/2ptWvpu3nS+8gX4u1Kq+8QWy3GqRg1c7YKLWCgOYarDiLS 0IzYwesD4pZranWi/JKuKcw10e8XCeSQhUJW0jZ0bhu9fis55VbUt9WCGTw5+ocsPDoO LrjIugQ71FjZCETaveYYKx/YnY2WXSv8ICvRiO8Q8jRSxhFrpMhlt8+AsALzRk4XJVPx hWAs+uDzOrCYlim+u8Y80sM237GYpm+fCsO6BRnRg+Eh0MUFixrd7AUwtnEfDGW8981U kajQ== X-Gm-Message-State: ALoCoQkX/7KRnM4saZPMqCn7HslBu/jPYLz3+4N/YUJDIyDDhGc3Dc9iJ0gky7ixYpM/ifUbgEVu MIME-Version: 1.0 X-Received: by 10.152.5.67 with SMTP id q3mr43255185laq.73.1418855407123; Wed, 17 Dec 2014 14:30:07 -0800 (PST) Received: by 10.25.12.215 with HTTP; Wed, 17 Dec 2014 14:30:07 -0800 (PST) In-Reply-To: <20141217155844.GS3241@localhost> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> Date: Wed, 17 Dec 2014 17:30:07 -0500 Message-ID: From: Richard Barnes To: Nico Williams Content-Type: multipart/alternative; boundary=089e013d1734879602050a71047c Archived-At: http://mailarchive.ietf.org/arch/msg/json/MpLYFjUsczp4hL5QRhhVG0hoWro Cc: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:30:14 -0000 --089e013d1734879602050a71047c Content-Type: text/plain; charset=UTF-8 Inline. On Wed, Dec 17, 2014 at 10:58 AM, Nico Williams wrote: > > On Wed, Dec 17, 2014 at 06:35:17AM -0800, Richard Barnes wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Section 2.4.: The logic for having a terminator character here seems > > pretty fishy to me. Can you explain the scenario in which this setup > > actually results in truncated texts being detected? What is the piece of > > Loggers that write(), possibly using O_APPEND. There's no guarantee > under POSIX that any or all bytes written will reach stable storage, but > whatever bytes do reach stable storage will be from the beginning of the > buffer towards the end. > > (There was a commit in the Linux kernel recently, perhaps a year ago, > that enabled posting SIGKILL to a process writing to a file with > O_APPEND. The signal will interrupt the writer at a block boundary > offset in the file being written. Other circumstances where one can > expect similar behavior on other operating systems includes ENOSPC.) > > > software that recognizes the truncation and chooses to omit the > > terminator? It seems like in the obvious design (source of JSON texts > > None. > > > feeding into sequence encoder), you just end up with (RS > > LF) anyway. In order for this not to be the case, you need to have > > Not if the writer does a single write() or writev() to write the RS, the > text, and the LF. And not even if it does multiple writes with a lock > and dies in the middle of writing any one of those things. > > > something in front of the sequence encoder that recognizes truncation and > > signals it to the encoder > > The idea is that the sequence encoder is also invoking the JSON text > encoder, rather than operating on already-encoded JSON texts. > So it seems like in order to detect truncation, it needs to be true that the JSON text generator (the logger in the above example) is writes a 0x0A character after the text. This needs to be integrated into the thing submitting JSON texts to the sequence, or at least something earlier than any code that could cause truncation. This is not a requirement for a general JSON generator, so you need to state this requirement explicitly. Proposed text for the top of Section 2.4.: OLD: """ Parsers MUST drop JSON-text sequence elements consisting of non-self-delimited top-level values that may have been truncated (that are not delimited by whitespace). """ NEW: """ JSON text sequences use 0x0A as a "canary" octet to detect truncation. Parsers MUST drop JSON-text sequence elements consisting of non-self-delimited top-level values that do not end in a 0x0A character (since they have been truncated). Since JSON is not required to be terminated with a 0x0A character, this implies that the JSON texts that are input to a JSON text sequence MUST be suffixed with 0x0A before any point where truncation may occur. """ > > Section 2.4.: If you're going to have a terminator character, why 0x0A in > > particular? That character is valid in JSON texts, so using that as a > > terminator requires special processing on the JSON texts. As with the > > It's not that special, since you can scan for RS bytes and check that > byte preceding the next RS is LF (or other ws; truncation isn't > necessarily a problem, just truncation that leaves you with an ambiguous > text). > > > above, this seems to require an architecture in which the source of JSON > > texts cannot be independent of the sequence encoder (which kind of > > defeats the purpose of this supposedly lightweight sequence encoding). > > I don't think this is true. One could simply bracket already-encoded > texts with RS/LF -- the sequence encoder might not be certain that the > texts are properly formed, but assuming that they are then the > bracketing is sufficient. But yes, the design in mind is that the > sequence encoder also invokes the JSON text encoder. > Looking at the parser ABNF, this makes sense (since the 0x0A is not there). Consider this point cleared. --Richard > > Nico > -- > --089e013d1734879602050a71047c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Inline.

On Wed, Dec 17, 2014 at 10:58 AM, Nico Williams <nic= o@cryptonector.com> wrote:
On Wed, Dec 17, 2014 at 06:35:17AM -0800, R= ichard Barnes wrote:
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Section 2.4.: The logic for having a terminator character here seems > pretty fishy to me.=C2=A0 Can you explain the scenario in which this s= etup
> actually results in truncated texts being detected?=C2=A0 What is the = piece of

Loggers that write(), possibly using O_APPEND.=C2=A0 There's no = guarantee
under POSIX that any or all bytes written will reach stable storage, but whatever bytes do reach stable storage will be from the beginning of the buffer towards the end.

(There was a commit in the Linux kernel recently, perhaps a year ago,
that enabled posting SIGKILL to a process writing to a file with
O_APPEND.=C2=A0 The signal will interrupt the writer at a block boundary offset in the file being written.=C2=A0 Other circumstances where one can expect similar behavior on other operating systems includes ENOSPC.)

> software that recognizes the truncation and chooses to omit the
> terminator?=C2=A0 It seems like in the obvious design (source of JSON = texts

None.

> feeding into sequence encoder), you just end up with (RS <truncated= -JSON>
> LF) anyway.=C2=A0 In order for this not to be the case, you need to ha= ve

Not if the writer does a single write() or writev() to write the RS,= the
text, and the LF.=C2=A0 And not even if it does multiple writes with a lock=
and dies in the middle of writing any one of those things.

> something in front of the sequence encoder that recognizes truncation = and
> signals it to the encoder

The idea is that the sequence encoder is also invoking the JSON text=
encoder, rather than operating on already-encoded JSON texts.

So it seems like in order to= detect truncation, it needs to be true that the JSON text generator (the l= ogger in the above example) is writes a 0x0A character after the text.=C2= =A0 This needs to be integrated into the thing submitting JSON texts to the= sequence, or at least something earlier than any code that could cause tru= ncation.=C2=A0 This is not a requirement for a general JSON generator, so y= ou need to state this requirement explicitly.

= Proposed text for the top of Section 2.4.:
OLD:
"&qu= ot;"
Parsers MUST drop JSON-text sequence elements consisting of no= n-self-delimited top-level values that may have been truncated (that are no= t delimited by whitespace).
"""

NEW:"""
JSON text sequences use 0x0A as a "c= anary" octet to detect truncation.=C2=A0 Parsers MUST drop JSON-text s= equence elements consisting of=20 non-self-delimited top-level values that do not end in a 0x0A character (si= nce they have been truncated).=C2=A0 Since JSON is not required to be termi= nated with a 0x0A character, this implies that the JSON texts that are inpu= t to a JSON text sequence MUST be suffixed with 0x0A before any point where= truncation may occur.
"""

<= br>=C2=A0
> Section 2.4.: If you're going to have a terminator character, why = 0x0A in
> particular?=C2=A0 That character is valid in JSON texts, so using that= as a
> terminator requires special processing on the JSON texts.=C2=A0 As wit= h the

It's not that special, since you can scan for RS bytes and check= that
byte preceding the next RS is LF (or other ws; truncation isn't
necessarily a problem, just truncation that leaves you with an ambiguous text).

> above, this seems to require an architecture in which the source of JS= ON
> texts cannot be independent of the sequence encoder (which kind of
> defeats the purpose of this supposedly lightweight sequence encoding).=

I don't think this is true.=C2=A0 One could simply bracket alrea= dy-encoded
texts with RS/LF -- the sequence encoder might not be certain that the
texts are properly formed, but assuming that they are then the
bracketing is sufficient.=C2=A0 But yes, the design in mind is that the
sequence encoder also invokes the JSON text encoder.

Lo= oking at the parser ABNF, this makes sense (since the 0x0A is not there).= =C2=A0 Consider this point cleared.

--Richard

=C2=A0

Nico
--
--089e013d1734879602050a71047c-- From nobody Wed Dec 17 15:19:41 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E97E1A000B; Wed, 17 Dec 2014 15:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFv5a-6Q6YCZ; Wed, 17 Dec 2014 15:19:22 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 213F61A0013; Wed, 17 Dec 2014 15:19:19 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 003C4B805B; Wed, 17 Dec 2014 15:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0Bbg1gj/Ks/1xA AQS24riCUWbgU=; b=cWjwgf/A2FpZceTHdaYtcu5kI5gTQVaXrXbnIojihcb+5I ypTt6vZrll6iRWjdZKqTXvi+LUV35tLfOP/HsBZQ2QILCxFt+LI6K1sw7Og6eY2u LPy7402sxg68UVsA+XdNrs/Jg1h441d1Z/w84/sI74t1+bJuS+eOCuFpEOwxs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id 5CF9FB8057; Wed, 17 Dec 2014 15:19:18 -0800 (PST) Date: Wed, 17 Dec 2014 17:19:17 -0600 From: Nico Williams To: Richard Barnes Message-ID: <20141217231913.GE9443@localhost> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/yug7IStg0Bf_-1i5tln0i2blFXU Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 23:19:23 -0000 On Wed, Dec 17, 2014 at 05:30:07PM -0500, Richard Barnes wrote: > On Wed, Dec 17, 2014 at 10:58 AM, Nico Williams > wrote: > > The idea is that the sequence encoder is also invoking the JSON text > > encoder, rather than operating on already-encoded JSON texts. > > So it seems like in order to detect truncation, it needs to be true that > the JSON text generator (the logger in the above example) is writes a 0x0A Well, the sequence generator. There's no need for the JSON text encoder to do this, and we wouldn't want to impose such a requirement on the JSON text encoder. > character after the text. This needs to be integrated into the thing > submitting JSON texts to the sequence, or at least something earlier than > any code that could cause truncation. This is not a requirement for a Truncation detection is for the JSON text sequence parser. A sequence encoder that uses already-encoded JSON texts from other sources cannot detect truncation in them (unless those texts could only be taken from another JSON text sequence). Such a sequence encoder has to be responsible for arranging for truncation detection with the source of those already-encoded JSON texts. I could add text saying _that_, but I don't see how we can provide that arrangement here. We certainly couldn't impose a requirement for a trailing LF on JSON text encoders, as that would mean updating RFC7159. > general JSON generator, so you need to state this requirement explicitly. Isn't this explicit enough in section 2.2? > Proposed text for the top of Section 2.4.: > OLD: > """ > Parsers MUST drop JSON-text sequence elements consisting of > non-self-delimited top-level values that may have been truncated (that are > not delimited by whitespace). > """ > > NEW: > """ > JSON text sequences use 0x0A as a "canary" octet to detect truncation. This first new sentence is fine. > Parsers MUST drop JSON-text sequence elements consisting of > non-self-delimited top-level values that do not end in a 0x0A character > (since they have been truncated). Since JSON is not required to be > terminated with a 0x0A character, this implies that the JSON texts that are > input to a JSON text sequence MUST be suffixed with 0x0A before any point > where truncation may occur. > """ The second new sentence (the last one here) is superfluous if you accept the above responses as to sequence encoders using already-encoded JSON texts. > [...] > > Looking at the parser ABNF, this makes sense (since the 0x0A is not > there). Consider this point cleared. Thanks, Nico -- From nobody Wed Dec 17 15:25:24 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FC21A0010; Wed, 17 Dec 2014 15:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYYxynELFXoh; Wed, 17 Dec 2014 15:25:21 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 280D81A0008; Wed, 17 Dec 2014 15:25:21 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 05FCA584057; Wed, 17 Dec 2014 15:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3i7HJ4L81NWr6y EwbII+3qHTz3Y=; b=tSvw3OQ0WHmXQusJGFIG51PhDRabsZL+goG7OniC60Qprx uB7ry9+xJmWs6Oxrbf6c9y6OX3Ohcqjhj3+ZadnNPMx5tEhMDbpVfnHCP4vBZqWZ yY+5uPIIzugrnE3HXF/pwUorw/228FhfSHEmWQ6VlEF/7TT14bE/q0art1Y/w= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id 85C65584059; Wed, 17 Dec 2014 15:25:20 -0800 (PST) Date: Wed, 17 Dec 2014 17:25:20 -0600 From: Nico Williams To: Ted Lemon Message-ID: <20141217232514.GG9443@localhost> References: <20141216142046.764.43871.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141216142046.764.43871.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/0rj5zFCI3HX8Y9fXD2DX0V7DRDM Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 23:25:22 -0000 On Tue, Dec 16, 2014 at 06:20:46AM -0800, Ted Lemon wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [...] > > I suspect that the intention is actually that these sequences never be > used this way, but it would be nice to state that explicitly, e.g. > something like this: > > This document does not define a mechanism for reliably identifying > text sequence by position (for example, when sending individual > elements of an array as unique text sequences. Each json text > sequence should therefore contain sufficient information that > it is meaningful regardless of the order in which it appears > in a stream of text sequences. > How about (at the end of section 2.3): This document does not define a mechanism for reliably identifying text sequence by position (for example, when sending individual elements of an array as unique text sequences). For applications where truncation is a possibility, this means that intended sequence elements can be truncated, and can even be missing entirely, therefore a reference to an nth element would be unreliable. ? Nico -- From nobody Wed Dec 17 18:50:46 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2731A004C; Wed, 17 Dec 2014 18:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wm-dFmsTpxQa; Wed, 17 Dec 2014 18:50:40 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DA21A00C5; Wed, 17 Dec 2014 18:50:37 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 8DAB5DA0107; Thu, 18 Dec 2014 02:50:42 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 0E31753E084; Wed, 17 Dec 2014 18:50:07 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Dec 2014 18:50:06 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <20141217232514.GG9443@localhost> Date: Wed, 17 Dec 2014 21:49:44 -0500 Content-Transfer-Encoding: 7bit Message-ID: References: <20141216142046.764.43871.idtracker@ietfa.amsl.com> <20141217232514.GG9443@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/json/y-TLYQOcIxKCdaW8smFooGxgqNg Cc: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Ted Lemon's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 02:50:41 -0000 On Dec 17, 2014, at 6:25 PM, Nico Williams wrote: > This document does not define a mechanism for reliably identifying > text sequence by position (for example, when sending individual > elements of an array as unique text sequences). For applications > where truncation is a possibility, this means that intended sequence > elements can be truncated, and can even be missing entirely, > therefore a reference to an nth element would be unreliable. That'll do it. Thanks! From nobody Thu Dec 18 07:00:58 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1BB1A8A60; Thu, 18 Dec 2014 07:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD97Zb6FWseQ; Thu, 18 Dec 2014 07:00:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 885BB1A9037; Thu, 18 Dec 2014 07:00:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218150041.13480.56779.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 07:00:41 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/z82tkWVJg34BLsfTSFqqJI1Za0A Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org Subject: [Json] Barry Leiba's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 15:00:52 -0000 Barry Leiba has entered the following ballot position for draft-ietf-json-text-sequence-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've asked that the media type registration request be posted to the media-types@iana.org list for comment. That's been done, and there's been a little discussion that's resulted in some suggestions for a couple of minor changes, but nothing major. I consider this point cleared, knowing that the minor changes are coming. From nobody Thu Dec 18 10:11:02 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E9D1A1B94 for ; Thu, 18 Dec 2014 10:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy66P0jaWM43; Thu, 18 Dec 2014 10:10:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3301A1BC0; Thu, 18 Dec 2014 10:10:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218181052.801.63983.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 10:10:52 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/DXaS8M63haR5O-ROzZv12Xz638w Subject: [Json] ID Tracker State Update Notice: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 18:10:59 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ From nobody Thu Dec 18 11:19:31 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673031A916C for ; Thu, 18 Dec 2014 11:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mzm3G4SCqUo for ; Thu, 18 Dec 2014 11:19:27 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AD91A9238 for ; Thu, 18 Dec 2014 11:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1068; q=dns/txt; s=iport; t=1418930358; x=1420139958; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JSux/mWYvEl7GmbcIo8S7e24j7cbBP2QtvLM3bxsrpc=; b=NXSpRrbrWjuHajHqxh1La4zg6YJPohA5PjwKxuZTCL6m2o2umowdW2cJ 2f0HS3QGKGnisDGlCJev5yjAR04F87Y1Ib7mauV87IwAlCadxtVwYv++0 FjMxtDbrC0XQYpV0y3U0P1VWMmo5FTuI3Sae6GdVLDQ0yEwHcCNNg41kP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAL8nk1StJV2b/2dsb2JhbABagwZSWASDAsMThXoCgSYWAQEBAQF9hA0BAQQjVQEQCw4MAgUWCwICCQMCAQIBRQYNAQUCAQGIKLsrljIBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhjh4zB4JogUEBBIlDiAWFMoV+i0QiggAcgXBPgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="381141488" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 18 Dec 2014 19:19:16 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sBIJJGV1007474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 19:19:16 GMT Received: from [10.129.24.63] (10.129.24.63) by xhc-rcd-x10.cisco.com (173.37.183.84) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 18 Dec 2014 13:19:16 -0600 Message-ID: <549328B3.8040808@cisco.com> Date: Thu, 18 Dec 2014 12:19:15 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Bray References: <547DFE75.8080903@cisco.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.63] Archived-At: http://mailarchive.ietf.org/arch/msg/json/skYbn4ZStRs23bgsD8eNHYTuYQo Cc: IETF JSON WG Subject: Re: [Json] I-JSON Outstanding AD Issues: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:19:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, It has been a couple of weeks since the question on Numbers was posed. So far, the responses (including those from the original discussion) appear to be in favor of substituting "MUST NOT assume"/"MUST NOT expect" with "cannot assume"/"cannot expect". Unless anyone has strong objections, the editor should submit a revised I-D with the suggested change. Thanks, - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUkyizAAoJEDWi+S0W7cO1OLoH/0b44mqppq0T0HOpSrK0IyUR 3asYhT4ewJvcIsXLg2Q2L4hbbeK0K8Ag4f/En8euFqAmZpv98E4LHWG/xHm0/s/I djRH0bO2lzEnJeAB4gWOJmanPtPMFhM7Wx3VgVteJGvI8iv7HNv7JPIAQSIkl+kR FsTnZhTuwm/CpMMkBlDOqxhwEtllnkkRUftDSXzxINhTANTS0e2db+p12u50s9b3 ZwDCjBnjdfVmvE124GSVWtqVKtTF9bZzcnZHvIdrZyzhfYUDKR+ZwtyVUl5BPlbT YjAL4wiuU4rUtyFIlICC1J6PMZMU2p/IgO8UCotv+vV2usTcQ5TSUF1lYYU9sHw= =DfDm -----END PGP SIGNATURE----- From nobody Thu Dec 18 11:20:28 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EA31A9250 for ; Thu, 18 Dec 2014 11:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oCp61QPJHI3 for ; Thu, 18 Dec 2014 11:20:21 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855631A923B for ; Thu, 18 Dec 2014 11:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=992; q=dns/txt; s=iport; t=1418930421; x=1420140021; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=PMfev2x4HkEoCZ81ehz54gf9wZkFgP1GAzn1wYsDnos=; b=PjKUKdgftQrssPmCELt1YFQq1ggyn1x6z0DMDmw/vYlCVvpfaYuSwRcM RjzRUXKiMS1vA2XH9xMlUwoEaw5AXuXeouxU+RxZHK/bBgKsDeZaDL7uW iTv36NqaxckOrQ8WK7M0hA19kLS2+cPEIItwskJjwq1JLYdYsVuDWiG9H o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAD8ok1StJV2a/2dsb2JhbABagwZSWASDAsMThXoCgSYWAQEBAQF9hA0BAQQjDwFFEQsaAgUWCwICCQMCAQIBRQYNBgIBAYgouzGWMQEBAQEBAQEDAQEBAQEBAQEWBIEhjh46gmiBQQWJQ4gFhTKFfotEIoIAHIFwT4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="381104719" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 18 Dec 2014 19:20:21 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBIJKKdI006957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Dec 2014 19:20:20 GMT Received: from [10.129.24.63] (10.129.24.63) by xhc-rcd-x10.cisco.com (173.37.183.84) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 18 Dec 2014 13:20:20 -0600 Message-ID: <549328F3.2040406@cisco.com> Date: Thu, 18 Dec 2014 12:20:19 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IETF JSON WG References: <547DFE31.6030507@cisco.com> <547EB4D0.8010901@it.aoyama.ac.jp> In-Reply-To: <547EB4D0.8010901@it.aoyama.ac.jp> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.63] Archived-At: http://mailarchive.ietf.org/arch/msg/json/oMgocfBwN3XgN3HwaGDxH8mzvws Subject: Re: [Json] I-JSON Outstanding AD Issues: Software Behavior X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:20:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, A couple of weeks have passed since the question on Software Behavior was posed. So far, all of the responses (of which there are two) appear to be in favor of Pete's proposed changes. Unless anyone has strong objections, the editor should submit a revised I-D with the new text. Thanks, - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUkyjzAAoJEDWi+S0W7cO1/tYH/jXFSNnYhETrWhjVzLvOmjMr IO6NxB70fRqoVTRwpHhD6eAd3JDkFxbDg3JynCq8uQg3P/4gF7mXfOs7rq22UTJM lDykQsBKSDwQv80mdzx2y4ZeOhQoteHiwGMWQ5dviYgsPVQ6cNzQOaAbJCFboxlU 0WojPlBf0F2AtLdu80izq3/JMiF+jgyuunLEu1GwsMtyGIziL9vq56THJMk+ZeMH neTLWDqvT3YpASn1EzA+ebXkWn1ttTrxlBnvRrLO21OANtbelDPpGYFWRTqq5Sqk 4/GQKwBrBezezz07XvvtekFipUPFxExVvUpgwOCYkgLqgabr6dOwbqCQdvTZNH0= =Ub5/ -----END PGP SIGNATURE----- From nobody Thu Dec 18 20:12:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EFD1A00CD; Thu, 18 Dec 2014 20:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7LNPSh7xzgv; Thu, 18 Dec 2014 20:11:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D36741A0120; Thu, 18 Dec 2014 20:11:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.8.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219041158.26181.37195.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 20:11:58 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/K_Ugu6erWiI_vgPK3asQrTsIE9w Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-i-json-05.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 04:12:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JavaScript Object Notation Working Group of the IETF. Title : The I-JSON Message Format Author : Tim Bray Filename : draft-ietf-json-i-json-05.txt Pages : 6 Date : 2014-12-18 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-ietf-json-i-json/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-i-json-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-i-json-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 18 20:13:17 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C9D1A006F for ; Thu, 18 Dec 2014 20:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f0epD94HIBY for ; Thu, 18 Dec 2014 20:13:11 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01601A00BE for ; Thu, 18 Dec 2014 20:13:10 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id u10so188870lbd.6 for ; Thu, 18 Dec 2014 20:13:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=mxIjLIqqGbZkjJiikI2fB/yPoaC52oqx6bRBIrDioV8=; b=DtKzK6VvbdRiK93k1pL8i90MkbYuMJWlm+KefzDEOAEEK3ZBydlQdg9ATZgdHZUiCQ yQY+Mbi8Sx6FvNI61FUaVUiO6P61YfTNl4nWJKv0SP3gRNwGNoiiiyTpPOX3vA7JyKUV 94RR9+pJYGywHj9f3Fo0lzPgRmNLn9hnrVBQk7EkPpxkwpoooH34QMRKYJOTjppkxRoy yu7CcY8vikeRWztMzX77wLauUyJO4JAOe1sLWOJ0/GMgjWXlfZqyu6cfndIhDhyO2vE6 eEBtnAeOR2vtTFd1gQrrA5BvpC4XIJ8C1KA4MVGNgl9pjG7f75AtNE+/ICbXi0Ikd/jG W/sw== X-Gm-Message-State: ALoCoQnBNe+m7158BGh48Gzt7FXZdSHOmq8mmWt0wwBfFT5O8fTMjGrkEc5mUh162H4c9iHPuFAo X-Received: by 10.112.99.71 with SMTP id eo7mr5750768lbb.26.1418962389123; Thu, 18 Dec 2014 20:13:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.2.212 with HTTP; Thu, 18 Dec 2014 20:12:48 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <20141219041158.26181.37195.idtracker@ietfa.amsl.com> References: <20141219041158.26181.37195.idtracker@ietfa.amsl.com> From: Tim Bray Date: Thu, 18 Dec 2014 20:12:48 -0800 Message-ID: To: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a113488a2275e6b050a89edff Archived-At: http://mailarchive.ietf.org/arch/msg/json/lPMNRxy_Z4ZSYB6wsG3WKQ24eEY Subject: Re: [Json] I-D Action: draft-ietf-json-i-json-05.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 04:13:16 -0000 --001a113488a2275e6b050a89edff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Real HTML at http://www.tbray.org/tmp/draft-ietf-json-i-json-05.html On Thu, Dec 18, 2014 at 8:11 PM, wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the JavaScript Object Notation Working Grou= p > of the IETF. > > Title : The I-JSON Message Format > Author : Tim Bray > Filename : draft-ietf-json-i-json-05.txt > Pages : 6 > Date : 2014-12-18 > > 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-ietf-json-i-json/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-json-i-json-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-i-json-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a113488a2275e6b050a89edff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rea= l HTML at=C2=A0http://www.tbray.org/tmp/draft-ietf-json-i-json-05.html

On Thu, Dec 1= 8, 2014 at 8:11 PM, <internet-drafts@ietf.org> wrote= :

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the JavaScript Object Notation Working G= roup of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The I-JSON Message Format
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Tim = Bray
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-json-i-json-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2014-12-18

Abstract:
=C2=A0 =C2=A0I-JSON is a restricted profile of JSON designed to maximize =C2=A0 =C2=A0interoperability and increase confidence that software can pro= cess it
=C2=A0 =C2=A0successfully with predictable results.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-json-i-json/
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-json-i-json-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-i-json-0= 5


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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


--
- Tim Bray (If you=E2=80=99d like to s= end me a private message, see https://keybase.io/timbray)
--001a113488a2275e6b050a89edff-- From nobody Fri Dec 19 13:44:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71871A1B7A; Fri, 19 Dec 2014 13:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNC_Q4wlCaMY; Fri, 19 Dec 2014 13:44:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CB81AC41A; Fri, 19 Dec 2014 13:43:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219214357.10356.51486.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 13:43:57 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/xbv6W-H2jPKFdeK-ntngZC1qr6s Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-text-sequence-12.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 21:44:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JavaScript Object Notation Working Group of the IETF. Title : JavaScript Object Notation (JSON) Text Sequences Author : Nicolas Williams Filename : draft-ietf-json-text-sequence-12.txt Pages : 11 Date : 2014-12-19 Abstract: This document describes the JSON text sequence format and associated media type, "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x1A). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-text-sequence-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 19 13:44:07 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B45E1A1B7A for ; Fri, 19 Dec 2014 13:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOyRNLQWmoHX; Fri, 19 Dec 2014 13:44:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7021ACDB1; Fri, 19 Dec 2014 13:43:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org, presnick@qti.qualcomm.com, rlb@ipv.sx X-Test-IDTracker: no X-IETF-IDTracker: 5.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141219214357.10356.39127.idtracker@ietfa.amsl.com> Date: Fri, 19 Dec 2014 13:43:57 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/fIBEH5xpaHstNeiJ_SlMGnD7udc Subject: [Json] New Version Notification - draft-ietf-json-text-sequence-12.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 21:44:03 -0000 A new version (-12) has been submitted for draft-ietf-json-text-sequence: http://www.ietf.org/internet-drafts/draft-ietf-json-text-sequence-12.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Dec 22 08:48:48 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0983D1A1A6E for ; Mon, 22 Dec 2014 08:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geojsIpWdkWF for ; Mon, 22 Dec 2014 08:48:39 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA5A1A1A7D for ; Mon, 22 Dec 2014 08:48:39 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id w7so4202397lbi.30 for ; Mon, 22 Dec 2014 08:48:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ac+Z547yxnCCLf97QlkxurUkITCgGw5r6aaj6FoUMAs=; b=Vxe96UVip9BHl7f2971WvHMUC3+/zSfjTfgktx3k2wEgPh7sVq1Xdg+Iy5UBAeKogD 6tIusZV90o38bzJa827K9h0TM0Ua3iIRv1GaoQuaeSsdWwKPpoqS5iC8i23tHddiq5XP TR/tUq39wL7gUIQlc3KNA915BjC1L1lWuJNhkQafwHedn8585cXTI1F4j1MBvuVGLBR2 5hE3xxtBHubsCyBvglvvHYiE65MIvOjO20y88nZ/wIyJNUFAcGHQ/JxSAI5+FbxfyM2q qV11krU/17BrOb32cX0E7Sp8kz2hhuZpaMmfkbhjO9ltwbkh9h17h6ajc0t2VtPUjzZ6 OK9w== X-Gm-Message-State: ALoCoQlVNjXxq6I0mv6vlgOK4qlbOzNHO4OcETRFCIFThdjiVNDRZB7/0sPNLSSVgOP853DFjBpt MIME-Version: 1.0 X-Received: by 10.152.29.129 with SMTP id k1mr23260226lah.10.1419266917564; Mon, 22 Dec 2014 08:48:37 -0800 (PST) Received: by 10.25.12.215 with HTTP; Mon, 22 Dec 2014 08:48:37 -0800 (PST) In-Reply-To: <20141217231913.GE9443@localhost> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> Date: Mon, 22 Dec 2014 11:48:37 -0500 Message-ID: From: Richard Barnes To: Nico Williams Content-Type: multipart/alternative; boundary=089e0160b7da769946050ad0d420 Archived-At: http://mailarchive.ietf.org/arch/msg/json/qi3_PWPQrk8_9Z-nlr1vXHAnJp8 Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 16:48:42 -0000 --089e0160b7da769946050ad0d420 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 17, 2014 at 6:19 PM, Nico Williams wrote: > > On Wed, Dec 17, 2014 at 05:30:07PM -0500, Richard Barnes wrote: > > On Wed, Dec 17, 2014 at 10:58 AM, Nico Williams > > wrote: > > > The idea is that the sequence encoder is also invoking the JSON text > > > encoder, rather than operating on already-encoded JSON texts. > > > > So it seems like in order to detect truncation, it needs to be true that > > the JSON text generator (the logger in the above example) is writes a > 0x0A > > Well, the sequence generator. There's no need for the JSON text encoder > to do this, and we wouldn't want to impose such a requirement on the > JSON text encoder. > > > character after the text. This needs to be integrated into the thing > > submitting JSON texts to the sequence, or at least something earlier than > > any code that could cause truncation. This is not a requirement for a > > Truncation detection is for the JSON text sequence parser. > > A sequence encoder that uses already-encoded JSON texts from other > sources cannot detect truncation in them (unless those texts could only > be taken from another JSON text sequence). > > Such a sequence encoder has to be responsible for arranging for > truncation detection with the source of those already-encoded JSON > texts. I could add text saying _that_, but I don't see how we can > provide that arrangement here. We certainly couldn't impose a > requirement for a trailing LF on JSON text encoders, as that would mean > updating RFC7159. > > > general JSON generator, so you need to state this requirement explicitly. > > Isn't this explicit enough in section 2.2? > > > Proposed text for the top of Section 2.4.: > > OLD: > > """ > > Parsers MUST drop JSON-text sequence elements consisting of > > non-self-delimited top-level values that may have been truncated (that > are > > not delimited by whitespace). > > """ > > > > NEW: > > """ > > JSON text sequences use 0x0A as a "canary" octet to detect truncation. > > This first new sentence is fine. > > > Parsers MUST drop JSON-text sequence elements consisting of > > non-self-delimited top-level values that do not end in a 0x0A character > > (since they have been truncated). Since JSON is not required to be > > terminated with a 0x0A character, this implies that the JSON texts that > are > > input to a JSON text sequence MUST be suffixed with 0x0A before any point > > where truncation may occur. > > """ > > The second new sentence (the last one here) is superfluous if you accept > the above responses as to sequence encoders using already-encoded JSON > texts. > I think you're still missing my point here. If I understand your use case right, you're envisioning the following process: JSON.stringify -> sprintf("\x1E%s\x0A", text) --(trunc)--> Append to sequence That's a particular processing chain, and I agree that the truncation detection provides value in that case. What I'm trying to say is that there are other ways of encoding a sequence that meet the same production ABNF, but which do *not* provide truncation detection. Most obviously: JSON.stringify --(trunc)--> sprintf("\x1E%s\x0A", text) --> Append to sequence That's why we need to say that the 0x0A needs to be added before truncation can occur. It's a critical requirement for truncation detection to work. It's not redundant with 2.2, since it's an additional requirement on the process of encoding (beyond the ABNF). --Richard > > [...] > > > > Looking at the parser ABNF, this makes sense (since the 0x0A is not > > there). Consider this point cleared. > > Thanks, > > Nico > -- > --089e0160b7da769946050ad0d420 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 17, 2014 at 6:19 PM, Nico Williams <nico@cryptonector.= com> wrote:
On Wed, Dec 17, = 2014 at 05:30:07PM -0500, Richard Barnes wrote:
> On Wed, Dec 17, 2014 at 10:58 AM, Nico Williams <nico@cryptonector.com>
> wrote:
> > The idea is that the sequence encoder is = also invoking the JSON text
> > encoder, rather than operating on already-encoded JSON texts.
>
> So it seems like in order to detect truncation, it needs to be true th= at
> the JSON text generator (the logger in the above example) is writes a = 0x0A

Well, the sequence generator.=C2=A0 There's no need for the JSON= text encoder
to do this, and we wouldn't want to impose such a requirement on the JSON text encoder.

> character after the text.=C2=A0 This needs to be integrated into the t= hing
> submitting JSON texts to the sequence, or at least something earlier t= han
> any code that could cause truncation.=C2=A0 This is not a requirement = for a

Truncation detection is for the JSON text sequence parser.

A sequence encoder that uses already-encoded JSON texts from other
sources cannot detect truncation in them (unless those texts could only
be taken from another JSON text sequence).

Such a sequence encoder has to be responsible for arranging for
truncation detection with the source of those already-encoded JSON
texts.=C2=A0 I could add text saying _that_, but I don't see how we can=
provide that arrangement here.=C2=A0 We certainly couldn't impose a
requirement for a trailing LF on JSON text encoders, as that would mean
updating RFC7159.

> general JSON generator, so you need to state this requirement explicit= ly.

Isn't this explicit enough in section 2.2?

> Proposed text for the top of Section 2.4.:
> OLD:
> """
> Parsers MUST drop JSON-text sequence elements consisting of
> non-self-delimited top-level values that may have been truncated (that= are
> not delimited by whitespace).
> """
>
> NEW:
> """
> JSON text sequences use 0x0A as a "canary" octet to detect t= runcation.

This first new sentence is fine.

> Parsers MUST drop JSON-text sequence elements consisting of
> non-self-delimited top-level values that do not end in a 0x0A characte= r
> (since they have been truncated).=C2=A0 Since JSON is not required to = be
> terminated with a 0x0A character, this implies that the JSON texts tha= t are
> input to a JSON text sequence MUST be suffixed with 0x0A before any po= int
> where truncation may occur.
> """

The second new sentence (the last one here) is superfluous if you ac= cept
the above responses as to sequence encoders using already-encoded JSON
texts.

I think you're still missing= my point here.=C2=A0 If I understand your use case right, you're envis= ioning the following process:

JSON.stringify ->= sprintf("\x1E%s\x0A", text) --(trunc)--> Append to sequence

That's a particular processing chain, and I agr= ee that the truncation detection provides value in that case.=C2=A0 What I&= #39;m trying to say is that there are other ways of encoding a sequence tha= t meet the same production ABNF, but which do *not* provide truncation dete= ction.=C2=A0 Most obviously:

JSON.stringify --(tru= nc)--> sprintf("\x1E%s\x0A", text) --> Append to sequence

That's why we need to say that the 0x0A needs t= o be added before truncation can occur.=C2=A0 It's a critical requireme= nt for truncation detection to work.

It's not = redundant with 2.2, since it's an additional requirement on the process= of encoding (beyond the ABNF).


--R= ichard

=C2=A0
> [...]
>
> Looking at the parser ABNF, this makes sense (since the 0x0A is not > there).=C2=A0 Consider this point cleared.

Thanks,

Nico
--
--089e0160b7da769946050ad0d420-- From nobody Mon Dec 22 10:00:37 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959111AC3C9; Mon, 22 Dec 2014 10:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 428SXlXoCvfA; Mon, 22 Dec 2014 10:00:34 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B07061AC3A8; Mon, 22 Dec 2014 10:00:34 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 7204F594061; Mon, 22 Dec 2014 10:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=v1Y1/vyl9jlJ2S 26ElQMX8dzGyo=; b=FBHHPnZN2PT55jsxVOqpyV5nKmb9gg2lV8nmz2zeRMn1H6 1i6P0BZTdVlnMd6EZb1PEh4Mt2v2z/QOZgVwh7aPUOy4sr3kZO1amSRgK1HZW11L ATWX5+o0a9JCyiOjl9k1HZL0ccuimXfhjScUXIPJaeKBHxLSHg5+vvefoNPSU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id EC174594059; Mon, 22 Dec 2014 10:00:33 -0800 (PST) Date: Mon, 22 Dec 2014 12:00:33 -0600 From: Nico Williams To: Richard Barnes Message-ID: <20141222180028.GF12662@localhost> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/o8czOoOf6PzNHtjEQ5Y_oSHMyjU Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 18:00:35 -0000 On Mon, Dec 22, 2014 at 11:48:37AM -0500, Richard Barnes wrote: > I think you're still missing my point here. If I understand your use case > right, you're envisioning the following process: > > JSON.stringify -> sprintf("\x1E%s\x0A", text) --(trunc)--> Append to > sequence Yes. > That's a particular processing chain, and I agree that the truncation > detection provides value in that case. What I'm trying to say is that > there are other ways of encoding a sequence that meet the same production > ABNF, but which do *not* provide truncation detection. Most obviously: > > JSON.stringify --(trunc)--> sprintf("\x1E%s\x0A", text) --> Append to > sequence > > That's why we need to say that the 0x0A needs to be added before truncation > can occur. It's a critical requirement for truncation detection to work. The source of potential truncation of interest in this document is "append to a file". Other sources of corruption (e.g., transmission over an insecure and fragile transport protocol) don't merely stop at truncation, and we can't do anything about those other forms of corruption as "JSON text sequence" is not a cryptographic format. How would append-to-file truncation occur in this second case? Clearly the file can't be a JSON text sequence, since otherwise a JSON text sequence encoder would have been in a position to ensure the writing of the LF. The source of truncation has to have been an append to a file meant to contain a *single* JSON text, but then the writer isn't a logger, and can take additional steps to ensure atomic operation. Therefore I don't think this case can really occur. This feels like a turtles-all-the-way-down situation, resolved by noting that either each sequence encoder in the chain invokves the JSON text sequence encoder itself, or is otherwise parsing and re-encoding a previously-encoded JSON text sequence. We can't make the JSON text encoder the last turtle, since that would mean updating RFC7159 here, which we can't really consider. All of this leads me to think that this is a use case to be considered out of scope or recommended against. The latter looks like a recommendation (or requirement) that the JSON text sequence encoder also be the one invoking the JSON text encoder. I'd even rather discourage the use of top-level numbers, true, false, and null, rather than agree to the text you proposed that I objected to. Instead, if you still think we need to say anything more, I'd rather say either that the second use case you mention above is out of scope. Nico -- From nobody Mon Dec 22 11:01:44 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658621A3BA3 for ; Mon, 22 Dec 2014 11:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2VsX6nM_lgZ for ; Mon, 22 Dec 2014 11:01:36 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BCE1A6F28 for ; Mon, 22 Dec 2014 11:01:33 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id pv20so4332454lab.41 for ; Mon, 22 Dec 2014 11:01:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zVsoUTbhxiVV1JiyOun1hSiv+8Wq9Yiz0pMoHVfpMvc=; b=XXPuTveNsIwoyx8nfVwr8ew3rwjdHeoZ10VUO4xOAVvqaMXpZDJPJUCESlTVacjXRq mvEe0+eoLMZYVb4BhgqWJH81w8UwExfEMcIsJ/WYxTdqjp+YyTMAhsUrDCXTXFV4ez7y achsCdUlvv1C30gO1mLkNPurlNrVQBxEim2ob9iqwH+NJX9KZXfY0++QAhVETKnjaERN v1KVS+8BU5pZEf1MBdyeECG3iUDaFLXzDVqR/7T/hHd0ieVr3CZhVj3MgqMmG3PXYWoU bQNcOwpm2hp/2PSQbbCkyRhNfSCOAtyEUyFS9R+XsNQ/oJ4ruxG0jrtOappSdrxsJmnV VokQ== X-Gm-Message-State: ALoCoQnwHvBL3sN9NpgZOPfO84dKFzyGwNxpNRvJb8tis9Uo9WmrYhRl/1kQgNEVkm4wUFrBnSNC MIME-Version: 1.0 X-Received: by 10.112.170.36 with SMTP id aj4mr23384945lbc.3.1419274891993; Mon, 22 Dec 2014 11:01:31 -0800 (PST) Received: by 10.25.12.215 with HTTP; Mon, 22 Dec 2014 11:01:31 -0800 (PST) In-Reply-To: <20141222180028.GF12662@localhost> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> <20141222180028.GF12662@localhost> Date: Mon, 22 Dec 2014 14:01:31 -0500 Message-ID: From: Richard Barnes To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c261fcc6bbce050ad2af52 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Dd-DxsgluUf_R_4VIrt6VESStn0 Cc: draft-ietf-json-text-sequence@tools.ietf.org, json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 19:01:37 -0000 --001a11c261fcc6bbce050ad2af52 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 22, 2014 at 1:00 PM, Nico Williams wrote: > > On Mon, Dec 22, 2014 at 11:48:37AM -0500, Richard Barnes wrote: > > I think you're still missing my point here. If I understand your use > case > > right, you're envisioning the following process: > > > > JSON.stringify -> sprintf("\x1E%s\x0A", text) --(trunc)--> Append to > > sequence > > Yes. > > > That's a particular processing chain, and I agree that the truncation > > detection provides value in that case. What I'm trying to say is that > > there are other ways of encoding a sequence that meet the same production > > ABNF, but which do *not* provide truncation detection. Most obviously: > > > > JSON.stringify --(trunc)--> sprintf("\x1E%s\x0A", text) --> Append to > > sequence > > > > That's why we need to say that the 0x0A needs to be added before > truncation > > can occur. It's a critical requirement for truncation detection to work. > > The source of potential truncation of interest in this document is > "append to a file". That assumption is not stated anywhere in the document. > Other sources of corruption (e.g., transmission > over an insecure and fragile transport protocol) don't merely stop at > truncation, and we can't do anything about those other forms of > corruption as "JSON text sequence" is not a cryptographic format. > > How would append-to-file truncation occur in this second case? Wouldn't that arise if you had something file-like between the JSON producer and the sequence encoder? For example: > json-logger >/tmp/log-pipe > sequence-encoder Clearly > the file can't be a JSON text sequence, since otherwise a JSON text > sequence encoder would have been in a position to ensure the writing of > the LF. The source of truncation has to have been an append to a file > meant to contain a *single* JSON text, but then the writer isn't a > logger, and can take additional steps to ensure atomic operation. > Therefore I don't think this case can really occur. > > This feels like a turtles-all-the-way-down situation, resolved by noting > that either each sequence encoder in the chain invokves the JSON text > sequence encoder itself, or is otherwise parsing and re-encoding a > previously-encoded JSON text sequence. We can't make the JSON text > encoder the last turtle, since that would mean updating RFC7159 here, > which we can't really consider. > > All of this leads me to think that this is a use case to be considered > out of scope or recommended against. The latter looks like a > recommendation (or requirement) that the JSON text sequence encoder also > be the one invoking the JSON text encoder. > > I'd even rather discourage the use of top-level numbers, true, false, > and null, rather than agree to the text you proposed that I objected to. > Instead, if you still think we need to say anything more, I'd rather say > either that the second use case you mention above is out of scope. > > Nico > -- > --001a11c261fcc6bbce050ad2af52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 22, 2014 at 1:00 PM, Nico Williams <nico@cryptonector.= com> wrote:
On= Mon, Dec 22, 2014 at 11:48:37AM -0500, Richard Barnes wrote:
> I think you're still missing my point here.=C2=A0 If I understand = your use case
> right, you're envisioning the following process:
>
> JSON.stringify -> sprintf("\x1E%s\x0A", text) --(trunc)--= > Append to
> sequence

Yes.

> That's a particular processing chain, and I agree that the truncat= ion
> detection provides value in that case.=C2=A0 What I'm trying to sa= y is that
> there are other ways of encoding a sequence that meet the same product= ion
> ABNF, but which do *not* provide truncation detection.=C2=A0 Most obvi= ously:
>
> JSON.stringify --(trunc)--> sprintf("\x1E%s\x0A", text) -= -> Append to
> sequence
>
> That's why we need to say that the 0x0A needs to be added before t= runcation
> can occur.=C2=A0 It's a critical requirement for truncation detect= ion to work.

The source of potential truncation of interest in this document is "append to a file".=C2=A0

That a= ssumption is not stated anywhere in the document.

= =C2=A0
Other sources of corruption (e.g= ., transmission
over an insecure and fragile transport protocol) don't merely stop at truncation, and we can't do anything about those other forms of
corruption as "JSON text sequence" is not a cryptographic format.=

How would append-to-file truncation occur in this second case?
=

Wouldn't that arise if you had something file-like = between the JSON producer and the sequence encoder?=C2=A0 For example:
> json-logger >/tmp/log-pipe
> sequence-encoder &l= t;/tmp/log-pipe

--Richard

=C2=A0
=C2=A0 Clearly
the file can't be a JSON text sequence, since otherwise a JSON text
sequence encoder would have been in a position to ensure the writing of
the LF.=C2=A0 The source of truncation has to have been an append to a file=
meant to contain a *single* JSON text, but then the writer isn't a
logger, and can take additional steps to ensure atomic operation.
Therefore I don't think this case can really occur.

This feels like a turtles-all-the-way-down situation, resolved by noting that either each sequence encoder in the chain invokves the JSON text
sequence encoder itself, or is otherwise parsing and re-encoding a
previously-encoded JSON text sequence.=C2=A0 We can't make the JSON tex= t
encoder the last turtle, since that would mean updating RFC7159 here,
which we can't really consider.

All of this leads me to think that this is a use case to be considered
out of scope or recommended against.=C2=A0 The latter looks like a
recommendation (or requirement) that the JSON text sequence encoder also be the one invoking the JSON text encoder.

I'd even rather discourage the use of top-level numbers, true, false, and null, rather than agree to the text you proposed that I objected to. Instead, if you still think we need to say anything more, I'd rather sa= y
either that the second use case you mention above is out of scope.

Nico
--
--001a11c261fcc6bbce050ad2af52-- From nobody Mon Dec 22 11:21:27 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BAB1A6FA3; Mon, 22 Dec 2014 11:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YawhcQCWERMe; Mon, 22 Dec 2014 11:21:22 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E0AF61A6FA9; Mon, 22 Dec 2014 11:21:17 -0800 (PST) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id BA88E161C; Mon, 22 Dec 2014 11:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=fHfSbMepTcTGpC JTB4c0n6zYPb4=; b=S5pj4UeiRSeaXwnKI6rYFTv5nMWWw22tJWuGuM3Q7TemDZ a5vfWh4iHMZ5IF6YH21Fca9MntemW/vSMDiYGeGyLlodvugRgiQV+XVjUkxv8blj 9fcGmAqSTcSUpH6HOjNiPBwrXdPoN5kszqH6tB4oBl74Xlm9zNRZC7HJt+Ipo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id 37E6F1619; Mon, 22 Dec 2014 11:21:17 -0800 (PST) Date: Mon, 22 Dec 2014 13:21:16 -0600 From: Nico Williams To: Richard Barnes Message-ID: <20141222192111.GG12662@localhost> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> <20141222180028.GF12662@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/PmboTh4SjPyojx9TSZ7f4rPGmfY Cc: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 19:21:23 -0000 On Mon, Dec 22, 2014 at 02:01:31PM -0500, Richard Barnes wrote: > On Mon, Dec 22, 2014 at 1:00 PM, Nico Williams > wrote: > > The source of potential truncation of interest in this document is > > "append to a file". > > That assumption is not stated anywhere in the document. It's mentioned in section 2.3: Per- Section 2.1, JSON text sequence parsers should not abort when an octet string contains a malformed JSON text, instead the JSON text sequence parser should skip to the next RS. Such a situation may arise in contexts where, for example, append-writes to log files are truncated by the filesystem (e.g., due to a crash, or administrative process termination). (as it appears in -12, which here is the same as -11 + s/textm/text,/). This (and only this) source of truncation was one reason we ended up with RS in the format at all. Otherwise all we'd need is a ws after non-self- delimited top-level JSON texts. The other reason is that the RS is also useful for implementations that don't have an incremental JSON text parser (thus the sequence parser has to find the entire possible-JSON-text octet string to feed to the JSON text parser, and without RS or similar, it couldn't). (There are applications using a JSON text sequence format with no RS and even no LF or other ws, where all the texts are objects. These sequences look like this: {"a":"foo"}{"a":"bar"}... A sequence parser with access to an incremental JSON text parser can manage to parse this, but if all you have is a parser that wants complete texts, then you lose. Whereas {"a":"foo"}{"a":"bar"} can be parsed with any kind of off-the-shelf JSON text parser.) > > Other sources of corruption (e.g., transmission > > over an insecure and fragile transport protocol) don't merely stop at > > truncation, and we can't do anything about those other forms of > > corruption as "JSON text sequence" is not a cryptographic format. > > > > How would append-to-file truncation occur in this second case? > > Wouldn't that arise if you had something file-like between the JSON > producer and the sequence encoder? For example: > > json-logger >/tmp/log-pipe > > sequence-encoder X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769CE1A6F10 for ; Mon, 22 Dec 2014 12:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkaIxxGU74UN for ; Mon, 22 Dec 2014 12:14:51 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE1A1A6F8E for ; Mon, 22 Dec 2014 12:14:50 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so4427631lbg.19 for ; Mon, 22 Dec 2014 12:14:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/q89gSxtstdsk30ZasVyEaeGPbeeNjMurUM/2ch1+p4=; b=fgig6n8A278Z3C+REdXWdfS2dqo5m6DkGtCc506qXIwr2HE5kRuzcRBA2cfZyNwHdy Fo1Bhr/EFtEmyHV/AdkZ7rvBlUkswKeIraoAIgoTYb6Vq1LJKI6W62SJFiAAKW4WA8iJ 8JV7yUTnmuCx7BllfBRJh1sjw4ljxMUaxMnTC12+xkbVgpfDjVIo4zuy9Jm9mAc5xtcK uuCwhCh0wAut8lRooSrSCgG741wVabx6LjRCMExL/vC3DJcrmnnN2jkMX1yBYHfqWJW7 pGDjHqdXAdYaB4n0slwQXNlQ8jQHyfib5KThiyoLIEWf7uzv83D9nmUOcJyqFoEUkmov CJYg== X-Gm-Message-State: ALoCoQmf3P3Zzoxxj0SROnaPM9ywdCkg+WLLkyjL43MXFZQMRYDfGapGF7iZoJrfQUqn9jMZCqw9 MIME-Version: 1.0 X-Received: by 10.152.5.67 with SMTP id q3mr23649339laq.73.1419279288866; Mon, 22 Dec 2014 12:14:48 -0800 (PST) Received: by 10.25.12.215 with HTTP; Mon, 22 Dec 2014 12:14:48 -0800 (PST) In-Reply-To: <20141222192111.GG12662@localhost> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> <20141222180028.GF12662@localhost> <20141222192111.GG12662@localhost> Date: Mon, 22 Dec 2014 15:14:48 -0500 Message-ID: From: Richard Barnes To: Nico Williams Content-Type: multipart/alternative; boundary=089e013d1734d9ada4050ad3b5c3 Archived-At: http://mailarchive.ietf.org/arch/msg/json/7a6UTw8xvIwPNILPtNJqLdjb7qg Cc: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 20:14:53 -0000 --089e013d1734d9ada4050ad3b5c3 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 22, 2014 at 2:21 PM, Nico Williams wrote: > > On Mon, Dec 22, 2014 at 02:01:31PM -0500, Richard Barnes wrote: > > On Mon, Dec 22, 2014 at 1:00 PM, Nico Williams > > wrote: > > > The source of potential truncation of interest in this document is > > > "append to a file". > > > > That assumption is not stated anywhere in the document. > > It's mentioned in section 2.3: > > Per- Section 2.1, JSON text sequence parsers should not abort when an > octet string contains a malformed JSON text, instead the JSON text > sequence parser should skip to the next RS. Such a situation may > arise in contexts where, for example, append-writes to log files are > truncated by the filesystem (e.g., due to a crash, or administrative > process termination). > "May arise" does not mean "this mechanism is only useful when". See suggested text below. > (as it appears in -12, which here is the same as -11 + s/textm/text,/). > > This (and only this) source of truncation was one reason we ended up > with RS in the format at all. Otherwise all we'd need is a ws after > non-self- delimited top-level JSON texts. > > The other reason is that the RS is also useful for implementations that > don't have an incremental JSON text parser (thus the sequence parser has > to find the entire possible-JSON-text octet string to feed to the JSON > text parser, and without RS or similar, it couldn't). > > (There are applications using a JSON text sequence format with no RS and > even no LF or other ws, where all the texts are objects. These > sequences look like this: {"a":"foo"}{"a":"bar"}... A sequence parser > with access to an incremental JSON text parser can manage to parse this, > but if all you have is a parser that wants complete texts, then you > lose. Whereas {"a":"foo"}{"a":"bar"} can be parsed with > any kind of off-the-shelf JSON text parser.) > > > > Other sources of corruption (e.g., transmission > > > over an insecure and fragile transport protocol) don't merely stop at > > > truncation, and we can't do anything about those other forms of > > > corruption as "JSON text sequence" is not a cryptographic format. > > > > > > How would append-to-file truncation occur in this second case? > > > > Wouldn't that arise if you had something file-like between the JSON > > producer and the sequence encoder? For example: > > > json-logger >/tmp/log-pipe > > > sequence-encoder > It depends on the OS. For POSIX systems there's a write() size below > which writes to pipes are atomic, and above which they are not, and even > in the latter case, if there's only one writer there's no problem > unless the writer dies (which the reader probably can't detect, unless > it's the writer's parent process). > So you're saying it could arise :) > I think informative text warning that truncation that occurs between > JSON text encoding and JSON text sequence encoding cannot be detected. > Proposed for Section 2.3, after the above-quoted paragraph: """ The JSON text sequence structure described by the encoding ABNF allows for the detection under certain circumstances. Namely, if you view the text sequence as a collection of "records" of the form (RS JSON-text LF), then it is possible for a parser to recognize when a record has been truncated (as described in Section 2.4). This mechanism does not cover other cases, e.g., if the JSON text is truncated before the LF octet is appended. Implementations that rely on the JSON text sequence structure to detect truncation MUST ensure that JSON texts end in LF before any point where truncation might occur. """ --Richard > > Nico > -- > --089e013d1734d9ada4050ad3b5c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 22, 2014 at 2:21 PM, Nico Williams <nico@cryptonector.= com> wrote:
On= Mon, Dec 22, 2014 at 02:01:31PM -0500, Richard Barnes wrote:
> On Mon, Dec 22, 2014 at 1:00 PM, Nico Williams <nico@cryptonector.com>
> wrote:
> > The source of potential truncation of int= erest in this document is
> > "append to a file".
>
> That assumption is not stated anywhere in the document.

It's mentioned in section 2.3:

=C2=A0 =C2=A0Per- Section 2.1, JSON text sequence parsers should not abort = when an
=C2=A0 =C2=A0octet string contains a malformed JSON text, instead the JSON = text
=C2=A0 =C2=A0sequence parser should skip to the next RS.=C2=A0 Such a situa= tion may
=C2=A0 =C2=A0arise in contexts where, for example, append-writes to log fil= es are
=C2=A0 =C2=A0truncated by the filesystem (e.g., due to a crash, or administ= rative
=C2=A0 =C2=A0process termination).

&quo= t;May arise" does not mean "this mechanism is only useful when&qu= ot;.=C2=A0 See suggested text below.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> (as it appears in -12, which here is the same as -11 + s/textm/text,/).

This (and only this) source of truncation was one reason we ended up
with RS in the format at all.=C2=A0 Otherwise all we'd need is a ws aft= er
non-self- delimited top-level JSON texts.

The other reason is that the RS is also useful for implementations that
don't have an incremental JSON text parser (thus the sequence parser ha= s
to find the entire possible-JSON-text octet string to feed to the JSON
text parser, and without RS or similar, it couldn't).

(There are applications using a JSON text sequence format with no RS and even no LF or other ws, where all the texts are objects.=C2=A0 These
sequences look like this: {"a":"foo"}{"a":&qu= ot;bar"}...=C2=A0 A sequence parser
with access to an incremental JSON text parser can manage to parse this, but if all you have is a parser that wants complete texts, then you
lose.=C2=A0 Whereas <RS>{"a":"foo"}<LF><= RS>{"a":"bar"}<LF> can be parsed with
any kind of off-the-shelf JSON text parser.)

> > Other sources of corruption (e.g., transmission
> > over an insecure and fragile transport protocol) don't merely= stop at
> > truncation, and we can't do anything about those other forms = of
> > corruption as "JSON text sequence" is not a cryptograph= ic format.
> >
> > How would append-to-file truncation occur in this second case? >
> Wouldn't that arise if you had something file-like between the JSO= N
> producer and the sequence encoder?=C2=A0 For example:
> > json-logger >/tmp/log-pipe
> > sequence-encoder </tmp/log-pipe

It depends on the OS.=C2=A0 For POSIX systems there's a write() = size below
which writes to pipes are atomic, and above which they are not, and even in the latter case, if there's only one writer there's no problem unless the writer dies (which the reader probably can't detect, unless<= br> it's the writer's parent process).

<= div>So you're saying it could arise :) =C2=A0

= =C2=A0
I think informative text warning that truncation that occurs between
JSON text encoding and JSON text sequence encoding cannot be detected.
<= /blockquote>

Proposed for Section 2.3, after the above-q= uoted paragraph:
"""
The JSON text seque= nce structure described by the encoding ABNF allows
for the detec= tion under certain circumstances.=C2=A0 Namely, if you view the text
<= div>sequence as a collection of "records" of the form (RS JSON-te= xt LF), then=C2=A0
it is possible for a parser to recognize when = a record has been truncated
(as described in Section 2.4).=C2=A0 = This mechanism does not cover other cases,=C2=A0
e.g., if the JSO= N text is truncated before the LF octet is appended. =C2=A0
Imple= mentations that rely on the JSON text sequence structure to detect
truncation MUST ensure that JSON texts end in LF before any point where
truncation might occur.
"""
--Richard



=C2=A0

Nico
--
--089e013d1734d9ada4050ad3b5c3-- From nobody Mon Dec 22 12:19:11 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BB91A8848; Mon, 22 Dec 2014 12:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45iLxpvjgu3m; Mon, 22 Dec 2014 12:19:07 -0800 (PST) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7E71AC3E2; Mon, 22 Dec 2014 12:19:07 -0800 (PST) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id 3698820046B15; Mon, 22 Dec 2014 12:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=34Z7FM2mYAqHgW 0BQj25UQ16a3Q=; b=mOSXtc+RRFxhjnEzg9I7PH5Ex17VHQdhXVN3T8wEHAgaR+ 22f6ETjc2aZPuvxXo36LGvTC2XhaKS0sunxyl0Vje/1mMBefy8wIGKqPsukI/2ve 5wE6f6kVBht2q18KHyQ9YekL156MEqf8L2YQ0wWlK9Oq0R3GznHO3LJMHOsKI= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPA id B9E1720046913; Mon, 22 Dec 2014 12:19:06 -0800 (PST) Date: Mon, 22 Dec 2014 14:19:06 -0600 From: Nico Williams To: Richard Barnes Message-ID: <20141222201900.GH12662@localhost> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> <20141222180028.GF12662@localhost> <20141222192111.GG12662@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/cDgPA4nMvFyUQTv6MPqBEBU-fgk Cc: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 20:19:08 -0000 On Mon, Dec 22, 2014 at 03:14:48PM -0500, Richard Barnes wrote: > On Mon, Dec 22, 2014 at 2:21 PM, Nico Williams > wrote: > > > Wouldn't that arise if you had something file-like between the JSON > > > producer and the sequence encoder? For example: > > > > json-logger >/tmp/log-pipe > > > > sequence-encoder > > > It depends on the OS. For POSIX systems there's a write() size below > > which writes to pipes are atomic, and above which they are not, and even > > in the latter case, if there's only one writer there's no problem > > unless the writer dies (which the reader probably can't detect, unless > > it's the writer's parent process). > > So you're saying it could arise :) Yes, I suppose so :) > > I think informative text warning that truncation that occurs between > > JSON text encoding and JSON text sequence encoding cannot be detected. > > Proposed for Section 2.3, after the above-quoted paragraph: > """ > The JSON text sequence structure described by the encoding ABNF allows > for the detection under certain circumstances. Namely, if you view the text > sequence as a collection of "records" of the form (RS JSON-text LF), then > it is possible for a parser to recognize when a record has been truncated > (as described in Section 2.4). This mechanism does not cover other cases, > e.g., if the JSON text is truncated before the LF octet is appended. > Implementations that rely on the JSON text sequence structure to detect > truncation MUST ensure that JSON texts end in LF before any point where > truncation might occur. > """ Alright, I'll take this. Nico -- From nobody Mon Dec 22 12:31:01 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FF01A6FFB for ; Mon, 22 Dec 2014 12:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYop8XYehHWs for ; Mon, 22 Dec 2014 12:30:54 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7821A6F10 for ; Mon, 22 Dec 2014 12:30:54 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gm9so4670749lab.12 for ; Mon, 22 Dec 2014 12:30:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Mj0gXDb4WlbKUIaFOPUedDWg/TUVgpEx1Ykl3RBRiyU=; b=kQarlMMc4pRNEV9cCaDlMylzexLIoAEvuBKnwkURRDm9p45zHL5KS8cHGmXoNpgbTY 9FjFKAEIUAEEX3rufVlp2G+QtJSqOvz1rnGWdZ5StaWueMGBc3lvylBznpMLC8e50rqb mHxK2kIyCl93cpg0nNA/2aBh/xHPFvJ6XcyH2dSbig1g3eeu6IOOMG2v3TiEOB8rlgtP woRWT6pHT+3sh6rnTODvgM+oTi3+LkAHNGdXa5QBiFMLGBZvKw8fJk0sv4XqKSIqNh50 aoSR7VKSXDLlFMrdCKnyuJsv2v/SlWGbOKrClzoVuU9kb29HVmZd9EUgDncn/cy+0mAA l2mQ== X-Gm-Message-State: ALoCoQm08udeX884GhxDvnN0Oc34tsdacA5aO9BYMVH/py+AfQ9QmooVWtJAwP+R8pHZIcDLgdwr MIME-Version: 1.0 X-Received: by 10.112.128.233 with SMTP id nr9mr8351047lbb.49.1419280252484; Mon, 22 Dec 2014 12:30:52 -0800 (PST) Received: by 10.25.12.215 with HTTP; Mon, 22 Dec 2014 12:30:52 -0800 (PST) In-Reply-To: <20141222201900.GH12662@localhost> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> <20141222180028.GF12662@localhost> <20141222192111.GG12662@localhost> <20141222201900.GH12662@localhost> Date: Mon, 22 Dec 2014 15:30:52 -0500 Message-ID: From: Richard Barnes To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b34396a4957b2050ad3ef31 Archived-At: http://mailarchive.ietf.org/arch/msg/json/qO8wcHbRAOMcuje2VdkYAzl724w Cc: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 20:30:56 -0000 --047d7b34396a4957b2050ad3ef31 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 22, 2014 at 3:19 PM, Nico Williams wrote: > > On Mon, Dec 22, 2014 at 03:14:48PM -0500, Richard Barnes wrote: > > On Mon, Dec 22, 2014 at 2:21 PM, Nico Williams > > wrote: > > > > Wouldn't that arise if you had something file-like between the JSON > > > > producer and the sequence encoder? For example: > > > > > json-logger >/tmp/log-pipe > > > > > sequence-encoder > > > > > It depends on the OS. For POSIX systems there's a write() size below > > > which writes to pipes are atomic, and above which they are not, and > even > > > in the latter case, if there's only one writer there's no problem > > > unless the writer dies (which the reader probably can't detect, unless > > > it's the writer's parent process). > > > > So you're saying it could arise :) > > Yes, I suppose so :) > > > > I think informative text warning that truncation that occurs between > > > JSON text encoding and JSON text sequence encoding cannot be detected. > > > > Proposed for Section 2.3, after the above-quoted paragraph: > > """ > > The JSON text sequence structure described by the encoding ABNF allows > > for the detection under certain circumstances. Namely, if you view the > text > > sequence as a collection of "records" of the form (RS JSON-text LF), then > > it is possible for a parser to recognize when a record has been truncated > > (as described in Section 2.4). This mechanism does not cover other > cases, > > e.g., if the JSON text is truncated before the LF octet is appended. > > Implementations that rely on the JSON text sequence structure to detect > > truncation MUST ensure that JSON texts end in LF before any point where > > truncation might occur. > > """ > > Alright, I'll take this. > Great. Let me know when that's in, and I'll clear. --Richard > > Nico > -- > --047d7b34396a4957b2050ad3ef31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 22, 2014 at 3:19 PM, Nico Williams <nico@cryptonector.= com> wrote:
On= Mon, Dec 22, 2014 at 03:14:48PM -0500, Richard Barnes wrote:
> On Mon, Dec 22, 2014 at 2:21 PM, Nico Williams <nico@cryptonector.com>
> wrote:
> > > Wouldn't that arise if you had s= omething file-like between the JSON
> > > producer and the sequence encoder?=C2=A0 For example:
> > > > json-logger >/tmp/log-pipe
> > > > sequence-encoder </tmp/log-pipe
> >
> > It depends on the OS.=C2=A0 For POSIX systems there's a write= () size below
> > which writes to pipes are atomic, and above which they are not, a= nd even
> > in the latter case, if there's only one writer there's no= problem
> > unless the writer dies (which the reader probably can't detec= t, unless
> > it's the writer's parent process).
>
> So you're saying it could arise :)

Yes, I suppose so :)

> > I think informative text warning that truncation that occurs betw= een
> > JSON text encoding and JSON text sequence encoding cannot be dete= cted.
>
> Proposed for Section 2.3, after the above-quoted paragraph:
> """
> The JSON text sequence structure described by the encoding ABNF allows=
> for the detection under certain circumstances.=C2=A0 Namely, if you vi= ew the text
> sequence as a collection of "records" of the form (RS JSON-t= ext LF), then
> it is possible for a parser to recognize when a record has been trunca= ted
> (as described in Section 2.4).=C2=A0 This mechanism does not cover oth= er cases,
> e.g., if the JSON text is truncated before the LF octet is appended. > Implementations that rely on the JSON text sequence structure to detec= t
> truncation MUST ensure that JSON texts end in LF before any point wher= e
> truncation might occur.
> """

Alright, I'll take this.

Gre= at.=C2=A0 Let me know when that's in, and I'll clear.
--Richard
=C2=A0

Nico
--
--047d7b34396a4957b2050ad3ef31-- From nobody Mon Dec 22 12:53:19 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEBC1A7020; Mon, 22 Dec 2014 12:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7Cy7N53SuH0; Mon, 22 Dec 2014 12:53:13 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535631A7003; Mon, 22 Dec 2014 12:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1419281593; x=1450817593; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=bbSixyTFQ0CWdHP6rqzPVUMObn6lHsaJWnMQQX+D500=; b=eSLjDNj2ivXAChPfUgd+mp185LqDQG0ODEobDvBQb+w8DXgSK4rA6ueN 4CZL7/Dm6GpLkRPZGbtZ8LTRDB1M5j+sblHBJMY+t+bgozEu6QvTrWwij Kb9IIRwL05G1lfn9EPqMNHayByrG8idOqOnPUDfJ7JsJHg0ozvHXgc4pt 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7660"; a="94836756" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Dec 2014 12:53:12 -0800 X-IronPort-AV: E=Sophos;i="5.07,626,1413270000"; d="scan'208,217";a="803209504" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Dec 2014 12:53:11 -0800 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 22 Dec 2014 12:53:10 -0800 Message-ID: <549884B4.5030301@qti.qualcomm.com> Date: Mon, 22 Dec 2014 14:53:08 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Richard Barnes References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> <20141222180028.GF12662@localhost> <20141222192111.GG12662@localhost> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060401070302040800070808" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: http://mailarchive.ietf.org/arch/msg/json/EqY6kglGB2umoabwGLXCzaaHnYc Cc: draft-ietf-json-text-sequence@tools.ietf.org, Nico Williams , json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 20:53:15 -0000 --------------060401070302040800070808 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 12/22/14 2:14 PM, Richard Barnes wrote: > > I think informative text warning that truncation that occurs between > JSON text encoding and JSON text sequence encoding cannot be detected. > > > Proposed for Section 2.3, after the above-quoted paragraph: > """ > The JSON text sequence structure described by the encoding ABNF allows > for the detection under certain circumstances. I assume there's a missing "of truncation" after "detection", eh? > Namely, if you view the text > sequence as a collection of "records" of the form (RS JSON-text LF), then > it is possible for a parser to recognize when a record has been truncated > (as described in Section 2.4). This mechanism does not cover other > cases, > e.g., if the JSON text is truncated before the LF octet is appended. > Implementations that rely on the JSON text sequence structure to detect > truncation MUST ensure that JSON texts end in LF before any point where > truncation might occur. > """ Very MUSTy of you. Are you equally OK with the following? Namely, if you view the text sequence as a collection of "records" of the form (RS JSON-text LF), then it is possible for a parser to recognize when a record has been truncated (as described in Section 2.4). However, this mechanism does not cover other cases. Importantly, truncation cannot be detected if the JSON text is truncated before the LF octet is appended. Since we're shooting for something "informative". pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------060401070302040800070808 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 12/22/14 2:14 PM, Richard Barnes wrote:
I think informative text warning that truncation that occurs between
JSON text encoding and JSON text sequence encoding cannot be detected.

Proposed for Section 2.3, after the above-quoted paragraph:
"""
The JSON text sequence structure described by the encoding ABNF allows
for the detection under certain circumstances.

I assume there's a missing "of truncation" after "detection", eh?

Namely, if you view the text
sequence as a collection of "records" of the form (RS JSON-text LF), then 
it is possible for a parser to recognize when a record has been truncated
(as described in Section 2.4).  This mechanism does not cover other cases, 
e.g., if the JSON text is truncated before the LF octet is appended.  
Implementations that rely on the JSON text sequence structure to detect
truncation MUST ensure that JSON texts end in LF before any point where
truncation might occur.
"""

Very MUSTy of you. Are you equally OK with the following?

   Namely, if you view the text sequence as a collection of "records" of
   the form (RS JSON-text LF), then it is possible for a parser to
   recognize when a record has been truncated (as described in Section
   2.4).  However, this mechanism does not cover other cases.
   Importantly, truncation cannot be detected if the JSON text is
   truncated before the LF octet is appended.

Since we're shooting for something "informative".

pr

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------060401070302040800070808-- From nobody Mon Dec 22 13:06:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0EE1A86E0 for ; Mon, 22 Dec 2014 13:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qmkj4N7ct2au for ; Mon, 22 Dec 2014 13:06:13 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8151A86F3 for ; Mon, 22 Dec 2014 13:05:56 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gd6so4666789lab.15 for ; Mon, 22 Dec 2014 13:05:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vilvyejPvq6iPN0QE5atPEZ4i/1gJx6rexgYXJhaacw=; b=RDuBzku745DJaxLwmBA9F0UPrH33DYJSO4CKB0baZSe0klkRYiI+5NiENWpOvMlS6C 0OmzNTzrW6rfxeteIjpmeiGfpDsxV08NoxsZhVNCvbK/PA82Ku7vUAVojlb+eYYyOxpC BLJuJWjhsqC64Vm0m9FalZ9tReM6v4PGXrPQ3JYdgl8Mn+odR58RvMtjVppaIuSjJjdw zAtgtCDlDyj5wDAYapVSFRtDZV6JDFTJJaeKb+DYwr6UZAwq/3YP1/AzhT4Db/5j9YUm Z09BXWsl8ftMcViJMZdthsLNAtXTQoz6Ed59zpc5ogh7NXcc9+5IMk1KEYa22/KLbZxH CGrA== X-Gm-Message-State: ALoCoQkXoVIxLs7gm32iak6NHHIJfGN2X1LKczn2rhnqJJQSOwCSCJtyfNJNA0+Hu0aUpmIVEefE MIME-Version: 1.0 X-Received: by 10.112.128.233 with SMTP id nr9mr8474460lbb.49.1419282354479; Mon, 22 Dec 2014 13:05:54 -0800 (PST) Received: by 10.25.12.215 with HTTP; Mon, 22 Dec 2014 13:05:54 -0800 (PST) In-Reply-To: <549884B4.5030301@qti.qualcomm.com> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> <20141222180028.GF12662@localhost> <20141222192111.GG12662@localhost> <549884B4.5030301@qti.qualcomm.com> Date: Mon, 22 Dec 2014 16:05:54 -0500 Message-ID: From: Richard Barnes To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7b34396a93342e050ad46cc4 Archived-At: http://mailarchive.ietf.org/arch/msg/json/o4hP5oXAhwAdZ2A8f2iPbRF618w Cc: draft-ietf-json-text-sequence@tools.ietf.org, Nico Williams , json-chairs@tools.ietf.org, The IESG , json@ietf.org Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 21:06:15 -0000 --047d7b34396a93342e050ad46cc4 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 22, 2014 at 3:53 PM, Pete Resnick wrote: > > On 12/22/14 2:14 PM, Richard Barnes wrote: > > I think informative text warning that truncation that occurs between >> JSON text encoding and JSON text sequence encoding cannot be detected. >> > > Proposed for Section 2.3, after the above-quoted paragraph: > """ > The JSON text sequence structure described by the encoding ABNF allows > for the detection under certain circumstances. > > > I assume there's a missing "of truncation" after "detection", eh? > > Namely, if you view the text > sequence as a collection of "records" of the form (RS JSON-text LF), then > it is possible for a parser to recognize when a record has been truncated > (as described in Section 2.4). This mechanism does not cover other cases, > e.g., if the JSON text is truncated before the LF octet is appended. > Implementations that rely on the JSON text sequence structure to detect > truncation MUST ensure that JSON texts end in LF before any point where > truncation might occur. > """ > > > Very MUSTy of you. Are you equally OK with the following? > > Namely, if you view the text sequence as a collection of "records" of > the form (RS JSON-text LF), then it is possible for a parser to > recognize when a record has been truncated (as described in Section > 2.4). However, this mechanism does not cover other cases. > Importantly, truncation cannot be detected if the JSON text is > truncated before the LF octet is appended. > > Since we're shooting for something "informative". > Speak for yourself :) This actually seems very MUSTy to me, as in "You don't get what you want if you don't do this." And it seems like something such that it should be possible to check whether an implementation complies. --Richard > > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > --047d7b34396a93342e050ad46cc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 22, 2014 at 3:53 PM, Pete Resnick <presnick@qti.qu= alcomm.com> wrote:
=20 =20
On 12/22/14 2:14 PM, Richard Barnes wrote:
I think informative text warning that truncation that occurs between
JSON text encoding and JSON text sequence encoding cannot be detected.

Proposed for Section 2.3, after the above-quoted paragraph:
"""
The JSON text sequence structure described by the encoding ABNF allows
for the detection under certain circumstances.

 I assume there's a missing "of truncation" after "detect= ion", eh?

Namely, if you view the text
sequence as a collection of "records" of the form (RS JSON= -text LF), then=C2=A0
it is possible for a parser to recognize when a record has been truncated
(as described in Section 2.4).=C2=A0 This mechanism does not cover other cases,=C2=A0
e.g., if the JSON text is truncated before the LF octet is appended. =C2=A0
Implementations that rely on the JSON text sequence structure to detect
truncation MUST ensure that JSON texts end in LF before any point where
truncation might occur.
"""

 Very MUSTy of you. Are you equally OK with the following?<= br>
=C2=A0=C2=A0 Namely, if you view the text sequence as a collection of "= ;records" of
=C2=A0=C2=A0 the form (RS JSON-text LF), then it is possible for a parser t= o
=C2=A0=C2=A0 recognize when a record has been truncated (as described in Se= ction
 =C2=A0=C2=A0 2.4).=C2=A0 However, this mechanism does not cover other cases= .
=C2=A0=C2=A0 Importantly, truncation cannot be detected if the JSON text is=
=C2=A0=C2=A0 truncated before the LF octet is appended.

 Since we're shooting for something "informative".

Speak for yourself :)

T= his actually seems very MUSTy to me, as in "You don't get what you= want if you don't do this." =C2=A0And it seems like something suc= h that it should be possible to check whether an implementation complies.

--Richard


<= br>
=C2=A0


pr

--=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--047d7b34396a93342e050ad46cc4-- From nobody Mon Dec 22 13:24:57 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7247A1A1BDF; Mon, 22 Dec 2014 13:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJTke9mdpQCJ; Mon, 22 Dec 2014 13:24:38 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78F91A701D; Mon, 22 Dec 2014 13:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1419283477; x=1450819477; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WYv2v7OH+vpizmOX+i+bs8Iw0tIFBrCsgCHwD5kTdpo=; b=DX9G5UYj2F9YED6jb6cxXD+eKjqmtbVqO+dA8SuK4KKv9HRRxWgCeLxm QZaq9ZVh93jO0aJDLTefTsfN2eUXuIbUBuhM/2I0Qxde5p1KclxRsOVgO /9jUpT5B1z9JVH/4Jb6MvXHV842VQVs9pgQQbRITV3W94ehxPj7X7YwQ9 0=; X-IronPort-AV: E=McAfee;i="5600,1067,7660"; a="80468128" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Dec 2014 13:24:37 -0800 X-IronPort-AV: E=Sophos;i="5.07,626,1413270000"; d="scan'208,217";a="803223409" Received: from nasanexm01a.na.qualcomm.com ([10.85.0.81]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Dec 2014 13:24:36 -0800 Received: from NASANEXM01F.na.qualcomm.com (10.85.0.32) by nasanexm01a.na.qualcomm.com (10.85.0.81) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 22 Dec 2014 13:24:36 -0800 Received: from NASANEXM01F.na.qualcomm.com ([10.85.0.32]) by NASANEXM01F.na.qualcomm.com ([10.85.0.32]) with mapi id 15.00.0995.032; Mon, 22 Dec 2014 13:24:36 -0800 From: "Resnick, Pete" To: Richard Barnes Thread-Topic: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) Thread-Index: AQHQGgawlSSyhgl1HUOasxYcvWXYfJyUdr+AgABtVICAAA29gIAHboGAgAAUGoCAABEIgIAABYUAgAAO9QCAAAq2AIAAA5EA//9/HUU= Date: Mon, 22 Dec 2014 21:24:35 +0000 Message-ID: References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> <20141222180028.GF12662@localhost> <20141222192111.GG12662@localhost> <549884B4.5030301@qti.qualcomm.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_ybl5tghttja6ttvwu6mjic181419283488839emailandroidcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/AWP4ww0WPOcikP0N3V55XmsEQqg Cc: "draft-ietf-json-text-sequence@tools.ietf.org" , Nico Williams , "json-chairs@tools.ietf.org" , The IESG , "json@ietf.org" Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 21:24:41 -0000 --_000_ybl5tghttja6ttvwu6mjic181419283488839emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, you know I don't buy into this "using MUSTs for compliance" nonsense.= And there's certainly no interoperability issue here. I will in the end le= ave it to the WG, but is your desire for a MUST a stylistic preference, or = is it "I really think implementers are going to screw the pooch if it's not= in there? BTW: Did I get the earlier edit correct? pr Richard Barnes wrote: On Mon, Dec 22, 2014 at 3:53 PM, Pete Resnick > wrote: On 12/22/14 2:14 PM, Richard Barnes wrote: I think informative text warning that truncation that occurs between JSON text encoding and JSON text sequence encoding cannot be detected. Proposed for Section 2.3, after the above-quoted paragraph: """ The JSON text sequence structure described by the encoding ABNF allows for the detection under certain circumstances. I assume there's a missing "of truncation" after "detection", eh? Namely, if you view the text sequence as a collection of "records" of the form (RS JSON-text LF), then it is possible for a parser to recognize when a record has been truncated (as described in Section 2.4). This mechanism does not cover other cases, e.g., if the JSON text is truncated before the LF octet is appended. Implementations that rely on the JSON text sequence structure to detect truncation MUST ensure that JSON texts end in LF before any point where truncation might occur. """ Very MUSTy of you. Are you equally OK with the following? Namely, if you view the text sequence as a collection of "records" of the form (RS JSON-text LF), then it is possible for a parser to recognize when a record has been truncated (as described in Section 2.4). However, this mechanism does not cover other cases. Importantly, truncation cannot be detected if the JSON text is truncated before the LF octet is appended. Since we're shooting for something "informative". Speak for yourself :) This actually seems very MUSTy to me, as in "You don't get what you want if= you don't do this." And it seems like something such that it should be po= ssible to check whether an implementation complies. --Richard pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --_000_ybl5tghttja6ttvwu6mjic181419283488839emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Well, you know I don't buy into this "using MUSTs for comp=
liance" nonsense. And there's certainly no interoperability issue here=
. I will in the end leave it to the WG, but is your desire for a MUST a sty=
listic preference, or is it "I really think implementers are going to =
screw the pooch if it's not in there?=0A=
=0A=
BTW: Did I get the earlier edit correct?=0A=
=0A=
pr=0A=
=0A=
Richard Barnes <rlb@ipv.sx> wrote:=0A=
=0A=


On Mon, Dec 22, 2014 at 3:53 PM, Pete Resnick <presnick= @qti.qualcomm.com> wrote:
On 12/22/14 2:14 PM, Richard Barn= es wrote:
I think informative text warning that truncation that occurs between
JSON text encoding and JSON text sequence encoding cannot be detected.

Proposed for Section 2.3, after the above-quoted paragraph:
"""
The JSON text sequence structure described by the encoding ABNF allows=
for the detection under certain circumstances.

I assume there's a missing "of truncation" after "det= ection", eh?

Namely, if you view the text
sequence as a collection of "records" of the form (RS JSON-t= ext LF), then 
it is possible for a parser to recognize when a record has been trunca= ted
(as described in Section 2.4).  This mechanism does not cover oth= er cases, 
e.g., if the JSON text is truncated before the LF octet is appended. &= nbsp;
Implementations that rely on the JSON text sequence structure to detec= t
truncation MUST ensure that JSON texts end in LF before any point wher= e
truncation might occur.
"""

Very MUSTy of you. Are you equally OK with the following?

   Namely, if you view the text sequence as a collection of "= ;records" of
   the form (RS JSON-text LF), then it is possible for a parser t= o
   recognize when a record has been truncated (as described in Se= ction
   2.4).  However, this mechanism does not cover othe= r cases.
   Importantly, truncation cannot be detected if the JSON text is=
   truncated before the LF octet is appended.

Since we're shooting for something "informative".

Speak for yourself :)

This actually seems very MUSTy to me, as in "You don't get what y= ou want if you don't do this."  And it seems like something such = that it should be possible to check whether an implementation complies.

--Richard



 

pr

--=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--_000_ybl5tghttja6ttvwu6mjic181419283488839emailandroidcom_-- From nobody Mon Dec 22 13:31:44 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596D51A875D for ; Mon, 22 Dec 2014 13:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF_HMYrGsLVF for ; Mon, 22 Dec 2014 13:31:37 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BED1A8753 for ; Mon, 22 Dec 2014 13:31:36 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id 10so4548323lbg.29 for ; Mon, 22 Dec 2014 13:31:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XE4PmivdiUFs+9VBH+/KDLpHbpf57jRK+4234vaGJ30=; b=LWjWfmfiF2HMEHDEuH1fJIXTMH2lzJm22nlYnUjoDD0/OvY8PmbjAIZdM3beKKq8f2 f09K4wL5h6nodCqvhqu2UXJ5LhX7nH3qnH20SPb6fvFQGN8P6MmBN0/QFgkd2dWE19JD 7LyRIyLFbe4z+ScKEEgA/k+erOezp4Nzs1DQgtqoyvoN31Qf4MFul5zLlmTOQrTVjVXb Gfm8LkUzmAXv9MZXj4UYayfjp2l/uRbnH2OwumgcJ7noGoCol9DR2uiUeEvTH6Ul6khY 9KwbtA28w6hCwBcUyEwcv0SLrkrwENP7q+vFlfgFV9CKP2RZX5kkjdf00h5+Hl2Udza3 Kd0w== X-Gm-Message-State: ALoCoQkYXKDYgo10NBJ9yyIeGQ0DXF2DQcuflF86KAAp48qXxXWog7aEyH/dHCKtxHwz+qwVMhiQ MIME-Version: 1.0 X-Received: by 10.152.170.194 with SMTP id ao2mr24472758lac.12.1419283894814; Mon, 22 Dec 2014 13:31:34 -0800 (PST) Received: by 10.25.12.215 with HTTP; Mon, 22 Dec 2014 13:31:34 -0800 (PST) In-Reply-To: References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> <20141222180028.GF12662@localhost> <20141222192111.GG12662@localhost> <549884B4.5030301@qti.qualcomm.com> Date: Mon, 22 Dec 2014 16:31:34 -0500 Message-ID: From: Richard Barnes To: "Resnick, Pete" Content-Type: multipart/alternative; boundary=089e011615f262e110050ad4c83d Archived-At: http://mailarchive.ietf.org/arch/msg/json/9fL1K7AyxJOA9NhKm2xAb4ktTRQ Cc: "draft-ietf-json-text-sequence@tools.ietf.org" , Nico Williams , "json-chairs@tools.ietf.org" , The IESG , "json@ietf.org" Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 21:31:39 -0000 --089e011615f262e110050ad4c83d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 22, 2014 at 4:24 PM, Resnick, Pete wrote: > > Well, you know I don't buy into this "using MUSTs for compliance" nonsen= se. And there's certainly no interoperability issue here. I will in the end= leave it to the WG, but is your desire for a MUST a stylistic preference, = or is it "I really think implementers are going to screw the pooch if it's = not in there? > > I think there's a non-negligible risk that an implementor will set up a scheme like the one I proposed up-thread, and think they are getting truncation detection when in fact they are not. > BTW: Did I get the earlier edit correct? > > Yep. --Richard > > pr > > Richard Barnes wrote: > > > > > On Mon, Dec 22, 2014 at 3:53 PM, Pete Resnick > wrote: >> >> On 12/22/14 2:14 PM, Richard Barnes wrote: >> >> I think informative text warning that truncation that occurs between >>> JSON text encoding and JSON text sequence encoding cannot be detected. >>> >> >> Proposed for Section 2.3, after the above-quoted paragraph: >> """ >> The JSON text sequence structure described by the encoding ABNF allows >> for the detection under certain circumstances. >> >> >> I assume there's a missing "of truncation" after "detection", eh? >> >> Namely, if you view the text >> sequence as a collection of "records" of the form (RS JSON-text LF), the= n >> it is possible for a parser to recognize when a record has been truncate= d >> (as described in Section 2.4). This mechanism does not cover other >> cases, >> e.g., if the JSON text is truncated before the LF octet is appended. >> Implementations that rely on the JSON text sequence structure to detect >> truncation MUST ensure that JSON texts end in LF before any point where >> truncation might occur. >> """ >> >> >> Very MUSTy of you. Are you equally OK with the following? >> >> Namely, if you view the text sequence as a collection of "records" of >> the form (RS JSON-text LF), then it is possible for a parser to >> recognize when a record has been truncated (as described in Section >> 2.4). However, this mechanism does not cover other cases. >> Importantly, truncation cannot be detected if the JSON text is >> truncated before the LF octet is appended. >> >> Since we're shooting for something "informative". >> > > Speak for yourself :) > > This actually seems very MUSTy to me, as in "You don't get what you want > if you don't do this." And it seems like something such that it should b= e > possible to check whether an implementation complies. > > --Richard > > > > > >> >> >> pr >> >> -- >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> >> --089e011615f262e110050ad4c83d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 22, 2014 at 4:24 PM, Resnick, Pete <presnick@qti.q= ualcomm.com> wrote:
Well, you know I don't buy into this "using MUSTs for com=
pliance" nonsense. And there's certainly no interoperability issue=
 here. I will in the end leave it to the WG, but is your desire for a MUST =
a stylistic preference, or is it "I really think implementers are goin=
g to screw the pooch if it's not in there?

I think there's a non-negligible risk that an implement= or will set up a scheme like the one I proposed up-thread, and think they a= re getting truncation detection when in fact they are not. =C2=A0
=C2=A0
BTW: Did I get th=
e earlier edit correct?
Yep.

--Richard
=C2=A0
pr

Richard Barnes <rlb@ipv.sx> wrote:


On Mon, Dec 22, 2014 at 3:53 PM, Pete Resnick <presnick= @qti.qualcomm.com> wrote:
On 12/22/14 2:14 PM, Richard Barnes wrote:
I think informative text warning that truncation that occurs between
JSON text encoding and JSON text sequence encoding cannot be detected.

Proposed for Section 2.3, after the above-quoted paragraph:
"""
The JSON text sequence structure described by the encoding ABNF allows=
for the detection under certain circumstances.

I assume there's a missing "of truncation" after "= ;detection", eh?

Namely, if you view the text
sequence as a collection of "records" of the form (RS JSON-t= ext LF), then=C2=A0
it is possible for a parser to recognize when a record has been trunca= ted
(as described in Section 2.4).=C2=A0 This mechanism does not cover oth= er cases,=C2=A0
e.g., if the JSON text is truncated before the LF octet is appended. = =C2=A0
Implementations that rely on the JSON text sequence structure to detec= t
truncation MUST ensure that JSON texts end in LF before any point wher= e
truncation might occur.
"""

Very MUSTy of you. Are you equally OK with the following?

=C2=A0=C2=A0 Namely, if you view the text sequence as a collection of "= ;records" of
=C2=A0=C2=A0 the form (RS JSON-text LF), then it is possible for a parser t= o
=C2=A0=C2=A0 recognize when a record has been truncated (as described in Se= ction
=C2=A0=C2=A0 2.4).=C2=A0 However, this mechanism does not cover othe= r cases.
=C2=A0=C2=A0 Importantly, truncation cannot be detected if the JSON text is=
=C2=A0=C2=A0 truncated before the LF octet is appended.

Since we're shooting for something "informative".

Speak for yourself :)

This actually seems very MUSTy to me, as in "You don't get wh= at you want if you don't do this." =C2=A0And it seems like somethi= ng such that it should be possible to check whether an implementation compl= ies.

--Richard



=C2=A0


pr

--=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--089e011615f262e110050ad4c83d-- From nobody Mon Dec 22 14:00:10 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A371A8786; Mon, 22 Dec 2014 14:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYbZDMao81fc; Mon, 22 Dec 2014 14:00:08 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B82971A887A; Mon, 22 Dec 2014 13:59:57 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 7D1CD20047B89; Mon, 22 Dec 2014 13:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=5Ia7fH7GYKDo74 f8NJaHPvBIp4M=; b=BZ7iS6gG1Z2Rp8XZLP7VHS9h/nZztDkORkG3oEvb4PiYXJ uwLdzvUuvwCXdzEEl9r0+V7QLbcNBuGHWTYvnfvVWeFsty9dxovOcqEQZ+oOx7o9 zVE5MqoTw5F1IK8LQj0gJLpR8X/CiFj35PbJTCCYidvVkiE9GJDUhTtFd0yGQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id DD84A20047B88; Mon, 22 Dec 2014 13:59:56 -0800 (PST) Date: Mon, 22 Dec 2014 15:59:56 -0600 From: Nico Williams To: Richard Barnes Message-ID: <20141222215951.GI12662@localhost> References: <20141217231913.GE9443@localhost> <20141222180028.GF12662@localhost> <20141222192111.GG12662@localhost> <549884B4.5030301@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/json/3ayvqPqT9JqN7NKf-qqKXUZ2yXk Cc: "draft-ietf-json-text-sequence@tools.ietf.org" , "Resnick, Pete" , "json-chairs@tools.ietf.org" , The IESG , "json@ietf.org" Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 22:00:09 -0000 On Mon, Dec 22, 2014 at 04:31:34PM -0500, Richard Barnes wrote: > On Mon, Dec 22, 2014 at 4:24 PM, Resnick, Pete > wrote: > > Well, you know I don't buy into this "using MUSTs for compliance" > > nonsense. And there's certainly no interoperability issue here. I > > will in the end leave it to the WG, but is your desire for a MUST a > > stylistic preference, or is it "I really think implementers are > > going to screw the pooch if it's not in there? > > I think there's a non-negligible risk that an implementor will set up > a scheme like the one I proposed up-thread, and think they are getting > truncation detection when in fact they are not. I only yielded as to the MUST because I want this over with. But I don't like it because I'm not sure how to adhere to that MUST in an implementation where the sequence and text encoders are as separated as you (and the secdir reviewer) think they might be. How about this text, in section 2.4, instead: Detection of truncation of non-self-delimited sequence elements (numbers, true, false, and null) is only possible when the sequence encoder produces or receives complete JSON texts. Implementations where the sequence encoder is not also in charge of encoding the individual JSON texts should ensure that those JSON texts are complete. This does make clear when a problem might arise, and what to do about it. The "should" could be a SHOULD, even a MUST if need be, though frankly, I think it should suffice to have a warning (as is already present in section 3) about lack of integrity protection. Nico -- From nobody Tue Dec 23 14:25:54 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478241A877F; Tue, 23 Dec 2014 14:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu_okT3GwGQA; Tue, 23 Dec 2014 14:25:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FFB1A8764; Tue, 23 Dec 2014 14:25:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223222550.11171.2504.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 14:25:50 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/kzvFRj9PY6e3u7NIQUwj1WzxibM Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-text-sequence-13.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:25:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JavaScript Object Notation Working Group of the IETF. Title : JavaScript Object Notation (JSON) Text Sequences Author : Nicolas Williams Filename : draft-ietf-json-text-sequence-13.txt Pages : 11 Date : 2014-12-23 Abstract: This document describes the JSON text sequence format and associated media type, "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x1A). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-text-sequence-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 23 14:25:57 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE5E1A876C for ; Tue, 23 Dec 2014 14:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6omV7eHoeZO; Tue, 23 Dec 2014 14:25:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 833D81A8760; Tue, 23 Dec 2014 14:25:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: json-chairs@tools.ietf.org, draft-ietf-json-text-sequence@tools.ietf.org, json@ietf.org, presnick@qti.qualcomm.com, rlb@ipv.sx X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141223222550.11171.46780.idtracker@ietfa.amsl.com> Date: Tue, 23 Dec 2014 14:25:50 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/EYqBZvj8zJpC-DupPiWM0Lv6dUE Subject: [Json] New Version Notification - draft-ietf-json-text-sequence-13.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:25:54 -0000 A new version (-13) has been submitted for draft-ietf-json-text-sequence: http://www.ietf.org/internet-drafts/draft-ietf-json-text-sequence-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Dec 23 14:52:12 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFF71A8030; Tue, 23 Dec 2014 14:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxv_wBJcFvXT; Tue, 23 Dec 2014 14:52:03 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183A01A6F8D; Tue, 23 Dec 2014 14:51:58 -0800 (PST) Received: from [10.20.30.90] (50-1-99-243.dsl.dynamic.fusionbroadband.com [50.1.99.243]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBNMpudK016721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2014 15:51:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-243.dsl.dynamic.fusionbroadband.com [50.1.99.243] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: Date: Tue, 23 Dec 2014 14:51:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <11DBD61E-6824-45DB-8070-5A7007409854@vpnc.org> References: <20141217143517.28709.96922.idtracker@ietfa.amsl.com> <20141217155844.GS3241@localhost> <20141217231913.GE9443@localhost> <20141222180028.GF12662@localhost> <20141222192111.GG12662@localhost> <549884B4.5030301@qti.qualcomm.com> To: Richard Barnes X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/json/3nuAxnzfY__GckokhgW5te6jIt4 Cc: The IESG , "json@ietf.org" Subject: Re: [Json] Richard Barnes' Discuss on draft-ietf-json-text-sequence-11: (with DISCUSS and COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:52:05 -0000 Nico has published a -12 of the draft. As shepherd, I think the new = wording added is probably in line with what the WG would have expected = (clarifications but no new requirements). Richard: let us know if this = wording addresses your concerns. --Paul Hoffman= From nobody Wed Dec 31 15:49:05 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FEC1A1A54; Wed, 31 Dec 2014 15:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRHAphwKOvQd; Wed, 31 Dec 2014 15:48:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBC31A1A78; Wed, 31 Dec 2014 15:48:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: iesg-secretary@ietf.org, iesg@ietf.org, draft-ietf-json-i-json.all@tools.ietf.org, linuxwolf@outer-planes.net, json-chairs@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141231234858.7530.81338.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 15:48:58 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/lp1nr4W5j8LSgVgb2a7ic-oCJCI Subject: [Json] Telechat update notice: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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 Dec 2014 23:49:01 -0000 Placed on agenda for telechat - 2015-01-22 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ From nobody Wed Dec 31 21:04:07 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B924D1A1B44; Wed, 31 Dec 2014 21:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bw46Fy4XN2c; Wed, 31 Dec 2014 21:04:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3826E1A1B36; Wed, 31 Dec 2014 21:04:03 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150101050403.32059.58457.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 21:04:03 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/json/IMkFgBL7OVhSvELu7r1ZPCl7dvA Cc: json@ietf.org Subject: [Json] Last Call: (The I-JSON Message Format) to Proposed Standard X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 05:04:05 -0000 The IESG has received a request from the JavaScript Object Notation WG (json) to consider the following document: - 'The I-JSON Message Format' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-01-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-json-i-json/ballot/ No IPR declarations have been submitted directly on this I-D. There are no IANA considerations for this document. From nobody Wed Dec 31 21:04:11 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F27E1A1B4F for ; Wed, 31 Dec 2014 21:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIkNf5z0rg5d; Wed, 31 Dec 2014 21:04:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A391A1B47; Wed, 31 Dec 2014 21:04:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: linuxwolf@outer-planes.net, draft-ietf-json-i-json.all@tools.ietf.org, json-chairs@tools.ietf.org, json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150101050406.32059.32123.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 21:04:06 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/zIvjzFApNcH7APyGbVCuzZgBK_Y Subject: [Json] ID Tracker State Update Notice: X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 05:04:09 -0000 Last call has been made for draft-ietf-json-i-json and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-json-i-json/