From nobody Sun Jun 1 15:35: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 B88641A00D5 for ; Sun, 1 Jun 2014 15:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 XnfAeELrWXEj for ; Sun, 1 Jun 2014 15:35:08 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 050BA1A00CF for ; Sun, 1 Jun 2014 15:35:07 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 86FA01DE060 for ; Sun, 1 Jun 2014 15:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=vkFX6wrozZzy4TZ7Ulb4 dpsGGUY=; b=TpjXyEAzY71BPTiz9eMtSjWJs+SaYbY0Y9RC3lC4L1S+TbmG4cTA xF9+QrtlZQwxpBtcAx4pZkxeY5eZoSMfogW/m2mI3SXcnnp9aVVdvFHIzrIn2SUs cKUDsxa14NcJSr23+t3CFOQB+t7+JI8nKaSQeDX90HnbFTOvJ/w6yJA= Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 3B9221DE059 for ; Sun, 1 Jun 2014 15:35:02 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a1so4235441wgh.3 for ; Sun, 01 Jun 2014 15:35:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.102.10 with SMTP id fk10mr17221952wib.42.1401662100903; Sun, 01 Jun 2014 15:35:00 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Sun, 1 Jun 2014 15:35:00 -0700 (PDT) In-Reply-To: References: Date: Sun, 1 Jun 2014 17:35:00 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/LdIn_CTIB0lA49lLC4zrtEum7fE Cc: Carsten Bormann , IETF JSON WG , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Paul Hoffman Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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, 01 Jun 2014 22:35:08 -0000 On Sun, Jun 1, 2014 at 12:08 AM, Tim Bray wrote: > On Sun, May 25, 2014 at 4:05 PM, Nico Williams wrote: > >> Currently my thinking is that for backwards compatibility reasons I'd >> want to to make this RECOMMENDED though, not REQUIRED, except for >> cases where incomplete writes are a potential problem. > > No. There should be only one way to do things. I'm not terribly fond of this. It'd be easier if we picked a Unicode whitespace character that's not used in the JSON whitespace rule and must be escaped in strings, preferably one that terminals and such generally handle as a whitespace. Failing that a character that terminals will ignore. But since the problem we're talking about is only relevant to log-like writing patterns, I'd prefer to make this optional for writers, mandatory for readers. Nico -- From nobody Sun Jun 1 15:55: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 77C4A1A00D4 for ; Sun, 1 Jun 2014 15:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 SztCs-40FC-8 for ; Sun, 1 Jun 2014 15:55:37 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E3F1E1A00CF for ; Sun, 1 Jun 2014 15:55:37 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 13C4B20047B5B for ; Sun, 1 Jun 2014 15:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6AFzPS0iTyLhOWslu2X4 I+Z03Yg=; b=CdiLzsQZLSHtHlzBiJtp4MQWa7d6/5Adcp+TQfsfHckrYUvPcYTc nDRNO85+MzAYwX1MRD5UVqAQFiasapr32BwjoGXV2JIYniQMkd4MjXd4JUim2ecl Krv9uNXl7mKAv/FSAvvMxf03JS7WbYlF+Nrl5eHmgvdZtLV06NxmjlM= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id BD14A20047B59 for ; Sun, 1 Jun 2014 15:55:32 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id k48so4392244wev.17 for ; Sun, 01 Jun 2014 15:55:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.5.5 with SMTP id o5mr44259122wjo.16.1401663331748; Sun, 01 Jun 2014 15:55:31 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Sun, 1 Jun 2014 15:55:31 -0700 (PDT) In-Reply-To: References: Date: Sun, 1 Jun 2014 17:55:31 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/tRaRDYwrZII80mCHIZKgEUtereg Cc: Carsten Bormann , IETF JSON WG , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Paul Hoffman Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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, 01 Jun 2014 22:55:38 -0000 As to Unicode encoding... that's a good point. I'd say that for JSON text sequences we should require the use of UTF-8. Nico -- From nobody Sun Jun 1 16:11: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 61B881A00D7 for ; Sun, 1 Jun 2014 16:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r73nyc3Cd_BK for ; Sun, 1 Jun 2014 16:11:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5BF1A00CF for ; Sun, 1 Jun 2014 16:11:07 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s51NAuIA068243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Jun 2014 16:10:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: Date: Sun, 1 Jun 2014 16:10:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <15F00865-592D-41B2-8E23-6C794C4B77EF@vpnc.org> References: To: Nico Williams X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/json/M2nk76zi5BEczbL3Mc7p_7Hj75o Cc: IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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, 01 Jun 2014 23:11:15 -0000 On Jun 1, 2014, at 3:35 PM, Nico Williams wrote: > On Sun, Jun 1, 2014 at 12:08 AM, Tim Bray = wrote: >> On Sun, May 25, 2014 at 4:05 PM, Nico Williams = wrote: >>=20 >>> Currently my thinking is that for backwards compatibility reasons = I'd >>> want to to make this RECOMMENDED though, not REQUIRED, except for >>> cases where incomplete writes are a potential problem. >>=20 >> No. There should be only one way to do things. >=20 > I'm not terribly fond of this. >=20 > It'd be easier if we picked a Unicode whitespace character that's not > used in the JSON whitespace rule and must be escaped in strings, > preferably one that terminals and such generally handle as a > whitespace. =20 What would a whitespace character be "easier" than a character not = allowed in Unicode? It seems to me that a character that could not exist = in a string and therefore never needs to be escaped is "easier". > Failing that a character that terminals will ignore. I suspect most terminals would ignore FEFF. But I don't think that's = actually as important as the fact that it doesn't require escaping. > But since the problem we're talking about is only relevant to log-like > writing patterns, I'd prefer to make this optional for writers, > mandatory for readers. Make what optional for writers and mandatory for readers? --Paul Hoffman= From nobody Sun Jun 1 16:12: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 9F4471A00D7 for ; Sun, 1 Jun 2014 16:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 ZkbDVvI3T1FB for ; Sun, 1 Jun 2014 16:12:14 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 243E41A00CF for ; Sun, 1 Jun 2014 16:12:14 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 3C3F8678063 for ; Sun, 1 Jun 2014 16:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=9dqI4Mdz4nUXLEwL04wK AIJe/SM=; b=nWMqMMd+ON74MzltM5zPOWVXaPyGdL2SJSswiUju2iJVWwnc49r8 I0u6m3NmMZww/CyfF8BGqD8KmpfSVfgzl0Pk1NkjAD3Hs3XhiSQBf0dcGiwo8dhZ jWVNtsCELp9R9dQhKhfv/0OyM5cumd3aIspDs6aPgf2TYbdhAxaQjx4= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id E5B7E678062 for ; Sun, 1 Jun 2014 16:12:08 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x13so4323617wgg.22 for ; Sun, 01 Jun 2014 16:12:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.77.225 with SMTP id v1mr17043317wiw.5.1401664327838; Sun, 01 Jun 2014 16:12:07 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Sun, 1 Jun 2014 16:12:07 -0700 (PDT) In-Reply-To: References: Date: Sun, 1 Jun 2014 18:12:07 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/83kwkTeXIVsNBJdT9djzG1G4ous Cc: Carsten Bormann , IETF JSON WG , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Paul Hoffman Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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, 01 Jun 2014 23:12:14 -0000 Oh, right, the separator must be a character that must be escaped in strings. That greatly limits the range of characters we can choose from. From nobody Sun Jun 1 16:13: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 DDF721A00D7 for ; Sun, 1 Jun 2014 16:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 fcyQO7aSXNui for ; Sun, 1 Jun 2014 16:13:27 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5796F1A00CF for ; Sun, 1 Jun 2014 16:13:27 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 6E66576805C for ; Sun, 1 Jun 2014 16:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=OpM/ftcS+jVHeOZxO9+r O5QuuoI=; b=yhD3ZhFqwLlNoGXFOjVlelu0gx7C3BY49E+mgMoD0jid4FiRKaHB IpzXDYpjMFi/jfbZFJ2bW1XnsheGcG9ecCSNbahPQHeiGWXPnBMrUsegMgm1pleq v0UP0vIrV5sFtshxz0azsIfU2JGXh3ro0GAJQws162wUbhYKRq+f0fw= Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 23A7D768059 for ; Sun, 1 Jun 2014 16:13:21 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id q58so4306950wes.25 for ; Sun, 01 Jun 2014 16:13:21 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.102.10 with SMTP id fk10mr17373463wib.42.1401664401136; Sun, 01 Jun 2014 16:13:21 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Sun, 1 Jun 2014 16:13:21 -0700 (PDT) In-Reply-To: References: Date: Sun, 1 Jun 2014 18:13:21 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/c3togjVY0c-GisG2QYZtQazMaw0 Cc: Carsten Bormann , IETF JSON WG , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Paul Hoffman Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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, 01 Jun 2014 23:13:28 -0000 On Sun, Jun 1, 2014 at 6:12 PM, Nico Williams wrote: > Oh, right, the separator must be a character that must be escaped in > strings. That greatly limits the range of characters we can choose > from. And it has to be a one-byte character (therefore an ASCII character, and the texts must be encoded in UTF-8). Nico -- From nobody Sun Jun 1 16:16: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 5F4581A00D7 for ; Sun, 1 Jun 2014 16:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 c3CbdocnXkQs for ; Sun, 1 Jun 2014 16:16:45 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A37361A00CF for ; Sun, 1 Jun 2014 16:16:45 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id C832E674059 for ; Sun, 1 Jun 2014 16:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=2OcPUquzJF65nCfTFVRM Cz+ZYsw=; b=V2NvPeHjd+fb1nV+ZFvzr2YSoSbb7MYpuyrq8vlGh/UvZ08ZDtbz 5M6CMn7d5TFMxV0CKhPLsXaw9Kcspf7NZ5N9EzmeVuBUwiyTt2aa+dEmL2IQV+21 B2AMcOnTpx0OgRY6D2yHiIAx5flIWWKG9jICKI0VqnEBXqAD0/Jnx7Q= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 7B318674058 for ; Sun, 1 Jun 2014 16:16:40 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so4246545wgg.13 for ; Sun, 01 Jun 2014 16:16:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.8.6 with SMTP id n6mr27600093wja.31.1401664599486; Sun, 01 Jun 2014 16:16:39 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Sun, 1 Jun 2014 16:16:39 -0700 (PDT) In-Reply-To: <15F00865-592D-41B2-8E23-6C794C4B77EF@vpnc.org> References: <15F00865-592D-41B2-8E23-6C794C4B77EF@vpnc.org> Date: Sun, 1 Jun 2014 18:16:39 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/6_tOpeCxq2pWEqaDe8XvXmGaPtk Cc: IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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, 01 Jun 2014 23:16:46 -0000 On Sun, Jun 1, 2014 at 6:10 PM, Paul Hoffman wrote: > On Jun 1, 2014, at 3:35 PM, Nico Williams wrote: >> On Sun, Jun 1, 2014 at 12:08 AM, Tim Bray wrote: >>> No. There should be only one way to do things. >> >> I'm not terribly fond of this. >> >> It'd be easier if we picked a Unicode whitespace character that's not >> used in the JSON whitespace rule and must be escaped in strings, >> preferably one that terminals and such generally handle as a >> whitespace. > > What would a whitespace character be "easier" than a character not allowed in Unicode? It seems to me that a character that could not exist in a string and therefore never needs to be escaped is "easier". Because I want text-based tools to be able to at least display (and grep, and...) JSON text sequence contents much as they can JSON text contents. >> Failing that a character that terminals will ignore. > > I suspect most terminals would ignore FEFF. But I don't think that's actually as important as the fact that it doesn't require escaping. Right, it has to be a character that must be escaped, and its encoding must require a single byte, otherwise we can't recover simply from incomplete appends. >> But since the problem we're talking about is only relevant to log-like >> writing patterns, I'd prefer to make this optional for writers, >> mandatory for readers. > > Make what optional for writers and mandatory for readers? I'd like what jq does now to continue to be valid. I'd like to add an alternate separator for the log-file case. Nico -- From nobody Sun Jun 1 16:18: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 ADEB51A00DF for ; Sun, 1 Jun 2014 16:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkqGlqahVstT for ; Sun, 1 Jun 2014 16:17:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D761A00DA for ; Sun, 1 Jun 2014 16:17:58 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s51NHo66068392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Jun 2014 16:17:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: Date: Sun, 1 Jun 2014 16:17:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> References: To: Nico Williams X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/json/uJhCYz5RNkMMjsvAA8FoB3hi2lA Cc: IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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, 01 Jun 2014 23:17:58 -0000 On Jun 1, 2014, at 4:13 PM, Nico Williams wrote: > On Sun, Jun 1, 2014 at 6:12 PM, Nico Williams = wrote: >> Oh, right, the separator must be a character that must be escaped in >> strings. That greatly limits the range of characters we can choose >> from. >=20 > And it has to be a one-byte character (therefore an ASCII character, > and the texts must be encoded in UTF-8). Why is that?= From nobody Sun Jun 1 17:03: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 B168A1A0103 for ; Sun, 1 Jun 2014 17:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 I1xedw9i_haf for ; Sun, 1 Jun 2014 17:03:24 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CC9921A0100 for ; Sun, 1 Jun 2014 17:03:24 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id ADB1F2AC05D for ; Sun, 1 Jun 2014 17:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=y2QCVEHbYtlm6xz2e5l3 iZJ05L8=; b=EgRbZu/g0BgurGqAlfucSwDDw7jzsI41tN3kmGoWomyQgiJ1Uapx CqqcrjV1Zi4Qe7HQGkaTjpQ0dUVz7ad47iinfTDKBPoUVyCVXjMbQngi5x1pCBTp nkgjX2kzuzgwH/wQ6+ikeecQ4eVRlzxVwRFyd5tuFgRT9wPQBse5CzE= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 62BF02AC059 for ; Sun, 1 Jun 2014 17:03:19 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so3725307wib.7 for ; Sun, 01 Jun 2014 17:03:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.12.135 with SMTP id y7mr17360936wib.39.1401667398077; Sun, 01 Jun 2014 17:03:18 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Sun, 1 Jun 2014 17:03:18 -0700 (PDT) In-Reply-To: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> Date: Sun, 1 Jun 2014 19:03:18 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Bi5TsaghK3WpS-NMdKECd07vzT4 Cc: IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Mon, 02 Jun 2014 00:03:25 -0000 On Sun, Jun 1, 2014 at 6:17 PM, Paul Hoffman wrote: >>> Oh, right, the separator must be a character that must be escaped in >>> strings. That greatly limits the range of characters we can choose >>> from. >> >> And it has to be a one-byte character (therefore an ASCII character, >> and the texts must be encoded in UTF-8). > > Why is that? The problem we're talking about is logfiles where applications "append" to the logfile. Incomplete writes can result in some circumstances. The question then is: how to recover? In particular: how to read past an incomplete entry to the next complete entry? The I-D currently describes a recovery heuristic, but some reviewers have stated a preference for a stronger, more easily understood recovery method. One obvious approach is to separate texts with a byte or byte sequence that could not normally happen in a JSON text. A byte is simpler and easier to handle and understand than a byte sequence: because the latter can be written incompletely for the same reasons that a JSON text can. We've considered all of these approaches (not in this order): 0) newline separator 1) #0 + JSON text boundary detection ABNF 2) #1 + removal of newlines from JSON texts (which does not require re-encoding, FYI) 3) #2 + write something like a text consisting of a single null value before every text 4) use some other separator (that isn't a JSON whitespace character) 5) #4 with ASCII RS as the separator Any separator for #4 has to be something that cannot happen in a JSON text normally, and it has to be something amenable to recovery from partial writes. Even partial writes always at least write complete _bytes_ (if they write any). Therefore a one-byte separator is always unambiguous. In order for a separator to be utterly unambiguous in the face of partial writes it has to involve a byte that can never occur in a JSON text. I suspect there's no such byte that works for UTF-8/16/32. If we limit JSON text sequences to UTF-8 then any ASCII character that must be escaped in strings and is not valid in the encoding of any values will do. That's a very small set of characters. RS (#5) was objected to. I don't see what other character can be used that won't result similar objections. The more I think about it the more I prefer the options in the I-D, #0, #1, #2, and #3. I don't see better alternatives, and I don't think this is fatal. Nico -- From nobody Sun Jun 1 18:13: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 C009A1A011D for ; Sun, 1 Jun 2014 18:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.158 X-Spam-Level: X-Spam-Status: No, score=0.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 FqX3FEyZ4ML8 for ; Sun, 1 Jun 2014 18:13:37 -0700 (PDT) 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 16BFD1A0119 for ; Sun, 1 Jun 2014 18:13:36 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 78BE632E550; Mon, 2 Jun 2014 10:13: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 7f11_497b_de914091_87e7_4ccb_a8cf_b8a7f65ec5f7; Mon, 02 Jun 2014 10:13:29 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 08A87BFB5E; Mon, 2 Jun 2014 10:13:30 +0900 (JST) Message-ID: <538BCFAB.4010307@it.aoyama.ac.jp> Date: Mon, 02 Jun 2014 10:13:15 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Nico Williams , Paul Hoffman References: <15F00865-592D-41B2-8E23-6C794C4B77EF@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/MAAeCEHshnGT2ZdqyXWPjgrWtwQ Cc: IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Mon, 02 Jun 2014 01:13:39 -0000 On 2014/06/02 08:16, Nico Williams wrote: > On Sun, Jun 1, 2014 at 6:10 PM, Paul Hoffman wrote: >> On Jun 1, 2014, at 3:35 PM, Nico Williams wrote: >>> On Sun, Jun 1, 2014 at 12:08 AM, Tim Bray wrote: >>>> No. There should be only one way to do things. I agree with this sentence, but I very strongly disagree with the proposal of U+FFFE. >>> I'm not terribly fond of this. >>> >>> It'd be easier if we picked a Unicode whitespace character that's not >>> used in the JSON whitespace rule and must be escaped in strings, >>> preferably one that terminals and such generally handle as a >>> whitespace. >> >> What would a whitespace character be "easier" than a character not allowed in Unicode? It seems to me that a character that could not exist in a string and therefore never needs to be escaped is "easier". > > Because I want text-based tools to be able to at least display (and > grep, and...) JSON text sequence contents much as they can JSON text > contents. Yes exactly. The Unicode spec says that U+FFFE must never be interpreted as an abstract character nor interchanged. While "interpreted as an abstract character" leaves quite a bit of room for interpretation (sic!), "not interchanged" is very clear. I hope we won't define a format that cannot be interchanged. The reason why Unicode defines things that way is that there may be implementations (think editors,...) that use U+FFFE internally, and those would be quite confused when receiving it. There will also be applications (editors and other tools, including security checkers) that will bark on U+FFFE as part of checking for correct UTF-8. Regards, Martin. From nobody Wed Jun 4 00:30: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 339821A00B0 for ; Wed, 4 Jun 2014 00:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vsGLwgYrFiE for ; Wed, 4 Jun 2014 00:30:31 -0700 (PDT) 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 E32F11A00AD for ; Wed, 4 Jun 2014 00:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1396; q=dns/txt; s=iport; t=1401867025; x=1403076625; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vI+tc6hbA2elx+QV5S2JtV17RiiDwecUGRhQL20Gvi8=; b=NF9k00w2jMLobEofGfFoaDhiDsjChGf7RnAoYS3xwvwIW4n342ERnv0k cq2n2CExp2diI0s/MxDaPw2jugYRkJsM5Gr7Ywkd0jpKy/iLVh5Ye6gVU l5NyQyTNscE4ZxTIOaQ7qrzKBxLuDk33sGCLZ8e0Yb+Tl14diM36TcLmg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhULAFvKjlOtJV2U/2dsb2JhbABZgweBKoJsp1gBBAUBmCcBGXUWdIImAQEEIxFFEAIBCBoCHwcCAgIwFRACBAENBYhCrG6ldReBKoQrg16FHweCdYFLAQOaD5M2gXiBQIIv X-IronPort-AV: E=Sophos;i="4.98,971,1392163200"; d="scan'208";a="330380404" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 04 Jun 2014 07:30:23 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s547UNYE026093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jun 2014 07:30:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 4 Jun 2014 02:30:23 -0500 From: "Joe Hildebrand (jhildebr)" To: Nico Williams , Paul Hoffman Thread-Topic: [Json] Using a non-whitespace separator (Re: Working Group Last Call on draft-ietf-json-text-sequence) Thread-Index: AQHPfVekIfY8Dj+1sEOKyquOPH0Q0ZtdLJQAgAAKXoCAAABZgIAAAUAAgAAMtACAAzz/gA== Date: Wed, 4 Jun 2014 07:30:23 +0000 Message-ID: References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.82.85] Content-Type: text/plain; charset="utf-8" Content-ID: <4CD10ACBFAC9B6478F9D3334F11718CE@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/3Vo-biRevaJHYPVBK9r-QLrNLSw Cc: IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Wed, 04 Jun 2014 07:30:32 -0000 T24gNi8xLzE0LCA2OjAzIFBNLCAiTmljbyBXaWxsaWFtcyIgPG5pY29AY3J5cHRvbmVjdG9yLmNv bT4gd3JvdGU6DQoNCj41KSAjNCB3aXRoIEFTQ0lJIFJTIGFzIHRoZSBzZXBhcmF0b3INCg0KVGhp cyBpcyB0aGUgYmVzdCBvbmUgb24gdGhlIGxpc3QuICBJdCdzIHdoYXQgUlMgaXMgZm9yLiAgSWYg eW91IGFsc28gd2FudA0KdG8gYWxsb3cgb3B0aW9uYWwgaW50ZXItaXRlbSBpZ25vcmFibGUgd2hp dGVzcGFjZSAoZS5nLiBcbikgZm9yIGJldHRlcg0KcHJpbnRhYmlsaXR5LCB5b3UgZ2V0IGV2ZXJ5 dGhpbmcgeW91IHdhbnQuICBSUyBpcyBvbmx5IHVzZWQgZm9yIHBhcnNlcg0Kc3RhdGUgc3luY2hy b25pemF0aW9uLiAgUlMgaXMgZm9yYmlkZGVuIGluIGEgSlNPTiB0ZXh0IGJ5IDcxNTksIHNvIGl0 J3MNCnVuYW1iaWd1b3VzbHkgYSByZWNvdmVyYWJsZSBwYXJzZSBlcnJvciBpZiBpdCBpcyBkZXRl Y3RlZCBpbiB0aGUgbWlkZGxlIG9mDQphbiBpdGVtLiAgR3JlcCB3b3JrcyBmaW5lIHdpdGggdGhp cyBmb3JtYXQsIHBhcnRpY3VsYXJseSB3aGVuIGNvbWJpbmVkDQp3aXRoIG5ld2xpbmVzLiAgU2V2 ZXJhbCBlZGl0b3JzIEkgdHJpZWQgd29ya2VkIGZpbmUgd2l0aCBpdDsgb25lIGV2ZW4NCnJlbmRl cmVkIHRoZSBSUyBhcyBhIG5pY2UgUlMtc3Vycm91bmRlZC1ieS1ib3ggZ2x5cGguICBJdCdzIGNl cnRhaW5seQ0KZ29pbmcgdG8gYmUgbW9yZSBpbnRlcm9wZXJhYmxlIHdpdGggdG9vbGluZyB0aGFu IFUrRkZGRSwgZm9yIGV4YW1wbGUuDQoNCkkgYWxzbyBhZ3JlZSB3aXRoIFRpbSB0aGF0IHRoZXJl IHNob3VsZCBiZSBwcmVjaXNlbHkgb25lIHdheSBvZiBkb2luZyBpdGVtDQpzZXBhcmF0aW9uLiAg SGF2aW5nIHRvIGRvIG11bHRpcGxlIHdheXMgaXMgZ29pbmcgdG8gbWFrZSB0aGUgcGFyc2Vycw0K c2xvd2VyIGFuZCBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhleSBoYXZlIHRvIGJlLCBmb3Igbm8g dGVjaG5pY2FsIGJlbmVmaXQuDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg0K From nobody Wed Jun 4 04:41: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 E4D731A01B3 for ; Wed, 4 Jun 2014 04:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 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, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmW5piXPygyN for ; Wed, 4 Jun 2014 04:41:16 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6827A1A01CF for ; Wed, 4 Jun 2014 04:41:16 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so8430028wes.30 for ; Wed, 04 Jun 2014 04:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=l9vtsukqxbaWyMluX+SYP7Kjj42G7PBgghZOp6/pVTo=; b=biTkuh/yhTeedKwTsZWFGKKGDcZkjMj6r5p8TtaNluHLgMHTfEU4SBAIER1Q5DyLA0 qqrOKQcFoQOy5wiGLEClqbOw5hZnXX1+P/4hXBPdGkIfj3tDIRNopWXZsPU5gG+fRfWh hB0r3rOYCqniJzGsciQJyYT+AlvOUFfraeQU47qk8gRDA6R5H49B8W8fZB7FvVX1LBVp 1C2RdHv2lJkv8jQEj5oz5kgqlcHgL2m3b8m592ADsnt/zEBxjBxNcQTW27xnyvAPmssw a8l+KlcWrZX4mjxgxuBFKRdqZhg5XMR/L/e8Omfp49XLawngtFGJV3dJfw0uU5rMTRpC YzMg== MIME-Version: 1.0 X-Received: by 10.194.175.106 with SMTP id bz10mr3804896wjc.96.1401882068809; Wed, 04 Jun 2014 04:41:08 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Wed, 4 Jun 2014 04:41:08 -0700 (PDT) In-Reply-To: References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> Date: Wed, 4 Jun 2014 07:41:08 -0400 X-Google-Sender-Auth: xSeDgCgF7FFa79nQi3Wlijzyess Message-ID: From: Phillip Hallam-Baker To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/369Jqxul_PzM8jjpMSZis_mw8KE Cc: Nico Williams , Paul Hoffman , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Wed, 04 Jun 2014 11:41:18 -0000 +1 on the separator MUST be an ascii character, not a UNICODE sequence. Most of my projects don't actually use or need Unicode because they are low level and don't deal with anything the user needs to see. I use ASCII tags to make it easier to support non-Unicode languages like C. Having to move to multibyte Unicode sequences for this one purpose would be a pain. If not RS then zero. On Wed, Jun 4, 2014 at 3:30 AM, Joe Hildebrand (jhildebr) wrote: > On 6/1/14, 6:03 PM, "Nico Williams" wrote: > >>5) #4 with ASCII RS as the separator > > This is the best one on the list. It's what RS is for. If you also want > to allow optional inter-item ignorable whitespace (e.g. \n) for better > printability, you get everything you want. RS is only used for parser > state synchronization. RS is forbidden in a JSON text by 7159, so it's > unambiguously a recoverable parse error if it is detected in the middle of > an item. Grep works fine with this format, particularly when combined > with newlines. Several editors I tried worked fine with it; one even > rendered the RS as a nice RS-surrounded-by-box glyph. It's certainly > going to be more interoperable with tooling than U+FFFE, for example. > > I also agree with Tim that there should be precisely one way of doing item > separation. Having to do multiple ways is going to make the parsers > slower and more complicated than they have to be, for no technical benefit. > > -- > Joe Hildebrand > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Wed Jun 4 09:12: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 E36541A02D9 for ; Wed, 4 Jun 2014 09:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 DOfsyk-26y9P for ; Wed, 4 Jun 2014 09:12:56 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFF61A0270 for ; Wed, 4 Jun 2014 09:12:56 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 5C4CC3B806C for ; Wed, 4 Jun 2014 09:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Nbk9M8n7iPZyhfI5JZZz XNdAJh0=; b=wa0mMHM4tqJFHwHl8GZlfT5ymZMLExiJsPIlK2pdMfLdS4Izwjms rDUxmnYIQD7N7ZaDj3ITL7YBJn+kWsjR+9Dxqzl60fIUBGbosB6OZe4er6PH7pYP TGEMQufhQSiRp25t5FfvO/1QaSwXYx2h1pHL3QnKdSjN/L+kIXwPP7M= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 0AB343B8062 for ; Wed, 4 Jun 2014 09:12:49 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so8926873wev.33 for ; Wed, 04 Jun 2014 09:12:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.93.202 with SMTP id cw10mr6152588wjb.95.1401898368652; Wed, 04 Jun 2014 09:12:48 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 4 Jun 2014 09:12:48 -0700 (PDT) In-Reply-To: References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> Date: Wed, 4 Jun 2014 11:12:48 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Y5wHA9Y_GfhdDnzQZqdzWzXZ3GY Cc: Paul Hoffman , "Joe Hildebrand \(jhildebr\)" , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Wed, 04 Jun 2014 16:12:57 -0000 Alright. Two proposals: 1) Writers MUST precede texts with RS, and SHOULD follow texts with LF. (RS must precede at least so as to make any complete text parseable even if the preceding one was written incompletely. LF is needed so as to make line-oriented tooling happy.) 2) Writers of logfiles (or any case where incomplete writes are a problem) MUST do the same as in (1). Other writers need only emit (MUST emit) an LF after each text. Symmetrically, parsers MUST be able to parse either form. I'm partial to (2) because it's backwards interoperable with what jq does today, but the consensus may well be for (1). Nico -- From nobody Wed Jun 4 10:43: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 BD67D1A0259 for ; Wed, 4 Jun 2014 10:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2alXNuz9PFL for ; Wed, 4 Jun 2014 10:43:25 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59A81A0254 for ; Wed, 4 Jun 2014 10:43:25 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s54Hh9NH046491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jun 2014 10:43:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: Date: Wed, 4 Jun 2014 10:43:07 -0700 Content-Transfer-Encoding: 7bit Message-Id: <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/json/WNQB7fejj0gx7Nr-bUJVSC9azfA Cc: Phillip Hallam-Baker , Joe Hildebrand Hildebrand , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Wed, 04 Jun 2014 17:43:27 -0000 On Jun 4, 2014, at 9:12 AM, Nico Williams wrote: > Alright. Two proposals: > > 1) Writers MUST precede texts with RS, and SHOULD follow texts with LF. > > (RS must precede at least so as to make any complete text parseable > even if the preceding one was written incompletely. LF is needed so > as to make line-oriented tooling happy.) > > 2) Writers of logfiles (or any case where incomplete writes are a > problem) MUST do the same as in (1). Other writers need only emit > (MUST emit) an LF after each text. Symmetrically, parsers MUST be > able to parse either form. (1) seems much cleaner than (2). --Paul Hoffman From nobody Wed Jun 4 10:55: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 3496F1A0306 for ; Wed, 4 Jun 2014 10:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 2IbwgPGmIY7l for ; Wed, 4 Jun 2014 10:54:56 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0241A024F for ; Wed, 4 Jun 2014 10:54:55 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id jz11so9138187veb.7 for ; Wed, 04 Jun 2014 10:54:49 -0700 (PDT) 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=+WLERh5bRDst83vkab0iTzgK5BH/lMW0Jt1h1OGm1qM=; b=PISGI3awhbBK9Q15o75rlttea7GCJ2FjLqd+8sgakXwsGwnyCVhOCDI2PRb5Pc+4H+ fibxmDxAPNoqvoMSnBXkUTuIrr6wKWTDi8FTyA2pJMKkxsHgdltiLPjayJFKzCeGTOcb qCpaMaj/TjVP9h8R3PZOrokKuLCUZOX/5ZBGPU8hsQJOlDeDJcTes6B85RDqB0ca66GX qa9SOAOFHWE5N49HI/ENm4mWeodpTqtXIA/jNCd2MkbAZfAB5oX4soR53P3NqU77+ued /zOJqjhutBNvloL0QkKglE/nmBBt8EJavvfyQ6GQd1fU1lYvBTLSUx+Z8S7fO8C8gqx9 pwYw== X-Gm-Message-State: ALoCoQmQIDyoD2kGnHtyQuow7Ru47tt1USiKl+Tz0eVX5JwuXykwUfSQxyQrMPstJf5DoNx+cxbc X-Received: by 10.58.118.228 with SMTP id kp4mr4473520veb.59.1401904489171; Wed, 04 Jun 2014 10:54:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Wed, 4 Jun 2014 10:54:29 -0700 (PDT) X-Originating-IP: [24.85.103.37] In-Reply-To: <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> From: Tim Bray Date: Wed, 4 Jun 2014 10:54:29 -0700 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e0122f8fc16216204fb06532a Archived-At: http://mailarchive.ietf.org/arch/msg/json/wLbrYeDY53yM_l6LWucTh4SMG-U Cc: Nico Williams , Phillip Hallam-Baker , Joe Hildebrand Hildebrand , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Wed, 04 Jun 2014 17:55:01 -0000 --089e0122f8fc16216204fb06532a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hah, I hadn=E2=80=99t realized that RS (U+001E, INFORMATION SEPARATOR TWO) = was excluded. OK, so the abnf for JSON-sequence becomes one of these two: JSON-sequence =3D JSON-text *( %1e JSON-text ) JSON-sequence =3D *( ws %1e JSON-text ) Depending on whether you see the RS as an initiator or a separator. I think I very slightly prefer the second. On Wed, Jun 4, 2014 at 10:43 AM, Paul Hoffman wrote= : > > > On Jun 4, 2014, at 9:12 AM, Nico Williams wrote: > > > Alright. Two proposals: > > > > 1) Writers MUST precede texts with RS, and SHOULD follow texts with LF. > > > > (RS must precede at least so as to make any complete text parseable > > even if the preceding one was written incompletely. LF is needed so > > as to make line-oriented tooling happy.) > > > > 2) Writers of logfiles (or any case where incomplete writes are a > > problem) MUST do the same as in (1). Other writers need only emit > > (MUST emit) an LF after each text. Symmetrically, parsers MUST be > > able to parse either form. > > (1) seems much cleaner than (2). > > --Paul Hoffman > > _______________________________________________ > 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) --089e0122f8fc16216204fb06532a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hah= , I hadn=E2=80=99t realized that RS (U+001E,=C2=A0INFORMATION SEPARATOR TWO= ) was excluded. =C2=A0 OK, so the abnf for JSON-sequence becomes one of the= se two:

JSON-sequence =3D JSON-te= xt *( %1e JSON-text )
JSON-sequence = =3D *( ws %1e JSON-text )

Depending on whether you see the RS as an initiator or a separator. =C2=A0I= think I very slightly prefer the second.


On Wed,= Jun 4, 2014 at 10:43 AM, Paul Hoffman <paul.hoffman@vpnc.org><= /span> wrote:
<no hat>

On Jun 4, 2014, at 9:12 AM, Nico Williams <nico@cryptonector.com> wrote:

> Alright. =C2=A0Two proposals:
>
> 1) Writers MUST precede texts with RS, and SHOULD follow texts with LF= .
>
> (RS must precede at least so as to make any complete text parseable > even if the preceding one was written incompletely. =C2=A0LF is needed= so
> as to make line-oriented tooling happy.)
>
> 2) Writers of logfiles (or any case where incomplete writes are a
> problem) MUST do the same as in (1). =C2=A0Other writers need only emi= t
> (MUST emit) an LF after each text. =C2=A0Symmetrically, parsers MUST b= e
> able to parse either form.

(1) seems much cleaner than (2).

--Paul Hoffman

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



--
=
- Tim Bray (If you=E2=80=99d like to send me a privat= e message, see htt= ps://keybase.io/timbray)
--089e0122f8fc16216204fb06532a-- From nobody Wed Jun 4 10:57:15 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 6F4DB1A0254 for ; Wed, 4 Jun 2014 10:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-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 2Gw5iSATx4jq for ; Wed, 4 Jun 2014 10:57:11 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD0D1A024F for ; Wed, 4 Jun 2014 10:57:10 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id pa12so9282424veb.18 for ; Wed, 04 Jun 2014 10:57:03 -0700 (PDT) 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=6ESnUtzv6JxY6lhaav6C2an3CP85g9cQvwA047kwW1A=; b=CG2YCMfnYRmWZ553P3Znt6Rz3g2FmkY9YXEa18SCQWbnaXDcesWeWGW6SGlZ2isYJp 4WzX6w6KV7TM0ic6BQjCLGQqeIbOo8zMO9lX58LDbeMbBBM+V4uZb4V9yg+I0krd+ZWP 8+zErAu9ey83tf/7ssv3TasOfivuMgVC9DRkKDEAarUnVO0OcqkJdtkD3FQDJSmT6v1C R0ZeeEIQQziTv0sU6vAkKI87TQ9wBuqDFsy6kq8Ee/fVnrSaCV+xsionTF63lEaMli+M 8IZQCVOHXQZXeFN57ElUpW1SDMC2bSBYY1EKjOtO5m+El1OpReT9Fhopdzen+S2+NslG 8Baw== X-Gm-Message-State: ALoCoQn1oGM8hcLqOouLWsoxkSxQSvmbSko31uEXRVnB+3QHBscJ/rKt3wiA+syeXQzs+oxqBzSi X-Received: by 10.220.165.6 with SMTP id g6mr6431727vcy.17.1401904623625; Wed, 04 Jun 2014 10:57:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Wed, 4 Jun 2014 10:56:43 -0700 (PDT) X-Originating-IP: [24.85.103.37] In-Reply-To: References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> From: Tim Bray Date: Wed, 4 Jun 2014 10:56:43 -0700 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c3576c19bddf04fb065b0b Archived-At: http://mailarchive.ietf.org/arch/msg/json/gr7sIzh8etX-d2Oh9cIsMU8Yv8o Cc: Nico Williams , Phillip Hallam-Baker , Joe Hildebrand Hildebrand , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Wed, 04 Jun 2014 17:57:13 -0000 --001a11c3576c19bddf04fb065b0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And, editing my own abnf, the two alternatives are: JSON-sequence =3D JSON-text *( %1e JSON-text ) JSON-sequence =3D ws *( %1e JSON-text ) I see no utility in saying anything about linefeeds whatsoever. On Wed, Jun 4, 2014 at 10:54 AM, Tim Bray wrote: > Hah, I hadn=E2=80=99t realized that RS (U+001E, INFORMATION SEPARATOR TWO= ) was > excluded. OK, so the abnf for JSON-sequence becomes one of these two: > > JSON-sequence =3D JSON-text *( %1e JSON-text ) > JSON-sequence =3D *( ws %1e JSON-text ) > > Depending on whether you see the RS as an initiator or a separator. I > think I very slightly prefer the second. > > > On Wed, Jun 4, 2014 at 10:43 AM, Paul Hoffman > wrote: > >> >> >> On Jun 4, 2014, at 9:12 AM, Nico Williams wrote: >> >> > Alright. Two proposals: >> > >> > 1) Writers MUST precede texts with RS, and SHOULD follow texts with LF= . >> > >> > (RS must precede at least so as to make any complete text parseable >> > even if the preceding one was written incompletely. LF is needed so >> > as to make line-oriented tooling happy.) >> > >> > 2) Writers of logfiles (or any case where incomplete writes are a >> > problem) MUST do the same as in (1). Other writers need only emit >> > (MUST emit) an LF after each text. Symmetrically, parsers MUST be >> > able to parse either form. >> >> (1) seems much cleaner than (2). >> >> --Paul Hoffman >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c3576c19bddf04fb065b0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And= , editing my own abnf, the two alternatives are:=C2=A0

JSON-sequence =3D JSON-text *( %1e JSON-text )
JSON-sequence =3D ws *( %1e JSON-text )=

I see no utility in saying anything about linefeeds whatsoeve= r.


On Wed, Jun 4, 2014 at 10:54 AM, Tim Bray <tbray@textuality.com>= wrote:
Hah= , I hadn=E2=80=99t realized that RS (U+001E,=C2=A0INFORMATION SEPARATOR TWO= ) was excluded. =C2=A0 OK, so the abnf for JSON-sequence becomes one of the= se two:

JSON-sequence =3D JSON-te= xt *( %1e JSON-text )
JSON-sequence = =3D *( ws %1e JSON-text )

Depending on whether you see the RS as an initiator or a separator. =C2=A0I= think I very slightly prefer the second.


On Wed, Jun 4, 2014 at 10:43 AM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
<no hat>

On Jun 4, 2014, at 9:12 AM, Nico Williams <nico@cryptonector.com> wrote:

> Alright. =C2=A0Two proposals:
>
> 1) Writers MUST precede texts with RS, and SHOULD follow texts with LF= .
>
> (RS must precede at least so as to make any complete text parseable > even if the preceding one was written incompletely. =C2=A0LF is needed= so
> as to make line-oriented tooling happy.)
>
> 2) Writers of logfiles (or any case where incomplete writes are a
> problem) MUST do the same as in (1). =C2=A0Other writers need only emi= t
> (MUST emit) an LF after each text. =C2=A0Symmetrically, parsers MUST b= e
> able to parse either form.

(1) seems much cleaner than (2).

--Paul Hoffman

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



<= /div>
--
- Tim Bray (If you=E2=80= =99d like to send me a private message, see https://keybase.io/timbray)



--
- Tim Bray (If you=E2=80=99d like to send me a private message, s= ee https://keybase= .io/timbray)
--001a11c3576c19bddf04fb065b0b-- From nobody Wed Jun 4 11:01: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 BA4871A0254 for ; Wed, 4 Jun 2014 11:01:36 -0700 (PDT) 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 yqu2AAP19X8X for ; Wed, 4 Jun 2014 11:01:35 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05C91A024F for ; Wed, 4 Jun 2014 11:01:34 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so8928635wgg.12 for ; Wed, 04 Jun 2014 11:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WNd+fhdZGgpaU0MVUmw2ln0XPRBelKzIaYTXUsdZq8s=; b=zwxjVI01c9W8xD/bypMp81TBh9CZpB/RUQy840o2xP/v2Dg6j8J0OVtcQ5vhxRuFnE 6infagrEBbYz8+mFMhNkSJbesEX1ydk0RyCGo+LVWxEYEuEB4rICN7H42B/apRa+oS+p aFbj59nONdFYvnxh4gvxkLNwpiDb/6HveCMJ1lF2keJ61PNoog7n1Ag6i1f8N3y8JSZp Ia+uhapul/yhba1ayW+NSytN8Naf5Lamztz2YSaK3IKOX9XeR1LhNOxnO0ws50gRzmp/ Adw/coyMcd9aTCOm1alGSUS9r0ZoeQZ+/9gVAVcbt1IIh+dPrpWLuwRDtnwOB/h58c9R bJBg== MIME-Version: 1.0 X-Received: by 10.194.62.176 with SMTP id z16mr7381551wjr.76.1401904887448; Wed, 04 Jun 2014 11:01:27 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Wed, 4 Jun 2014 11:01:27 -0700 (PDT) In-Reply-To: References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> Date: Wed, 4 Jun 2014 14:01:27 -0400 X-Google-Sender-Auth: dk24oMK6x8ub4E4t1emHGl9BEb0 Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/jcahQW6IhAZ8TrGPTDhrWoK4oAs Cc: Nico Williams , Paul Hoffman , Joe Hildebrand Hildebrand , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Wed, 04 Jun 2014 18:01:36 -0000 +1 I prefer the 'strict writer, lose reader' approach here. And that is not my usual stance. The reason that I think readers need to be tolerant is that they should be able to read log files after they have been 'damaged' by tools that strip out the RS characters. For example, lets say that I have some program that records every transaction to a logfile and it is discovered that one of the transactions was wrong and is corrupting the database. The simplest solution is usually to take the log file, find the broken transaction, edit it out and rebuild the data base. Given the quality of editing tools available on many machines, I don't trust them to preserve non printing ASCII characters. Heck, the editor on ubuntu can't even start in a root account without writing garbage to the terminal. So readers should be tolerant. On Wed, Jun 4, 2014 at 1:54 PM, Tim Bray wrote: > Hah, I hadn=E2=80=99t realized that RS (U+001E, INFORMATION SEPARATOR TWO= ) was > excluded. OK, so the abnf for JSON-sequence becomes one of these two: > > JSON-sequence =3D JSON-text *( %1e JSON-text ) > JSON-sequence =3D *( ws %1e JSON-text ) > > Depending on whether you see the RS as an initiator or a separator. I th= ink > I very slightly prefer the second. > > > On Wed, Jun 4, 2014 at 10:43 AM, Paul Hoffman wro= te: >> >> >> >> On Jun 4, 2014, at 9:12 AM, Nico Williams wrote: >> >> > Alright. Two proposals: >> > >> > 1) Writers MUST precede texts with RS, and SHOULD follow texts with LF= . >> > >> > (RS must precede at least so as to make any complete text parseable >> > even if the preceding one was written incompletely. LF is needed so >> > as to make line-oriented tooling happy.) >> > >> > 2) Writers of logfiles (or any case where incomplete writes are a >> > problem) MUST do the same as in (1). Other writers need only emit >> > (MUST emit) an LF after each text. Symmetrically, parsers MUST be >> > able to parse either form. >> >> (1) seems much cleaner than (2). >> >> --Paul Hoffman >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json > > > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) From nobody Wed Jun 4 13:24: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 4BC591A03C9 for ; Wed, 4 Jun 2014 13:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_22=1, 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 bK2p1RjXCgSk for ; Wed, 4 Jun 2014 13:23:58 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 751EE1A0339 for ; Wed, 4 Jun 2014 13:23:58 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 7868B20202C for ; Wed, 4 Jun 2014 13:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=MrV7zkjbFSfHCWfKdpOl0XZ++/U=; b=BtXfOz/BzeO txhVFez0GECAEjc1kMuwpUCJHG2DhsuoRGqZwoUUnTVNeQo84KaW08p3vUnAkUm+ 6IDDYbJOb9Sts2XP4AX9dbWVMnTotOTsI+DNqNV8EaP/P0dOb0Y5d4Kxr+EYzvOC JQlT7+/Yz8+1uY9cD8f2NL1CyD0WlJC8= Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 4B144202018 for ; Wed, 4 Jun 2014 13:23:52 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wn1so22286obc.41 for ; Wed, 04 Jun 2014 13:23:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.97.97 with SMTP id dz1mr61672518obb.13.1401913431708; Wed, 04 Jun 2014 13:23:51 -0700 (PDT) Received: by 10.182.234.4 with HTTP; Wed, 4 Jun 2014 13:23:51 -0700 (PDT) In-Reply-To: References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> Date: Wed, 4 Jun 2014 15:23:51 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/mOnkg1DtTE1g_mUHUWueWcG1_yY Cc: Tim Bray , Paul Hoffman , Joe Hildebrand Hildebrand , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Wed, 04 Jun 2014 20:23:59 -0000 On Wed, Jun 4, 2014 at 1:01 PM, Phillip Hallam-Baker wrote: > On Wed, Jun 4, 2014 at 1:54 PM, Tim Bray wrote: >> Hah, I hadn=E2=80=99t realized that RS (U+001E, INFORMATION SEPARATOR TW= O) was >> excluded. OK, so the abnf for JSON-sequence becomes one of these two: Someone (Carsten?) proposed it earlier. RS is, indeed, perfect for this. >> >> JSON-sequence =3D JSON-text *( %1e JSON-text ) >> JSON-sequence =3D *( ws %1e JSON-text ) >> >> Depending on whether you see the RS as an initiator or a separator. I t= hink >> I very slightly prefer the second. It has to be an initiator for append-write logfiles, as it then marks the end of a possibly incompletely-written text. Otherwise you might lose the first text following an incompletely-written text. RS could also follow a text, but I prefer LF for this because it's friendly to line-oriented text tools. It's harmless to have a trailing LF (since the JSON-text ABNF allows extra trailing whitespace anyways). > +1 > > I prefer the 'strict writer, lose reader' approach here. And that is > not my usual stance. Is that in reference to my (2) or Tim's point? Since you top-posted, and since Tim didn't propose a loose reader, I can't tell :) > The reason that I think readers need to be tolerant is that they > should be able to read log files after they have been 'damaged' by > tools that strip out the RS characters. Yes. If you see something like: it should parse, even though it should have been: RSRSRS because, why not parse it? Thus my (2). To repeat myself, jq doesn't insist on any separator at parse time, except where the separator is needed to disambiguate. E.g., if you have to texts consisting of numbers, or booleans, or null, then the parser can't parse them without a separator of some sort. > For example, lets say that I have some program that records every > transaction to a logfile and it is discovered that one of the > transactions was wrong and is corrupting the database. The simplest > solution is usually to take the log file, find the broken transaction, > edit it out and rebuild the data base. Or leave it in and just skip past it when you parse. > Given the quality of editing tools available on many machines, I don't > trust them to preserve non printing ASCII characters. Heck, the editor > on ubuntu can't even start in a root account without writing garbage > to the terminal. > > So readers should be tolerant. Right, which is one reason that I want the ABNF for writers to be: sequence =3D RS JSON-text LF but parsers should be more liberal. I'll grant that if there's an RS present then one can use any kind of JSON parser to parse the sequence whereas otherwise only incremental and streaming JSON parsers can be used. This is the one reason to require that RS always be written. Nico -- From nobody Wed Jun 4 13:36: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 A24FB1A02F0 for ; Wed, 4 Jun 2014 13:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, 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 vHWvbutCq785 for ; Wed, 4 Jun 2014 13:36:46 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CBC41A0024 for ; Wed, 4 Jun 2014 13:36:46 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id pa12so51170veb.12 for ; Wed, 04 Jun 2014 13:36:39 -0700 (PDT) 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=X0axjuEf1b60zVrgalcYZCMvHYX5xK7Z1z8dQqLiuns=; b=kNRFUFaEZLwmbsmgyGI7yFvU2T9qQoyPyOGBaBCe7jQQ7tHUPNlEHkvBBCzUNBgcKP dMFN6TbP591tXV94epd9p/RTafQ7miDI/1DHE2qpazcEu7e0RDxzH37BFE2gXdyzSXLO KKubIsI9nPxdyy+Si6ekbp8JvTQFqsV0mwYp554Fjy9sxLCb8sM6DNb0kAv6kSX8Sd0d FhPUqn5c/E0nI2HfH9Ib43s6GP1txotJQG+SbagUnX+uO2GRMCHFJm2laozWV5o0tFQp BYMDgFTON2Iilokf21CRmTLQMV0ZJZ7OCt0Hs9HDk+051DNVO5X6AQemBiB1BpGiu38T J3Hg== X-Gm-Message-State: ALoCoQmZewuztotryQmJzvB3rRzYULE8lepU0Irbdz9ihkmup4oTE4nnhYYvXzqN22+xTlCZTD6K X-Received: by 10.58.123.71 with SMTP id ly7mr46371314veb.11.1401914199431; Wed, 04 Jun 2014 13:36:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Wed, 4 Jun 2014 13:36:19 -0700 (PDT) X-Originating-IP: [24.85.103.37] In-Reply-To: References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> From: Tim Bray Date: Wed, 4 Jun 2014 13:36:19 -0700 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=089e0115f0a2dcf0b304fb089502 Archived-At: http://mailarchive.ietf.org/arch/msg/json/zxPlsq0RmCy1wZZ1H1n5cy8z7Vw Cc: Phillip Hallam-Baker , Paul Hoffman , Joe Hildebrand Hildebrand , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Wed, 04 Jun 2014 20:36:47 -0000 --089e0115f0a2dcf0b304fb089502 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I totally don=E2=80=99t get why you want the LF involved. I can=E2=80=99t = see how it would make any difference, could you explain more? On Wed, Jun 4, 2014 at 1:23 PM, Nico Williams wrote= : > On Wed, Jun 4, 2014 at 1:01 PM, Phillip Hallam-Baker > wrote: > > On Wed, Jun 4, 2014 at 1:54 PM, Tim Bray wrote: > >> Hah, I hadn=E2=80=99t realized that RS (U+001E, INFORMATION SEPARATOR = TWO) was > >> excluded. OK, so the abnf for JSON-sequence becomes one of these two= : > > Someone (Carsten?) proposed it earlier. RS is, indeed, perfect for this. > > >> > >> JSON-sequence =3D JSON-text *( %1e JSON-text ) > >> JSON-sequence =3D *( ws %1e JSON-text ) > >> > >> Depending on whether you see the RS as an initiator or a separator. I > think > >> I very slightly prefer the second. > > It has to be an initiator for append-write logfiles, as it then marks > the end of a possibly incompletely-written text. Otherwise you might > lose the first text following an incompletely-written text. > > RS could also follow a text, but I prefer LF for this because it's > friendly to line-oriented text tools. It's harmless to have a > trailing LF (since the JSON-text ABNF allows extra trailing whitespace > anyways). > > > +1 > > > > I prefer the 'strict writer, lose reader' approach here. And that is > > not my usual stance. > > Is that in reference to my (2) or Tim's point? Since you top-posted, > and since Tim didn't propose a loose reader, I can't tell :) > > > The reason that I think readers need to be tolerant is that they > > should be able to read log files after they have been 'damaged' by > > tools that strip out the RS characters. > > Yes. If you see something like: > > > > it should parse, even though it should have been: > > RSRSRS > > because, why not parse it? > > Thus my (2). > > To repeat myself, jq doesn't insist on any separator at parse time, > except where the separator is needed to disambiguate. E.g., if you > have to texts consisting of numbers, or booleans, or null, then the > parser can't parse them without a separator of some sort. > > > For example, lets say that I have some program that records every > > transaction to a logfile and it is discovered that one of the > > transactions was wrong and is corrupting the database. The simplest > > solution is usually to take the log file, find the broken transaction, > > edit it out and rebuild the data base. > > Or leave it in and just skip past it when you parse. > > > Given the quality of editing tools available on many machines, I don't > > trust them to preserve non printing ASCII characters. Heck, the editor > > on ubuntu can't even start in a root account without writing garbage > > to the terminal. > > > > So readers should be tolerant. > > Right, which is one reason that I want the ABNF for writers to be: > > sequence =3D RS JSON-text LF > > but parsers should be more liberal. > > I'll grant that if there's an RS present then one can use any kind of > JSON parser to parse the sequence whereas otherwise only incremental > and streaming JSON parsers can be used. This is the one reason to > require that RS always be written. > > Nico > -- > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --089e0115f0a2dcf0b304fb089502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I t= otally don=E2=80=99t get why you want the LF involved. =C2=A0I can=E2=80=99= t see how it would make any difference, could you explain more?
=


On Wed, Jun 4, 2014 at 1:23 PM, Nico Wil= liams <nico@cryptonector.com> wrote:
On Wed, Jun 4, 2014 at 1:01 PM, Phillip Hallam-Baker
<ietf@hallambaker.com> wr= ote:
> On Wed, Jun 4, 2014 at 1:54 PM, Tim Bray <tbray@textuality.com> wrote:
>> Hah, I hadn=E2=80=99t realized that RS (U+001E, INFORMATION SEPARA= TOR TWO) was
>> excluded. =C2=A0 OK, so the abnf for JSON-sequence becomes one of = these two:

Someone (Carsten?) proposed it earlier. =C2=A0RS is, indeed, perfect = for this.

>>
>> JSON-sequence =3D JSON-text *( %1e JSON-text )
>> JSON-sequence =3D *( ws %1e JSON-text )
>>
>> Depending on whether you see the RS as an initiator or a separator= . =C2=A0I think
>> I very slightly prefer the second.

It has to be an initiator for append-write logfiles, as it then marks=
the end of a possibly incompletely-written text. =C2=A0Otherwise you might<= br> lose the first text following an incompletely-written text.

RS could also follow a text, but I prefer LF for this because it's
friendly to line-oriented text tools. =C2=A0It's harmless to have a
trailing LF (since the JSON-text ABNF allows extra trailing whitespace
anyways).

> +1
>
> I prefer the 'strict writer, lose reader' approach here. And t= hat is
> not my usual stance.

Is that in reference to my (2) or Tim's point? =C2=A0Since you to= p-posted,
and since Tim didn't propose a loose reader, I can't tell :)

> The reason that I think readers need to be tolerant is that they
> should be able to read log files after they have been 'damaged'= ; by
> tools that strip out the RS characters.

Yes. =C2=A0If you see something like:

<text> <text> <text>

it should parse, even though it should have been:

RS<text>RS<text>RS<text>

because, why not parse it?

Thus my (2).

To repeat myself, jq doesn't insist on any separator at parse time,
except where the separator is needed to disambiguate. =C2=A0E.g., if you have to texts consisting of numbers, or booleans, or null, then the
parser can't parse them without a separator of some sort.

> For example, lets say that I have some program that records every
> transaction to a logfile and it is discovered that one of the
> transactions was wrong and is corrupting the database. The simplest > solution is usually to take the log file, find the broken transaction,=
> edit it out and rebuild the data base.

Or leave it in and just skip past it when you parse.

> Given the quality of editing tools available on many machines, I don&#= 39;t
> trust them to preserve non printing ASCII characters. Heck, the editor=
> on ubuntu can't even start in a root account without writing garba= ge
> to the terminal.
>
> So readers should be tolerant.

Right, which is one reason that I want the ABNF for writers to be:
=C2=A0 =C2=A0 sequence =3D RS JSON-text LF

but parsers should be more liberal.

I'll grant that if there's an RS present then one can use any kind = of
JSON parser to parse the sequence whereas otherwise only incremental
and streaming JSON parsers can be used. =C2=A0This is the one reason to
require that RS always be written.

Nico
--



--
- Tim Bray (If you=E2=80=99d like to send me a private message, s= ee https://keybase= .io/timbray)
--089e0115f0a2dcf0b304fb089502-- From nobody Wed Jun 4 13:52: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 E4EB21A02F0 for ; Wed, 4 Jun 2014 13:52:35 -0700 (PDT) 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 MHR1oRkjRiSD for ; Wed, 4 Jun 2014 13:52:35 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E783E1A0024 for ; Wed, 4 Jun 2014 13:52:34 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id c1so6785196igq.10 for ; Wed, 04 Jun 2014 13:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=WdB7pGrYYyy9f5UiwXxXLisVkMtPHREuhaiVlCNb048=; b=QAVGFso24ZU+9QdZed8BoKX8KLMXuMeg4+JNkacvFvtwZaWIUpgtMG3O8ldKl+vX5i 3x9XS6htnlvqE+rYBljXniHNlyB+z1+GUQQhGVlwMwH8VEKu8xFXM0rG4zJZ8XdJKZUf 5il1Oc6E+4XvrdnZmGCqe3/bEDpMN7x6RX0HZhxMYC9kFDigsPEdX8jbMKTTsmc3iANW cFLOj8nRzK9A7nhzrajhVM1zGzQBpZkwTBslmFoQaAt96d/+RRhvWlLJRLFkiHR9ptEQ C9IzFn+GmGfuy26fEYgx5lI+0iJJ1VnX8w5EHnrnhX4y0N2m0s1fwOEKOfBmolXBLa7z 0j5g== X-Received: by 10.50.122.67 with SMTP id lq3mr11499899igb.8.1401915148509; Wed, 04 Jun 2014 13:52:28 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.50.89.133 with HTTP; Wed, 4 Jun 2014 13:52:08 -0700 (PDT) In-Reply-To: References: From: Jacob Davies Date: Wed, 4 Jun 2014 13:52:08 -0700 X-Google-Sender-Auth: QqjjC5rRCS4sNjnymyZhoJHESqk Message-ID: To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/8orMySNFvarXdO0CAiaYJFNB3_U Cc: Matthew Morley , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] Proposal to move forward on acceptable roots 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, 04 Jun 2014 20:52:36 -0000 Should you mention "in a string element" in the binary- & date-encoding adv= ice? On Fri, May 30, 2014 at 3:57 PM, Tim Bray wrote: > OK, I=E2=80=99ve got a i-json-01 in progress at > http://www.tbray.org/tmp/draft-ietf-json-i-json-01.html which I think > captures all the consensus calls and also includes a =E2=80=9CProtocol-de= sign > Recommendations=E2=80=9D section and drops the array-or-object top-level = constraint. > > Diffs at > http://tools.ietf.org/rfcdiff?url1=3Dhttp://www.tbray.org/tmp/draft-ietf-= json-i-json-00.txt&url2=3Dhttp://www.tbray.org/tmp/draft-ietf-json-i-json-0= 1.txt > > > On Fri, May 30, 2014 at 2:18 PM, Matthew Morley wrote: >> >> +1 >> >> >> On Fri, May 30, 2014 at 12:13 PM, Joe Hildebrand (jhildebr) >> wrote: >>> >>> One way we could go on the topic of what goes in the root that would wo= rk >>> for me would be for us to add a non-normative section to I-JSON giving >>> protocol design advice, and move the issue of potential incompatibility >>> of >>> non-[object,array] roots to that section. >>> >>> Into that section, we can also put some suggestions about how to encode >>> integers, floats, and dates in strings, how to do forward-compatibility >>> with objects (MUST ignore what you don't understand), and whatever othe= r >>> pearls of wisdom we come up with. >>> >>> Yes, I know that will make the document take longer, and open up other >>> areas for us to argue about. >>> >>> -- >>> Joe Hildebrand >>> >>> >>> >>> _______________________________________________ >>> json mailing list >>> json@ietf.org >>> https://www.ietf.org/mailman/listinfo/json >> >> >> >> >> -- >> Matthew P. C. Morley >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Wed Jun 4 15:40:13 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 8181F1A0373 for ; Wed, 4 Jun 2014 15:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9YryLW9qTh6 for ; Wed, 4 Jun 2014 15:40:05 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4621A0348 for ; Wed, 4 Jun 2014 15:40:05 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id C7920161E for ; Wed, 4 Jun 2014 15:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=6lqkC9BaUYpBmIZBj36ZwikMAhQ=; b=MAG3OdWq0ST rkD+1rxxTTHothMhIihyHHh0k9fLzu5MuRVEKJLtKsAiMhX1feaD2OGgtwdMzh1H hIhm7M6HQQkxK3pDaBA5Izz+CPzVSLRkK1jMPeDz2ydzT0KIhAVrmjZDJejhG46o iYxEjpveo/wqTbXZM69v3Nt0hIHuPkg8= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 738BA161D for ; Wed, 4 Jun 2014 15:39:58 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so166701wgg.18 for ; Wed, 04 Jun 2014 15:39:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.93.202 with SMTP id cw10mr9248323wjb.95.1401921596280; Wed, 04 Jun 2014 15:39:56 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 4 Jun 2014 15:39:56 -0700 (PDT) In-Reply-To: References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> Date: Wed, 4 Jun 2014 17:39:56 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/1trIacgfG5LNSByf4fVb--sktko Cc: Phillip Hallam-Baker , Paul Hoffman , Joe Hildebrand Hildebrand , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Wed, 04 Jun 2014 22:40:08 -0000 On Wed, Jun 4, 2014 at 3:36 PM, Tim Bray wrote: > I totally don=E2=80=99t get why you want the LF involved. I can=E2=80=99= t see how it would > make any difference, could you explain more? Sure. Short version: I'm a fan of ASN.1 and PER and XDR. But it's true that JSON is a _textual_ encoding and so I can use $PAGER. That's nice. And if I'm going to use $PAGER, then newlines between texts is... necessary. Long version: Let's start with this: jq(1) _today_ deals in JSON text sequences as inputs and outputs. You can ask jq(1) to output compact texts (like pretty much all JSON encoders I know) or pretty-print, even colorize texts, but jq(1) will always output a newline after every text, so this: % jq -C . some-file | $PAGER -R and the texts in 'some-file' will not run on: each will end in a newline. Most JSON encoders I know have a "compact" output option: the whole text with no extra whitespace. jq(1)'s encoder does too, and so we can: % jq -c -f program.jq input-file > output % wc -l output And sure, I could just as easily: % jq length output and that's more correct even (since if 'output' came from some other processor, there might be consecutive newlines, giving an incorrect count with wc(1)). But I can do all sorts of things with just text. Like: use grep(1) as an optimization to avoid parsing non-matching texts: % grep -i "error.*some.error.or.other" output | jq -C -f more-specific-filter.jq | $PAGER -R Sure, it's an optimization, but don't diss optimizations. PHB mentions $EDITOR. I mention $PAGER. And as I said, I'm a fan of binary encodings. If jq(1) spoke some binary encoding of JSON none of that would work, but that's OK: if I had and were using such an encoding (that worked well with sequences) I'd just not expect text-oriented tools to be any use, or I could throw a re-encoder in the pipe so I could use text-oriented tools. Nico -- From nobody Wed Jun 4 23:25:34 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 8419A1A0331 for ; Wed, 4 Jun 2014 23:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, 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 XnoxQoYvnQqK for ; Wed, 4 Jun 2014 23:25:30 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id E069F1A02F8 for ; Wed, 4 Jun 2014 23:25:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,978,1392123600"; d="scan'208";a="217000968" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 05 Jun 2014 16:25:03 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7459"; a="284387393" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcavi.tcif.telstra.com.au with ESMTP; 05 Jun 2014 16:25:03 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 5 Jun 2014 16:25:03 +1000 From: "Manger, James" To: Nico Williams , Phillip Hallam-Baker Date: Thu, 5 Jun 2014 16:25:01 +1000 Thread-Topic: [Json] Using a non-whitespace separator (Re: Working Group Last Call on draft-ietf-json-text-sequence) Thread-Index: Ac+AMuq+MLrk5FTwQ6i0mvLUdD7wdgATJ9PQ Message-ID: <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Px3NVp4COpedoTJZAUZHedQb3fM Cc: Tim Bray , Paul Hoffman , Joe Hildebrand Hildebrand , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 06:25:31 -0000 Pj4gSlNPTi1zZXF1ZW5jZSA9ICooIHdzICUxZSBKU09OLXRleHQgKQ0KDQpSUyBhcyBhIEpTT04g c2VxdWVuY2UgcHJlZml4IG9yIHNlcGFyYXRvciB3YXMgYSBiYWQgaWRlYSB3aGVuIGRpc2N1c3Nl ZCBhIG1vbnRoIGFnbyBhbmQgc3RpbGwgaXMuDQoNCiogWW91IGNhbm5vdCAoZWFzaWx5KSBlbnRl ciBhbiBSUyBpbiBub3RlcGFkLg0KKiBZb3UgY2Fubm90IChlYXNpbHkpIGVudGVyIGFuIFJTIGlu IHZpLg0KKiBZb3UgY2Fubm90IHNlZSBhbiBSUy4NCiogQW4gUlMgY2F1c2VzIENocm9tZSB0byB0 cmVhdCBhIGZpbGUgYXMgYmluYXJ5IGRhdGEsIGluc3RlYWQgb2YgdGV4dC4NCiogQ3V0LW4tcGFz dGUgYSBKU09OIHZhbHVlIHdpdGggYW4gaW52aXNpYmxlIFJTIHByZWZpeCBhbmQgdGhlIHJlc3Vs dCBpcyBOT1QgSlNPTiwgaWUgaXQgd2lsbCBmYWlsIHdpdGggYSBKU09OIHBhcnNlciBhcyBSUyBp cyBub3QgYWxsb3dlZCBpbiBKU09OLg0KKiBObyBvbmUgdXNlcyBSUy4NCiogUlMgaXMgbm93IGxh YmVsbGVkIElORk9STUFUSU9OIFNFUEFSQVRPUiBUV08sIG5vdCBSRUNPUkQgU0VQQVJBVE9SLg0K KiBXZSBhcmVuJ3QgdXNpbmcgSU5GT1JNQVRJT04gU0VQQVJBVE9SIE9ORSwgVEhSRUUgb3IgRk9V Ui4NCiogQSBuZXdsaW5lIGFzIGEgSlNPTiB2YWx1ZSB0ZXJtaW5hdG9yIGlzIHN1ZmZpY2llbnQg dG8gcGFyc2UgYSBKU09OIHNlcXVlbmNlIHVuYW1iaWd1b3VzbHkuDQoqIFJTIGRvZXNuJ3Qgd29y ayB3ZWxsIHdpdGggQVBJcyB0aGF0IHJlYWQgdGV4dCBieSB0aGUgbGluZS4NCiogRGV0ZWN0aW5n IGEgbmV3bGluZSB0aGF0IHNlcGFyYXRlcyBKU09OIHZhbHVlcyBpcyBtb3JlIGNvbXBsZXggdGhh biBkZXRlY3RpbmcgYW4gUlMgY2hhcmFjdGVyLCBidXQgaXQgaXMgbm90IHRoYXQgY29tcGxleCAo ZWcgaGFuZGZ1bCBvZiBsaW5lcyBvZiBjb2RlKS4NCiogQW4gUlMgcHJlZml4IGRldGVjdHMgb25s eSBzbGlnaHRseSBtb3JlIGNhc2VzIG9mIGFjY2lkZW50YWxseSB0cnVuY2F0ZWQgd3JpdGVzIChp biB0aGUgbWlkZGxlIG9mIGEgdG9wLWxldmVsIG51bWJlciwgaW4gYSB0b3AtbGV2ZWwgc3RyaW5n IGluIHRoZSBtaWRkbGUgb2YgYW4gZXNjYXBlIHNlcXVlbmNlKSAtLSBub3QgZW5vdWdoIHRvIGJl IGNvbXBlbGxpbmcuDQoqIFRoZSBhd2t3YXJkbmVzcyBvZiBSUyB3aWxsIG1lYW4gbWFueSBpbXBs ZW1lbnRhdGlvbnMgd2lsbCBiZSBsZW5pZW50LCBidXQgbGVuaWVuY3kgYmVjb21lcyAiZXhwZWN0 ZWQiIHdoaWNoIGxlYWRzIHRvIGludGVyb3AgcHJvYmxlbXMuDQoNCiJBIEpTT04gc2VxdWVuY2Ug aXMgdGhlIGNvbmNhdGVuYXRpb24gb2YgemVybyBvciBtb3JlIEpTT04gdmFsdWVzLCB3aGVyZSBl YWNoIEpTT04gdmFsdWUgaXMgdGVybWluYXRlZCB3aXRoIGEgbmV3bGluZS4iDQoNClNpbXBsZSB0 byB1bmRlcnN0YW5kLiBTaW1wbGUgdG8gd3JpdGUuIFNpbXBsZSBlbm91Z2ggdG8gcGFyc2UuIFNp bXBsZSBlbm91Z2ggdG8gcmVzeW5jIGZyb20gdGhlIG1pZGRsZSBvZiBhIHNlcXVlbmNlLiBBbG1v c3QgaWRlbnRpY2FsIHJlY292ZXJ5IGZyb20gYWNjaWRlbnRhbCBjb3JydXB0aW9uIGlzIHBvc3Np YmxlIGluIGFsbW9zdCBhbGwgdGhlIHNhbWUgaW5zdGFuY2VzIHJlZ2FyZGxlc3Mgb2Ygd2hldGhl ciBhbiBSUyBwcmVmaXggb3IgbmV3bGluZSBzdWZmaXggaXMgdXNlZC4NCg0KLS0NCkphbWVzIE1h bmdlcg0KDQo= From nobody Thu Jun 5 01:59: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 D47AF1A01C0 for ; Thu, 5 Jun 2014 01:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 YHFYv47c1rMc for ; Thu, 5 Jun 2014 01:59:25 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 98EC51A042B for ; Thu, 5 Jun 2014 01:59:25 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 6F8F83B8069 for ; Thu, 5 Jun 2014 01:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=gCJDygB+BEUAkePgYSyz ibbOYJ4=; b=ZBMeEOwIXoActzMNDByufPk7xH+UjMe8senvbntw2AyANboRbhgH s87YJfg3BuTzzt/rl7vlOK67dGqbXJiwSvoH3M5KRG594Iuudd/NWhN0unL1TaEj ufu63bWz9Ibo3JQxczojbOnNO1sogHBsgZN97mABmbU1QKVC4C8wNU8= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id EE0CB3B8062 for ; Thu, 5 Jun 2014 01:59:18 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so710603wgg.0 for ; Thu, 05 Jun 2014 01:59:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.102.10 with SMTP id fk10mr13764593wib.42.1401958757740; Thu, 05 Jun 2014 01:59:17 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 5 Jun 2014 01:59:17 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 5 Jun 2014 03:59:17 -0500 Message-ID: From: Nico Williams To: "Manger, James" Content-Type: multipart/alternative; boundary=f46d0444ebfdbec69204fb12f5aa Archived-At: http://mailarchive.ietf.org/arch/msg/json/S_QYM4sDDcoj6XQYLvR0EtQm2tU Cc: Phillip Hallam-Baker , Tim Bray , Paul Hoffman , Joe Hildebrand Hildebrand , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 08:59:27 -0000 --f46d0444ebfdbec69204fb12f5aa Content-Type: text/plain; charset=UTF-8 On Thursday, June 5, 2014, Manger, James wrote: > >> JSON-sequence = *( ws %1e JSON-text ) > > RS as a JSON sequence prefix or separator was a bad idea when discussed a > month ago and still is. I'm happy to go with the current I-D's LF-based recovery mechanism or variant of it. If that's not acceptable then something like RS has to be it. A third alternative is to abandon logfiles as a use or accept truncated writes leading to fatal parse errors from the corrupted point forwards. A fourth alternative is to not publish on the Standards track, maybe publish as Informational or Experimental whatever fewer of us think is best. Before we get to any of those alternatives I'd like to try to get consensus. Remember, it's rough consensus and running code. I have running code and I'm open to changing it, but if some views are mutually exclusive and therefore some have to be on the rough side of consensus, then so be it. > * You cannot (easily) enter an RS in notepad. A reason to make it optional, as I proposed -- only logfile writers should have to emit it. > * You cannot (easily) enter an RS in vi. Meh. !printf '\x1E'. Also, same answer as above. > * You cannot see an RS. But that's harmless. Especially if you know to expect to find it there. > * An RS causes Chrome to treat a file as binary data, instead of text. That could get fixed (e.g., if Chrome learns about this new MIME type). > * Cut-n-paste a JSON value with an invisible RS prefix and the result is > NOT JSON, ie it will fail with a JSON parser as RS is not allowed in JSON. But you can be careful to not cut the RS. Or we could make it RS SP, to make it easier to find where to cut. > * No one uses RS. That's not much of an argument :) > * RS is now labelled INFORMATION SEPARATOR TWO, not RECORD SEPARATOR. Ditto. And noted. > * We aren't using INFORMATION SEPARATOR ONE, THREE or FOUR. Again. > * A newline as a JSON value terminator is sufficient to parse a JSON > sequence unambiguously. Except in the presence of incompletely-written entries. > * RS doesn't work well with APIs that read text by the line. Do you have any examples of such APIs? Define "well". > * Detecting a newline that separates JSON values is more complex than > detecting an RS character, but it is not that complex (eg handful of lines > of code). Maybe, and that is my preferred solution. I'm with you there. > * An RS prefix detects only slightly more cases of accidentally truncated > writes (in the middle of a top-level number, in a top-level string in the > middle of an escape sequence) -- not enough to be compelling. There are other cases if we have as a goal to recover starting at the very next full text following the truncated one. Preceding and following texts with LF also helps recovery in the cases you mention. But it's not enough. The current I-D covers some alternatives that do remove all ambiguities at little cost to either the parser or the encoder, including: removing internal newlines from texts (cheap operation; no need to parse and re-encode) and/or preceding texts with "null" LF. > * The awkwardness of RS will mean many implementations will be lenient, > but leniency becomes "expected" which leads to interop problems. Parsers shouldn't require it. Encoders should emit it if there's a chance of truncated writes. How can interop problems arise from this formula? What am I missing? > "A JSON sequence is the concatenation of zero or more JSON values, where > each JSON value is terminated with a newline." > > Simple to understand. Simple to write. Simple enough to parse. Simple > enough to resync from the middle of a sequence. Almost identical recovery > from accidental corruption is possible in almost all the same instances > regardless of whether an RS prefix or newline suffix is used. > Yes, and I very much like that, right up until one wants to cater to logfiles and the truncated write problem. See alternatives above. We must choose one. Two camps are squared off and I'm in the middle. One will win or all may lose. My preference is to say that logfile writers must remove internal newlines from the texts they write. That is by far the simplest fix for write truncation. Not all sequences will be logfile-like. No RS if we go with that. I haven't seen any strong arguments against that, in fact You have stronger arguments against RS than I have seen against internal newline removal by logfile writers. Let's sleep on it and revisit tomorrow, Nico -- --f46d0444ebfdbec69204fb12f5aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, June 5, 2014, Manger, James <James.H.Manger@team.telstra.com> wrote:
>> JSON-sequence =3D *( ws %1e JSON-text )

RS as a JSON sequence prefix or separator was a bad idea when discussed a m= onth ago and still is.

I'm happy to go with = the current I-D's LF-based recovery mechanism or variant of it. =C2=A0I= f that's not acceptable then something like=C2=A0RS has to be it.

A third alternative is to abandon logfiles as a use or accep= t truncated writes leading to fatal parse errors from the corrupted point f= orwards. =C2=A0A fourth=C2=A0alternative is to not=C2=A0publish on the Stan= dards track, maybe=C2=A0publish as Informational or Experimental whatever f= ewer of us=C2=A0think is best. =C2=A0Before we get to any of=C2=A0those=C2= =A0alternatives I'd like to try to get consensus.

Remember, it's rough consensus and running code. =C2=A0I= have running code and I'm open to changing it, but if some=C2=A0views= =C2=A0are=C2=A0mutually exclusive and therefore some=C2=A0have to be on the= rough side of consensus, then so be it.
=C2=A0
* You cannot (easily) enter an RS in notepad.

A reason to make it optional, as I proposed -- only=C2=A0logfile writers= should have to emit it.
=C2=A0
* You cannot (easily) enter an RS in vi.

Me= h. =C2=A0!printf '\x1E'. =C2=A0Also, same answer as above.
=C2=A0
* You cannot see an RS.

But that's harm= less. =C2=A0Especially if you know to expect to find it there.
= =C2=A0
* An RS causes Chrome to treat a file as binary data, instead of text.

That could get fixed (e.g., if Chrome learns ab= out this new MIME type).
=C2=A0
* Cut-n-paste a JSON value with an invisible RS prefix and the result is NO= T JSON, ie it will fail with a JSON parser as RS is not allowed in JSON.

But you can be careful to not cut the RS. =C2= =A0Or we could make it RS SP, to make it easier to find where to cut.
=C2=A0
* No one uses RS.

That's not much of an= =C2=A0argument :)
=C2=A0
* RS is now labelled INFORMATION SEPARATOR TWO, not RECORD SEPARATOR.

Ditto. =C2=A0And noted.
=C2=A0
* We aren't using INFORMATION SEPARATOR ONE, THREE or FOUR.

Again.
=C2=A0
* A newline as a JSON value terminator is sufficient to parse a JSON sequen= ce unambiguously.

Except in the presence of= incompletely-written entries.
=C2=A0
* RS doesn't work well with APIs that read text by the line.

Do you have any examples of such APIs? =C2=A0Define "= well".
=C2=A0
* Detecting a newline that separates JSON values is more complex than detec= ting an RS character, but it is not that complex (eg handful of lines of co= de).

Maybe, and that is my preferred soluti= on. =C2=A0I'm with you there.
=C2=A0
* An RS prefix detects only slightly more cases of accidentally truncated w= rites (in the middle of a top-level number, in a top-level string in the mi= ddle of an escape sequence) -- not enough to be compelling.

There are other cases if we have as a goal to recover s= tarting at the very next full text following the truncated one. =C2=A0Prece= ding and following=C2=A0texts with LF also helps recovery in the cases you = mention.=C2=A0 But it's not=C2=A0enough. =C2=A0The current I-D covers s= ome alternatives that do remove all ambiguities at little cost to either th= e parser or the encoder,=C2=A0including: removing internal newlines from te= xts (cheap operation; no need to parse and re-encode) and/or preceding text= s with "null" LF.
=C2=A0
* The awkwardness of RS will mean many implementations will be lenient, but= leniency becomes "expected" which leads to interop problems.

Parsers shouldn't require it. =C2=A0Encode= rs should emit it if there's a chance of truncated writes. =C2=A0How ca= n interop problems arise from this formula? =C2=A0What am I missing?
=C2=A0
"A JSON sequence is the concatenation of zero or more JSON values, whe= re each JSON value is terminated with a newline."

Simple to understand. Simple to write. Simple enough to parse. Simple enoug= h to resync from the middle of a sequence. Almost identical recovery from a= ccidental corruption is possible in almost all the same instances regardles= s of whether an RS prefix or newline suffix is used.

Yes, and I very much like that,=C2=A0right= up until one wants to cater to logfiles and the truncated write problem. = =C2=A0See alternatives above. =C2=A0We must choose one. =C2=A0Two camps are= squared off and I'm in the middle. =C2=A0One will win or all may lose.=

My preference is to say that logfile writers must remov= e internal newlines from the texts they write. =C2=A0That is by far the sim= plest fix for write truncation. =C2=A0 Not all sequences will be logfile-li= ke. =C2=A0No RS if we go with that. =C2=A0I haven't seen any strong arg= uments against that, in fact=C2=A0 You have stronger=C2=A0arguments against= RS than I have seen against internal=C2=A0newline removal by logfile write= rs. =C2=A0Let's sleep on it and revisit tomorrow,

Nico
--=C2=A0=C2=A0
--f46d0444ebfdbec69204fb12f5aa-- From nobody Thu Jun 5 09:03: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 D3FCF1A0170 for ; Thu, 5 Jun 2014 09:03:25 -0700 (PDT) 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 00NYhQ3ksxzA for ; Thu, 5 Jun 2014 09:03:23 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1EA61A02A5 for ; Thu, 5 Jun 2014 09:03:01 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id rp18so1011055iec.26 for ; Thu, 05 Jun 2014 09:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=mMelAi/8k4AwH/UNXHOS+2szWGb5RwB5QjdPNxi7r6s=; b=Km/t7yMSAX2JqgvRGD1MYNkWjOlP1ea2MW1e5JMEfiNpwJiah2BZfA/2CEJGHx5jjP BNnA7tedjvsuncfLKP4dJe+3tLtL3BAH9XCQ0ucU/Hhhd6y5j/LKutZ5Vbk2UacRBm53 xyfhrXL+rmnFw5X5Sq9hlAGfg63HYGvBQJYSDdThoaf1jH26cfXxuW/UQ13cxyILyohV uUQvO5Q1pg4eVulqN7cgNpGvXDlgzTl8BIb4WcCRCj4HZHNCi3JFvt2zGntQkgH3gORd XOgnZFEbYTV13SGbnNaAxRuCs3BDoF1k2p8mX3LiDWn1BMwFtg2H9p15Cu12p5K/tzv6 wtxg== X-Received: by 10.50.143.9 with SMTP id sa9mr21770156igb.2.1401984175036; Thu, 05 Jun 2014 09:02:55 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.50.89.133 with HTTP; Thu, 5 Jun 2014 09:02:34 -0700 (PDT) In-Reply-To: References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> From: Jacob Davies Date: Thu, 5 Jun 2014 09:02:34 -0700 X-Google-Sender-Auth: C7zJvdjrnPjoyMU7c6PcADsM1jA Message-ID: To: Nico Williams Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/aBJ0qDdbN6zPjv4nepvdcDv6zCA Cc: Phillip Hallam-Baker , Paul Hoffman , IETF JSON WG , Tim Bray , Joe Hildebrand Hildebrand , "Manger, James" Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 16:03:26 -0000 I suggested FF if RS was not acceptable. I made the RS suggestion because it has the correct semantics for this role. (If you prefer INFORMATION_SEPARATOR_ONE on the basis of this being UTF-8 - fine.) It also seemed less likely to be accidentally emitted/transmitted than FF. (I was also curious how many people would oppose it just for being d=C3=A9class=C3=A9; ASCII ain't that big even before you write off swathes = of it.) Could be worse, it could have been BEL. FF is also barred from JSON texts, including in non-significant whitespace: "whitespace characters are: character tabulation (U+0009), line feed (U+000A), carriage return (U+000D), and space (U+0020)". Pagers like "more" do pause on FF, but that behavior may be desirable when you're dumping large, pretty-printed structures. The accidental inclusion of the separator when cut & pasting is a reasonable concern. It applies to FF as well as other control characters though. As a sample, I looked at the Java code for the json.org parser, Gson, and a parser I wrote: json.org accepts anything before U+0020 as "whitespace"; Gson accepts only the four whitespace characters specified (i.e. from what I could tell would reject FF as well); I used Character.isWhitespace(char) which accepts RS and FF as whitespace. So behavior here seems hard to rely on. Ideally one would choose a printing resync character. But JSON reserves all printing characters for use in strings. It also reserves all non-ASCII Unicode characters. The *only* characters that work for separating arbitrary JSON texts are ASCII control characters (and excluding those mentioned above in the non-significant whitespace section). All of them potentially suffer from cut & paste issues because they are all of course illegal in JSON texts. FF is the only "traditional" whitespace character in that set (i.e. typically matched by \s in regular expressions) but as seen above, that does not mean that it will be accepted by maximally-strict JSON parsers. LF has many advantages beginning with compatibility with existing line-oriented tools, at the cost of losing the possibility of pretty-printing and requiring the removal of insignificant newlines from input JSON texts (which as Nico says can be done mechanically, without parsing them, so the difficulty is low). Pretty-printing could be recovered pretty trivially in a filter or in tools. Also Nico is the one with experience & code here and he says it works well. However, if you use LF to separate, it should be required of emitters, and other insignificant whitespace between or inside values should be barred for emitters, to maximize the usefulness of existing line-oriented tools. There should not be multiple versions of this format with different options. I am guessing this will overwhelmingly be a log format, and dealing with the possibility of truncation and bad records is always important for logfiles. On Thu, Jun 5, 2014 at 1:59 AM, Nico Williams wrote= : > On Thursday, June 5, 2014, Manger, James > wrote: >> >> >> JSON-sequence =3D *( ws %1e JSON-text ) >> >> RS as a JSON sequence prefix or separator was a bad idea when discussed = a >> month ago and still is. > > > I'm happy to go with the current I-D's LF-based recovery mechanism or > variant of it. If that's not acceptable then something like RS has to be > it. > > A third alternative is to abandon logfiles as a use or accept truncated > writes leading to fatal parse errors from the corrupted point forwards. = A > fourth alternative is to not publish on the Standards track, maybe publis= h > as Informational or Experimental whatever fewer of us think is best. Bef= ore > we get to any of those alternatives I'd like to try to get consensus. > > Remember, it's rough consensus and running code. I have running code and > I'm open to changing it, but if some views are mutually exclusive and > therefore some have to be on the rough side of consensus, then so be it. > > >> >> * You cannot (easily) enter an RS in notepad. > > > A reason to make it optional, as I proposed -- only logfile writers shoul= d > have to emit it. > >> >> * You cannot (easily) enter an RS in vi. > > > Meh. !printf '\x1E'. Also, same answer as above. > >> >> * You cannot see an RS. > > > But that's harmless. Especially if you know to expect to find it there. > >> >> * An RS causes Chrome to treat a file as binary data, instead of text. > > > That could get fixed (e.g., if Chrome learns about this new MIME type). > >> >> * Cut-n-paste a JSON value with an invisible RS prefix and the result is >> NOT JSON, ie it will fail with a JSON parser as RS is not allowed in JSO= N. > > > But you can be careful to not cut the RS. Or we could make it RS SP, to > make it easier to find where to cut. > >> >> * No one uses RS. > > > That's not much of an argument :) > >> >> * RS is now labelled INFORMATION SEPARATOR TWO, not RECORD SEPARATOR. > > > Ditto. And noted. > > >> >> * We aren't using INFORMATION SEPARATOR ONE, THREE or FOUR. > > > Again. > >> >> * A newline as a JSON value terminator is sufficient to parse a JSON >> sequence unambiguously. > > > Except in the presence of incompletely-written entries. > >> >> * RS doesn't work well with APIs that read text by the line. > > > Do you have any examples of such APIs? Define "well". > > >> >> * Detecting a newline that separates JSON values is more complex than >> detecting an RS character, but it is not that complex (eg handful of lin= es >> of code). > > > Maybe, and that is my preferred solution. I'm with you there. > >> >> * An RS prefix detects only slightly more cases of accidentally truncate= d >> writes (in the middle of a top-level number, in a top-level string in th= e >> middle of an escape sequence) -- not enough to be compelling. > > > There are other cases if we have as a goal to recover starting at the ver= y > next full text following the truncated one. Preceding and following text= s > with LF also helps recovery in the cases you mention. But it's not enoug= h. > The current I-D covers some alternatives that do remove all ambiguities a= t > little cost to either the parser or the encoder, including: removing > internal newlines from texts (cheap operation; no need to parse and > re-encode) and/or preceding texts with "null" LF. > >> >> * The awkwardness of RS will mean many implementations will be lenient, >> but leniency becomes "expected" which leads to interop problems. > > > Parsers shouldn't require it. Encoders should emit it if there's a chanc= e > of truncated writes. How can interop problems arise from this formula? > What am I missing? > >> >> "A JSON sequence is the concatenation of zero or more JSON values, where >> each JSON value is terminated with a newline." >> >> Simple to understand. Simple to write. Simple enough to parse. Simple >> enough to resync from the middle of a sequence. Almost identical recover= y >> from accidental corruption is possible in almost all the same instances >> regardless of whether an RS prefix or newline suffix is used. > > > Yes, and I very much like that, right up until one wants to cater to > logfiles and the truncated write problem. See alternatives above. We mu= st > choose one. Two camps are squared off and I'm in the middle. One will w= in > or all may lose. > > My preference is to say that logfile writers must remove internal newline= s > from the texts they write. That is by far the simplest fix for write > truncation. Not all sequences will be logfile-like. No RS if we go wit= h > that. I haven't seen any strong arguments against that, in fact You hav= e > stronger arguments against RS than I have seen against internal newline > removal by logfile writers. Let's sleep on it and revisit tomorrow, > > Nico > -- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Thu Jun 5 10:01: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 44D361A017F for ; Thu, 5 Jun 2014 10:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUlSshksXeFT for ; Thu, 5 Jun 2014 10:01:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F0C1A0171 for ; Thu, 5 Jun 2014 10:01:16 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s55H17Mw002944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jun 2014 10:01:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 5 Jun 2014 10:01:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <93018E84-581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/json/ASx4GnVq5mKmtRsJg7NwrRGpZFg Cc: IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 17:01:18 -0000 As a summary from below: you prefer a more normal character like NL plus = the need to escape it in strings, versus an obscure character like RS = that requires no escaping. Is that correct? On Jun 4, 2014, at 11:25 PM, Manger, James = wrote: >>> JSON-sequence =3D *( ws %1e JSON-text ) >=20 > RS as a JSON sequence prefix or separator was a bad idea when = discussed a month ago and still is. >=20 > * You cannot (easily) enter an RS in notepad. > * You cannot (easily) enter an RS in vi. > * You cannot see an RS. It seems like the purpose of draft-ietf-json-text-sequence is to create = a format that can be used for log files and other such files that are = constantly added to. If so, then the above complaints are not really = relevant, right? > * An RS causes Chrome to treat a file as binary data, instead of text. Ditto. > * Cut-n-paste a JSON value with an invisible RS prefix and the result = is NOT JSON, ie it will fail with a JSON parser as RS is not allowed in = JSON. That will be true of anything other than a character that doesn't need = to be escaped, right? People asked for RS (or something like it) so that = they didn't have to deal with escaping when the value chosen was also in = a string.=20 > * No one uses RS. > * RS is now labelled INFORMATION SEPARATOR TWO, not RECORD SEPARATOR. > * We aren't using INFORMATION SEPARATOR ONE, THREE or FOUR. All irrelevant. We are creating a new specification. > * A newline as a JSON value terminator is sufficient to parse a JSON = sequence unambiguously. Sure. And it also causes the need to have escaping. > * RS doesn't work well with APIs that read text by the line. Are there JSON APIs that do that? > * Detecting a newline that separates JSON values is more complex than = detecting an RS character, but it is not that complex (eg handful of = lines of code). The people who asked for RS seemed more concerned about escaping = newlines in the JSON being written, not detecting it on the incoming. Do = you agree that that is also a concern? > * An RS prefix detects only slightly more cases of accidentally = truncated writes (in the middle of a top-level number, in a top-level = string in the middle of an escape sequence) -- not enough to be = compelling. That was not the major motivation, however. > * The awkwardness of RS will mean many implementations will be = lenient, but leniency becomes "expected" which leads to interop = problems. That is a prediction of the future. > "A JSON sequence is the concatenation of zero or more JSON values, = where each JSON value is terminated with a newline." >=20 > Simple to understand. Simple to write. Simple enough to parse. Simple = enough to resync from the middle of a sequence. Almost identical = recovery from accidental corruption is possible in almost all the same = instances regardless of whether an RS prefix or newline suffix is used. Sure, but it ignores the issue many people had about escaping. --Paul Hoffman= From nobody Thu Jun 5 10:07: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 05D2F1A017F for ; Thu, 5 Jun 2014 10:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 xl8qKjKpjx2S for ; Thu, 5 Jun 2014 10:07:02 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AAF271A01A0 for ; Thu, 5 Jun 2014 10:07:02 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 715082007F10D for ; Thu, 5 Jun 2014 10:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=AzZ2wb4ZSEAjNdNvepg+ DVb8wvU=; b=TZYhINbYcewTF6Z8ZbR9x8y1XXiAZqFSGmAp9gyQHD1yn+0BGyC1 kzm3Vq51c0AeWckfWTCSU8pmuhwpiCpT5emnbiW0yHRRieKrotZrix4XHgJlMYDN 5ju0sTAyz4i0vcQ44ZAjcDCf3y7GBtZw+zC2nxMngVNvhRy+2UW5c7Y= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 20DB52007F10B for ; Thu, 5 Jun 2014 10:06:55 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so10824676wib.17 for ; Thu, 05 Jun 2014 10:06:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.120.68 with SMTP id la4mr83195129wjb.40.1401988014674; Thu, 05 Jun 2014 10:06:54 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 5 Jun 2014 10:06:54 -0700 (PDT) In-Reply-To: <93018E84-581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> <93018E84-581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> Date: Thu, 5 Jun 2014 12:06:54 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/x9-H5EJ68cRkuVy96j_2OAbhJfU Cc: "Manger, James" , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 17:07:04 -0000 On Thu, Jun 5, 2014 at 12:01 PM, Paul Hoffman wrote: > > > As a summary from below: you prefer a more normal character like NL plus the need to escape it in strings, versus an obscure character like RS that requires no escaping. Is that correct? Just so we're clear, LF already has to get escaped inJSON strings. Thus using LF in sequences imposes no new constraints on JSON encoders. Nico -- From nobody Thu Jun 5 10:24: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 98F2B1A01F6 for ; Thu, 5 Jun 2014 10:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvmOGTQStOaT for ; Thu, 5 Jun 2014 10:24:27 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB6C1A01A0 for ; Thu, 5 Jun 2014 10:24:26 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s55HOFj3004059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jun 2014 10:24:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: Date: Thu, 5 Jun 2014 10:24:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> <93018E84-! 581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/json/aGqioM9ddxc9rLWleeyCJ7_WfUY Cc: "Manger, James" , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 17:24:27 -0000 On Jun 5, 2014, at 10:06 AM, Nico Williams = wrote: > On Thu, Jun 5, 2014 at 12:01 PM, Paul Hoffman = wrote: >> >>=20 >> As a summary from below: you prefer a more normal character like NL = plus the need to escape it in strings, versus an obscure character like = RS that requires no escaping. Is that correct? >=20 > Just so we're clear, LF already has to get escaped inJSON strings. > Thus using LF in sequences imposes no new constraints on JSON > encoders. Maybe I'm misunderstanding the earlier messages and the current draft. = The draft says: To make resynchronization reliable, and work both forwards and backwards, the writer MUST first ensure that the JSON text being written is valid, and SHOULD apply either (or both) of the following: 1. Remove internal newlines (not including escaped newlines in strings) from any JSON text being written. 2. Prefix any JSON text with a null value and a newline. The append write must still be atomic (one write), and contain both texts. With the change to something like RS, neither of those would be = required, right? --Paul Hoffman= From nobody Thu Jun 5 11:10: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 C62F81A01A0 for ; Thu, 5 Jun 2014 11:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-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 evajC80SWhjo for ; Thu, 5 Jun 2014 11:10:48 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BE51A017F for ; Thu, 5 Jun 2014 11:10:48 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id db11so1660308veb.22 for ; Thu, 05 Jun 2014 11:10:41 -0700 (PDT) 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=YOvsW+TDSxDdR+j8fSy/+U2AB1ycJSYoFoh3GlBwObE=; b=b6CKzg97ccua1bw/8IJgrG8Hg277yCqwYy0vih8K1AKB6afgyVFSAUjLkkWkrX1KNc n/fqb7StezG3rPUUoQxBGWFnyUBN6LbyaftfdCIL2PcS/sm/9jJ+NIDdu4BLkz8kqJ1p 5AVaaK5wdkIFkaqAgCaVqcCf1a12cDwhTaxCC2njkW2uOJb8/dE2EKAFW35+rqu78Len 6qgwZ4cbREObcXMBNVKpH9ppsQHfBr9tX+48mezC4oORm8IJ2nbfXJjjltgsNiJ0pwLv HbuuqhWqSrZYKnsPCWVO3iRHrLTLJQzbwlJ0QAj7N1QTd/Tr1YM58vOEij6kYddvRlQ/ P3ow== X-Gm-Message-State: ALoCoQlRvBJvU4GwxrEHs4pJ/z1XpWIMnGA6YgzevD0Jt0xfMibmEQ6aLLf0Us40j/EpnHB53zrp X-Received: by 10.58.126.4 with SMTP id mu4mr54295407veb.0.1401991840964; Thu, 05 Jun 2014 11:10:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Thu, 5 Jun 2014 11:10:20 -0700 (PDT) X-Originating-IP: [24.85.103.37] In-Reply-To: <93018E84-581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> <93018E84-581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> From: Tim Bray Date: Thu, 5 Jun 2014 11:10:20 -0700 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b6700afa8be1d04fb1aa97f Archived-At: http://mailarchive.ietf.org/arch/msg/json/HX_Dy0bidKplO794KIgPEdFrzA4 Cc: "Manger, James" , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 18:10:51 -0000 --047d7b6700afa8be1d04fb1aa97f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with every point Paul made. I=E2=80=99m completely convinced that = we need an unambiguous can=E2=80=99t-appear-in-JSON separator/prefix. Anything s= maller than 1F other than the characters included in JSON would be fine by me. How about U+0000? On Thu, Jun 5, 2014 at 10:01 AM, Paul Hoffman wrote= : > > > As a summary from below: you prefer a more normal character like NL plus > the need to escape it in strings, versus an obscure character like RS tha= t > requires no escaping. Is that correct? > > On Jun 4, 2014, at 11:25 PM, Manger, James < > James.H.Manger@team.telstra.com> wrote: > > >>> JSON-sequence =3D *( ws %1e JSON-text ) > > > > RS as a JSON sequence prefix or separator was a bad idea when discussed > a month ago and still is. > > > > * You cannot (easily) enter an RS in notepad. > > * You cannot (easily) enter an RS in vi. > > * You cannot see an RS. > > It seems like the purpose of draft-ietf-json-text-sequence is to create a > format that can be used for log files and other such files that are > constantly added to. If so, then the above complaints are not really > relevant, right? > > > * An RS causes Chrome to treat a file as binary data, instead of text. > > Ditto. > > > * Cut-n-paste a JSON value with an invisible RS prefix and the result i= s > NOT JSON, ie it will fail with a JSON parser as RS is not allowed in JSON= . > > That will be true of anything other than a character that doesn't need to > be escaped, right? People asked for RS (or something like it) so that the= y > didn't have to deal with escaping when the value chosen was also in a > string. > > > * No one uses RS. > > * RS is now labelled INFORMATION SEPARATOR TWO, not RECORD SEPARATOR. > > * We aren't using INFORMATION SEPARATOR ONE, THREE or FOUR. > > All irrelevant. We are creating a new specification. > > > * A newline as a JSON value terminator is sufficient to parse a JSON > sequence unambiguously. > > Sure. And it also causes the need to have escaping. > > > * RS doesn't work well with APIs that read text by the line. > > Are there JSON APIs that do that? > > > * Detecting a newline that separates JSON values is more complex than > detecting an RS character, but it is not that complex (eg handful of line= s > of code). > > The people who asked for RS seemed more concerned about escaping newlines > in the JSON being written, not detecting it on the incoming. Do you agree > that that is also a concern? > > > * An RS prefix detects only slightly more cases of accidentally > truncated writes (in the middle of a top-level number, in a top-level > string in the middle of an escape sequence) -- not enough to be compellin= g. > > That was not the major motivation, however. > > > * The awkwardness of RS will mean many implementations will be lenient, > but leniency becomes "expected" which leads to interop problems. > > That is a prediction of the future. > > > "A JSON sequence is the concatenation of zero or more JSON values, wher= e > each JSON value is terminated with a newline." > > > > Simple to understand. Simple to write. Simple enough to parse. Simple > enough to resync from the middle of a sequence. Almost identical recovery > from accidental corruption is possible in almost all the same instances > regardless of whether an RS prefix or newline suffix is used. > > Sure, but it ignores the issue many people had about escaping. > > --Paul Hoffman > _______________________________________________ > 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) --047d7b6700afa8be1d04fb1aa97f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I a= gree with every point Paul made. =C2=A0I=E2=80=99m completely convinced tha= t we need an unambiguous can=E2=80=99t-appear-in-JSON separator/prefix. =C2= =A0 =C2=A0Anything smaller than 1F other than the characters included in JS= ON would be fine by me. =C2=A0How about U+0000?


On Thu,= Jun 5, 2014 at 10:01 AM, Paul Hoffman <paul.hoffman@vpnc.org><= /span> wrote:
<no hat>

As a summary from below: you prefer a more normal character like NL plus th= e need to escape it in strings, versus an obscure character like RS that re= quires no escaping. Is that correct?

On Jun 4, 2014, at 11:25 PM, Manger, James <James.H.Manger@team.telstra.com> wrote:

>>> JSON-sequence =3D *( ws %1e JSON-text )
>
> RS as a JSON sequence prefix or separator was a bad idea when discusse= d a month ago and still is.
>
> * You cannot (easily) enter an RS in notepad.
> * You cannot (easily) enter an RS in vi.
> * You cannot see an RS.

It seems like the purpose of draft-ietf-json-text-sequence is to crea= te a format that can be used for log files and other such files that are co= nstantly added to. If so, then the above complaints are not really relevant= , right?

> * An RS causes Chrome to treat a file as binary data, instead of text.=

Ditto.

> * Cut-n-paste a JSON value with an invisible RS prefix and the result = is NOT JSON, ie it will fail with a JSON parser as RS is not allowed in JSO= N.

That will be true of anything other than a character that doesn't= need to be escaped, right? People asked for RS (or something like it) so t= hat they didn't have to deal with escaping when the value chosen was al= so in a string.

> * No one uses RS.
> * RS is now labelled INFORMATION SEPARATOR TWO, not RECORD SEPARATOR.<= br> > * We aren't using INFORMATION SEPARATOR ONE, THREE or FOUR.

All irrelevant. We are creating a new specification.

> * A newline as a JSON value terminator is sufficient to parse a JSON s= equence unambiguously.

Sure. And it also causes the need to have escaping.

> * RS doesn't work well with APIs that read text by the line.

Are there JSON APIs that do that?

> * Detecting a newline that separates JSON values is more complex than = detecting an RS character, but it is not that complex (eg handful of lines = of code).

The people who asked for RS seemed more concerned about escaping newl= ines in the JSON being written, not detecting it on the incoming. Do you ag= ree that that is also a concern?

> * An RS prefix detects only slightly more cases of accidentally trunca= ted writes (in the middle of a top-level number, in a top-level string in t= he middle of an escape sequence) -- not enough to be compelling.

That was not the major motivation, however.

> * The awkwardness of RS will mean many implementations will be lenient= , but leniency becomes "expected" which leads to interop problems= .

That is a prediction of the future.

> "A JSON sequence is the concatenation of zero or more JSON values= , where each JSON value is terminated with a newline."
>
> Simple to understand. Simple to write. Simple enough to parse. Simple = enough to resync from the middle of a sequence. Almost identical recovery f= rom accidental corruption is possible in almost all the same instances rega= rdless of whether an RS prefix or newline suffix is used.

Sure, but it ignores the issue many people had about escaping.

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



--
=
- Tim Bray (If you=E2=80=99d like to send me a privat= e message, see htt= ps://keybase.io/timbray)
--047d7b6700afa8be1d04fb1aa97f-- From nobody Thu Jun 5 11:46:36 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 A633A1A02B8; Thu, 5 Jun 2014 11:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YCSnElrlCFDH; Thu, 5 Jun 2014 11:28:19 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBF81A0259; Thu, 5 Jun 2014 11:28:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C8FAD1E4366; Thu, 5 Jun 2014 11:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVpa6jZ2y46z; Thu, 5 Jun 2014 11:26:39 -0700 (PDT) Received: from [192.168.2.100] (pool-96-255-144-77.washdc.fios.verizon.net [96.255.144.77]) by c8a.amsl.com (Postfix) with ESMTPSA id 2C9581E40EF; Thu, 5 Jun 2014 11:26:39 -0700 (PDT) From: IAB Chair Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jun 2014 14:28:11 -0400 Message-Id: To: IETF Announce Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/json/Ky6AZQJ5nreTHP5vNX67BxGmt0E X-Mailman-Approved-At: Thu, 05 Jun 2014 11:46:28 -0700 Cc: Internet Architecture Board , ietf-http-wg@w3.org, Apps Discuss , json@ietf.org Subject: [Json] Call for Volunteers for Liaison Manager to ECMA TC39 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, 05 Jun 2014 18:28:21 -0000 The IAB and ECMA International's TC39 have agreed to establish a liaison = relationship between the two organizations. The IAB is seeking a = volunteer to serve as IETF liaison manager to ECMA TC39 to represent = IETF views, as required. The IETF process for managing such = relationships is detailed in RFCs 4052, 4053, and 4691. It is preferred = to have a liaison manager that participates in with both the IETF and = TC39 activities, and is familiar with the processes of the = organizations. As it is expected that the first activity will be = related to JSON, therefore some understanding of JSON is desirable. If you are interested, please reply to this message by 7 July 2014, with = a brief note that explains your interest, your background, availability = to attend meetings, and whether you have any potential conflicts of = interest. The IAB would like to make a decision during the week of the = Toronto IETF meeting. Please note, the IAB may seek the views of the community on candidates, = and we may wish to interview candidates during the Toronto meeting. On behalf of the IAB, Russ Housley IAB Chair From nobody Thu Jun 5 11:48:34 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 8CEAA1A026F for ; Thu, 5 Jun 2014 11:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 9EX1h2RI3Gf3 for ; Thu, 5 Jun 2014 11:48:31 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CEA111A01DF for ; Thu, 5 Jun 2014 11:48:31 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 68FCD21DE65 for ; Thu, 5 Jun 2014 11:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=cF0Roj/YH6Kg35Yv7MoxJIZj2TM=; b=OApOygggSWg nzqsemT7R4RBAvdoQy1qmm5bn9pIKtKavhSe3HEBDMw+CJOKoYIORIe7TIw0XRyL Wi9sZVe3O8pU1qegP5qmu+aQt+pBZZDVj2NydSKzbT34anE2hA+MKyCQ3ZBBfxi6 Z6ZrSJ5u5prx+I8ES7DrafY3gu3c5fKc= Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 10C0B21DE59 for ; Thu, 5 Jun 2014 11:48:24 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so1604355wes.4 for ; Thu, 05 Jun 2014 11:48:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.142.205 with SMTP id ry13mr18818051wjb.69.1401994103736; Thu, 05 Jun 2014 11:48:23 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 5 Jun 2014 11:48:23 -0700 (PDT) In-Reply-To: References: <03CFAB3E-F4C6-4AE8-A501-8525376C4AA7@vpnc.org> <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> <93018E84-581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> Date: Thu, 5 Jun 2014 13:48:23 -0500 Message-ID: From: Nico Williams To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/URmJzIhTQsQ6gMV5F2XAancjUQI Cc: "Manger, James" , Paul Hoffman , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 18:48:32 -0000 On Thu, Jun 5, 2014 at 1:10 PM, Tim Bray wrote: > I agree with every point Paul made. I=E2=80=99m completely convinced tha= t we need > an unambiguous can=E2=80=99t-appear-in-JSON separator/prefix. Anything= smaller > than 1F other than the characters included in JSON would be fine by me. = How > about U+0000? I don't understand Paul's point about escaping. Can either of you elaborat= e? As for NUL, that has all the problems that RS has, and worse. I'd rather use RS. FF even. Nico -- From nobody Thu Jun 5 16:35: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 703491A032D for ; Thu, 5 Jun 2014 16:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 laXXcmik7LSv for ; Thu, 5 Jun 2014 16:35:56 -0700 (PDT) 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 B53E21A027B for ; Thu, 5 Jun 2014 16:35:56 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WshCE-0003mj-Sc; Thu, 05 Jun 2014 19:35:46 -0400 Date: Thu, 5 Jun 2014 19:35:46 -0400 From: John Cowan To: Tim Bray Message-ID: <20140605233546.GF15558@mercury.ccil.org> References: <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> <93018E84-581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/Y1d3QjT63UUIbK1E40LP-QTb1W4 Cc: "Manger, James" , Paul Hoffman , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 23:35:58 -0000 Tim Bray scripsit: > How about U+0000? Are you serious? /me starts jumping up and down yelling KILL, KILL. There is no reason why a JSON value should ever contain an explicit LF. Explicit LFs are used solely for decoration. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Andrew Watt on Microsoft: Never in the field of human computing has so much been paid by so many to so few! (pace Winston Churchill) From nobody Thu Jun 5 16:37: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 C85011A032D for ; Thu, 5 Jun 2014 16:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 MEkYzxFemXfX for ; Thu, 5 Jun 2014 16:37:06 -0700 (PDT) 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 4AA1C1A027B for ; Thu, 5 Jun 2014 16:37:06 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WsgtD-0001qq-9S; Thu, 05 Jun 2014 19:16:07 -0400 Date: Thu, 5 Jun 2014 19:16:07 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20140605231607.GE15558@mercury.ccil.org> References: <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> <93018E84-581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93018E84-581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/ma23mz99b7kJzXsoeq532Z6SwU0 Cc: "Manger, James" , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 23:37:08 -0000 Paul Hoffman scripsit: > As a summary from below: you prefer a more normal character like NL > plus the need to escape it in strings, versus an obscure character > like RS that requires no escaping. Is that correct? Both require escaping in strings. The difference is that LF can appear as insignificant whitespace, whereas RS cannot. So to achieve the same thing as RS achieves (restartable/correctable writes), it's simply necessary never to spit out an insignificant LF. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org And now here I was, in a country where a right to say how the country should be governed was restricted to six persons in each thousand of its population. For the nine hundred and ninety-four to express dissatisfaction with the regnant system and propose to change it, would have made the whole six shudder as one man, it would have been so disloyal, so dishonorable, such putrid black treason. --Mark Twain's Connecticut Yankee From nobody Thu Jun 5 16:39: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 BD5781A032D for ; Thu, 5 Jun 2014 16:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 eEmxRKpyf3WE for ; Thu, 5 Jun 2014 16:39:53 -0700 (PDT) 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 B492D1A027B for ; Thu, 5 Jun 2014 16:39:53 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WshG5-0004C3-C9; Thu, 05 Jun 2014 19:39:45 -0400 Date: Thu, 5 Jun 2014 19:39:45 -0400 From: John Cowan To: Paul Hoffman Message-ID: <20140605233945.GH15558@mercury.ccil.org> References: <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> <93018E84-!581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/eV9bbfMxniIOlgy2g26aLZAtt8k Cc: Nico Williams , "Manger, James" , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 23:39:55 -0000 Paul Hoffman scripsit: > 1. Remove internal newlines (not including escaped newlines in > strings) from any JSON text being written. It would be clearer to say "internal non-significant newlines". > 2. Prefix any JSON text with a null value and a newline. The append > write must still be atomic (one write), and contain both texts. > > With the change to something like RS, neither of those would be > required, right? Correct, but with other problems around data entry and display. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Linguistics is arguably the most hotly contested property in the academic realm. It is soaked with the blood of poets, theologians, philosophers, philologists, psychologists, biologists and neurologists, along with whatever blood can be got out of grammarians. - Russ Rymer From nobody Thu Jun 5 16:40: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 71A461A035B for ; Thu, 5 Jun 2014 16:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 oXCjzrJjIL55 for ; Thu, 5 Jun 2014 16:40:23 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D19CF1A0358 for ; Thu, 5 Jun 2014 16:40:23 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 8290554058 for ; Thu, 5 Jun 2014 16:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=tx4p+CK/4mAD6DHNPKG4 B8o4O6s=; b=oCBk9ygXyHsUbNGl5JkwD/R15artf7qiLcSojtQnKEBhUhi76zht RmcuYP2nnIXTSexwZQxXD+FHv53lUfGa/98QL0LklAexRyJlP/IM12ciisMNaqgq L/E9p3NHomnCD6XWaaFhNzjcZOyBv6Y3wR8I5ShmnDAYK61zkwCxYyU= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 32A4854057 for ; Thu, 5 Jun 2014 16:40:17 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id bs8so29066wib.0 for ; Thu, 05 Jun 2014 16:40:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.12.135 with SMTP id y7mr2485022wib.39.1402011614953; Thu, 05 Jun 2014 16:40:14 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 5 Jun 2014 16:40:14 -0700 (PDT) In-Reply-To: <20140605231607.GE15558@mercury.ccil.org> References: <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> <93018E84-581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> <20140605231607.GE15558@mercury.ccil.org> Date: Thu, 5 Jun 2014 18:40:14 -0500 Message-ID: From: Nico Williams To: John Cowan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/zHy2_-jEpglg6H7I1AbZ18PN-60 Cc: "Manger, James" , Paul Hoffman , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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: Thu, 05 Jun 2014 23:40:24 -0000 On Thu, Jun 5, 2014 at 6:16 PM, John Cowan wrote: > Paul Hoffman scripsit: >> As a summary from below: you prefer a more normal character like NL >> plus the need to escape it in strings, versus an obscure character >> like RS that requires no escaping. Is that correct? > > Both require escaping in strings. The difference is that LF can appear as > insignificant whitespace, whereas RS cannot. So to achieve the same thing > as RS achieves (restartable/correctable writes), it's simply necessary never > to spit out an insignificant LF. Or to remove any LFs. Since unescaped LFs are insignificant in JSON texts, it's always OK to remove them without parsing and re-encoding. Your argument is convincing to me: there's no real difference between RS and LF this way. Perhaps someone can explain why it would be bad for log writers to remove [unescaped] LFs from JSON texts? I can't tell why it's bad. I only know that some object. Nico -- From nobody Thu Jun 5 18:34: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 8C3A31A0382 for ; Thu, 5 Jun 2014 18:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, 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 sjbHK4R8C2c6 for ; Thu, 5 Jun 2014 18:34:17 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id E3B0F1A0380 for ; Thu, 5 Jun 2014 18:34:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,985,1392123600"; d="scan'208";a="17042384" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 06 Jun 2014 11:21:36 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7460"; a="226969657" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipccvi.tcif.telstra.com.au with ESMTP; 06 Jun 2014 11:34:08 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Fri, 6 Jun 2014 11:34:07 +1000 From: "Manger, James" To: Nico Williams , John Cowan Date: Fri, 6 Jun 2014 11:34:05 +1000 Thread-Topic: [Json] Using a non-whitespace separator (Re: Working Group Last Call on draft-ietf-json-text-sequence) Thread-Index: Ac+BF4XJ7OjEcLu8Sxq+tJv0SK2lhQAB+ttw Message-ID: <255B9BB34FB7D647A506DC292726F6E11546B223C9@WSMSG3153V.srv.dir.telstra.com> References: <084664DB-A55D-465E-8888-97BA0BB59637@vpnc.org> <255B9BB34FB7D647A506DC292726F6E11546B21D22@WSMSG3153V.srv.dir.telstra.com> <93018E84-581D-4B75-8B58-6BFAD27D8EE3@vpnc.org> <20140605231607.GE15558@mercury.ccil.org> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/PuxOdFPufxW5kcCWvjNWH2sNAWQ Cc: Paul Hoffman , IETF JSON WG Subject: Re: [Json] Using a non-whitespace separator (Re: Working Group Last Call on 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, 06 Jun 2014 01:34:18 -0000 PiBCb3RoIHJlcXVpcmUgZXNjYXBpbmcgaW4gc3RyaW5ncy4gIFRoZSBkaWZmZXJlbmNlIGlzIHRo YXQgTEYgY2FuIGFwcGVhciBhcw0KPiBpbnNpZ25pZmljYW50IHdoaXRlc3BhY2UsIHdoZXJlYXMg UlMgY2Fubm90Lg0KDQpDb3JyZWN0Lg0KDQo+ICBTbyB0byBhY2hpZXZlIHRoZSBzYW1lIHRoaW5n DQo+IGFzIFJTIGFjaGlldmVzIChyZXN0YXJ0YWJsZS9jb3JyZWN0YWJsZSB3cml0ZXMpLCBpdCdz IHNpbXBseSBuZWNlc3NhcnkgbmV2ZXINCj4gdG8gc3BpdCBvdXQgYW4gaW5zaWduaWZpY2FudCBM Ri4NCg0KSW5jb3JyZWN0Lg0KSXQgaXMgbm90ICpuZWNlc3NhcnkqIHRvIG9taXQgaW5zaWduaWZp Y2FudCBMRi4NCkl0IGlzIGp1c3QgKmVhc2llciogZm9yIHBhcnNlcnMgaWYgZXZlcnkgTEYgdGVy bWluYXRlcyBhIHNpbmdsZSBKU09OIHZhbHVlIChhbmQgaXMgbmV2ZXIgb3RoZXIgaW5zaWduaWZp Y2FudCB3aGl0ZXNwYWNlKS4NCg0KV2l0aCBMRiBhcyB0aGUgdGVybWluYXRvciBidXQgYWxzbyBh bGxvd2VkIGFzIGluc2lnbmlmaWNhbnQgd2hpdGVzcGFjZSwgPGVuZGNoYXI+IExGIDxzdGFydGNo YXI+IHVuYW1iaWd1b3VzbHkgc2VwYXJhdGVzIEpTT04gdmFsdWVzLg0KVGhpcyBhbGxvd3MgeW91 IHRvIHJlc3RhcnQgZnJvbSBhbnl3aGVyZSBpbiB0aGUgbWlkZGxlIG9mIGEgc2VxdWVuY2UuDQpU aGlzIGFsbG93cyB5b3UgdG8gcmVzdGFydCBhZnRlciBvbmUgdmFsdWUgaXMgY29ycnVwdGVkIG9y IHRydW5jYXRlZC4NCklmIHlvdSBoYXZlIGhhZCBzb21lIGNvcnJ1cHRpb24gKHNvIHdlIGFyZSBh bHJlYWR5IGluIGEgbmljaGUgY2FzZSkgYW5kIHlvdSByZWFsbHkgZG9uJ3Qgd2FudCB0byBtaXNz IHRoZSB2ZXJ5IG5leHQgdmFsdWUsIHlvdSBhcmUgc3RpbGwgb2sgd2hlbiB2YWx1ZXMgYXJlIG9i amVjdHMgb3IgYXJyYXlzIChhcyBsb2cgZW50cmllcyB3aWxsIGludmFyaWFibHkgYmUpLiBUaGUg ZW5kIG9mIHRoZSBuZXh0IChub24tY29ycnVwdGVkKSB2YWx1ZSBpcyBmb3VuZCBhcyBub3JtYWwg KDxlbmRjaGFyPiBMRiA8c3RhcnRjaGFyPiksIHRoZW4gbG9vayBiYWNrIGZvciB0aGUgbWF0Y2hp bmcgeyBvciBbIHRoYXQgc3RhcnRlZCBpdC4NCg0KSW4gbXkganVkZ2VtZW50IGl0IGlzIHdvcnRo IGFjY2VwdGluZyBhIGxpdHRsZSBleHRyYSBjb21wbGV4aXR5IGZvciBKU09OIHNlcXVlbmNlIHBh cnNlcnMgKGVnIGhhdmluZyB0byBsb29rIGZvciA8ZW5kY2hhcj4gTEYgPHN0YXJ0Y2hhcj4pIHRv IG1ha2UgaXQgbXVjaCBlYXNpZXIgZm9yIEpTT04gc2VxdWVuY2UgcHJvZHVjZXJzIChubyBhd2t3 YXJkIGNvbnRyb2wgY2hhcmFjdGVycywgY2FuIGJlIHByZXR0eS1wcmludGVkLCBjYW4gYmUgY3V0 LW4tcGFzdGUsIGNhbiBiZSBtYW51YWxseSBlZGl0ZWQsIGNhbiBjYXQgbXVsdGlwbGUgZmlsZXMg dG9nZXRoZXIsIGNhbiB3cmFwIGxvbmcgbGluZXMuLi4pLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From nobody Fri Jun 13 12:58: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 A19831B27CB; Fri, 13 Jun 2014 12:58:06 -0700 (PDT) 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 tZpmW_1X8VIo; Fri, 13 Jun 2014 12:58:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3B21A023A; Fri, 13 Jun 2014 12:58:05 -0700 (PDT) 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.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 12:58:05 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/P4OlmXerJrit5pExkh70h99cZMY Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-i-json-01.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, 13 Jun 2014 19:58:07 -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-01.txt Pages : 6 Date : 2014-06-13 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-i-json-01 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 Jun 13 13:01:55 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 8B0FB1B27CB for ; Fri, 13 Jun 2014 13:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-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 MXfr1TO9wwHg for ; Fri, 13 Jun 2014 13:01:51 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30211A023A for ; Fri, 13 Jun 2014 13:01:51 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id il7so2822792vcb.12 for ; Fri, 13 Jun 2014 13:01:50 -0700 (PDT) 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=uUvwP2yxwelen1YH9kEfJB03WD6poXaATAA/jUOxyRE=; b=Ly/NxhggTybPdDJ/1n3bGikdm62sloiVsESNM3IYT6tO5QCRWzo60kOJg8FtjH5Lhh 894ulG7JepuhHBkw0ehxzQIAiYYm70wgtPMnvTzfjxzvKlp4h+rozzlCeKcl+KwiTAiw 59gDbpDyxFKqmKtlGiNIuKfC25s+08WlzoyWTqpUv2ua8yzBB8+GemxsgeLWs1m3Q9Xy kKw8Emwa6OPpnHFdJdy85P4zJvVF8AcbICsgplD9Z+QCPpzYKtFhP48Vvihuv+64NQFi LfVvXCAwSoQWmqZvcbeu4dR3Q+rfCvX2aIe+pmwdy2xGTVpzad6Q5Svrhvk0lO7PsbAQ YI9g== X-Gm-Message-State: ALoCoQn9N1ULH0KFb6eKawilORAH015NU2l9I71LWr7tzGSc0RDD+di7FbfdmTB+wtjfqZnDwBwL X-Received: by 10.221.64.80 with SMTP id xh16mr2390952vcb.35.1402689710501; Fri, 13 Jun 2014 13:01:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Fri, 13 Jun 2014 13:01:30 -0700 (PDT) X-Originating-IP: [24.85.103.37] In-Reply-To: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> References: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> From: Tim Bray Date: Fri, 13 Jun 2014 13:01:30 -0700 Message-ID: To: "json@ietf.org" Content-Type: multipart/alternative; boundary=001a113351b2eccb5204fbbd2597 Archived-At: http://mailarchive.ietf.org/arch/msg/json/DYsSaGF2Dr5Yq6D1cWsTbDuxGyI Subject: Re: [Json] I-D Action: draft-ietf-json-i-json-01.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, 13 Jun 2014 20:01:53 -0000 --001a113351b2eccb5204fbbd2597 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Real HTML is at http://www.tbray.org/tmp/draft-ietf-json-i-json-01.html On Fri, Jun 13, 2014 at 12:58 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-01.txt > Pages : 6 > Date : 2014-06-13 > > 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-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-json-i-json-01 > > > 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) --001a113351b2eccb5204fbbd2597 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rea= l HTML is at=C2=A0http://www.tbray.org/tmp/draft-ietf-json-i-json-01.html


On Fri, Jun 13, 2014 at 12:58 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 : 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-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =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-06-13

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-01

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


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 send me a private message, s= ee https://keybase= .io/timbray)
--001a113351b2eccb5204fbbd2597-- From nobody Sat Jun 14 04:35: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 857E61B27DB for ; Sat, 14 Jun 2014 04:35:09 -0700 (PDT) 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, 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 ZZYPfpGjlD1O for ; Sat, 14 Jun 2014 04:35:08 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27641A0325 for ; Sat, 14 Jun 2014 04:35:07 -0700 (PDT) Received: from newyork.local.box ([80.187.96.183]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0LqXBp-1WIZfl2Zw9-00e8kT; Sat, 14 Jun 2014 13:35:04 +0200 Message-ID: <539C3367.7090301@drees.name> Date: Sat, 14 Jun 2014 13:35:03 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Tim Bray References: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:tvfV0RAuWtRqHji0z7Eq10wByM++V2qWEuBs+R3GzSszZDxwmt+ IhqggiK4IHvXamMf+I8lcSH4pQStT5UiQM0PnU68WZTE+T7RhqEhxVEYcDTEJvD1ooPdCqW Qy7VPSPdw7mofy9/ahTbM5/dzZkgkz46fvV/2ahSUXdNIjffN2Vp2j04t6B+Sx2GMlwGHU4 WjBbFQpzfdAQ26nD2Nr2w== Archived-At: http://mailarchive.ietf.org/arch/msg/json/hpc1aOACqVJPkyfcNihsAESaSfM Cc: json@ietf.org Subject: [Json] I-JSON(2014-06-13) Section 4.3. Time and Date Handling X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stefan@drees.name List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 11:35:09 -0000 Thanks for providing this, Tim. On 2014-06-13 22:01 +02:00, Tim Bray wrote: > Real HTML is at http://www.tbray.org/tmp/draft-ietf-json-i-json-01.html > > > On Fri, Jun 13, 2014 at 12:58 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 Group of the IETF. > > Title : The I-JSON Message Format > Author : Tim Bray > Filename : draft-ietf-json-i-json-01.txt > Pages : 6 > Date : 2014-06-13 > > 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/ > ... I read over it and section 4.3 "Time and Date Handling" might profit from one or two small changes: OLD: 4.3. Time and Date Handling Protocols often contain data items which are designed to contain timestamps or time durations. It is RECOMMENDED that in all such data items be expressed in in ISO 8601 format, as specified in [RFC3339]. NEW (suggested): 4.3. Time and Date Handling Protocols often contain data items which are designed to contain timestamps or time durations. It is RECOMMENDED that in all such data temporal items be expressed in ISO 8601 format, as specified in [RFC3339]. {"end_of_changes": true} Removing the doubled "in" is a sure thing for me, but if others would also subsume "the targeted items" as "temporal items" I do really not know and thus happily delegate to the native english speakers on this list. The motivating sentence reminds me a bit of the significance of sister phrases like "Life often is ..." but as it is true (in my experience) and if no one else is irritated by quantifiers like "often" I see no need to discuss. All the best, Stefan. From nobody Sat Jun 14 17:06: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 8CDE21B2A47 for ; Sat, 14 Jun 2014 17:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-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 alN_yDQJL_TQ for ; Sat, 14 Jun 2014 17:06:00 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2261B2A41 for ; Sat, 14 Jun 2014 17:06:00 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id db11so4804811veb.32 for ; Sat, 14 Jun 2014 17:05:59 -0700 (PDT) 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=S0ACSxJWpnepG+wlxgza8gDiIySM8aZZ4o3/5O8na3I=; b=Igx/NYXZfyBuY9wDbZ/LP9QtleHeIkCDnh6kjkuMJsz7hO44LfoASDcboKMyZsrBFo 3+Ok8LlKOXl05/NaYxBvQDoTa2Zc3QecQBP8V1Lzj+b7t1pM84hOt6GBLpp4wEIrBR1I 6PJvAfw3zJzEkRONp+MjXDG6JfXA2T0cV4S5v7COvgxiAoIDMccdAwjMvk72W3LeD6ss ArWkTseD2Br7ZqeBocIwQBR7UIbosK3AAtp2wAIuzFdR6HfyCTCl6eE8JvMu4hheefyg 1LFkxJsaHihloD3vy9DXLdsrIB5y3qhgewkCmH1NWpYIuHS2jvaOY0mo9rLs7HHX2c3F ac+A== X-Gm-Message-State: ALoCoQmb6VLfSovpLWKBHKyztIMfpP/P0QbxRir1GMClKE7NAVNHF1tOWAA+qAGr44lV/f4SXZAz X-Received: by 10.58.119.75 with SMTP id ks11mr4863601veb.20.1402790759060; Sat, 14 Jun 2014 17:05:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Sat, 14 Jun 2014 17:05:38 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <539C3367.7090301@drees.name> References: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> <539C3367.7090301@drees.name> From: Tim Bray Date: Sat, 14 Jun 2014 17:05:38 -0700 Message-ID: To: Stefan Drees Content-Type: multipart/alternative; boundary=001a11c21fc0e36b2604fbd4ac11 Archived-At: http://mailarchive.ietf.org/arch/msg/json/ichuVO_k-4lRUzHboLAvt3hJ77I Cc: "json@ietf.org" Subject: Re: [Json] I-JSON(2014-06-13) Section 4.3. Time and Date Handling 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, 15 Jun 2014 00:06:02 -0000 --001a11c21fc0e36b2604fbd4ac11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Superfluous =E2=80=9Cin=E2=80=9D nuked, thanks. Also, could any date/time scholars here have a look at section 3.3 of RFC4287 - http://tools.ietf.org/html/rfc4287#section-3.3 - and see if they think some of that language should be adopted here. On Sat, Jun 14, 2014 at 4:35 AM, Stefan Drees wrote: > Thanks for providing this, Tim. > On 2014-06-13 22:01 +02:00, Tim Bray wrote: > >> Real HTML is at http://www.tbray.org/tmp/draft-ietf-json-i-json-01.html >> >> >> On Fri, Jun 13, 2014 at 12:58 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 Group of the IETF. >> >> Title : The I-JSON Message Format >> Author : Tim Bray >> Filename : draft-ietf-json-i-json-01.txt >> Pages : 6 >> Date : 2014-06-13 >> >> 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/ >> ... >> > > I read over it and section 4.3 "Time and Date Handling" might profit from > one or two small changes: > > OLD: > 4.3. Time and Date Handling > > Protocols often contain data items which are designed to contain > timestamps or time durations. It is RECOMMENDED that in all such > data items be expressed in in ISO 8601 format, as specified in > [RFC3339]. > > NEW (suggested): > 4.3. Time and Date Handling > > Protocols often contain data items which are designed to contain > timestamps or time durations. It is RECOMMENDED that in all such > data temporal items be expressed in ISO 8601 format, as specified > in [RFC3339]. > > > {"end_of_changes": true} > > Removing the doubled "in" is a sure thing for me, but if others would als= o > subsume "the targeted items" as "temporal items" I do really not know and > thus happily delegate to the native english speakers on this list. > > The motivating sentence reminds me a bit of the significance of sister > phrases like "Life often is ..." but as it is true (in my experience) and > if no one else is irritated by quantifiers like "often" I see no need to > discuss. > > All the best, > Stefan. > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c21fc0e36b2604fbd4ac11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Superfluous =E2=80=9Cin=E2=80=9D nuked, thanks.

Also, could any date/time scholars here have a look at section 3.3 of RFC42= 87 -=C2=A0http://tools.ietf.org/html/rfc4287#section-3.3 - and see if= they think some of that language should be adopted here.


On Sat,= Jun 14, 2014 at 4:35 AM, Stefan Drees <stefan@drees.name> w= rote:
Thanks for providing this, Tim.
On 2014-06-13 22:01 +02:00, Tim Bray wrote:
Real HTML is at http://www.tbray.org/tmp/draft-ietf-json-= i-json-01.html


On Fri, Jun 13, 2014 at 12:58 PM, <internet-drafts@ietf.org
<mailto:in= ternet-drafts@ietf.org>> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts
=C2=A0 =C2=A0 directories.
=C2=A0 =C2=A0 =C2=A0 This draft is a work item of the JavaScript Object Not= ation
=C2=A0 =C2=A0 Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : The I-JSON Message Format
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: Tim Bray
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2= =A0 =C2=A0: draft-ietf-json-i-json-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0: 2014-06-13

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-JSON is a restricted profile of JSON designed= to maximize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 interoperability and increase confidence that s= oftware can
=C2=A0 =C2=A0 process it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 successfully with predictable results.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://datatracker.ietf.org/doc/draft-iet= f-json-i-json/
...

I read over it and section 4.3 "Time and Date Handling" might pro= fit from one or two small changes:

OLD:
4.3. =C2=A0Time and Date Handling

=C2=A0 =C2=A0Protocols often contain data items which are designed to conta= in
=C2=A0 =C2=A0timestamps or time durations. =C2=A0It is RECOMMENDED that in = all such
=C2=A0 =C2=A0data items be expressed in in ISO 8601 format, as specified in=
=C2=A0 =C2=A0[RFC3339].

NEW (suggested):
4.3. =C2=A0Time and Date Handling

=C2=A0 =C2=A0Protocols often contain data items which are designed to conta= in
=C2=A0 =C2=A0timestamps or time durations. =C2=A0It is RECOMMENDED that in = all such
=C2=A0 =C2=A0data temporal items be expressed in ISO 8601 format, as specif= ied
=C2=A0 =C2=A0in [RFC3339].


{"end_of_changes": true}

Removing the doubled "in" is a sure thing for me, but if others w= ould also subsume "the targeted items" as "temporal items&qu= ot; I do really not know and thus happily delegate to the native english sp= eakers on this list.

The motivating sentence reminds me a bit of the significance of sister phra= ses like "Life often is ..." but as it is true (in my experience)= and if no one else is irritated by quantifiers like "often" I se= e no need to discuss.

All the best,
Stefan.




--
- Tim Bray (If you=E2=80=99d like to send me a private message, s= ee https://keybase= .io/timbray)
--001a11c21fc0e36b2604fbd4ac11-- From nobody Sat Jun 14 18:38: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 5053A1B2A5A for ; Sat, 14 Jun 2014 18:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.251 X-Spam-Level: X-Spam-Status: No, score=-5.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 CiugJJxydImc for ; Sat, 14 Jun 2014 18:38:14 -0700 (PDT) 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 7D6F81B2946 for ; Sat, 14 Jun 2014 18:38:14 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WvzOe-0008Vp-4J; Sat, 14 Jun 2014 21:38:12 -0400 Date: Sat, 14 Jun 2014 21:38:12 -0400 From: John Cowan To: Tim Bray Message-ID: <20140615013812.GA22935@mercury.ccil.org> References: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> <539C3367.7090301@drees.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/3-2BqAShf5DlNTYTyXNcEIhlFDI Cc: Stefan Drees , "json@ietf.org" Subject: Re: [Json] I-JSON(2014-06-13) Section 4.3. Time and Date Handling 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, 15 Jun 2014 01:38:17 -0000 Tim Bray scripsit: > Also, could any date/time scholars here have a look at section 3.3 of > RFC4287 - http://tools.ietf.org/html/rfc4287#section-3.3 - and see if they > think some of that language should be adopted here. That basically says to use T and Z rather than t and z, which I agree is good. So here's my proposal: Protocols often contain data items which are designed to contain timestamps or time durations. It is RECOMMENDED that all data items containing timestamps conform to the "date-time" production in [RFC3339], with the additional restriction that uppercase rather than lowercase letters be used. It is also RECOMMENDED that all data items containing time durations conform to the "duration" production in Appendix A of [RFC3339], with the same additional restriction. I would further urge that the recommendation be changed to requirements. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org A few times, I did some exuberant stomping about, like a hippo auditioning for Riverdance, though I stopped when I thought I heard something at the far side of the room falling over in rhythm with my feet. --Joseph Zitt From nobody Sun Jun 15 17:44: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 DC0A71B298C for ; Sun, 15 Jun 2014 17:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWtpi10knHab for ; Sun, 15 Jun 2014 17:44:13 -0700 (PDT) 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 0CBDC1B2997 for ; Sun, 15 Jun 2014 17:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4542; q=dns/txt; s=iport; t=1402879453; x=1404089053; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PTmPTh2pmL+DZvCDu3GtrpXcyH7VQivjMXQ3Vn6M6O0=; b=TBaaiJGLWFjkvZq/CLEFksk7frZdGIkckVXH0eJej9gm0cu6/eomFegK jM8d6iMKsW0arlpiJfVa6wiuD101yFgWLaqYlcEbUF+nv7ZBvqZ34J/Jw 9QTuLEf+NyYtZfvr0HFONu7pTNAE+NbYkyWKCZI4Y7I4kaedYqxkKg18A M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngKACc9nlOtJV2b/2dsb2JhbABagw1SUweCbKZ5AQEBAwUBkWeHPQEZbRZ1hAMBAQEEAQEBIBE6GwIBCA4KAgImAgICJQsVEAIEARIJiDkIBbBgnWUXgSqEOYhgOoJ3gUwEmkOBQ5IVg0BsgUQ X-IronPort-AV: E=Sophos;i="5.01,482,1400025600"; d="scan'208";a="333279977" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 16 Jun 2014 00:44:12 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5G0iC7I017484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jun 2014 00:44:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Sun, 15 Jun 2014 19:44:11 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , "json@ietf.org" Thread-Topic: [Json] I-D Action: draft-ietf-json-i-json-01.txt Thread-Index: AQHPh0HQFvMb2e2gF0GlAL2QI1x4EptvydYAgADbL4A= Date: Mon, 16 Jun 2014 00:44:11 +0000 Message-ID: References: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.99.172] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/njfEn1N_Z6e4UCxbXdJEDUdaXZA Subject: Re: [Json] I-D Action: draft-ietf-json-i-json-01.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: Mon, 16 Jun 2014 00:44:15 -0000 V3JpdGluZyB0aGlzIG9uIGEgcGxhbmUsIHNvIEknbSBzb3JyeSBpZiB0aGlzIGNyb3NzZXMgc29t ZW9uZSBlbHNlJ3MNCnJldmlldyB0aGF0IG1ha2VzIHRoZSBzYW1lIHBvaW50cy4NCg0KczIuMSwg cy9hbHdheXMgaWxsZWdhbC9pbGxlZ2FsLw0KDQpzMi4yLCAiRm9yIGFwcGxpY2F0aW9ucyBzdWNo IGFzIGNyeXB0b2dyYXBoeSwgd2hlcmUgZXhhY3QgaW50ZXJjaGFuZ2Ugb2YNCm11Y2ggbGFyZ2Vy IG51bWJlcnMgaXMgcmVxdWlyZWQsIGl0IGlzIFJFQ09NTUVOREVEIHRvIGVuY29kZSB0aGVtIGlu IEpTT04NCnN0cmluZyB2YWx1ZXMiLCBJIHN1Z2dlc3QgYWRkaW5nIHNvbWUgZ3VpZGFuY2Ugb24g ZW5jb2RpbmcgaWYgd2UgaGF2ZSBhDQpxdWljayBjb25zZW5zdXMgb24gZGVjaW1hbHxoZXh8YmFz ZTY0dXJsfGV0Yy4gIE90aGVyd2lzZSBsZWF2aW5nIGl0IGFzLWlzDQp3b3Jrcy4gIE5vdGUgdGhh dCBKT1NFIGNob3NlIGJhc2U2NHVybCBmb3IgZ29vZCByZWFzb24uDQoNCnMyLjMsIEkgZG9uJ3Qg dGhpbmsgd2UgZXZlciBzcGVjaWZpZWQgd2hhdCAiZHVwbGljYXRlIiBtZWFucy4gIEZvcg0KZXhh bXBsZSwgaXMgdGhpcyBsZWdhbD8NCg0KeyAiYSI6IDEsICJcdTAwNjEiOiAyIH0NCg0Kd2hhdCBh Ym91dCB0aGlzPw0KDQp7ICJhXHUwMzAxIjogMSwgIlx1MDBlMSI6IDJ9DQoNCm9yIHRoaXM6DQoN CnsgIml2IjogMSwgIlx1MjE2MyI6IDJ9DQoNCk15IG9waW5pb246IHRoZSBmaXJzdCBvbmUgaXMg aWxsZWdhbC4gIFRoZSBzZWNvbmQgYW5kIHRoaXJkIGFyZSBsZWdhbCwgc28NCndlIGRvbid0IGJy aW5nIGluIE5GQyBvciAoc2h1ZGRlcikgTkZLQy4NCg0KczQsIEkgdGhpbmsgdGhlcmUgb3VnaHQg dG8gYmUgYW5vdGhlciBzZW50ZW5jZSBpbiB0aGVyZSBhYm91dCB3aHkgeW91DQptaWdodCB3YW50 IHRvIHNwZWNpZnkgSS1KU09OLiAgTmFtZWx5LCB0aGF0IHlvdSdyZSBleHByZXNzaW5nIHRoYXQg YXMgYQ0Kc2VuZGVyLCBpZiB0aGVyZSdzIGEgYnVnIGluIHlvdXIgY29kZSB5b3Ugd291bGQgcmF0 aGVyIGhhdmUgdGhlIHJlY2VpdmVyDQpmYWlsIG9uIHByb2Nlc3NpbmcgdGhhbiB0cnkgdG8gcmVj b3Zlci4gIEFsdGVybmF0ZWx5LCB0aGF0IGNvdWxkIGdvIGluIHRoZQ0KaW50cm9kdWN0aW9uLg0K DQpzNC4zLCBleHBsaWNpdGx5IGNhbGwgb3V0IHRoYXQgdGhlIGRhdGUgd2lsbCBiZSBpbiBhIHN0 cmluZywgcGxlYXNlLg0KczQuNCwgZXhwbGljaXRseSBjYWxsIG91dCB0aGF0IHRoZSBiYXNlNjR1 cmwgd2lsbCBiZSBpbiBhIHN0cmluZywgcGxlYXNlLg0KDQpmb3IgYm90aCBzNC4zIGFuZCBzNC40 LCB0aGV5IG1heSB3b3JrIGJldHRlciBpbiBzMi4NCg0KczYsIGRvZXMgSmltIFNjaGFhZCBoYXZl IGFueXRoaW5nIGVsc2UgdG8gYWRkLCBwZXJoYXBzIGF0dGFja3Mgd2l0aA0KbXVsdGlwbGUgb2Jq ZWN0IGtleXMgYW5kIHRoZSBsaWtlPyAgQXJlIHRoZXJlIGFueSBvdGhlciB0aGluZ3MgaGUgd2Fz DQp3b3JyaWVkIGFib3V0IGZyb20gSk9TRSB0aGF0IGRpZG4ndCBtYWtlIGl0IGludG8gdGhpcyBk cmFmdD8NCg0KT24gNi8xMy8xNCwgMjowMSBQTSwgIlRpbSBCcmF5IiA8dGJyYXlAdGV4dHVhbGl0 eS5jb20+IHdyb3RlOg0KDQo+UmVhbCBIVE1MIGlzIGF0IGh0dHA6Ly93d3cudGJyYXkub3JnL3Rt cC9kcmFmdC1pZXRmLWpzb24taS1qc29uLTAxLmh0bWwNCj4NCj4NCj4NCj5PbiBGcmksIEp1biAx MywgMjAxNCBhdCAxMjo1OCBQTSwgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQo+ DQo+DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzDQo+ZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIEphdmFTY3JpcHQgT2JqZWN0IE5vdGF0aW9uIFdvcmtpbmcNCj5Hcm91cCBvZiB0 aGUgSUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFRoZSBJLUpTT04gTWVzc2Fn ZSBGb3JtYXQNCj4gICAgICAgIEF1dGhvciAgICAgICAgICA6IFRpbSBCcmF5DQo+ICAgICAgICBG aWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWpzb24taS1qc29uLTAxLnR4dA0KPiAgICAgICAg UGFnZXMgICAgICAgICAgIDogNg0KPiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNC0wNi0x Mw0KPg0KPkFic3RyYWN0Og0KPiAgIEktSlNPTiBpcyBhIHJlc3RyaWN0ZWQgcHJvZmlsZSBvZiBK U09OIGRlc2lnbmVkIHRvIG1heGltaXplDQo+ICAgaW50ZXJvcGVyYWJpbGl0eSBhbmQgaW5jcmVh c2UgY29uZmlkZW5jZSB0aGF0IHNvZnR3YXJlIGNhbiBwcm9jZXNzIGl0DQo+ICAgc3VjY2Vzc2Z1 bGx5IHdpdGggcHJlZGljdGFibGUgcmVzdWx0cy4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWpzb24taS1qc29uLw0KPg0KPlRoZXJlJ3MgYWxzbyBhIGh0 bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtanNvbi1pLWpzb24tMDENCj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMg dmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1qc29uLWktanNvbi0wMQ0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlzc2lv bg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQN Cj50b29scy5pZXRmLm9yZyA8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4NCj5JbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPmpzb24gbWFpbGluZyBsaXN0DQo+anNvbkBpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vanNvbg0KPg0KPg0KPg0K Pg0KPg0KPg0KPg0KPi0tIA0KPi0gVGltIEJyYXkgKElmIHlvdeKAmWQgbGlrZSB0byBzZW5kIG1l IGEgcHJpdmF0ZSBtZXNzYWdlLCBzZWUNCj5odHRwczovL2tleWJhc2UuaW8vdGltYnJheSA8aHR0 cHM6Ly9rZXliYXNlLmlvL3RpbWJyYXk+KQ0KPg0KPg0KPg0KDQoNCi0tIA0KSm9lIEhpbGRlYnJh bmQNCg0KDQoNCg== From nobody Mon Jun 16 00:14: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 6FD081B2C00 for ; Mon, 16 Jun 2014 00:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 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, RP_MATCHES_RCVD=-0.651] 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 n9DX1bmOvo9Z for ; Mon, 16 Jun 2014 00:14:35 -0700 (PDT) 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 E950B1B2B61 for ; Mon, 16 Jun 2014 00:14:34 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 32ADF32E52C; Mon, 16 Jun 2014 16:14:33 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 324b_d633_e342603a_b0ef_4caf_8058_78adb3b465e7; Mon, 16 Jun 2014 16:14:31 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id C3B02BF547; Mon, 16 Jun 2014 16:14:31 +0900 (JST) Message-ID: <539E9947.2030805@it.aoyama.ac.jp> Date: Mon, 16 Jun 2014 16:14:15 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , Tim Bray , "json@ietf.org" References: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/kcVjneeoi1oivKZErKkfAleLg0Y Subject: Re: [Json] I-D Action: draft-ietf-json-i-json-01.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: Mon, 16 Jun 2014 07:14:36 -0000 On 2014/06/16 09:44, Joe Hildebrand (jhildebr) wrote: > Writing this on a plane, so I'm sorry if this crosses someone else's > review that makes the same points. > > s2.1, s/always illegal/illegal/ s/illegal/invalid/ There may be jurisdictions where unpaired surrogates are outlawed, but I wouldn't know any :-). Regards, Martin. From nobody Tue Jun 17 10:54: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 5A36B1A03BD for ; Tue, 17 Jun 2014 10:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 9csHATm6A4LT for ; Tue, 17 Jun 2014 10:54:01 -0700 (PDT) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D65D1A0111 for ; Tue, 17 Jun 2014 10:54:01 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id sa20so6159300veb.10 for ; Tue, 17 Jun 2014 10:54:00 -0700 (PDT) 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:content-transfer-encoding; bh=MMMRwfYSDPhF5CN7pzfnAYgjQpoDn2vEN4Q0dyt6K/8=; b=YD42NyTsBe5quPQFaacYbuySmDyDQSDOSruj1KU/82TeBeb3wSjTOamsECGbPsonvZ P+lG+A08CmhkZBHPNhsMr1HdrokGN0uhzc4kBr5upRjxLphfDNNSNKynbUcBdaBgutJm Hj/rqBpLMU1WDKnHGlTB2Oeo8EeuGtmd7vdUcdwOXQqGjDLoaCRCwNj/2aK0eSh4c6jl rDaS0Fjtohs8prDnHdXTc1PjnIbAvX0+dVvz8PtXON2CjW1QBkHsNOwCnrZniH/KW+Xs evE4HzFlGTDB4ruV+Ege3GFt+vjBZeI2X1YZh2bIWAvjb53NcYOYDspQIpDw44upwWhV KETA== X-Gm-Message-State: ALoCoQkxgTvLHM7Js/8S1zo4wGKwLJoa2Mb4Az8Q+j83QVA1ey+Wr5I3h0Gl+q4jqleFquo3amW+ X-Received: by 10.58.118.168 with SMTP id kn8mr2330978veb.44.1403027640171; Tue, 17 Jun 2014 10:54:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Tue, 17 Jun 2014 10:53:40 -0700 (PDT) X-Originating-IP: [24.85.103.37] In-Reply-To: References: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> From: Tim Bray Date: Tue, 17 Jun 2014 10:53:40 -0700 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/YOu_dq10zA0FnK0tEkzMXSyGHr8 Cc: "json@ietf.org" Subject: Re: [Json] I-D Action: draft-ietf-json-i-json-01.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, 17 Jun 2014 17:54:03 -0000 OK, I just made an -02 pre-draft, anyone want to sanity check before I submit? Get it at http://www.tbray.org/tmp/draft-ietf-json-i-json-02.html http://www.tbray.org/tmp/draft-ietf-json-i-json-02.txt diff at http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://www.= tbray.org/tmp/draft-ietf-json-i-json-01.txt&url2=3Dhttp://www.tbray.org/tmp= /draft-ietf-json-i-json-02.txt I took almost all the suggestions from reviewers except as follows: On Sun, Jun 15, 2014 at 5:44 PM, Joe Hildebrand (jhildebr) wrote: > s2.2, "For applications such as cryptography, where exact interchange of > much larger numbers is required, it is RECOMMENDED to encode them in JSON > string values", I suggest adding some guidance on encoding if we have a > quick consensus on decimal|hex|base64url|etc. Otherwise leaving it as-is > works. Note that JOSE chose base64url for good reason. Not sure I get this... for big numbers, it=E2=80=99s just digits, right? > s4, I think there ought to be another sentence in there about why you > might want to specify I-JSON. Namely, that you're expressing that as a > sender, if there's a bug in your code you would rather have the receiver > fail on processing than try to recover. Alternately, that could go in th= e > introduction. I eventually decided that the last sentence of section 1 probably meets our needs, but if someone wants to propose language, go for it. From nobody Tue Jun 17 12:30: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 C9ED71A03D2 for ; Tue, 17 Jun 2014 12:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 uzocO2Tf6Hj2 for ; Tue, 17 Jun 2014 12:30:15 -0700 (PDT) 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 5DB2A1A00C0 for ; Tue, 17 Jun 2014 12:30:15 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Wwz5B-0002Zg-8q; Tue, 17 Jun 2014 15:30:13 -0400 Date: Tue, 17 Jun 2014 15:30:13 -0400 From: John Cowan To: Tim Bray Message-ID: <20140617193013.GD29802@mercury.ccil.org> References: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/iVUkXYOo2XeHFQzEWEsHh2t2-GM Cc: "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] I-D Action: draft-ietf-json-i-json-01.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, 17 Jun 2014 19:30:17 -0000 Tim Bray scripsit: > > s2.2, "For applications such as cryptography, where exact interchange of > > much larger numbers is required, it is RECOMMENDED to encode them in JSON > > string values", I suggest adding some guidance on encoding if we have a > > quick consensus on decimal|hex|base64url|etc. Otherwise leaving it as-is > > works. Note that JOSE chose base64url for good reason. > > Not sure I get this... for big numbers, it’s just digits, right? Yes, but digits of what base? Decimal, ça va sans dire; but it goes even better when it is said. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You cannot enter here. Go back to the abyss prepared for you! Go back! Fall into the nothingness that awaits you and your Master. Go! --Gandalf From nobody Tue Jun 17 15:49: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 973C21A008F for ; Tue, 17 Jun 2014 15:49:07 -0700 (PDT) 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 50nFnxf5KHnn for ; Tue, 17 Jun 2014 15:49:06 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8AE1A00FC for ; Tue, 17 Jun 2014 15:49:06 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id rl12so23868iec.39 for ; Tue, 17 Jun 2014 15:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=knLA+SbLZsdoD6lR0FlvkCLa+bD+pS0XYr7f7+W3qEk=; b=ylIpBdp1HEl4mQ3QFoSqDJPefALHRHpEVew3nvBW7lCAAwhJybJ8LB09QfBaVWeZwp 0WImwy8eZYcgwWYlJu8bQrxZgJ2AASdIJZqvAPBRPDfuxcWsOpba89xVLOu+zfIptmu8 bjjQwEfLR5R6/y8tKXIS6CpgtcOascoYmvpg6BpvAS/BhWr7LPmrrwAx7NsWUerQCb94 Cb8fOgTwaxVr9aEFMDHvqbDP6uoUDf2+ZQzav3NL3YuxNPgFYjMl+v++9F4bqHcaAyuV ex9SFTyn4pY9lilgPtk7lr6VvIMxFZ7QEO1qTN3MwELwI0X+MLNdYCWohj52kjI7Oaxk JVlQ== X-Received: by 10.42.37.199 with SMTP id z7mr12996691icd.11.1403045345815; Tue, 17 Jun 2014 15:49:05 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.50.243.50 with HTTP; Tue, 17 Jun 2014 15:48:45 -0700 (PDT) In-Reply-To: <20140617193013.GD29802@mercury.ccil.org> References: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> <20140617193013.GD29802@mercury.ccil.org> From: Jacob Davies Date: Tue, 17 Jun 2014 15:48:45 -0700 X-Google-Sender-Auth: IZ543W71u7TBY8VQoOvmvKPnrNg Message-ID: To: John Cowan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/FHCkfNEE_a1Md1hLI400K6cDmoU Cc: Tim Bray , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] I-D Action: draft-ietf-json-i-json-01.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, 17 Jun 2014 22:49:07 -0000 "For applications such as cryptography, where exact interchange of much larger numbers is required, it is RECOMMENDED to encode them in JSON string values." The phrasing of "it is recommended to encode them" seems awkward to me. Maybe "it is recommended that such values be encoded as"? "encoded" also seems off. Maybe "written", "stored", "represented"? I am not sure that cryptography is the right example. The most common surprising case will be people trying to store arbitrary 64-bit integers from commonplace types like Java longs and finding that most of the value range can't be read & correctly represented in Javascript. Those numbers might come from 64-bit hashes or storage systems that assign evenly-distributed 64-bit IDs. Cryptographic applications deal with much larger numbers, and are already accustomed to exchanging them as binary, hex, or base64. I doubt anyone would really even think of trying to send a 2048-bit key as a JSON number. On Tue, Jun 17, 2014 at 12:30 PM, John Cowan wrote= : > Tim Bray scripsit: > >> > s2.2, "For applications such as cryptography, where exact interchange = of >> > much larger numbers is required, it is RECOMMENDED to encode them in J= SON >> > string values", I suggest adding some guidance on encoding if we have = a >> > quick consensus on decimal|hex|base64url|etc. Otherwise leaving it as= -is >> > works. Note that JOSE chose base64url for good reason. >> >> Not sure I get this... for big numbers, it=E2=80=99s just digits, right? > > Yes, but digits of what base? Decimal, =C3=A7a va sans dire; but it goes > even better when it is said. > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > You cannot enter here. Go back to the abyss prepared for you! Go back! > Fall into the nothingness that awaits you and your Master. Go! --Gandalf > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Wed Jun 18 08:07: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 8450D1A01E8 for ; Wed, 18 Jun 2014 08:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-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 gw0jRQEK3g6o for ; Wed, 18 Jun 2014 08:07:30 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B671A0279 for ; Wed, 18 Jun 2014 08:07:29 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id id10so916041vcb.24 for ; Wed, 18 Jun 2014 08:07:27 -0700 (PDT) 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=zpfpEjONFSNKbpgtamV6+7teyoxxHW7AateEX+OE/nU=; b=SuUKf5aB4Xhrgy5X5Ok6hQzVgqPi5Mn+GVafk2cIZYcIoDVdndzmJyu6mnMEOUAPhL ZF+jCA3R5wEeg1IWItltLQHJT+Vgkt7gTR1OqiRfuvmKmxmYc1obK3aUzSffSOaBfRg/ qJb1IIRqXw6M6vp2CzOyt+6jPGfACwidWk2cgKfi7UmrIc+Dy8Ta0PRHK/hzEFTS0OS3 9gXtUuc2KQFGePxyHY29T9UcSKhl2MpZKu5J/AhjtRoytJjYzQHw/UuzReGAk8vzu3Pi 3eK/9y4J7YD0M0o4J5EyeKZ7Tk7yx/S0PQ0enTlZNWrMpD0rXsJPA2AR4Wj2p3rXCRg5 2o9A== X-Gm-Message-State: ALoCoQnCZegGuS/vlDI6xhReqbmBnES4VMUCMeikjyz/SvN/slO4FTZNsL+lJb0QimT/2U+nw8+e X-Received: by 10.52.243.225 with SMTP id xb1mr10963145vdc.36.1403104047394; Wed, 18 Jun 2014 08:07:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Wed, 18 Jun 2014 08:07:07 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> <20140617193013.GD29802@mercury.ccil.org> From: Tim Bray Date: Wed, 18 Jun 2014 08:07:07 -0700 Message-ID: To: Jacob Davies Content-Type: multipart/alternative; boundary=001a11c2454453f6ae04fc1d9eb8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Kk64z_QHLYOaCOIXG0QSVBp78x8 Cc: John Cowan , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] I-D Action: draft-ietf-json-i-json-01.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: Wed, 18 Jun 2014 15:07:33 -0000 --001a11c2454453f6ae04fc1d9eb8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 17, 2014 at 3:48 PM, Jacob Davies wrote: > "For applications such as cryptography, where exact interchange of > much larger numbers is required, it is RECOMMENDED to encode them in > JSON string values." > > The phrasing of "it is recommended to encode them" seems awkward to > me. Maybe "it is recommended that such values be encoded as"? > > "encoded" also seems off. Maybe "written", "stored", "represented"? > =E2=80=8BThe recommend/encode terminology has been around for a while and = =E2=80=8Bthis is the first gripe I=E2=80=99ve heard. Anyone want to pile on? =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > I am not sure that cryptography is the right example. The most common > =E2=80=8B=E2=80=8B > surprising case will be people trying to store arbitrary 64-bit > =E2=80=8B=E2=80=8B > integers > =E2=80=8B=E2=80=8B > =E2=80=8B =E2=80=8BI confess to having cryptography on the brain. I think he=E2=80= =99s right, the simplest example is just a 64-bit integer, might as well say that; will change unless someone screams. > from commonplace types like Java longs and finding that most > of the value range can't be read & correctly represented in > Javascript. Those numbers might come from 64-bit hashes or storage > systems that assign evenly-distributed 64-bit IDs. > > Cryptographic applications deal with much larger numbers, and are > already accustomed to exchanging them as binary, hex, or base64. I > doubt anyone would really even think of trying to send a 2048-bit key > as a JSON number. > > On Tue, Jun 17, 2014 at 12:30 PM, John Cowan > wrote: > > Tim Bray scripsit: > > > >> > s2.2, "For applications such as cryptography, where exact interchang= e > of > >> > much larger numbers is required, it is RECOMMENDED to encode them in > JSON > >> > string values", I suggest adding some guidance on encoding if we hav= e > a > >> > quick consensus on decimal|hex|base64url|etc. Otherwise leaving it > as-is > >> > works. Note that JOSE chose base64url for good reason. > >> > >> Not sure I get this... for big numbers, it=E2=80=99s just digits, righ= t? > > > > Yes, but digits of what base? Decimal, =C3=A7a va sans dire; but it go= es > > even better when it is said. > > > > -- > > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > > You cannot enter here. Go back to the abyss prepared for you! Go back= ! > > Fall into the nothingness that awaits you and your Master. Go! --Ganda= lf > > > > _______________________________________________ > > 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) --001a11c2454453f6ae04fc1d9eb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 17, 2014 at 3:48 PM, Jacob Davies <jacob@well.com> wrot= e:
"For applications such as cryptography, where exact in= terchange of
much larger numbers is required, it is RECOMMENDED to encode them in
JSON string values."

The phrasing of "it is recommended to encode them" seems awkward = to
me. Maybe "it is recommended that such values be encoded as"?

"encoded" also seems off. Maybe "written", "stored= ", "represented"?

=E2=80=8BThe recommend/enc= ode terminology has been around for a while and =E2=80=8Bthis is the first = gripe I=E2=80=99ve heard. Anyone want to pile on?
=E2=80=8B=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8B
I am not sure that cryptography is the right exampl= e. The most common
=E2= =80=8B=E2=80=8B
surprising case will be people trying to store arbitra= ry 64-bit
=E2= =80=8B=E2=80=8B
integers
=E2=80=8B=E2=80=8B
=E2=80=8B
=E2=80=8BI confess to having cryptography on the brain. =C2=A0I think= he=E2=80=99s right, the simplest example is just a 64-bit integer, might a= s well say that; will change unless someone screams.



=C2=A0
from commonplace types like Java longs and finding that most=
of the value range can't be read & correctly represented in
Javascript. Those numbers might come from 64-bit hashes or storage
systems that assign evenly-distributed 64-bit IDs.

Cryptographic applications deal with much larger numbers, and are
already accustomed to exchanging them as binary, hex, or base64. I
doubt anyone would really even think of trying to send a 2048-bit key
as a JSON number.

On Tue, Jun 17, 2014 at 12:30 PM, John Cowan <cowan@mercury.ccil.org> wrote:
> Tim Bray scripsit:
>
>> > s2.2, "For applications such as cryptography, where exac= t interchange of
>> > much larger numbers is required, it is RECOMMENDED to encode = them in JSON
>> > string values", I suggest adding some guidance on encodi= ng if we have a
>> > quick consensus on decimal|hex|base64url|etc. =C2=A0Otherwise= leaving it as-is
>> > works. =C2=A0Note that JOSE chose base64url for good reason.<= br> >>
>> Not sure I get this... for big numbers, it=E2=80=99s just digits, = right?
>
> Yes, but digits of what base? =C2=A0Decimal, =C3=A7a va sans dire; but= it goes
> even better when it is said.
>
> --
> John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ccil.org/~cowan =C2=A0 =C2= =A0 =C2=A0 =C2=A0cowan@ccil.org
> You cannot enter here. =C2=A0Go back to the abyss prepared for you! = =C2=A0Go back!
> Fall into the nothingness that awaits you and your Master. =C2=A0Go! -= -Gandalf
>
> __________________= _____________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json



--
=
- Tim Bray (If you=E2=80=99d like to send me a privat= e message, see htt= ps://keybase.io/timbray)
--001a11c2454453f6ae04fc1d9eb8-- From nobody Wed Jun 18 08:13: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 4C9C11A0293 for ; Wed, 18 Jun 2014 08:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-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 pGGkuSJXe3p6 for ; Wed, 18 Jun 2014 08:13:10 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3237C1A005B for ; Wed, 18 Jun 2014 08:13:10 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id id10so924741vcb.24 for ; Wed, 18 Jun 2014 08:13:09 -0700 (PDT) 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=CLsjJM2GOv6oyrPkn1kEzJ+XM73fnH8XhhyEwfWX9ts=; b=gB5FQ6ft0EOPmnZZL21rGZrSknOrzA5leHHb/tEac9UdzXmTZo8/zAeDUUEX8MRct3 U+BYRhXPT1zIBYIIPT2O6b1YDYUdrZo8o+LiM3Eb+rcPGvjVRZNo7yEoqU0mwMhFK4j2 3mQR5JUxmGxgM6ALGOkL9Hxn5A/jQSSxxRrxRW8CEESwOVYlpaQ3WW7SYgv71Bz9m6nR IjkWZExtSbk19cCWXRy07lfc18FcX43P8uYbts3j2EdrsXvE/woEpEWVW+PgPyNYZ1Q4 cplFSv1ZmgJH8kzWmumfT7AmXlUxKnjjzZVo0GAi5hmdSY7Nq/RAa1SMvEjxamAnLtio IBWQ== X-Gm-Message-State: ALoCoQnjQl3+0PVYWpaGrmyoI2eoJxxBEfjQ8KFgAxkj/hq1I77QUrWi6X5N3uimKBitmNk5Sxlq X-Received: by 10.58.152.194 with SMTP id va2mr924866veb.54.1403104389371; Wed, 18 Jun 2014 08:13:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Wed, 18 Jun 2014 08:12:48 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> <20140617193013.GD29802@mercury.ccil.org> From: Tim Bray Date: Wed, 18 Jun 2014 08:12:48 -0700 Message-ID: To: Jacob Davies Content-Type: multipart/alternative; boundary=089e013cbcd2b62b6504fc1db254 Archived-At: http://mailarchive.ietf.org/arch/msg/json/9iigSvu60U0jnMuCUDz10Vj0Kb0 Cc: John Cowan , "Joe Hildebrand \(jhildebr\)" , "json@ietf.org" Subject: Re: [Json] I-D Action: draft-ietf-json-i-json-01.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: Wed, 18 Jun 2014 15:13:19 -0000 --089e013cbcd2b62b6504fc1db254 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Refreshed the -02 pre-drafts per Jacob Davies=E2=80=99s suggestions, see http://www.tbray.org/tmp/draft-ietf-json-i-json-02.html or http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttp://www.tbray.or= g/tmp/draft-ietf-json-i-json-01.txt&url2=3Dhttp://www.tbray.org/tmp/draft-i= etf-json-i-json-02.txt On Wed, Jun 18, 2014 at 8:07 AM, Tim Bray wrote: > On Tue, Jun 17, 2014 at 3:48 PM, Jacob Davies wrote: > >> "For applications such as cryptography, where exact interchange of >> much larger numbers is required, it is RECOMMENDED to encode them in >> JSON string values." >> >> The phrasing of "it is recommended to encode them" seems awkward to >> me. Maybe "it is recommended that such values be encoded as"? >> >> "encoded" also seems off. Maybe "written", "stored", "represented"? >> > > =E2=80=8BThe recommend/encode terminology has been around for a while and= =E2=80=8Bthis is > the first gripe I=E2=80=99ve heard. Anyone want to pile on? > =E2=80=8B=E2=80=8B=E2=80=8B > >> =E2=80=8B=E2=80=8B >> I am not sure that cryptography is the right example. The most common >> =E2=80=8B=E2=80=8B >> surprising case will be people trying to store arbitrary 64-bit >> =E2=80=8B=E2=80=8B >> integers >> =E2=80=8B=E2=80=8B >> > =E2=80=8B > =E2=80=8BI confess to having cryptography on the brain. I think he=E2=80= =99s right, the > simplest example is just a 64-bit integer, might as well say that; will > change unless someone screams. > > > > > >> from commonplace types like Java longs and finding that most >> of the value range can't be read & correctly represented in >> Javascript. Those numbers might come from 64-bit hashes or storage >> systems that assign evenly-distributed 64-bit IDs. >> >> Cryptographic applications deal with much larger numbers, and are >> already accustomed to exchanging them as binary, hex, or base64. I >> doubt anyone would really even think of trying to send a 2048-bit key >> as a JSON number. >> >> On Tue, Jun 17, 2014 at 12:30 PM, John Cowan >> wrote: >> > Tim Bray scripsit: >> > >> >> > s2.2, "For applications such as cryptography, where exact >> interchange of >> >> > much larger numbers is required, it is RECOMMENDED to encode them i= n >> JSON >> >> > string values", I suggest adding some guidance on encoding if we >> have a >> >> > quick consensus on decimal|hex|base64url|etc. Otherwise leaving it >> as-is >> >> > works. Note that JOSE chose base64url for good reason. >> >> >> >> Not sure I get this... for big numbers, it=E2=80=99s just digits, rig= ht? >> > >> > Yes, but digits of what base? Decimal, =C3=A7a va sans dire; but it g= oes >> > even better when it is said. >> > >> > -- >> > John Cowan http://www.ccil.org/~cowan cowan@ccil.org >> > You cannot enter here. Go back to the abyss prepared for you! Go bac= k! >> > Fall into the nothingness that awaits you and your Master. Go! >> --Gandalf >> > >> > _______________________________________________ >> > json mailing list >> > json@ietf.org >> > https://www.ietf.org/mailman/listinfo/json >> > > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --089e013cbcd2b62b6504fc1db254 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed,= Jun 18, 2014 at 8:07 AM, Tim Bray <tbray@textuality.com>= wrote:
=
On Tue, Jun 17, 2014 at 3:48 PM,= Jacob Davies <jacob@well.com> wrote:
"For applications such as cryptography, where exact interchange o= f
much larger numbers is required, it is RECOMMENDED to encode them in
JSON string values."

The phrasing of "it is recommended to encode them" seems awkward = to
me. Maybe "it is recommended that such values be encoded as"?

"encoded" also seems off. Maybe "written", "stored= ", "represented"?

=
=E2=80=8BThe recomme= nd/encode terminology has been around for a while and =E2=80=8Bthis is the = first gripe I=E2=80=99ve heard. Anyone want to pile on?
=E2=80=8B=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8B
I am not sure that cryptography is the right exampl= e. The most common
=E2= =80=8B=E2=80=8B
surprising case will be people trying to store arbitra= ry 64-bit
=E2= =80=8B=E2=80=8B
integers
=E2=80=8B=E2=80=8B
=E2=80=8B
=E2=80=8BI confess to having cryptography on the brain. =C2=A0I= think he=E2=80=99s right, the simplest example is just a 64-bit integer, m= ight as well say that; will change unless someone screams.



=C2=A0<= /div>
from commonplace types like Java longs= and finding that most
of the value range can't be read & correctly represented in
Javascript. Those numbers might come from 64-bit hashes or storage
systems that assign evenly-distributed 64-bit IDs.

Cryptographic applications deal with much larger numbers, and are
already accustomed to exchanging them as binary, hex, or base64. I
doubt anyone would really even think of trying to send a 2048-bit key
as a JSON number.

On Tue, Jun 17, 2014 at 12:30 PM, John Cowan <cowan@mercury.ccil.org> wrote:
> Tim Bray scripsit:
>
>> > s2.2, "For applications such as cryptography, where exac= t interchange of
>> > much larger numbers is required, it is RECOMMENDED to encode = them in JSON
>> > string values", I suggest adding some guidance on encodi= ng if we have a
>> > quick consensus on decimal|hex|base64url|etc. =C2=A0Otherwise= leaving it as-is
>> > works. =C2=A0Note that JOSE chose base64url for good reason.<= br> >>
>> Not sure I get this... for big numbers, it=E2=80=99s just digits, = right?
>
> Yes, but digits of what base? =C2=A0Decimal, =C3=A7a va sans dire; but= it goes
> even better when it is said.
>
> --
> John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ccil.org/~cowan =C2=A0 =C2= =A0 =C2=A0 =C2=A0cowan@= ccil.org
> You cannot enter here. =C2=A0Go back to the abyss prepared for you! = =C2=A0Go back!
> Fall into the nothingness that awaits you and your Master. =C2=A0Go! -= -Gandalf
>
> _______________________________________________<= br> > json mailing list
> json@ietf.org > https://www.ietf.org/mailman/listinfo/json



--
- Tim Bray (If you=E2=80=99d like to send me a private message, see <= a href=3D"https://keybase.io/timbray" target=3D"_blank">https://keybase.io/= timbray)



--
- Tim Bray (If you=E2=80=99d like to send me a private message, s= ee https://keybase= .io/timbray)
--089e013cbcd2b62b6504fc1db254-- From nobody Wed Jun 18 08:13: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 C0FCC1A0293 for ; Wed, 18 Jun 2014 08:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.952 X-Spam-Level: X-Spam-Status: No, score=-13.952 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_12=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhpHyI1K69Q3 for ; Wed, 18 Jun 2014 08:13:19 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00A81A028B for ; Wed, 18 Jun 2014 08:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1933; q=dns/txt; s=iport; t=1403104394; x=1404313994; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jyKh9k7sTNRUzEML/o0DtlRi+upEv0wa+IQrsaY69JQ=; b=lb9B6CyPYvC6Scvztu0y5fTFALiSZNOafIKhfh5HyCpCd+itJvgKQAd6 1eDS3utuhL0RONLl/dCqcFym712dYFkkATvYQvKWIacWdCAXzbwLcSHLI HaVNQgZV2x5DvQ3sru5mHwGtHyzKKl70UdqbsL/kn/HM31BA6RAJG/SEy U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8IAJaroVOtJV2Q/2dsb2JhbABagw1SWqoHDAEBAQEBAQUBmSgBgQoWdYQDAQEBBHgBEAsOCgkWCAcJAwIBAgE0EQYNAQUCAQGIPsxpF4ViiGAzB4RDAQOKBTqQBJNYg2GCEQ X-IronPort-AV: E=Sophos;i="5.01,501,1400025600"; d="scan'208";a="333813299" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jun 2014 15:13:13 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5IFDCxl011436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jun 2014 15:13:12 GMT Received: from MAMILLE2-M-T03K.CISCO.COM (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jun 2014 10:13:12 -0500 Message-ID: <53A1AC89.7030004@cisco.com> Date: Wed, 18 Jun 2014 09:13:13 -0600 From: Matt Miller 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: <20140613195805.1386.5992.idtracker@ietfa.amsl.com> <20140617193013.GD29802@mercury.ccil.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/json/N0bqa9ovIFwCzXz6HDexynI9YVc Cc: "json@ietf.org" Subject: Re: [Json] I-D Action: draft-ietf-json-i-json-01.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: Wed, 18 Jun 2014 15:13:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 6/18/14, 9:07 AM, Tim Bray wrote: > On Tue, Jun 17, 2014 at 3:48 PM, Jacob Davies > wrote: > > "For applications such as cryptography, where exact interchange of > much larger numbers is required, it is RECOMMENDED to encode them > in JSON string values." > > The phrasing of "it is recommended to encode them" seems awkward > to me. Maybe "it is recommended that such values be encoded as"? > > "encoded" also seems off. Maybe "written", "stored", > "represented"? > > > ?The recommend/encode terminology has been around for a while and ? > this is the first gripe I?ve heard. Anyone want to pile on? ??? > > ?? I am not sure that cryptography is the right example. The most > common ?? surprising case will be people trying to store arbitrary > 64-bit ?? integers ?? > > ? ?I confess to having cryptography on the brain. I think he?s > right, the simplest example is just a 64-bit integer, might as well > say that; will change unless someone screams. > > /me doffs hat I think that makes sense. It's a far more common issue for people to run into than how to encode a key/ciphertext/signature. - -- - - 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJToayJAAoJEDWi+S0W7cO1+l8H+wTF/RZaRP2GuEpsmmYFfbk1 nDRlwWTh9aIYG7a9AlHfp3JO56kDKXJxNvtt7vV4K4mAwSo9AjM53BJdPBTKekVu BjhmVZD7wIGeUuI1kzSHaWkR9DCslcd5BtwQfwrZbGB6f7LRMsddVngT6cSWHtG8 zC7/rVDVEB1zzxe31fvV/6WJ6GSRi7tLMrsr6W0dDIL9o3MJk13t2aY9bWGuuv1/ YXqcnHuer6ocgie/gjHbQgvzTO5jE+XST6nHJDyI67H8+X79E+/uDrYmD6X3lrwr R+QmXgGSyZ1lcJkzS0/yjam81+7can1fQPCdGDTCxGwot94iZjzpzYHQF/pDapg= =Iw01 -----END PGP SIGNATURE----- From nobody Mon Jun 23 03:26: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 E94FF1B28A0 for ; Mon, 23 Jun 2014 03:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g5qdmUqdnvs for ; Mon, 23 Jun 2014 03:26:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82351A035B for ; Mon, 23 Jun 2014 03:26:11 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MY3Ho-1XCLFh3NHE-00Uvob for ; Mon, 23 Jun 2014 12:26:09 +0200 Message-ID: <53A800C0.8030605@gmx.de> Date: Mon, 23 Jun 2014 12:26:08 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "json@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:m/8NjJOELkF/l5D4HnQBuba89YplXKtdw/EOO8B7TEMKIBWMHB6 1guKgBmwQUDILI4RhjiEOKU8oSq6DwR6gN29IfPWlze+coxc8OQInqvShnx5koVr6utaRRg S9pXnFtMDPf5FOumebpkrh5OJgNPtNifYHeKrTSsjbrEtbbmCZnsR3l+ind6ikOrmqzF3pL 1mLl0ugrdqMLPpw6xHvXg== Archived-At: http://mailarchive.ietf.org/arch/msg/json/nOXBV_qTqO6vKg4qBkq_rmmcLS0 Subject: [Json] JSON in "Tracking Preference Expression (DNT)" 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, 23 Jun 2014 10:26:18 -0000 Hi there. DNT defines a JSON payload, but does so using ABNF. See This is in LC (or just past LC), so more feedback - directed to public-tracking-comments@w3.org - might be helpful. Best regards, Julian From nobody Mon Jun 30 10:32: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 0C43E1A03EE; Mon, 30 Jun 2014 10:32:38 -0700 (PDT) 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 EWbShqPKcp-M; Mon, 30 Jun 2014 10:32:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 960C51A01FF; Mon, 30 Jun 2014 10:32:36 -0700 (PDT) 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.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140630173236.19477.38239.idtracker@ietfa.amsl.com> Date: Mon, 30 Jun 2014 10:32:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/7cIHlGnKIswM5W4TEweWbutSP0w Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-i-json-02.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: Mon, 30 Jun 2014 17:32:38 -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-02.txt Pages : 6 Date : 2014-06-30 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-json-i-json-02 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 Mon Jun 30 19:39: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 9F0B11A0426 for ; Mon, 30 Jun 2014 19:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ92eOodkzLK for ; Mon, 30 Jun 2014 19:39:38 -0700 (PDT) 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 B48571A00A8 for ; Mon, 30 Jun 2014 19:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1452; q=dns/txt; s=iport; t=1404182378; x=1405391978; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=M5XQBOMH8XZNwn2QKUSH1iwW4FckIeyRELvZ3Va66EU=; b=DlritgvszZJg20KI2CaJQS7hBS2bsRfixQeFbSQGgyAHqgrdOrlWLzAu hV3alZXganr/ZkfhZs/YhGrb5QRV2a6fz5LAm6TewjPoAtCZhSVJ8I1Fg c2spMdVFUMqqgndgQXb7dYBADTGgANCN4smV2/6ptH+4tCHqodPWhHIpR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYFAJseslOtJV2d/2dsb2JhbABagw1SWqsfAQEBAQEBBQEFaZpZFnWEeAo9FhgDAgECAUsNCAEBiD6cM6tpF4VkjW0Fig06jACEF4FGhUCMd4NhghE X-IronPort-AV: E=Sophos;i="5.01,579,1400025600"; d="scan'208";a="336873772" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 01 Jul 2014 02:39:38 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s612dcaD023642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 1 Jul 2014 02:39:38 GMT Received: from [10.89.0.36] (10.89.0.36) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 30 Jun 2014 21:39:37 -0500 Message-ID: <53B21F69.7010101@cisco.com> Date: Mon, 30 Jun 2014 20:39:37 -0600 From: Matt Miller 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 X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.89.0.36] Archived-At: http://mailarchive.ietf.org/arch/msg/json/K7ONguKnoCGh-9RUGK8hVj01fJ4 Subject: [Json] Working Group Last Call on draft-ietf-i-json-02 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, 01 Jul 2014 02:39:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This message begins the Working Group Last Call (WGLC) on "The I-JSON Message Format" < draft-ietf-json-i-json-02 >. WGLC will end in two weeks, on July 14. Please review the document and send comments to the Working Group mailing list < json at ietf.org > or the co-chairs before the end of the WGLC. Any and all comments on the document are sought in order to asses the strength of consensus. Even if you have read and commented on this or earlier versions of the draft, please feel free to comment again. As a reminder, comments can be anything from "this looks fine" to "this is a horrible idea"; they can include suggestions for minor editorial corrections to significant editorial changes. - -- Paul Hoffman and Matt Miller -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTsh9pAAoJEDWi+S0W7cO12mIH/iYK/dE8PDjD7kCXsIYeXTcM Zi+5dsByNVwfXxsYy4bR2kx+4RCawGUATESR6YrbuKsS52Xbmtg4S9k6rpWp5nS8 65DnRQ256hpxVFoHq68QNd36Bj4cJurBTHSmF4Ho1/q+2dpCLxCFjZW2Jap7yxE+ D/YJh1sZiyRTYrwSPtRyKTbi0OqzmJw64QIgrADEFzkGofrBPUdxr5aG014ARzbY eZjtDvI3BQkghwYXvDegwQDQzDTaX+m5NnjBhUpeOa6s7avO6DMg0Q1IgmToBpXV YsptEBGwlBAlVBtEWqNywonBP2Z6VRaW4jM6u7+o/M8gkDM57NckK0D1+nrV0yo= =wetX -----END PGP SIGNATURE----- From nobody Mon Jun 30 22:05: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 655111A0104 for ; Mon, 30 Jun 2014 22:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDEJUjkNZh_G for ; Mon, 30 Jun 2014 22:05:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9891A0100 for ; Mon, 30 Jun 2014 22:05:32 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.193.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A2F4922E255; Tue, 1 Jul 2014 01:05:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Mark Nottingham In-Reply-To: <53B21F69.7010101@cisco.com> Date: Tue, 1 Jul 2014 15:05:20 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <6CE9B079-6CAF-4A33-B126-23BB5F353897@mnot.net> References: <53B21F69.7010101@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/json/wA1auUroZh9RmJEqi4fWseqXIIg Cc: IETF JSON WG Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 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, 01 Jul 2014 05:05:35 -0000 In the Introduction of = : > RFC 7149 describes practices which may be used to avoid these = interoperability problems. I'm not sure how "Software-Defined Networking: A Perspective from within = a Service Provider Environment" does that... Cheers, On 1 Jul 2014, at 12:39 pm, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > This message begins the Working Group Last Call (WGLC) on "The I-JSON > Message Format" < draft-ietf-json-i-json-02 >. WGLC will end in two > weeks, on July 14. >=20 > Please review the document and send comments to the Working Group > mailing list < json at ietf.org > or the co-chairs tools.ietf.org > before the end of the WGLC. Any and all comments on > the document are sought in order to asses the strength of consensus. > Even if you have read and commented on this or earlier versions of the > draft, please feel free to comment again. >=20 > As a reminder, comments can be anything from "this looks fine" to > "this is a horrible idea"; they can include suggestions for minor > editorial corrections to significant editorial changes. >=20 >=20 > - -- Paul Hoffman and Matt Miller > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQEcBAEBCgAGBQJTsh9pAAoJEDWi+S0W7cO12mIH/iYK/dE8PDjD7kCXsIYeXTcM > Zi+5dsByNVwfXxsYy4bR2kx+4RCawGUATESR6YrbuKsS52Xbmtg4S9k6rpWp5nS8 > 65DnRQ256hpxVFoHq68QNd36Bj4cJurBTHSmF4Ho1/q+2dpCLxCFjZW2Jap7yxE+ > D/YJh1sZiyRTYrwSPtRyKTbi0OqzmJw64QIgrADEFzkGofrBPUdxr5aG014ARzbY > eZjtDvI3BQkghwYXvDegwQDQzDTaX+m5NnjBhUpeOa6s7avO6DMg0Q1IgmToBpXV > YsptEBGwlBAlVBtEWqNywonBP2Z6VRaW4jM6u7+o/M8gkDM57NckK0D1+nrV0yo=3D > =3DwetX > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jun 30 22:53: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 E29FD1A0166 for ; Mon, 30 Jun 2014 22:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBxfh00Mu_Fe for ; Mon, 30 Jun 2014 22:52:56 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A4B1A014D for ; Mon, 30 Jun 2014 22:52:56 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id dc16so7392824qab.15 for ; Mon, 30 Jun 2014 22:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2OXc+wQFU4DuIIZWsWpKNkL0tg9bOH/6NWDyHj7JWVo=; b=zFelpSd9F9lu0P9ihNa3VqR11aLm/tRyV0n8rVw2bmi7yCtDAd0CBZokL08v9Y7mVI jf5kfFLot/UnbxfVv4UAhujXXQB9bkhEw/QoThI+Wl/gHJjkLUuyY9QOaedirzNMji6o sph+0MWCeJOctF1Zt6kbp7VFTuhVJYJvn1TZUYjVDyrhH5OQS6PksZKWZjG+iW2wK4ld f5FFyN+srzKGHVtNmgMeXatveJHCRs+Gsx5kvnrPpj483tx12LLeImbm5PTIKPyelXnR Q6tNNZey/SQ6Njoo8NjKE3+9BVBm+YKWLJ669NUZsXUD106UZrZP+kJbTOsHhuUgzium 4Drw== MIME-Version: 1.0 X-Received: by 10.140.81.240 with SMTP id f103mr66899557qgd.47.1404193975706; Mon, 30 Jun 2014 22:52:55 -0700 (PDT) Received: by 10.140.36.139 with HTTP; Mon, 30 Jun 2014 22:52:55 -0700 (PDT) In-Reply-To: <6CE9B079-6CAF-4A33-B126-23BB5F353897@mnot.net> References: <53B21F69.7010101@cisco.com> <6CE9B079-6CAF-4A33-B126-23BB5F353897@mnot.net> Date: Mon, 30 Jun 2014 22:52:55 -0700 Message-ID: From: R S To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a11c13b521e2b9704fd1b6391 Archived-At: http://mailarchive.ietf.org/arch/msg/json/SgKqPD_cwg-o1jvWdKW4Liy7fSA Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 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, 01 Jul 2014 05:52:59 -0000 --001a11c13b521e2b9704fd1b6391 Content-Type: text/plain; charset=UTF-8 A bit of a troll, that. One reference in the introduction refers to RFC 71 *4* 9, rather than RFC 7159. It's a typo. - Rob On Mon, Jun 30, 2014 at 10:05 PM, Mark Nottingham wrote: > In the Introduction of < > https://tools.ietf.org/html/draft-ietf-json-i-json-02>: > > > RFC 7149 describes practices which may be used to avoid these > interoperability problems. > > I'm not sure how "Software-Defined Networking: A Perspective from within a > Service Provider Environment" does that... > > Cheers, > > > > On 1 Jul 2014, at 12:39 pm, Matt Miller wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > This message begins the Working Group Last Call (WGLC) on "The I-JSON > > Message Format" < draft-ietf-json-i-json-02 >. WGLC will end in two > > weeks, on July 14. > > > > Please review the document and send comments to the Working Group > > mailing list < json at ietf.org > or the co-chairs > tools.ietf.org > before the end of the WGLC. Any and all comments on > > the document are sought in order to asses the strength of consensus. > > Even if you have read and commented on this or earlier versions of the > > draft, please feel free to comment again. > > > > As a reminder, comments can be anything from "this looks fine" to > > "this is a horrible idea"; they can include suggestions for minor > > editorial corrections to significant editorial changes. > > > > > > - -- Paul Hoffman and Matt Miller > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > > Comment: GPGTools - https://gpgtools.org > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iQEcBAEBCgAGBQJTsh9pAAoJEDWi+S0W7cO12mIH/iYK/dE8PDjD7kCXsIYeXTcM > > Zi+5dsByNVwfXxsYy4bR2kx+4RCawGUATESR6YrbuKsS52Xbmtg4S9k6rpWp5nS8 > > 65DnRQ256hpxVFoHq68QNd36Bj4cJurBTHSmF4Ho1/q+2dpCLxCFjZW2Jap7yxE+ > > D/YJh1sZiyRTYrwSPtRyKTbi0OqzmJw64QIgrADEFzkGofrBPUdxr5aG014ARzbY > > eZjtDvI3BQkghwYXvDegwQDQzDTaX+m5NnjBhUpeOa6s7avO6DMg0Q1IgmToBpXV > > YsptEBGwlBAlVBtEWqNywonBP2Z6VRaW4jM6u7+o/M8gkDM57NckK0D1+nrV0yo= > > =wetX > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Mark Nottingham https://www.mnot.net/ > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c13b521e2b9704fd1b6391 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A bit of a troll, that.

One reference i= n the introduction refers to RFC 71 *4* 9, rather than RFC 7159. It's a= typo.

- Rob




On Mon, Jun 3= 0, 2014 at 10:05 PM, Mark Nottingham <mnot@mnot.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> In the Introduction of <https://tools.ietf.org/html/draft-ietf-= json-i-json-02>:

> RFC 7149 describes practices which may be used to avoid these interope= rability problems.

I'm not sure how "Software-Defined Networking: A Perspective from = within a Service Provider Environment" does that...

Cheers,



On 1 Jul 2014, at 12:39 pm, Matt Miller <mamille2@cisco.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> This message begins the =C2=A0Working Group Last Call (WGLC) on "= The I-JSON
> Message Format" < draft-ietf-json-i-json-02 >. WGLC will en= d in two
> weeks, on July 14.
>
> Please review the document and send comments to the Working Group
> mailing list < json at ietf.org > or the co-chairs <json-chairs at
> tools.ietf.org= > before the end of the WGLC. =C2=A0Any and all comments on
> the document are sought in order to asses the strength of consensus. > Even if you have read and commented on this or earlier versions of the=
> draft, please feel free to comment again.
>
> As a reminder, comments can be anything from "this looks fine&quo= t; to
> "this is a horrible idea"; they can include suggestions for = minor
> editorial corrections to significant editorial changes.
>
>
> - -- Paul Hoffman and Matt Miller
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJTsh9pAAoJEDWi+S0W7cO12mIH/iYK/dE8PDjD7kCXsIYeXTcM
> Zi+5dsByNVwfXxsYy4bR2kx+4RCawGUATESR6YrbuKsS52Xbmtg4S9k6rpWp5nS8
> 65DnRQ256hpxVFoHq68QNd36Bj4cJurBTHSmF4Ho1/q+2dpCLxCFjZW2Jap7yxE+
> D/YJh1sZiyRTYrwSPtRyKTbi0OqzmJw64QIgrADEFzkGofrBPUdxr5aG014ARzbY
> eZjtDvI3BQkghwYXvDegwQDQzDTaX+m5NnjBhUpeOa6s7avO6DMg0Q1IgmToBpXV
> YsptEBGwlBAlVBtEWqNywonBP2Z6VRaW4jM6u7+o/M8gkDM57NckK0D1+nrV0yo=3D
> =3DwetX
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

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




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

--001a11c13b521e2b9704fd1b6391-- From nobody Mon Jun 30 23:27: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 ECD9C1B27C9 for ; Mon, 30 Jun 2014 23:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-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 MOEiICEOSWYH for ; Mon, 30 Jun 2014 23:26:59 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0681B278C for ; Mon, 30 Jun 2014 23:26:59 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db11so9076598veb.40 for ; Mon, 30 Jun 2014 23:26:58 -0700 (PDT) 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=J9Z5MnnBy023NVcyylDtnrzoZHGadEViYrUcLtq9KG4=; b=Cyl2CK661YPdxLXaYXtkZaPzRIR+B5WW4q2OxFZRwVO3h/NJ65uekqoBCy00Rh+l5l OpW2PU3fmPP47n41m3bUkeYaSg8wxNQoNkQPoNCfeM4qfmWE8hkPQr5RATPd27WrO2Bm jgWsC0Vohs6isT/r60FUMiwpSX85C9HddrLjHOG1Y0dj41noNI6PNDCQEdSszGvzsfsg g5j3w1E6eOLKhm5f3lQd4gtSRcXQmaT59PZm94VhF0IqeX6oJzy1RGOgqkEMfoXI/FLz r2ruLSA3QSbB7hAawRIdpcMRAmEDI9Kmxb2d2r0ztPnTYLdbMfEMDcTSayBNs+liP2T1 dDZw== X-Gm-Message-State: ALoCoQmlUdb3Xmw15JDMAjBa37ulWq+rsqsmHiCSFBFdDn53jV/Lid2yw+l5l72g1S1wLLCpB5GQ MIME-Version: 1.0 X-Received: by 10.52.92.82 with SMTP id ck18mr35595346vdb.6.1404196018107; Mon, 30 Jun 2014 23:26:58 -0700 (PDT) Received: by 10.221.49.199 with HTTP; Mon, 30 Jun 2014 23:26:57 -0700 (PDT) X-Originating-IP: [209.121.225.213] Received: by 10.221.49.199 with HTTP; Mon, 30 Jun 2014 23:26:57 -0700 (PDT) In-Reply-To: <6CE9B079-6CAF-4A33-B126-23BB5F353897@mnot.net> References: <53B21F69.7010101@cisco.com> <6CE9B079-6CAF-4A33-B126-23BB5F353897@mnot.net> Date: Mon, 30 Jun 2014 23:26:57 -0700 Message-ID: From: Tim Bray To: Mark Nottingham Content-Type: multipart/alternative; boundary=bcaec501674ddad0c704fd1bdcfd Archived-At: http://mailarchive.ietf.org/arch/msg/json/8lx7puJTD0Mtf_jl8t6GA2vae1M Cc: "Matt Miller, \(mamille2\)" , json@ietf.org Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 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, 01 Jul 2014 06:27:01 -0000 --bcaec501674ddad0c704fd1bdcfd Content-Type: text/plain; charset=UTF-8 Clearly you're not up to date with current Enterprise Technology Synergies. On Jun 30, 2014 10:05 PM, "Mark Nottingham" wrote: > In the Introduction of < > https://tools.ietf.org/html/draft-ietf-json-i-json-02>: > > > RFC 7149 describes practices which may be used to avoid these > interoperability problems. > > I'm not sure how "Software-Defined Networking: A Perspective from within a > Service Provider Environment" does that... > > Cheers, > > > > On 1 Jul 2014, at 12:39 pm, Matt Miller wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > This message begins the Working Group Last Call (WGLC) on "The I-JSON > > Message Format" < draft-ietf-json-i-json-02 >. WGLC will end in two > > weeks, on July 14. > > > > Please review the document and send comments to the Working Group > > mailing list < json at ietf.org > or the co-chairs > tools.ietf.org > before the end of the WGLC. Any and all comments on > > the document are sought in order to asses the strength of consensus. > > Even if you have read and commented on this or earlier versions of the > > draft, please feel free to comment again. > > > > As a reminder, comments can be anything from "this looks fine" to > > "this is a horrible idea"; they can include suggestions for minor > > editorial corrections to significant editorial changes. > > > > > > - -- Paul Hoffman and Matt Miller > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > > Comment: GPGTools - https://gpgtools.org > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iQEcBAEBCgAGBQJTsh9pAAoJEDWi+S0W7cO12mIH/iYK/dE8PDjD7kCXsIYeXTcM > > Zi+5dsByNVwfXxsYy4bR2kx+4RCawGUATESR6YrbuKsS52Xbmtg4S9k6rpWp5nS8 > > 65DnRQ256hpxVFoHq68QNd36Bj4cJurBTHSmF4Ho1/q+2dpCLxCFjZW2Jap7yxE+ > > D/YJh1sZiyRTYrwSPtRyKTbi0OqzmJw64QIgrADEFzkGofrBPUdxr5aG014ARzbY > > eZjtDvI3BQkghwYXvDegwQDQzDTaX+m5NnjBhUpeOa6s7avO6DMg0Q1IgmToBpXV > > YsptEBGwlBAlVBtEWqNywonBP2Z6VRaW4jM6u7+o/M8gkDM57NckK0D1+nrV0yo= > > =wetX > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Mark Nottingham https://www.mnot.net/ > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --bcaec501674ddad0c704fd1bdcfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Clearly you're not up to date with current Enterprise Te= chnology Synergies.

On Jun 30, 2014 10:05 PM, "Mark Nottingham&= quot; <mnot@mnot.net> wrote:
In the Introduction of <https://tools.ietf.org/html/draft-ietf-= json-i-json-02>:

> RFC 7149 describes practices which may be used to avoid these interope= rability problems.

I'm not sure how "Software-Defined Networking: A Perspective from = within a Service Provider Environment" does that...

Cheers,



On 1 Jul 2014, at 12:39 pm, Matt Miller <mamille2@cisco.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> This message begins the =C2=A0Working Group Last Call (WGLC) on "= The I-JSON
> Message Format" < draft-ietf-json-i-json-02 >. WGLC will en= d in two
> weeks, on July 14.
>
> Please review the document and send comments to the Working Group
> mailing list < json at ietf.org > or the co-chairs <json-chairs at
> tools.ietf.org= > before the end of the WGLC. =C2=A0Any and all comments on
> the document are sought in order to asses the strength of consensus. > Even if you have read and commented on this or earlier versions of the=
> draft, please feel free to comment again.
>
> As a reminder, comments can be anything from "this looks fine&quo= t; to
> "this is a horrible idea"; they can include suggestions for = minor
> editorial corrections to significant editorial changes.
>
>
> - -- Paul Hoffman and Matt Miller
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJTsh9pAAoJEDWi+S0W7cO12mIH/iYK/dE8PDjD7kCXsIYeXTcM
> Zi+5dsByNVwfXxsYy4bR2kx+4RCawGUATESR6YrbuKsS52Xbmtg4S9k6rpWp5nS8
> 65DnRQ256hpxVFoHq68QNd36Bj4cJurBTHSmF4Ho1/q+2dpCLxCFjZW2Jap7yxE+
> D/YJh1sZiyRTYrwSPtRyKTbi0OqzmJw64QIgrADEFzkGofrBPUdxr5aG014ARzbY
> eZjtDvI3BQkghwYXvDegwQDQzDTaX+m5NnjBhUpeOa6s7avO6DMg0Q1IgmToBpXV
> YsptEBGwlBAlVBtEWqNywonBP2Z6VRaW4jM6u7+o/M8gkDM57NckK0D1+nrV0yo=3D
> =3DwetX
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

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




_______________________________________________
json mailing list
json@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/json
--bcaec501674ddad0c704fd1bdcfd-- From nobody Mon Jun 30 23:27: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 A9F5E1B27C9 for ; Mon, 30 Jun 2014 23:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWzm7Bwqm2xv for ; Mon, 30 Jun 2014 23:27:43 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0AD1B27C7 for ; Mon, 30 Jun 2014 23:27:43 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.193.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AE25922E2CE; Tue, 1 Jul 2014 02:27:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Mark Nottingham In-Reply-To: Date: Tue, 1 Jul 2014 16:27:36 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53B21F69.7010101@cisco.com> <6CE9B079-6CAF-4A33-B126-23BB5F353897@mnot.net> To: Tim Bray X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/json/9HTlg8U60d2J0tiRjHmvIBsMPNQ Cc: "Matt Miller, \(mamille2\)" , json@ietf.org Subject: Re: [Json] Working Group Last Call on draft-ietf-i-json-02 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, 01 Jul 2014 06:27:46 -0000 Alas, I left that world behind...=20 /me sheds a single tear On 1 Jul 2014, at 4:26 pm, Tim Bray wrote: > Clearly you're not up to date with current Enterprise Technology = Synergies. >=20 > On Jun 30, 2014 10:05 PM, "Mark Nottingham" wrote: > In the Introduction of = : >=20 > > RFC 7149 describes practices which may be used to avoid these = interoperability problems. >=20 > I'm not sure how "Software-Defined Networking: A Perspective from = within a Service Provider Environment" does that... >=20 > Cheers, >=20 >=20 >=20 > On 1 Jul 2014, at 12:39 pm, Matt Miller wrote: >=20 > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > This message begins the Working Group Last Call (WGLC) on "The = I-JSON > > Message Format" < draft-ietf-json-i-json-02 >. WGLC will end in two > > weeks, on July 14. > > > > Please review the document and send comments to the Working Group > > mailing list < json at ietf.org > or the co-chairs > tools.ietf.org > before the end of the WGLC. Any and all comments = on > > the document are sought in order to asses the strength of consensus. > > Even if you have read and commented on this or earlier versions of = the > > draft, please feel free to comment again. > > > > As a reminder, comments can be anything from "this looks fine" to > > "this is a horrible idea"; they can include suggestions for minor > > editorial corrections to significant editorial changes. > > > > > > - -- Paul Hoffman and Matt Miller > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > > Comment: GPGTools - https://gpgtools.org > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iQEcBAEBCgAGBQJTsh9pAAoJEDWi+S0W7cO12mIH/iYK/dE8PDjD7kCXsIYeXTcM > > Zi+5dsByNVwfXxsYy4bR2kx+4RCawGUATESR6YrbuKsS52Xbmtg4S9k6rpWp5nS8 > > 65DnRQ256hpxVFoHq68QNd36Bj4cJurBTHSmF4Ho1/q+2dpCLxCFjZW2Jap7yxE+ > > D/YJh1sZiyRTYrwSPtRyKTbi0OqzmJw64QIgrADEFzkGofrBPUdxr5aG014ARzbY > > eZjtDvI3BQkghwYXvDegwQDQzDTaX+m5NnjBhUpeOa6s7avO6DMg0Q1IgmToBpXV > > YsptEBGwlBAlVBtEWqNywonBP2Z6VRaW4jM6u7+o/M8gkDM57NckK0D1+nrV0yo=3D > > =3DwetX > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham https://www.mnot.net/