From nobody Wed Apr 2 13:00: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 7047E1A03A9 for ; Wed, 2 Apr 2014 13:00:31 -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 ra8TPYS_OUCX for ; Wed, 2 Apr 2014 13:00:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 444A51A03C2 for ; Wed, 2 Apr 2014 13:00:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140402200022.20776.77683.idtracker@ietfa.amsl.com> Date: Wed, 02 Apr 2014 13:00:22 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/PFIw_7vMK6Or0NAqUZPJDz9aNVY Subject: [Json] State changed: charter-ietf-json-01-01 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 20:00:31 -0000 State changed to Internal review. URL: http://datatracker.ietf.org/doc/charter-ietf-json/ From nobody Wed Apr 2 13:13:28 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3252B1A03CD; Wed, 2 Apr 2014 13:13:24 -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 nUeGZ_N4hwDJ; Wed, 2 Apr 2014 13:13:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 510AC1A039C; Wed, 2 Apr 2014 13:13:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140402201319.14893.23931.idtracker@ietfa.amsl.com> Date: Wed, 02 Apr 2014 13:13:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/MG5wrRxR3o-xWxtnsUpwdfiroqA Cc: json@ietf.org Subject: [Json] Pete Resnick's Yes on charter-ietf-json-01-01: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 20:13:24 -0000 Pete Resnick has entered the following ballot position for charter-ietf-json-01-01: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am ambivalent about external review. On the one hand, these activities are really IETF internal. On the other, we've been trying to develop a liaison relationship with Ecma. Input on this question welcome. From nobody Wed Apr 2 13:17:07 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174EB1A03C3; Wed, 2 Apr 2014 13:17:02 -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 bBkvG0n0gp0G; Wed, 2 Apr 2014 13:16:57 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AB3611A039C; Wed, 2 Apr 2014 13:16:56 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id c9so826462qcz.30 for ; Wed, 02 Apr 2014 13:16:52 -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=q/qBOmVLdOZIMxhyc7jA2bMQ1qXbnTEyqImvnwEsaOw=; b=Gfk+n0YbzbDuS55tujcZmQWCXKh8C3v3Gal3oZqNwzU1PEjWO81ftR63gimm44Egrb Nyjd2RyiGyXHWoj4xYWPf2h/jXKW2W7a3+u4OoHnOwmA67SAxPecvMa/JoDDhnYzMWm0 rKh8ez9/G4V1g4B2Nm8obWEapvVSYvxGRp70vNuaJoDCgxrxmQQ8AqsEdIztVWkbA8Uh DNDrA6R7Zfp9179zLHBd9VGDah2psDFzVPhbMPSqx+7dPOdDhSW+ZsLSXPPtgn6yGihH z6aMap96z7LDJmRnaIdYJa70clPdPNsxLxuNJpfkcI4p4EFFCHX0oQrWTY90wIhnPLv7 /UGA== MIME-Version: 1.0 X-Received: by 10.140.93.22 with SMTP id c22mr2802623qge.53.1396469812513; Wed, 02 Apr 2014 13:16:52 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.136.134 with HTTP; Wed, 2 Apr 2014 13:16:52 -0700 (PDT) In-Reply-To: <20140402201319.14893.23931.idtracker@ietfa.amsl.com> References: <20140402201319.14893.23931.idtracker@ietfa.amsl.com> Date: Wed, 2 Apr 2014 16:16:52 -0400 X-Google-Sender-Auth: CjLY40N8No_FuDRidy8meOzS6uE Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Or3FPegnfu044BYzRk44aUU6uGg Cc: The IESG , "json@ietf.org" Subject: Re: [Json] Pete Resnick's Yes on charter-ietf-json-01-01: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 20:17:02 -0000 > I am ambivalent about external review. On the one hand, these activities > are really IETF internal. On the other, we've been trying to develop a > liaison relationship with Ecma. Input on this question welcome. Given what's happened with Ecma and what we're trying to make happen, I think it would be a mistake not to loop them in. On the other hand: are they even on new-work? External review won't be sufficient -- an explicit message to Ecma inviting their review would be needed. Barry From nobody Wed Apr 2 13:29: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 D12451A03D7 for ; Wed, 2 Apr 2014 13:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04BxKDNUHf9m for ; Wed, 2 Apr 2014 13:29:53 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id F3E341A03D4 for ; Wed, 2 Apr 2014 13:29:49 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id lf12so1083623vcb.25 for ; Wed, 02 Apr 2014 13:29:45 -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=4uvB7ES8OLbY2JWYXstoOD+4X3wIX7xy/F9TX5sEfC0=; b=jE6VHLkUGh6WFgCvpmA7emL4o1Ew0jOomlW6aMJHANoEWVfcVI28ckiQVwIjtX1DG3 GcMKE+SMvzLv9++W1mYU4KG1RE5IXSng8JLaz1gRAbeynaPfdwDn/e/JuuwvtbUmyuTc TDYRYiU1DAbfHx7MagGMRDBTV+OyWwfH0kwEEdKO0oYooKZ5/njjMPSmRAV9ysJKwfjG zszbT9sZ/VKXybr6fSIY55fWWFkwxxTbHSfzDg9gFCeX7KLJD76nVPwdX9g2Po4xXNxn TsBpRvUGwpRzp6TzbH5ctfGd6tLY6evHbhRTLlfQeIQWqYgvsJqsDG0mifldXu1xro4R 6d9w== X-Gm-Message-State: ALoCoQmSdtuF4vZjFsD2Ijm4FNm0e6fY8Ddq9wfE2xG5/BjxAHGQ4CV+F18C+HHkDL93zHFdRDgo X-Received: by 10.52.119.197 with SMTP id kw5mr2934477vdb.5.1396470585791; Wed, 02 Apr 2014 13:29:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Wed, 2 Apr 2014 13:29:24 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <20140402201319.14893.23931.idtracker@ietfa.amsl.com> From: Tim Bray Date: Wed, 2 Apr 2014 13:29:24 -0700 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/4IfoyeZeeccwWuK5Pn6paCaQe9Y Cc: Pete Resnick , The IESG , "json@ietf.org" Subject: Re: [Json] Pete Resnick's Yes on charter-ietf-json-01-01: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 20:29:57 -0000 +1 on explicit invitation. I wouldn=E2=80=99t be surprised if it didn=E2= =80=99t get much/any reaction, but there=E2=80=99s nothing to lose. On Wed, Apr 2, 2014 at 1:16 PM, Barry Leiba wrote= : >> I am ambivalent about external review. On the one hand, these activities >> are really IETF internal. On the other, we've been trying to develop a >> liaison relationship with Ecma. Input on this question welcome. > > Given what's happened with Ecma and what we're trying to make happen, > I think it would be a mistake not to loop them in. On the other hand: > are they even on new-work? External review won't be sufficient -- an > explicit message to Ecma inviting their review would be needed. > > Barry > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Fri Apr 4 07:33:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B0D1A01B5; Fri, 4 Apr 2014 07:33:18 -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 N-Tml4ke9yTQ; Fri, 4 Apr 2014 07:33:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D4B1A0152; Fri, 4 Apr 2014 07:33:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140404143313.3319.82104.idtracker@ietfa.amsl.com> Date: Fri, 04 Apr 2014 07:33:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/DUzSDRr1p8krqyZ5O2oGBrE3c2w Cc: json@ietf.org Subject: [Json] Brian Haberman's No Objection on charter-ietf-json-01-01: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 14:33:18 -0000 Brian Haberman has entered the following ballot position for charter-ietf-json-01-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- To answer Pete's question, I think it would be "nice" to inform Ecma of this pending re-chartering. I do not know all the politics of the interactions, but it seems that such notification could be seen as a sign of willingness on behalf of the IETF to work with them. Can I assume that Ecma is not on the new-work list? From nobody Tue Apr 8 09:22: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 50C371A04FA; Tue, 8 Apr 2014 09:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 xVemW7wW5PcQ; Tue, 8 Apr 2014 09:22:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD871A0484; Tue, 8 Apr 2014 09:22:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140408162237.4321.65178.idtracker@ietfa.amsl.com> Date: Tue, 08 Apr 2014 09:22:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/lj5bCsYY-HueAcuDeI73xsQzeP4 Cc: json@ietf.org Subject: [Json] Spencer Dawkins' No Objection on charter-ietf-json-01-01: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:22:39 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-json-01-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I wish all charters were this short. I salute you all. I looked at the draft that will be used as a starting point, and didn't see a list of interoperability issues ("what problem are we trying to solve?"). Are those issues well known in the community, so there's no reason to write them down? Is anyone likely to raise issues that aren't addressed in the current draft? From nobody Wed Apr 9 08:05: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 7A5D01A069B; Tue, 8 Apr 2014 16:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] 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 JRMkYCgXomps; Tue, 8 Apr 2014 16:27:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5791B1A02AE; Tue, 8 Apr 2014 16:27:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140408232710.12099.32393.idtracker@ietfa.amsl.com> Date: Tue, 08 Apr 2014 16:27:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/pHTLALKiiawT8sGYyCq-bBrAZns X-Mailman-Approved-At: Wed, 09 Apr 2014 08:05:33 -0700 Cc: json@ietf.org Subject: [Json] Alissa Cooper's No Objection on charter-ietf-json-01-01: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 23:27:12 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-json-01-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think giving Ecma a heads-up is a good idea. From nobody Wed Apr 9 10:11:47 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D4B1A03F7; Wed, 9 Apr 2014 10:11:38 -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 UbVGhRdFIpZK; Wed, 9 Apr 2014 10:11:34 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B95B71A03D5; Wed, 9 Apr 2014 10:11:34 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s39HBVaW054955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2014 10:11:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20140408162237.4321.65178.idtracker@ietfa.amsl.com> Date: Wed, 9 Apr 2014 10:11:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140408162237.4321.65178.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/-WwXU2ZTW-uzKxeLuvQ4uN4FDo4 Cc: The IESG , json@ietf.org Subject: Re: [Json] Spencer Dawkins' No Objection on charter-ietf-json-01-01: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 17:11:39 -0000 On Apr 8, 2014, at 9:22 AM, Spencer Dawkins = wrote: > Spencer Dawkins has entered the following ballot position for > charter-ietf-json-01-01: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-json/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I wish all charters were this short. I salute you all. >=20 > I looked at the draft that will be used as a starting point, and = didn't > see a list of interoperability issues ("what problem are we trying to > solve?").=20 >=20 > Are those issues well known in the community, so there's no reason to > write them down? >=20 > Is anyone likely to raise issues that aren't addressed in the current > draft? Wearing my chair hat: - The current draft discusses each interoperability problem it = addresses, but not as a single list at the front. - We have no idea if people will bring up new issues for the draft, but = of course it is fine if they do. --Paul Hoffman= From nobody Wed Apr 9 13:41:37 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8CC1A0321; Wed, 9 Apr 2014 13:41:34 -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 9Mmw9XbE9YUN; Wed, 9 Apr 2014 13:41:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0003D1A02B3; Wed, 9 Apr 2014 13:41:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140409204133.31563.90091.idtracker@ietfa.amsl.com> Date: Wed, 09 Apr 2014 13:41:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/_yRmf_x7J9Gwm-t3e1CkFNUvrlI Cc: json@ietf.org Subject: [Json] Ted Lemon's No Objection on charter-ietf-json-01-01: (with COMMENT) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:41:35 -0000 Ted Lemon has entered the following ballot position for charter-ietf-json-01-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-json/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I suspect I know what a streamable sequence of JSON texts is, but it's a bit unclear, and would be nice if it were stated in a tiny bit more detail. From nobody Fri Apr 11 14:10: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 9380F1A02FA; Fri, 11 Apr 2014 14:10:34 -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 8Uo8DP_ZFmY1; Fri, 11 Apr 2014 14:10:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EFA1A02EA; Fri, 11 Apr 2014 14:10:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140411211021.21946.59726.idtracker@ietfa.amsl.com> Date: Fri, 11 Apr 2014 14:10:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/htBdlYuibZoQ-E-UP--LOolXl2Y Cc: json WG Subject: [Json] WG Review: JavaScript Object Notation (json) 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, 11 Apr 2014 21:10:34 -0000 The JavaScript Object Notation (json) working group in the Applications Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-04-21. JavaScript Object Notation (json) ------------------------------------------------ Current Status: Active WG Chairs: Matthew Miller Paul Hoffman Assigned Area Director: Pete Resnick Mailing list Address: json@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/json Archive: http://www.ietf.org/mail-archive/web/json/ Charter: Javascript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard, and is published in RFC 7159. The WG will work on an restricted profile of JSON designed to maximize interoperability. The work will start from draft-bray-i-json-01. The WG will work on a format for a streamable sequence of JSON texts. The work will start from draft-williams-json-text-sequence-00. Milestones: Jun 2014 - IETF Last Call for restricted profile Jun 2014 - IETF Last Call for text sequences From nobody Fri Apr 11 14:15: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 767A81A02FA for ; Fri, 11 Apr 2014 14:15:20 -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 kRbqBsu7DXYQ for ; Fri, 11 Apr 2014 14:15:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F201A02F4 for ; Fri, 11 Apr 2014 14:15:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140411211518.19400.36006.idtracker@ietfa.amsl.com> Date: Fri, 11 Apr 2014 14:15:18 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/s5KHYgnJXm2CrWJsCL76bRRcM6Y Subject: [Json] State changed: charter-ietf-json-01-01 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, 11 Apr 2014 21:15:20 -0000 State changed to External review. URL: http://datatracker.ietf.org/doc/charter-ietf-json/ From nobody Tue Apr 22 06:47: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 935341A047E for ; Tue, 22 Apr 2014 06:47:07 -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 fs6Fq16hzcvl for ; Tue, 22 Apr 2014 06:47:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E97591A0441 for ; Tue, 22 Apr 2014 06:47:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: json@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140422134703.4494.6818.idtracker@ietfa.amsl.com> Date: Tue, 22 Apr 2014 06:47:03 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/json/QfB63sD1DgyZz8t-MWinPqbrAtY Subject: [Json] State changed: charter-ietf-json-01-01 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 13:47:07 -0000 State changed to IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-json/ From nobody Fri Apr 25 08:16:54 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31F21A0535; Fri, 25 Apr 2014 08:16:48 -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 PEYaOvJkqu4S; Fri, 25 Apr 2014 08:16:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 821DE1A0522; Fri, 25 Apr 2014 08:16:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140425151644.27331.5605.idtracker@ietfa.amsl.com> Date: Fri, 25 Apr 2014 08:16:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/BF6_rI3TM3mkBWKw81wcIwJ_tHw Cc: json WG Subject: [Json] WG Action: Rechartered JavaScript Object Notation (json) 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, 25 Apr 2014 15:16:49 -0000 The JavaScript Object Notation (json) working group in the Applications Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. JavaScript Object Notation (json) ------------------------------------------------ Current Status: Active WG Chairs: Matthew Miller Paul Hoffman Assigned Area Director: Pete Resnick Mailing list Address: json@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/json Archive: http://www.ietf.org/mail-archive/web/json/ Charter: Javascript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard, and is published in RFC 7159. The WG will work on an restricted profile of JSON designed to maximize interoperability. The work will start from draft-bray-i-json-01. The WG will work on a format for a streamable sequence of JSON texts. The work will start from draft-williams-json-text-sequence-00. Milestones: Jun 2014 - IETF Last Call for restricted profile Jun 2014 - IETF Last Call for text sequences From nobody Mon Apr 28 10:34: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 3FC351A6FE9; Mon, 28 Apr 2014 10:34:28 -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 yGjOLbWkQ8C7; Mon, 28 Apr 2014 10:34:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 240861A6F8E; Mon, 28 Apr 2014 10:34:27 -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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428173427.19994.76980.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 10:34:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/vpn4SpiNsjdGVdMaHMaRBBr22Og Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-text-sequence-00.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, 28 Apr 2014 17:34:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JavaScript Object Notation Working Group of the IETF. Title : JavaScript Object Notation (JSON) Text Sequences Author : Nicolas Williams Filename : draft-ietf-json-text-sequence-00.txt Pages : 8 Date : 2014-04-28 Abstract: This document describes the JSON text sequence format and associated media type. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-json-text-sequence-00 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 Apr 28 10:57: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 6A0871A6FC0 for ; Mon, 28 Apr 2014 10:57:20 -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 PcR1aot6MugT for ; Mon, 28 Apr 2014 10:57:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D31331A6F8E for ; Mon, 28 Apr 2014 10:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1262; q=dns/txt; s=iport; t=1398707837; x=1399917437; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=o6oAhsrw97LTQuZ54MiYjTchj1nJeNk6d2ZLCFBUYds=; b=Mk8SVAUWr2D6Pg/0W/rEL6k+6mEXGghOQXq1p/xoyJ5YiXMxwAziTdxI pUxuAN4P9zs0QdfaDSRUhNcRgGxkGeguOMN+5RhRNt3e+YMbrzbi7nFQu bian5xzT8C72dj2YbrsWm2jhxvMzYBTLD1guC7US6X6ipVqHRGnet4H9s w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0FAMSVXlOtJA2I/2dsb2JhbABZgwZPV6pfCgEBAQEBBAGbDxZ0gklbPRYYAwIBAgFLDQgBAYg9lSuzGBeFWo0/BIk3Oo8bkl6DUIIM X-IronPort-AV: E=Sophos;i="4.97,945,1389744000"; d="scan'208";a="320953214" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP; 28 Apr 2014 17:57:17 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3SHvHqQ003048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Apr 2014 17:57:18 GMT Received: from MAMILLE2-M-T03K.local (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Apr 2014 12:57:17 -0500 Message-ID: <535E967D.6040109@cisco.com> Date: Mon, 28 Apr 2014 11:57:17 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.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.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/json/m7b5-5HQVj69FUn27S11WxTUBLI Subject: [Json] New Charter and Next Steps X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 17:57:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, As announced earlier, the new Working Group charter is approved! The text-sequence WG draft has just been submitted; Tim, please submit the I-JSON WG draft at your convenience. Discussion is actively encouraged! The current milestones are: Jun 2014 - IETF Last Call for restricted profile Jun 2014 - IETF Last Call for text sequences This means Working Group Last Call for both documents should happen next month (May). Does the Working Group believe this schedule is still realistic, or is it too aggressive? Thanks, - -- 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/ iQEcBAEBCgAGBQJTXpZ9AAoJEDWi+S0W7cO1+PgIALQ8YbMHkA5H5ZezSXsX1XC+ XAZvf/4nEv6+foWhvtwXol1KjTUsC4lkkkv1qPJWcXg/jQKB6hl5x6WsgkrvCbSI B1OAYkgfEXF/nUXzPDsdsNZtgvUIa8ORF1PwUk4Bi92IeodRw07IeHmr+gOIrTrH 2iwEzGLyfdbd/0FP2EzbndNOgG53dEx+7SvN/kePMaqLO0R6qXCpdpAIq0qT+QvJ B3k81DHsYPmX+CmW4jD37UOMiX3dg7p8FLb6IeOiSiUzSD69G3lrutYGUfGdkXFp VdyDLHGwOtygH/8UbHfD8VWe+opGkGBXuQyx2WEwnPutiexsEpW2m79rEYn3kBA= =4Vyh -----END PGP SIGNATURE----- From nobody Mon Apr 28 11:16: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 28A9A1A6F39 for ; Mon, 28 Apr 2014 11:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsaBCJw4ermM for ; Mon, 28 Apr 2014 11:16:50 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 951BC1A04F1 for ; Mon, 28 Apr 2014 11:16:50 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id lh4so1829444vcb.34 for ; Mon, 28 Apr 2014 11:16: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:from:date:message-id:subject:to :content-type; bh=0kOcpJAM+tqJfvFBZiFAs5mtZe8giVgZ/x7I7wajGh4=; b=CqtGaiE0p1LqGpoEpDrJpy9QcR1NlSa9YXc0x4JI9ARSkLIzcdSLh8U5upXow5oArd wjc4FOAksi9SA3dRto353aHA2+xBYgwUdpCuKWjk1iP1alXPPxF2uo5S5h0TgBbDiuys XD63ohCHzovG4fLkl8c6IWiXwx7zpBoYBAQk4oEzJn2V5+SpHyvDuGfa7mSASqxuK4cp qxdKGtqfJQvZ7WgHHZcl8GTBCV5TSnVTzBW2hiqU1rt+7irfQe2XMXJxyuSZeTPUiDMJ RHP6Plrfm6/wTSW7KPmQE6yUxPmnEnkvRCoZVgs2BvguSO+eczaKPv+ceBElVZWmrI+g UdZQ== X-Gm-Message-State: ALoCoQlhl7tIanaYe3tzphp5YK5nbLWUoSB0HlhCphi8Cds2HCTZvsNAL9whApAa9ffCM4TRR6oS X-Received: by 10.52.134.202 with SMTP id pm10mr312341vdb.55.1398709009656; Mon, 28 Apr 2014 11:16:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Mon, 28 Apr 2014 11:16:29 -0700 (PDT) X-Originating-IP: [96.49.81.176] From: Tim Bray Date: Mon, 28 Apr 2014 11:16:29 -0700 Message-ID: To: "json@ietf.org" Content-Type: multipart/alternative; boundary=bcaec5299f9baa445704f81e518e Archived-At: http://mailarchive.ietf.org/arch/msg/json/9TK24BUnmQTT3ozKw4mRp3GW0sA Subject: [Json] How to argue about I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:16:52 -0000 --bcaec5299f9baa445704f81e518e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is an attempt to leap in front of the debate, use the take-aways from the very useful London f2f, and make our time arguing about I-JSON maximally =E2=80=8Bproductive . There are plenty of bikesheds out there, but I think the number of useful arguments is limited and the issues in them pretty clear. Argument 1 - Media types? Should there be an I-JSON media type, or a application/*+i-json suffix? draft i-json-01 calls for it, but this is at best controversial. My suggestion is that people who still think this is a good idea =E2=80=8Bneed to speak up. (I won=E2=80=99t.) Argument 2 - Top-level draft-i-json-01 says the top level is an object (but doesn=E2=80=99t say MU= ST, eek). I have heard arguments for allowing arrays too=E2=80=8B; anyone who = thinks that is a good idea should speak up. (I won=E2=80=99t.) Argument 3 - Unicode draft-i-json-01 excludes the use of, and I quote, =E2=80=9CSurrogates or Noncharacters=E2=80=9D. Is that the right use of Unicode nomenclature? T= his really matters and I think it=E2=80=99s OK now, but first-class Unicode law= yering is required here. Argument 4 - Software behavior Section 3 of draft-json-01 implies draconian error handling - when a message is specified to be i-json but the receiver finds, for example, a dupe key, it is required to halt and catch fire. There=E2=80=99s a chance t= hat this will be interpreted as =E2=80=9Ctbray poisons JSON with XML draconianism=E2= =80=9D. People with alternate language should suggest it. (I probably won=E2=80=99t argue = this one either way.) Argument 5 - Numbers draft-i-json-01 says that you MUST not put in a string representing a number with greater precision/magnitude than IEEE754 doubles can support. I think this is a good idea but I'm a little nervous because I=E2=80=99ve n= ever written the code, if this is unreasonably hard at either the sending or receiving end someone should say so. ...... aaaaaaand, that=E2=80=99s all folks. I=E2=80=99m optimistic that w= e can zero in on this one quickly. --bcaec5299f9baa445704f81e518e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is an attempt to leap in front of the debate, use the= take-aways from the very useful London f2f, and make our time arguing abou= t I-JSON maximally
=E2=80=8Bproductive
. =C2=A0There are plenty of bikesheds out there, b= ut I think the number of useful arguments is limited and the issues in them= pretty clear.

Argument 1 - Media types?

<= /div>
Should there be an I-JSON media type, or a application/*+i-json suffix? =C2= =A0draft i-json-01 calls for it, but this is at best controversial. =C2=A0M= y suggestion is that people who still think this is a good idea=C2=A0
=E2=80=8Bneed to speak up. =C2=A0(I won=E2=80=99t.)

Argument 2 - Top-level

draft-i-json-01 says the top level is an object (but = doesn=E2=80=99t say MUST, eek). =C2=A0I have heard arguments for allowing a= rrays too=E2=80=8B; anyone who thinks that is a good idea should speak up. = (I won=E2=80=99t.)

Argument 3 - Unicode

draft-i-json-01 excludes the use of, and I quote, =E2=80=9C= Surrogates or Noncharacters=E2=80=9D. =C2=A0 Is that the right use of Unico= de nomenclature? =C2=A0This really matters and I think it=E2=80=99s OK now,= but first-class Unicode lawyering is required here.

Argument 4 - Software behavior

Section 3 of draft-json-01 implies draconian error handling= - when a message is specified to be i-json but the receiver finds, for exa= mple, a dupe key, it is required to halt and catch fire. There=E2=80=99s a = chance that this will be interpreted as =E2=80=9Ctbray poisons JSON with XM= L draconianism=E2=80=9D. People with alternate language should suggest it. = (I probably won=E2=80=99t argue this one either way.)

Argument 5 - Numbers

draft-i-json-01 says that you MUST not put in a string repr= esenting a number with greater precision/magnitude than IEEE754 doubles can= support. =C2=A0 I think this is a good idea but I'm a little nervous b= ecause I=E2=80=99ve never written the code, if this is unreasonably hard at= either the sending or receiving end someone should =C2=A0say so.

...... aaaaaaand, that=E2=80=99s all folks. =C2=A0 I= =E2=80=99m optimistic that we can zero in on this one quickly.
--bcaec5299f9baa445704f81e518e-- From nobody Mon Apr 28 11:53: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 9A2EB1A700A for ; Mon, 28 Apr 2014 11:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVoo_7GG8Qpu for ; Mon, 28 Apr 2014 11:53:18 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4FABF1A6FF4 for ; Mon, 28 Apr 2014 11:53:16 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id z11so4029457lbi.40 for ; Mon, 28 Apr 2014 11:53:15 -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:content-transfer-encoding; bh=dFIpUUcjq3yAgJP4TmzdkVY7hQhb6r5OOUEqxFgc8Jc=; b=b68L2f0S+H7Mr0AF0YRAWB4l9Bg5Q1y6aXilX5AdJ40r+N05xxELrIk0gpk5H0HdYf Vg7amQO5CJxCFHbBl242Hk33YCkGw6MkDpkvpK9wCZzxJNzRL4S/+8eel26AtAEWmtFG z2Tx9dMjtC8PlygGhf7H1zbo/ly1YDTG9RSUh655NcT7qlBY8G52kesVzqdF7p1PPZDc JCaHu51XFCihmOZ1Q0sVKLAIzmERk6uJ+aG9WhVowyqUcFZtP/mZsf8+hX4cIE8colnq tqoAqFUZoFa18wviw9X2RvT4rcMCIlyTsG4h/O/g0aAj24vGKryMCAQkilVTeYtv60dd R+tA== MIME-Version: 1.0 X-Received: by 10.152.203.168 with SMTP id kr8mr2482130lac.17.1398711194836; Mon, 28 Apr 2014 11:53:14 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Mon, 28 Apr 2014 11:53:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Apr 2014 14:53:14 -0400 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/43_yZmPPZrWrmZgRYpfBPp4jpHo Cc: "json@ietf.org" Subject: Re: [Json] How to argue about I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:53:21 -0000 On Mon, Apr 28, 2014 at 2:16 PM, Tim Bray wrote: > This is an attempt to leap in front of the debate, use the take-aways fro= m > the very useful London f2f, and make our time arguing about I-JSON maxima= lly > productive > . There are plenty of bikesheds out there, but I think the number of use= ful > arguments is limited and the issues in them pretty clear. > > Argument 1 - Media types? > > Should there be an I-JSON media type, or a application/*+i-json suffix? > draft i-json-01 calls for it, but this is at best controversial. My > suggestion is that people who still think this is a good idea > need to speak up. (I won=E2=80=99t.) No, if there is a different media type from JSON then I won't every use it. > Argument 2 - Top-level > > draft-i-json-01 says the top level is an object (but doesn=E2=80=99t say = MUST, eek). > I have heard arguments for allowing arrays too; anyone who thinks that is= a > good idea should speak up. (I won=E2=80=99t.) I can see applications where I want multiple top level objects but not in Web Services protocols. I can't see a reason to exchange more than one object per transaction slot. The one case where I can see an argument for having multiples is log files. And we had a long argument over that a while back, the alternatives being A: [ {entry1} , {entry2}, {entry3} ] B: {entry1} , {entry2}, {entry3} C: {entry1} {entry2} {entry3} The arguments against being: A: Cannot be written as an append-only operation. The last ] messes everything up B: No particular reason against C: Isn't a proper JSON encoding A is obviously a non-starter, so taking these arguments, the best choice is= C. The reason for this became obvious when I tried to actually use a log file with a JSON structure. Because the thing about log files is that you often want to jump into the middle of the log and look there. The problem with option B is that there is no way to tell whether a coma is a separator of two elements within one entry or two entries. They both look the same. So there is no way to resynchronize. The only relevance here is that if we don't need option A then I can't see much purpose in having an array as a toplevel entry. But what would make sense is to have a MIME type for a JSON log format which consists of a sequence of JSON objects that are separated by a (possibly null) sequence of whitespace entries. > Argument 5 - Numbers > > draft-i-json-01 says that you MUST not put in a string representing a num= ber > with greater precision/magnitude than IEEE754 doubles can support. I th= ink > this is a good idea but I'm a little nervous because I=E2=80=99ve never w= ritten the > code, if this is unreasonably hard at either the sending or receiving end > someone should say so. Seems pointless to me. if you care about precision then you don't want to use decimal encoding for a binary float. Probably a better restriction would be to say that reals cannot be more than X characters long so that the encoder/decoder can know when to abort. --=20 Website: http://hallambaker.com/ From nobody Mon Apr 28 12:24: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 720AE1A7031 for ; Mon, 28 Apr 2014 12:24:55 -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] 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 mvNM48K66CTW for ; Mon, 28 Apr 2014 12:24:54 -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 6B21B1A702F for ; Mon, 28 Apr 2014 12:24:54 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id BCF043B805B for ; Mon, 28 Apr 2014 12:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=s30ltDF+E07QTrzDkwq6LzZ7ua4=; b=NJqvIxG48+k +Ex7pYMsm74o1ENEahlzZelu5r20bXT6SKyvHfdTxqqPGnZkwPOTBx9J1VoTpnXT oHQ74ZLJJ+Lv3A4YVtn7tGgn484dM0Bry4DO/LjuY7q1s/EyxO2McQZH5+s+c6L+ RYTOgiBSn208tCO2prTH3mv3Jd5xUl2M= Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 7189F3B8059 for ; Mon, 28 Apr 2014 12:24:53 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x12so2330767wgg.2 for ; Mon, 28 Apr 2014 12:24:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.216.68 with SMTP id oo4mr3025601wjc.69.1398713092287; Mon, 28 Apr 2014 12:24:52 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 12:24:52 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Apr 2014 14:24:52 -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/9IhB_D5FJxv4sk5YPBxXWzQxEAM Cc: "json@ietf.org" Subject: Re: [Json] How to argue about I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 19:24:56 -0000 On Mon, Apr 28, 2014 at 1:16 PM, Tim Bray wrote: > Argument 2 - Top-level > > draft-i-json-01 says the top level is an object (but doesn=E2=80=99t say = MUST, eek). > I have heard arguments for allowing arrays too; anyone who thinks that is= a > good idea should speak up. (I won=E2=80=99t.) This is really for indicating schema information in-band. But we already rely on indicating format out of band (via MIME type). I find in-band schema signalling in JSON to be a bad idea, especially when we can do it out-of-band anyways. Question: can schema information be encoded as a parameter to the application/json media type? > Argument 4 - Software behavior > > Section 3 of draft-json-01 implies draconian error handling - when a mess= age > is specified to be i-json but the receiver finds, for example, a dupe key= , > it is required to halt and catch fire. There=E2=80=99s a chance that this= will be > interpreted as =E2=80=9Ctbray poisons JSON with XML draconianism=E2=80=9D= . People with > alternate language should suggest it. (I probably won=E2=80=99t argue thi= s one > either way.) A bigger problem is that this requirement involves changes to existing parsers to meet it. Nico -- From nobody Mon Apr 28 12:26: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 14E4F1A6FEC for ; Mon, 28 Apr 2014 12:26:17 -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] 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 FpFcTo2Mi5GP for ; Mon, 28 Apr 2014 12:26:16 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9941A04F1 for ; Mon, 28 Apr 2014 12:26:15 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id A8B0543807C for ; Mon, 28 Apr 2014 12:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=wMOm5u9seAEYkoFJV5WlADdnRYQ=; b=iFktRPQBP0I CwpgPnW48jWTV9inmRV0nDrxWf9UOnSKzK1N3bNezJKuxKWPmToA4O5msdvuTDyt 1iWuyztvIUsk+o9gwUZnLcj5Oh8lSl/9CyyleWin8tKB9fs1NVvenudqBr5tG5l0 V18vzjrzrt5XkGwAvT1zugTIoAOQXvl0= 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-a64.g.dreamhost.com (Postfix) with ESMTPSA id 5C35143807E for ; Mon, 28 Apr 2014 12:26:14 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so6244460wiv.12 for ; Mon, 28 Apr 2014 12:26:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.108.147 with SMTP id hk19mr16876349wib.42.1398713173050; Mon, 28 Apr 2014 12:26:13 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 12:26:13 -0700 (PDT) Date: Mon, 28 Apr 2014 14:26:13 -0500 Message-ID: From: Nico Williams To: "json@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Gbwtwuqg9Ciz6PHIaaOAgbWSBt0 Subject: [Json] New JSON Text Sequence I-D submitted X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 19:26:18 -0000 https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ From nobody Mon Apr 28 12:43: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 B253C1A6FA1 for ; Mon, 28 Apr 2014 12:43: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 VGrJgh_JS8UZ for ; Mon, 28 Apr 2014 12:43:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A34011A064C for ; Mon, 28 Apr 2014 12:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3276; q=dns/txt; s=iport; t=1398714191; x=1399923791; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=eO5O4SbesONYp4P0Pwqh2VyIeH/NrNDlFcHs1zhcpus=; b=SeseHvwRcWBHz+pCaQQhRuxrnijR0R6EJfXGgeCrnnOGqyXdvyNmEhho IsaB8vAdAZNuqFaKX0eSHvCi5+bRVk3QHVxZpAO0BkOMzxgS1gvT+Ht0r kiNSfMcNUT+q/Rr5JknnUEA1dInGMLK2IXNfSejdueZs/kY2ebAKDJi9m I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFANmuXlOtJA2B/2dsb2JhbABZgwZPV4JlqAcBAQEFkj2HOYEbFnSCJQEBAQQBAQEgDwE7ChELGAICBRYLAgIJAwIBAgEVMAYNBgIBARuIIg2kZqQBF4EphDGIJwQhOoJvgUoEiXGPG5Jeg1CBSkI X-IronPort-AV: E=Sophos;i="4.97,945,1389744000"; d="scan'208";a="320988060" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 28 Apr 2014 19:43:10 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s3SJhAIb005509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Apr 2014 19:43:10 GMT Received: from MAMILLE2-M-T03K.local (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Apr 2014 14:43:10 -0500 Message-ID: <535EAF4D.3070508@cisco.com> Date: Mon, 28 Apr 2014 13:43:09 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "json@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/json/nq12uuWZryXGdY_hg4-DJguMkJw Subject: Re: [Json] How to argue about I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 19:43:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Before the discussions on each topic get too intertwined, the Chairs would find it more useful to have a separate thread for each of the topics below. We ask that you hold off on further comments until the relevant thread is sent -- which I'm in the process of doing now. Thanks, - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 4/28/14, 12:16 PM, Tim Bray wrote: > This is an attempt to leap in front of the debate, use the > take-aways from the very useful London f2f, and make our time > arguing about I-JSON maximally ​productive . There are plenty of > bikesheds out there, but I think the number of useful arguments is > limited and the issues in them pretty clear. > > Argument 1 - Media types? > > Should there be an I-JSON media type, or a application/*+i-json > suffix? draft i-json-01 calls for it, but this is at best > controversial. My suggestion is that people who still think this > is a good idea ​need to speak up. (I won’t.) > > Argument 2 - Top-level > > draft-i-json-01 says the top level is an object (but doesn’t say > MUST, eek). I have heard arguments for allowing arrays too​; > anyone who thinks that is a good idea should speak up. (I won’t.) > > Argument 3 - Unicode > > draft-i-json-01 excludes the use of, and I quote, “Surrogates or > Noncharacters”. Is that the right use of Unicode nomenclature? > This really matters and I think it’s OK now, but first-class > Unicode lawyering is required here. > > Argument 4 - Software behavior > > Section 3 of draft-json-01 implies draconian error handling - when > a message is specified to be i-json but the receiver finds, for > example, a dupe key, it is required to halt and catch fire. There’s > a chance that this will be interpreted as “tbray poisons JSON with > XML draconianism”. People with alternate language should suggest > it. (I probably won’t argue this one either way.) > > Argument 5 - Numbers > > draft-i-json-01 says that you MUST not put in a string representing > a number with greater precision/magnitude than IEEE754 doubles can > support. I think this is a good idea but I'm a little nervous > because I’ve never written the code, if this is unreasonably hard > at either the sending or receiving end someone should say so. > > ...... aaaaaaand, that’s all folks. I’m optimistic that we can > zero in on this one quickly. > > > _______________________________________________ json mailing list > json@ietf.org https://www.ietf.org/mailman/listinfo/json > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTXq9NAAoJEDWi+S0W7cO16YQIAIgmtylb10/6Bx5tC6jSvNoF 7qNNGclLk27sUd7URx+Ol8rN8gMhmiGgNE1tbisgiBTRrLiDqkzEvexLtg37gjY4 uGR+fcA/x9tHZ/OyUaeyYyzDP/VQBFrBl4MC4IH589MueMLJL8fOj9O1/B8Uqtnb isFjmINAB+Pu8igsRx9L/hliMNzbH9FhjdlopKtsbavgo7fqxkU3KR+7cudQAES0 YC/0dvTVgDm30mGNYe8FNfdImork3AZvZOiJL1vWEMPDVMsmwh+YQ1jLeOpiisw/ i3iiIuIUaQgiOMq527/rHNP15AU7FkFpFpS69k/vOo7tiDdAxXu63vTCm9oHtis= =UrH/ -----END PGP SIGNATURE----- From nobody Mon Apr 28 12:45:43 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1D31A0691 for ; Mon, 28 Apr 2014 12:45:41 -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 SPxYht-ptzWO for ; Mon, 28 Apr 2014 12:45:38 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 402091A067C for ; Mon, 28 Apr 2014 12:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1124; q=dns/txt; s=iport; t=1398714336; x=1399923936; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ijXnA0R3kpehpTRcT7kmfpys8W37KNRVU+wH2TDMpyI=; b=dX2KmcPfB0QWm+/ZuBxGhJPtTnIcLS28LJchY2lGji0MfVW08vUPTWpf U8pcKwLWOWkj99AV6GNhW/D5FgStYgwJYcxIxKf/yWk4lRiwwPduTqeuk jk6TzUtUrEJ4e7yaBuSYDNEKfOpwRDfA3d+HMIsiYzLnOoWwSo26whBtS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAJeuXlOtJA2E/2dsb2JhbABZgwZPV4Jlp3sMAQEBBZsRFnSCT1U2AgUWCwILAwIBAgFLDQYCAQEFiDgNlUePH6QBF4EphDGILgEBg0WBSgSJcY8bkl6DUIFTOQ X-IronPort-AV: E=Sophos;i="4.97,945,1389744000"; d="scan'208";a="320994938" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 28 Apr 2014 19:45:36 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s3SJjaLH027490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Apr 2014 19:45:36 GMT Received: from MAMILLE2-M-T03K.local (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Apr 2014 14:45:36 -0500 Message-ID: <535EAFDF.2020403@cisco.com> Date: Mon, 28 Apr 2014 13:45:35 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: IETF JSON WG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/json/6JHr_cndXfz1scGSRt3J5KZWJeo Subject: [Json] I-JSON Topic #1: Media Types? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 19:45:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 "Should there be an I-JSON media type, or a application/*+i-json suffix? Draft i-json-01 calls for it, but this is at best controversial." If you are in favor -- or not -- of an I-JSON media type or media type suffice, please respond to this thread with your reasoning. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. * "How to Argue about I-JSON" < http://www.ietf.org/mail-archive/web/json/current/msg02775.html > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTXq/fAAoJEDWi+S0W7cO1n9cH/0MGVK3lZn5c1C65Wpoa6jhK U7vfd7EUC8+W9T8qn3sR16A1MnGSnUvrSw1M4krYwjZfVTiMyEUBpuD8IGcPPj7B +7dM2WTk1GgJOwAjpBSmRksbfC+W4rzoZO/XTdz4FvgDNHZ+4MuK9P1wcXRY0ahy IpEky0RVv3osXLkGraUVos6DGVV9op6vR6uZw8wH9RuLSVzoVjGlQ56RkigmSA3O OjfK9Xo5cHmahHMvuyPXDldyfKWFlfYtA//4z8dRHF42KkoDv6Qv3LtsGSNQoTzq l0IOyb3e8eqDO6C9mqlLceniiZbFrxbUL4c2fxvt6FI1pGZbNe5grUVbtEVdI10= =JG8k -----END PGP SIGNATURE----- From nobody Mon Apr 28 12:50: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 3AE6B1A6FAB for ; Mon, 28 Apr 2014 12:50:54 -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 1PEOIh_WqosF for ; Mon, 28 Apr 2014 12:50:51 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9B11A6FA8 for ; Mon, 28 Apr 2014 12:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1146; q=dns/txt; s=iport; t=1398714650; x=1399924250; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=ov/IEDGH0KUQAK0i7aN/tW0wrGMVKrgEnziibhzp4G4=; b=j3vEgFZ9xS1B6xzYxuJP3dZdiiFsUjwowcdY+Oa0XI7qmwAsNSkFb0vx 82eB2jy9A35EoxeJB7XDe+I8OYx6g07MY6WGKCuqyVlf6bYKPhsoRF8+x GQI/t3C/F44vfMB7fX8OoGuaTlEtUTAOmF6dYJfLDTT2zV735tXDW+T0u 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFAG6wXlOtJA2E/2dsb2JhbABZgwZPV6pgDAEBAQWbERZ0gl4BRT0WGAMCAQIBSw0GAgEBBYg4DZVKsyEXhVqILgEBhQ8EiXGPG5Jeg1CBUzk X-IronPort-AV: E=Sophos;i="4.97,945,1389744000"; d="scan'208";a="321002343" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP; 28 Apr 2014 19:50:50 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s3SJooiW030232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Apr 2014 19:50:50 GMT Received: from MAMILLE2-M-T03K.local (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Apr 2014 14:50:49 -0500 Message-ID: <535EB119.4000908@cisco.com> Date: Mon, 28 Apr 2014 13:50:49 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: IETF JSON WG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/json/y-SgEmZ3-anH3eMhvn57i0_9K20 Subject: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 19:50:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 "draft-i-json-01 says the top level is an object (but doesnt say MUST, eek). I have heard arguments for allowing arrays too." If you are in favor -- or not -- of restricting the top-level I-JSON text to only be object (or array / object), please respond to this thread with your reasoning. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. * "How to Argue about I-JSON" < http://www.ietf.org/mail-archive/web/json/current/msg02775.html > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTXrEZAAoJEDWi+S0W7cO1bjAH/RxLeWEABXMoJEJrw92lYfkP bLgoS7TRoSxVdUY9K8SVMEJKHMrY2QrK/aNqhwlpWvIirM70xFUT7Sb40M+Msmm/ qFZTFfVRdRsnqsd21dciZ6hA4eSDfkP81cIoMn4MiCx8EExZCj7yroWaTor8jNct 7BgVCWkom2ENVNOb6JEPFa7LD6hpm/9vx1FHctbDgreJuhsYxY9Uy17h/BjxxwPc NkNFbo+OX4Zw6f053cKWbITps/R+IAM57atzJ9PgGpMpN+POQJF/BihnB1qRdUsv y8QqQ1s8r47DauWQ0eX4BxgPXeGV+jBqXrtVAzyNq2B7KFkDukf9UVahUaJjwJU= =nAfX -----END PGP SIGNATURE----- From nobody Mon Apr 28 12:55: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 A2DD81A6FB2 for ; Mon, 28 Apr 2014 12:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.552 X-Spam-Level: X-Spam-Status: No, score=-9.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_21=0.6, 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 NO6JKp7VprZB for ; Mon, 28 Apr 2014 12:55:21 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA901A03FC for ; Mon, 28 Apr 2014 12:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1245; q=dns/txt; s=iport; t=1398714921; x=1399924521; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=3tHWTK0T1HCRZWd8wucfbYhXGXqULxD80Jr6VNZ8jcY=; b=iEjfucJkzk4vWmXjDVHepJZPRFIRQF/D+DQBF7UCao7DLekU9/totW9W 5P0iqHsgBlUBf22imy+fRBmaouEaup5uLV9XCQo3PQ1lacnG78RHjWrbp IWWazKsqRgLPL5Vq9jlJRXYOtjL9ZBlQLBSR2IinP3Oo0l6hRxeqxBrLW 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFAMCwXlOtJV2c/2dsb2JhbABZgwZPV6pgDAEBAQWbERZ0gyQ9FhgDAgECAUsNBgIBAQWIOA2VTrMhF4VaiC4BAYUPBIk3Oo8bkl6DUIFTOQ X-IronPort-AV: E=Sophos;i="4.97,945,1389744000"; d="scan'208";a="39437580" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 28 Apr 2014 19:55:20 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3SJtKE8009583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Apr 2014 19:55:20 GMT Received: from MAMILLE2-M-T03K.local (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Apr 2014 14:55:20 -0500 Message-ID: <535EB227.6050300@cisco.com> Date: Mon, 28 Apr 2014 13:55:19 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.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.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/json/tH1PpXpLZc9e4aC_UP0r5fN6Dqo Subject: [Json] I-JSON Topic #3: Unicode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 19:55:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 "draft-i-json-01 excludes the use of, and I quote, 'Surrogates or Noncharacters'. Is that the right use of Unicode nomenclature? This really matters and I think it?s OK now, but first-class Unicode lawyering is required here." If you have suggestions for better text -- or if you believe the current text is adequate -- please respond to this thread with your suggestions or reasoning. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. * "How to Argue about I-JSON" < http://www.ietf.org/mail-archive/web/json/current/msg02775.html > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTXrInAAoJEDWi+S0W7cO1X7gH/3XaWY+onBfaK64i6Uq5Rkwb kwOqMofRFl2U3R6ZqtrE9yfoUg3jba9hB2x0u1H5ijPchk3zim+zsi0Dzf/cpvWL eO2VADNaZM9Z6/A/TRZJLv8toN1FO5Aql7mBHYNzlcTsUCNebBGIOCWS3qjXTBWx +UT1MCtavWL2MF5C2C8j/m77S/G/8sjkGImGVdz1cOuA5/0H/rjUSK+vaWCAgWWX 1J5PqcxtpWl5QcT1kKU7YY5Cw/lX1F9tH/T/Yj52nxfPjzE5YiNuaHEQ8BWhmSav A6kG64VDUnKFtbm/+Upuo5V/3sCUx+retwxmSAFWhmiPxDOAh29Rg5geFEgv7RU= =8w5d -----END PGP SIGNATURE----- From nobody Mon Apr 28 12:56:32 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2C41A6F9E for ; Mon, 28 Apr 2014 12:56:19 -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_66=0.6] 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 SzvNzxWBko7Y for ; Mon, 28 Apr 2014 12:56:18 -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 C53621A064C for ; Mon, 28 Apr 2014 12:56:18 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 1AFD021DE59 for ; Mon, 28 Apr 2014 12:56:18 -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=0/bXy6wIZY3DC/dOgFgy kiCN6p8=; b=LN3w+1TIco2edQ6/oYrGmR4jPTjFoYD6y7sAulRoBR2V1D3gJsxw KsBfKiIVHpDzkPqukOm9HKwoolcjZZXyIg1Y03UNJDLttgF4+6gkjwo7YHUdWa+h /Q2urORj9Bo7orSvYQ+ds+sjLiYL6+kzMhCstujM51ZFYhyi5obmtsA= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id B497E21DE58 for ; Mon, 28 Apr 2014 12:56:17 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id z2so6332292wiv.6 for ; Mon, 28 Apr 2014 12:56:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.108.147 with SMTP id hk19mr16970306wib.42.1398714976589; Mon, 28 Apr 2014 12:56:16 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 12:56:16 -0700 (PDT) In-Reply-To: <535EAFDF.2020403@cisco.com> References: <535EAFDF.2020403@cisco.com> Date: Mon, 28 Apr 2014 14:56:16 -0500 Message-ID: From: Nico Williams To: Matt Miller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Y6EGPGMpO-Aa716hCSlgWMNOB_0 Cc: IETF JSON WG Subject: Re: [Json] I-JSON Topic #1: Media Types? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 19:56:19 -0000 On Mon, Apr 28, 2014 at 2:45 PM, Matt Miller wrote: > "Should there be an I-JSON media type, or a application/*+i-json > suffix? Draft i-json-01 calls for it, but this is at best controversial." > > If you are in favor -- or not -- of an I-JSON media type or media type > suffice, please respond to this thread with your reasoning. To me this is closely related to the top-level type question. For both I have this reply: ISTM that the top-level-must-be-an-object requirement is really for indicating schema information in-band. But we already rely on indicating format out of band (via MIME type). I find in-band schema signalling in JSON to be a bad idea, especially when we can do it out-of-band anyways. Question: can schema information be encoded as a parameter to the application/json media type? Something like Content-Type: application/json; schema=FooBar . Nico -- From nobody Mon Apr 28 12:58:53 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9481A6F9E for ; Mon, 28 Apr 2014 12:58:51 -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] 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 TmSIHlhttDR2 for ; Mon, 28 Apr 2014 12:58:51 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFDF1A03FC for ; Mon, 28 Apr 2014 12:58:51 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 7FFB450808F for ; Mon, 28 Apr 2014 12:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=b6AQJgNfpe4ThE9nZWpr7cE3I+0=; b=shrYMcUlA54 X9mZYP61Z6Y3LI+Oh2ec5cT2+OSOTODXg7LU2bA8aIgcPHDC/QWOwarvD8ftvjny L0AHvFQ4lBRPDhC//KUH2Artt9zMwxfbqxM0wVmy625a1Pz3BOud/FLuGY8kHyo+ DWFUq//cIILwU+su+ZX56Le/T+/Z1Ddw= Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 34A58508084 for ; Mon, 28 Apr 2014 12:58:50 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id q59so1386091wes.9 for ; Mon, 28 Apr 2014 12:58:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.188.41 with SMTP id fx9mr3782303wjc.56.1398715128908; Mon, 28 Apr 2014 12:58:48 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 12:58:48 -0700 (PDT) In-Reply-To: <535EB119.4000908@cisco.com> References: <535EB119.4000908@cisco.com> Date: Mon, 28 Apr 2014 14:58:48 -0500 Message-ID: From: Nico Williams To: Matt Miller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/RbDWV73NC2YsTMsqsM99LOEY5hQ Cc: IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 19:58:52 -0000 On Mon, Apr 28, 2014 at 2:50 PM, Matt Miller wrote: > "draft-i-json-01 says the top level is an object (but doesn=E2=80=99t say > MUST, eek). I have heard arguments for allowing arrays too." > > If you are in favor -- or not -- of restricting the top-level I-JSON > text to only be object (or array / object), please respond to this > thread with your reasoning. I am opposed. The rationale given is that fields can be added to objects. Sure, but schemas can be changed in other ways, especially if there's out-of-band signalling as to schema. Nico -- From nobody Mon Apr 28 13:00: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 98A611A6FE7 for ; Mon, 28 Apr 2014 13:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.552 X-Spam-Level: X-Spam-Status: No, score=-9.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_51=0.6, 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 pd2IRFnjjZhW for ; Mon, 28 Apr 2014 13:00:03 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7421F1A6F9E for ; Mon, 28 Apr 2014 13:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1350; q=dns/txt; s=iport; t=1398715203; x=1399924803; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=CvtNF+9x+Xlbe5vNACEgX3+8GFeLhbvt+HuO2JhI6NE=; b=dlrurm5WE4Wud4PM/OOFdGSzKtkVToyQQ0jebfaogcGKNbCNYag0B2Cs e96KmXeUYyAZAkxYchdvz8LNJZB2BqnKILxTqGVnRkQm4Ns5uZULGxgzf Pe/atu3GEppW78gPPCtIdX1w/gwOsBR8ftjlFtRE4SDyr8NNcUqfgPxDc M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFAGCyXlOtJV2Y/2dsb2JhbABZgwZPV6pgDAEBAQWbERZ0gyQ9FhgDAgECAUsNBgIBAQWIOA2VUbMhF4VaiC4BAYUPBIk3Oo8bkl6DUIFTOQ X-IronPort-AV: E=Sophos;i="4.97,945,1389744000"; d="scan'208";a="39441599" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 28 Apr 2014 20:00:00 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3SK00FV005832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Apr 2014 20:00:00 GMT Received: from MAMILLE2-M-T03K.local (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Apr 2014 15:00:00 -0500 Message-ID: <535EB33F.7090006@cisco.com> Date: Mon, 28 Apr 2014 13:59:59 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.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.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/json/fFhZbhG8BZ2lasNwqht6-kK0D6w Subject: [Json] Topic #4: Software Behavior X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:00:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 "Section 3 of draft-json-01 implies draconian error handling - when a message is specified to be i-json but the receiver finds, for example, a dupe key, it is required to halt and catch fire. There?s a chance that this will be interpreted as 'tbray poisons JSON with XML draconianism'. People with alternate language should suggest it." If you have suggestions for better text -- or other comments/concerns on this language -- please respond to this thread with your suggestions or reasoning. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. * "How to Argue about I-JSON" < http://www.ietf.org/mail-archive/web/json/current/msg02775.html > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTXrM/AAoJEDWi+S0W7cO1eMoIAIBspmnUYyvwoAHOFHFXqUSY Mw+9btXlV8RfODp8UInQmLFUno7sRgdw/WKRm7qtsrUBH8Fv7YVHpBc3Lf3hDkOW 6zw4sgklHp+tmIpGNUCAsERh3hmNfpsp+aOTJh0EE/5AvsPKSZgw6TEYg52BJQUg LzzgWFGo9uPJ0slqBnA6jbb4MsCNc1KxbrXCed9Xw7Ph/lj0oeItzoQWU7e26+PA fXd3GhPG5e4WwYGVXhe0LFAkcY+yfijs3WfytRFFez6RhMCjbTRLGGyXkhSAhpYu SWfvRSr5x/2/P7qQjK7kcosh2aQIm2hF1j2SMVKer0ALLPCSvHNGzlOoPmoiA28= =ovzI -----END PGP SIGNATURE----- From nobody Mon Apr 28 13:02: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 1C3391A6FFC for ; Mon, 28 Apr 2014 13:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.552 X-Spam-Level: X-Spam-Status: No, score=-9.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_12=0.6, 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 iqzlAfjm8bzY for ; Mon, 28 Apr 2014 13:02:08 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id C6A531A6FA8 for ; Mon, 28 Apr 2014 13:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1342; q=dns/txt; s=iport; t=1398715328; x=1399924928; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=CteaUeO9tMGQOIvQwyMBoy5bzKEUxgNNscBbpSohy8s=; b=CG2KoggRjVOWds65lQZ4aNFVKipRuVamxD/1lv0jQWTy1JQC/QMa/Sw2 0dRCk+cSuLdD0pXpsP0l4BpfUH4xTPuW+jQZBrJE0Ou5Uud4hpo01BXvg X+3tkV8aSajIatUwqHI/zPE7cv/pVq7FaSniTShJGfo1g2Sk19pT7GUI1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFAFizXlOtJA2H/2dsb2JhbABZgwZPV6pgDAEBAQWbERZ0gyQ9FhgDAgECAUsNBgIBAQWIOA2VULMhF4VaiC4BAYUPBIk3Oo8bkl6DUIFTOQ X-IronPort-AV: E=Sophos;i="4.97,946,1389744000"; d="scan'208";a="39439026" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP; 28 Apr 2014 20:02:07 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3SK27Es004628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Apr 2014 20:02:07 GMT Received: from MAMILLE2-M-T03K.local (10.129.24.57) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 28 Apr 2014 15:02:07 -0500 Message-ID: <535EB3BF.8080606@cisco.com> Date: Mon, 28 Apr 2014 14:02:07 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.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.129.24.57] Archived-At: http://mailarchive.ietf.org/arch/msg/json/QB1OAXI638G5AjCPAy5Xs8XHUy0 Subject: [Json] I-JSON Topic #5: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:02:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 "draft-i-json-01 says that you MUST not put in a string representing a number with greater precision/magnitude than IEEE754 doubles can support. I think this is a good idea but I'm a little nervous because I?ve never written the code; if this is unreasonably hard at either the sending or receiving end someone should say so." If you have suggestions for better text -- or other comments/concerns on this language -- please respond to this thread with your suggestions or reasoning. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. * "How to Argue about I-JSON" < http://www.ietf.org/mail-archive/web/json/current/msg02775.html > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTXrO+AAoJEDWi+S0W7cO14CgH+wepgV8mwBjeF0GVU64pKR0p QGoC4JWHGv0X+6YBRDb/aaBJCHFS9pv+8uZGW39/rBZQecQub+/1EHoef0of/X86 sWd48We6AWzh35thRw+GpJMjVHT8KP00i/5R4jJSnTvMLh6+wAU5BdBMQu2JGjND EFa4xY0yCF9MNYcwLvGXCgmVrSejgvqhd0LYrhY3afr/w1og5ac14qPiZdjNAGql dETtwbvoxqIe9OiI21F+0NUNvEFqw5gVASZCrr8Q8UK3GCjyzoabZgUevlrgpY77 kJkiwmWWTgN8j1OuGWspNWA13t4hTm8HShTjG93NxNtBwi3u6Sy+8gtPggDnTUA= =Q7v0 -----END PGP SIGNATURE----- From nobody Mon Apr 28 13:03:51 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437A81A6FBA for ; Mon, 28 Apr 2014 13:03:45 -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 0aQMOms8IiDb for ; Mon, 28 Apr 2014 13:03:41 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id B0F741A03FC for ; Mon, 28 Apr 2014 13:03:41 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1Werm8-0000kw-LI; Mon, 28 Apr 2014 16:03:40 -0400 Date: Mon, 28 Apr 2014 16:03:40 -0400 From: John Cowan To: Tim Bray Message-ID: <20140428200340.GL1547@mercury.ccil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/3kp-i9aqsWQ1rMl-YVHHifYC7L0 Cc: "json@ietf.org" Subject: Re: [Json] How to argue about I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:03:45 -0000 Tim Bray scripsit: > Argument 1 - Media types? > > Should there be an I-JSON media type, or a application/*+i-json suffix? > draft i-json-01 calls for it, but this is at best controversial. My > suggestion is that people who still think this is a good idea > ​need to speak up. (I won’t.) If you expect JSON and get I-JSON, all is well, so I see no point in adding a media type or suffix to actual documents. It would be marginally useful to indicate that you expect I-JSON, but surely nobody would be so foolish at this stage as to insist on I-JSON. So let's not bother with these formalities until there is a proven need for them (which may be never). > Argument 2 - Top-level > > draft-i-json-01 says the top level is an object (but doesn’t say MUST, > eek). I have heard arguments for allowing arrays too​; anyone who thinks > that is a good idea should speak up. (I won’t.) As I understand it, the reason for this restriction was to support the in-band I-JSON signature. Since this is now dropped, there is no further reason not to allow the sending of arbitrary JSON values. > Argument 3 - Unicode > > draft-i-json-01 excludes the use of, and I quote, “Surrogates or > Noncharacters”. Is that the right use of Unicode nomenclature? This > really matters and I think it’s OK now, but first-class Unicode lawyering > is required here. It should say "code points which represent unpaired surrogates or noncharacters." The statement "\uDEAD is always illegal" is incorrect; it is entirely legal in the sequence "\uD800\uDEAD", which represents U+102AD CARIAN LETTER T. Rather it should say that "\uDEAD" is illegal unless preceded by an escape between "\uD800" and "\uDBFF" inclusive. > Argument 5 - Numbers > > draft-i-json-01 says that you MUST not put in a string representing a > number with greater precision/magnitude than IEEE754 doubles can support. > I think this is a good idea but I'm a little nervous because I’ve never > written the code, if this is unreasonably hard at either the sending or > receiving end someone should say so. Most programming language standards don't require accurate and minimal external representations of floats, Scheme being the exception. I think the existing wording is satisfactory. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org [P]olice in many lands are now complaining that local arrestees are insisting on having their Miranda rights read to them, just like perps in American TV cop shows. When it's explained to them that they are in a different country, where those rights do not exist, they become outraged. --Neal Stephenson From nobody Mon Apr 28 13:17:22 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0571A6F54 for ; Mon, 28 Apr 2014 13:17:20 -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 QiSOwx1VJ0Ad for ; Mon, 28 Apr 2014 13:17:18 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5671A03FC for ; Mon, 28 Apr 2014 13:17:18 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id im17so9016465vcb.0 for ; Mon, 28 Apr 2014 13:17:17 -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=t5+iUtuXG6cjTj9+fHNjfYsIUnw9QbappFVgLHZSGv4=; b=iVIYgnwywGvIS2v4q4iSJ1DN0TmSl37+Zftdp9nZtXGa+IMeOe7p8dmlvL6brk6a3z s0ZjnJ1NvEHP/nGvQHKTV3sFCADVsmmu0bJAWjV/GVR8pAGesSeIcmyRqt10yoVCBUF3 /6XXXSlGJQM1/HXUJsnhDGkj3dBP2ol4Mgr/jjzkVtBicfhGp0kJAVKsjseSw64d5T+H qiOATqKghSKMYg1yEDXJCQqgH4scsqASY1+1OEvAwbwsUJB6MtOutN04LaP8yHYC/mkh YHZwyUtZ6NBUAuX45H3o532ft+b4VTOxxzNys4pnEjoS4szB7l7kPO39HFSBCKhjhFsi Barg== X-Gm-Message-State: ALoCoQniZqZjxUHCPaPnhVzP+oH/t7vTxV+1UVuKpwqwmC8MgBFbr4oiyD6RR/sokALqBdYpoiNY X-Received: by 10.58.207.74 with SMTP id lu10mr25085248vec.15.1398716237172; Mon, 28 Apr 2014 13:17:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Mon, 28 Apr 2014 13:16:57 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <535EAFDF.2020403@cisco.com> References: <535EAFDF.2020403@cisco.com> From: Tim Bray Date: Mon, 28 Apr 2014 13:16:57 -0700 Message-ID: To: Matt Miller Content-Type: multipart/alternative; boundary=047d7b6783ce756d4f04f820005f Archived-At: http://mailarchive.ietf.org/arch/msg/json/ORTSneZsYA0OH57AX8NgoTag10s Cc: IETF JSON WG Subject: Re: [Json] I-JSON Topic #1: Media Types? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 20:17:20 -0000 --047d7b6783ce756d4f04f820005f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Having thought some more about this, I can=E2=80=99t actually imagine a sce= nario in which the media type (or suffix) would add value. I say lose it from the draft. On Mon, Apr 28, 2014 at 12:45 PM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > "Should there be an I-JSON media type, or a application/*+i-json > suffix? Draft i-json-01 calls for it, but this is at best controversial.= " > > If you are in favor -- or not -- of an I-JSON media type or media type > suffice, please respond to this thread with your reasoning. > > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > * "How to Argue about I-JSON" < > http://www.ietf.org/mail-archive/web/json/current/msg02775.html > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTXq/fAAoJEDWi+S0W7cO1n9cH/0MGVK3lZn5c1C65Wpoa6jhK > U7vfd7EUC8+W9T8qn3sR16A1MnGSnUvrSw1M4krYwjZfVTiMyEUBpuD8IGcPPj7B > +7dM2WTk1GgJOwAjpBSmRksbfC+W4rzoZO/XTdz4FvgDNHZ+4MuK9P1wcXRY0ahy > IpEky0RVv3osXLkGraUVos6DGVV9op6vR6uZw8wH9RuLSVzoVjGlQ56RkigmSA3O > OjfK9Xo5cHmahHMvuyPXDldyfKWFlfYtA//4z8dRHF42KkoDv6Qv3LtsGSNQoTzq > l0IOyb3e8eqDO6C9mqlLceniiZbFrxbUL4c2fxvt6FI1pGZbNe5grUVbtEVdI10=3D > =3DJG8k > -----END PGP SIGNATURE----- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b6783ce756d4f04f820005f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hav= ing thought some more about this, I can=E2=80=99t actually imagine a scenar= io in which the media type (or suffix) would add value. I say lose it from = the draft.


On Mon,= Apr 28, 2014 at 12:45 PM, Matt Miller <mamille2@cisco.com>= wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

"Should there be an I-JSON media type, or a application/*+i-json
suffix? =C2=A0Draft i-json-01 calls for it, but this is at best controversi= al."

If you are in favor -- or not -- of an I-JSON media type or media type
suffice, please respond to this thread with your reasoning.


- --
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

* "How to Argue about I-JSON" <
http://www.ietf.org/mail-archive/web/json/current/msg027= 75.html >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTXq/fAAoJEDWi+S0W7cO1n9cH/0MGVK3lZn5c1C65Wpoa6jhK
U7vfd7EUC8+W9T8qn3sR16A1MnGSnUvrSw1M4krYwjZfVTiMyEUBpuD8IGcPPj7B
+7dM2WTk1GgJOwAjpBSmRksbfC+W4rzoZO/XTdz4FvgDNHZ+4MuK9P1wcXRY0ahy
IpEky0RVv3osXLkGraUVos6DGVV9op6vR6uZw8wH9RuLSVzoVjGlQ56RkigmSA3O
OjfK9Xo5cHmahHMvuyPXDldyfKWFlfYtA//4z8dRHF42KkoDv6Qv3LtsGSNQoTzq
l0IOyb3e8eqDO6C9mqlLceniiZbFrxbUL4c2fxvt6FI1pGZbNe5grUVbtEVdI10=3D
=3DJG8k
-----END PGP SIGNATURE-----

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

--047d7b6783ce756d4f04f820005f-- From nobody Mon Apr 28 13:21: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 ACD171A7026 for ; Mon, 28 Apr 2014 13:20:56 -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 a_Aks7pALdHM for ; Mon, 28 Apr 2014 13:20:54 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 451DC1A700B for ; Mon, 28 Apr 2014 13:20:52 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lc6so8618173vcb.7 for ; Mon, 28 Apr 2014 13:20:51 -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=CHnI3GLq+whpWyvUumd/fqCs784IdGhRA8Gvkb6P9Lg=; b=SBkDzFu5PIjGtFzSumH57sumsxoc5X+RzEUYrkiIXEH1UEcKtum+RanZCvI0WRRp6e zqRFEzcLVnbNGrhctb//BPyiDfYHDTSszNP3VjiMfeEtLCawJxekjJICM8GvlXFgZSdy eoMw5F48bdIOEkoMuoAmMCf/v9gEa9manpf2MBVGCqWzZWFRsxwEdNa4pkRs+PFNEavC ALxe54NubEtj4tmv7N0js/7+FRYJifgQZTbYlrNIkEqyb8YmP+E9zLRM7F+RSCDRGYE+ DtpFtaUxsbjW2zoTIQWA55fJILIhivhR/HtSo8n/XchsEf0IFmGy1JEnP2g3hGb7BrJY u5TQ== X-Gm-Message-State: ALoCoQkJzXkGyKB7E8aTgSTvkXKAhxDqQ20O7SOYYncshjwh8Iwg7SfXUphHcCfiT4YbAbOXCeCz X-Received: by 10.220.12.66 with SMTP id w2mr25080395vcw.15.1398716451068; Mon, 28 Apr 2014 13:20:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Mon, 28 Apr 2014 13:20:31 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <535EB119.4000908@cisco.com> References: <535EB119.4000908@cisco.com> From: Tim Bray Date: Mon, 28 Apr 2014 13:20:31 -0700 Message-ID: To: Matt Miller Content-Type: multipart/alternative; boundary=001a11c315003532f704f8200da8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/t7njw-i_Puhez5El_inuMsy7bMo Cc: IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 20:20:57 -0000 --001a11c315003532f704f8200da8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BProtocols with messages which are objects are better than other pr= otocols, because they are architecturally friendly to MustIgnore policies. Allowing top-level JSON to be a primitive - true, null, 42=E2=80=8B - is ba= tshit crazy for anything the IETF might contemplate, and one of I-JSON=E2=80=99s = main virtues is ruling that out. I don=E2=80=99t think top-level arrays are actively harmful at the same lev= el, but the MustIgnore is a pretty big value-add, forcing people to sort-of future-proof themselves even when they haven=E2=80=99t realized why that=E2= =80=99s a good idea. So I=E2=80=99d leave it object-only. On Mon, Apr 28, 2014 at 12:50 PM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > "draft-i-json-01 says the top level is an object (but doesn=E2=80=99t say > MUST, eek). I have heard arguments for allowing arrays too." > > If you are in favor -- or not -- of restricting the top-level I-JSON > text to only be object (or array / object), please respond to this > thread with your reasoning. > > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > * "How to Argue about I-JSON" < > http://www.ietf.org/mail-archive/web/json/current/msg02775.html > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTXrEZAAoJEDWi+S0W7cO1bjAH/RxLeWEABXMoJEJrw92lYfkP > bLgoS7TRoSxVdUY9K8SVMEJKHMrY2QrK/aNqhwlpWvIirM70xFUT7Sb40M+Msmm/ > qFZTFfVRdRsnqsd21dciZ6hA4eSDfkP81cIoMn4MiCx8EExZCj7yroWaTor8jNct > 7BgVCWkom2ENVNOb6JEPFa7LD6hpm/9vx1FHctbDgreJuhsYxY9Uy17h/BjxxwPc > NkNFbo+OX4Zw6f053cKWbITps/R+IAM57atzJ9PgGpMpN+POQJF/BihnB1qRdUsv > y8QqQ1s8r47DauWQ0eX4BxgPXeGV+jBqXrtVAzyNq2B7KFkDukf9UVahUaJjwJU=3D > =3DnAfX > -----END PGP SIGNATURE----- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11c315003532f704f8200da8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2= =80=8BProtocols with messages which are objects are better than other proto= cols, because they are architecturally friendly to MustIgnore policies. =C2= =A0

Allowing t= op-level JSON to be a primitive - true, null, 42=E2=80=8B - is batshit craz= y for anything the IETF might contemplate, and one of I-JSON=E2=80=99s main= virtues is ruling that out. =C2=A0

I don=E2=80=99t think top-leve= l arrays are actively harmful at the same level, but the MustIgnore is a pr= etty big value-add, forcing people to sort-of future-proof themselves even = when they haven=E2=80=99t realized why that=E2=80=99s a good idea.

So I=E2=80=99d leave it object= -only.


O= n Mon, Apr 28, 2014 at 12:50 PM, Matt Miller <mamille2@cisco.com>= wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

"draft-i-json-01 says the top level is an object (but doesn=E2=80=99t = say
MUST, eek). =C2=A0I have heard arguments for allowing arrays too."

If you are in favor -- or not -- of restricting the top-level I-JSON
text to only be object (or array / object), please respond to this
thread with your reasoning.


- --
- - m&m

Matt Miller < ma= mille2@cisco.com >
Cisco Systems, Inc.

* "How to Argue about I-JSON" <
http://www.ietf.org/mail-archive/web/json/current/msg027= 75.html >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTXrEZAAoJEDWi+S0W7cO1bjAH/RxLeWEABXMoJEJrw92lYfkP
bLgoS7TRoSxVdUY9K8SVMEJKHMrY2QrK/aNqhwlpWvIirM70xFUT7Sb40M+Msmm/
qFZTFfVRdRsnqsd21dciZ6hA4eSDfkP81cIoMn4MiCx8EExZCj7yroWaTor8jNct
7BgVCWkom2ENVNOb6JEPFa7LD6hpm/9vx1FHctbDgreJuhsYxY9Uy17h/BjxxwPc
NkNFbo+OX4Zw6f053cKWbITps/R+IAM57atzJ9PgGpMpN+POQJF/BihnB1qRdUsv
y8QqQ1s8r47DauWQ0eX4BxgPXeGV+jBqXrtVAzyNq2B7KFkDukf9UVahUaJjwJU=3D
=3DnAfX
-----END PGP SIGNATURE-----

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

--001a11c315003532f704f8200da8-- From nobody Mon Apr 28 13:22: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 9A0BE1A702F for ; Mon, 28 Apr 2014 13:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 QEzYhFTk2nuZ for ; Mon, 28 Apr 2014 13:22:00 -0700 (PDT) Received: from nm34-vm8.bullet.mail.ir2.yahoo.com (nm34-vm8.bullet.mail.ir2.yahoo.com [212.82.97.122]) by ietfa.amsl.com (Postfix) with ESMTP id EBBC41A7026 for ; Mon, 28 Apr 2014 13:21:59 -0700 (PDT) Received: from [212.82.98.57] by nm34.bullet.mail.ir2.yahoo.com with NNFMP; 28 Apr 2014 20:21:58 -0000 Received: from [46.228.39.108] by tm10.bullet.mail.ir2.yahoo.com with NNFMP; 28 Apr 2014 20:21:58 -0000 Received: from [127.0.0.1] by smtp145.mail.ir2.yahoo.com with NNFMP; 28 Apr 2014 20:21:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398716518; bh=wxCjpIhPPIAwKoy1rlfPDcmOwctKdGOK+qh7SRjX5Io=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Received:X-Gm-Message-State:X-Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=jfPpJTlCb9eYRQSJ4gxqraZAz3IPtgMJ9XINJie4t5l+7S/+d6J3QK7o5r+j14YuY89PQrbEkfw3ujvoQxF7mpT/3rM5gaYrQu2LNY57ckIEYWObkZGCGlcdgvKtSsddjnl7DXANhJhcsvMubZc7pP24yBXzlbKNFmSMkHs7kxc= X-Yahoo-Newman-Id: 635927.7100.bm@smtp145.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: irJzIHkVM1mby6MLEyDWH5zMJIX7aHga0AwGny7_kY.89FA KNwuCmc2AlHpsqkMzricr_WPN8._jUZF_pSglWVPaVejOpQ6BZfDa.P.Hnvk tIFSQlfgUw6xQBrN6BJi614so4_cHyjnoxuVhBeycrC.xIZPil2NXYc2PR1p fcrU.KPJbI5imxpxEzsgS4oJdrXvaqXYk.XdYnR8X1maCLVxVQEm6ocuzPPI 3xhqOgED6wyLpWqGrGxf3pTr816PlBrNO92tmo7z7vQ95z9bBgHobQ7k_ucR CjPQtGMtYD6rITxLz94vtYnzj30ob8bFFcyUbXZWaFZxIKV5w1dV49yOpWXs N2Yt_8oQWMD.JwyxwXDwqCEeNgnFzu9KvjnVwVbXSf9wnvV3Lp1AMsgoxrpr .ydtmfUWhaNVSZ8aZ_Kki6s9F_u2CxcPUluiHtkXOO3CfWZXBLeLh6gHmeYK ZjuODDDWiGBxvwvIIo6Z8RErlWEG.UWPumB_Teu.Md9lrxFhwjlWSlgKrAqW Jdp.pymUmQHDi4Tn4xiwS8YIQ_dl8LDkDx8KiOxZiHy9YsYh_2Mk1jlQPQGh aByWGZBAMf4OlOmbbElDvVJTSsL1Gz0ypALcwHfgnorrVxWg_yAnclxIQJGT U_Y75XVeT4GdnE4m6sOq5jYlnRhiIqujKl7JMC0uzaHrfl.9KtI_otYjMWs2 XeDnKPx7LFJVW.7XdUvu75uMjs5NmElxGCw6JYX0KyRoWMbjCP5yOmVaxRTW RIAFgOLw58Ab_KQKs.e1qWCvu9Zcgdh85G44fTqOSC.ZRNMMSc1QJ3zMXfYi GG6B7V3zCR7iLohbO3UVrMhNsVgxocpWb X-Yahoo-SMTP: i12ABOmswBAkPG1PnjmsmmFRWA-- X-Rocket-Received: from mail-wg0-f47.google.com (mamund@74.125.82.47 with plain [188.125.68.56]) by smtp145.mail.ir2.yahoo.com with SMTP; 28 Apr 2014 20:21:58 +0000 UTC Received: by mail-wg0-f47.google.com with SMTP id n12so3736676wgh.30 for ; Mon, 28 Apr 2014 13:21:57 -0700 (PDT) X-Gm-Message-State: ALoCoQlwBb2cyp0jqxIGPRdMqLpj0cj2KhL2ZFrgjMYozyCewn7sBWB/Hi3NEbD9kTWrnxNFQWqO X-Received: by 10.194.24.74 with SMTP id s10mr8918846wjf.43.1398716517431; Mon, 28 Apr 2014 13:21:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.60.68 with HTTP; Mon, 28 Apr 2014 13:21:37 -0700 (PDT) In-Reply-To: References: <535EAFDF.2020403@cisco.com> From: mike amundsen Date: Mon, 28 Apr 2014 16:21:37 -0400 Message-ID: To: Tim Bray Content-Type: multipart/alternative; boundary=047d7b5d254229ca5a04f8201134 Archived-At: http://mailarchive.ietf.org/arch/msg/json/NBoaYQ2EUMEXEB3itiQcRCuQYW0 Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] I-JSON Topic #1: Media Types? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 20:22:01 -0000 --047d7b5d254229ca5a04f8201134 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable if you have differences in validation or well-formed-ness between application/json and I-JSON, you need a new media-type identifier to make sure the right parser kicks in (both on the sender and receiver sides). mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://linkedin.com/in/mamund On Mon, Apr 28, 2014 at 4:16 PM, Tim Bray wrote: > Having thought some more about this, I can=E2=80=99t actually imagine a s= cenario > in which the media type (or suffix) would add value. I say lose it from t= he > draft. > > > On Mon, Apr 28, 2014 at 12:45 PM, Matt Miller wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> "Should there be an I-JSON media type, or a application/*+i-json >> suffix? Draft i-json-01 calls for it, but this is at best controversial= ." >> >> If you are in favor -- or not -- of an I-JSON media type or media type >> suffice, please respond to this thread with your reasoning. >> >> >> - -- >> - - m&m >> >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >> >> * "How to Argue about I-JSON" < >> http://www.ietf.org/mail-archive/web/json/current/msg02775.html > >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> Comment: GPGTools - https://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQEcBAEBCgAGBQJTXq/fAAoJEDWi+S0W7cO1n9cH/0MGVK3lZn5c1C65Wpoa6jhK >> U7vfd7EUC8+W9T8qn3sR16A1MnGSnUvrSw1M4krYwjZfVTiMyEUBpuD8IGcPPj7B >> +7dM2WTk1GgJOwAjpBSmRksbfC+W4rzoZO/XTdz4FvgDNHZ+4MuK9P1wcXRY0ahy >> IpEky0RVv3osXLkGraUVos6DGVV9op6vR6uZw8wH9RuLSVzoVjGlQ56RkigmSA3O >> OjfK9Xo5cHmahHMvuyPXDldyfKWFlfYtA//4z8dRHF42KkoDv6Qv3LtsGSNQoTzq >> l0IOyb3e8eqDO6C9mqlLceniiZbFrxbUL4c2fxvt6FI1pGZbNe5grUVbtEVdI10=3D >> =3DJG8k >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --047d7b5d254229ca5a04f8201134 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
if you have differences in validation or well-formed-ness = between application/json and I-JSON, you need a new media-type identifier t= o make sure the right parser kicks in (both on the sender and receiver side= s).




On Mon, Apr 28, 2014 at 4:16 PM, Tim Bra= y <tbray@textuality.com> wrote:
Hav= ing thought some more about this, I can=E2=80=99t actually imagine a scenar= io in which the media type (or suffix) would add value. I say lose it from = the draft.

On Mon, Apr 28, 2014 at 12:45 PM, Matt Mil= ler <mamille2@cisco.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

"Should there be an I-JSON media type, or a application/*+i-json
suffix? =C2=A0Draft i-json-01 calls for it, but this is at best controversi= al."

If you are in favor -- or not -- of an I-JSON media type or media type
suffice, please respond to this thread with your reasoning.


- --
- - m&m

Matt Miller < ma= mille2@cisco.com >
Cisco Systems, Inc.

* "How to Argue about I-JSON" <
http://www.ietf.org/mail-archive/web/json/current/msg027= 75.html >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTXq/fAAoJEDWi+S0W7cO1n9cH/0MGVK3lZn5c1C65Wpoa6jhK
U7vfd7EUC8+W9T8qn3sR16A1MnGSnUvrSw1M4krYwjZfVTiMyEUBpuD8IGcPPj7B
+7dM2WTk1GgJOwAjpBSmRksbfC+W4rzoZO/XTdz4FvgDNHZ+4MuK9P1wcXRY0ahy
IpEky0RVv3osXLkGraUVos6DGVV9op6vR6uZw8wH9RuLSVzoVjGlQ56RkigmSA3O
OjfK9Xo5cHmahHMvuyPXDldyfKWFlfYtA//4z8dRHF42KkoDv6Qv3LtsGSNQoTzq
l0IOyb3e8eqDO6C9mqlLceniiZbFrxbUL4c2fxvt6FI1pGZbNe5grUVbtEVdI10=3D
=3DJG8k
-----END PGP SIGNATURE-----

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


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


--047d7b5d254229ca5a04f8201134-- From nobody Mon Apr 28 13:23: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 B324C1A702F for ; Mon, 28 Apr 2014 13:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, 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 6wMAfwQRJezz for ; Mon, 28 Apr 2014 13:23:16 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 60C281A7026 for ; Mon, 28 Apr 2014 13:23:16 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id sa20so8628008veb.22 for ; Mon, 28 Apr 2014 13:23:14 -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=JQs9JAMPpK5MZGo6ogNvMY/nwNuQCz4cHLxv7bzNBmM=; b=Ek6ckwI1LKuXJdxd7X9Dx49yIrF7GgUyP6CMX1VDM6tqf8FxeApniDRP13A92T892Z pjAYUVhZp/oqY1aaiGu9ZUdQa9lBxMHF9UHmTBPGi2P5mdv2MJmsZdnpuMLB4tMbBfAz 41f8zUgnATrhHM57gf7xt95yct/d/XiLMTjX4/XYzCBbDp3aXw4MNj5RZGJwp0Hd5zLg wdKtW/XXufERhox07KDTVVW3yx4g0WZmUsVkSviLcw3Q8oT+GOTi78jdgENkqwvvUBJS Bszj0Y0u3fOc9iRNSSmTBgatt0+hWoIHpDI0aDPRDCI6zO/GMQerIJf7v9bypZBGYGtO 2Qog== X-Gm-Message-State: ALoCoQmcoeLRaz9KCqhRT+o+S20AfbnLmlXeXwUIY6tCmwSKOlOpeElLHiZj1/Yv6xwt3XPKdTvn X-Received: by 10.221.37.1 with SMTP id tc1mr2455641vcb.32.1398716594530; Mon, 28 Apr 2014 13:23:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Mon, 28 Apr 2014 13:22:54 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <535EB3BF.8080606@cisco.com> References: <535EB3BF.8080606@cisco.com> From: Tim Bray Date: Mon, 28 Apr 2014 13:22:54 -0700 Message-ID: To: Matt Miller Content-Type: multipart/alternative; boundary=001a11334c38c23f5e04f8201544 Archived-At: http://mailarchive.ietf.org/arch/msg/json/X5MOhMTbFPskBoyQRv3xQT7rTVI Cc: IETF JSON WG Subject: Re: [Json] I-JSON Topic #5: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:23:18 -0000 --001a11334c38c23f5e04f8201544 Content-Type: text/plain; charset=UTF-8 It occurs to me that it would be super-useful for the draft to include explanation of how to follow this rule, including examples of printf and Java format strings. On Mon, Apr 28, 2014 at 1:02 PM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > "draft-i-json-01 says that you MUST not put in a string representing a > number with greater precision/magnitude than IEEE754 doubles can > support. I think this is a good idea but I'm a little nervous > because I?ve never written the code; if this is unreasonably hard at > either the sending or receiving end someone should say so." > > If you have suggestions for better text -- or other comments/concerns > on this language -- please respond to this thread with your > suggestions or reasoning. > > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > * "How to Argue about I-JSON" < > http://www.ietf.org/mail-archive/web/json/current/msg02775.html > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTXrO+AAoJEDWi+S0W7cO14CgH+wepgV8mwBjeF0GVU64pKR0p > QGoC4JWHGv0X+6YBRDb/aaBJCHFS9pv+8uZGW39/rBZQecQub+/1EHoef0of/X86 > sWd48We6AWzh35thRw+GpJMjVHT8KP00i/5R4jJSnTvMLh6+wAU5BdBMQu2JGjND > EFa4xY0yCF9MNYcwLvGXCgmVrSejgvqhd0LYrhY3afr/w1og5ac14qPiZdjNAGql > dETtwbvoxqIe9OiI21F+0NUNvEFqw5gVASZCrr8Q8UK3GCjyzoabZgUevlrgpY77 > kJkiwmWWTgN8j1OuGWspNWA13t4hTm8HShTjG93NxNtBwi3u6Sy+8gtPggDnTUA= > =Q7v0 > -----END PGP SIGNATURE----- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11334c38c23f5e04f8201544 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It = occurs to me that it would be super-useful for the draft to include explana= tion of how to follow this rule, including examples of printf and Java form= at strings. =C2=A0


On Mon,= Apr 28, 2014 at 1:02 PM, Matt Miller <mamille2@cisco.com> = wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

"draft-i-json-01 says that you MUST not put in a string representing a=
number with greater precision/magnitude than IEEE754 doubles can
support. =C2=A0 I think this is a good idea but I'm a little nervous because I?ve never written the code; if this is unreasonably hard at
either the sending or receiving end someone should say so."

If you have suggestions for better text -- or other comments/concerns
on this language -- please respond to this thread with your
suggestions or reasoning.


- --
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

* "How to Argue about I-JSON" <
http://www.ietf.org/mail-archive/web/json/current/msg027= 75.html >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTXrO+AAoJEDWi+S0W7cO14CgH+wepgV8mwBjeF0GVU64pKR0p
QGoC4JWHGv0X+6YBRDb/aaBJCHFS9pv+8uZGW39/rBZQecQub+/1EHoef0of/X86
sWd48We6AWzh35thRw+GpJMjVHT8KP00i/5R4jJSnTvMLh6+wAU5BdBMQu2JGjND
EFa4xY0yCF9MNYcwLvGXCgmVrSejgvqhd0LYrhY3afr/w1og5ac14qPiZdjNAGql
dETtwbvoxqIe9OiI21F+0NUNvEFqw5gVASZCrr8Q8UK3GCjyzoabZgUevlrgpY77
kJkiwmWWTgN8j1OuGWspNWA13t4hTm8HShTjG93NxNtBwi3u6Sy+8gtPggDnTUA=3D
=3DQ7v0
-----END PGP SIGNATURE-----

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

--001a11334c38c23f5e04f8201544-- From nobody Mon Apr 28 13:36: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 D89A31A6FB7 for ; Mon, 28 Apr 2014 13:36:29 -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] 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 zOf43eGcv49o for ; Mon, 28 Apr 2014 13:36:29 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 185A01A064C for ; Mon, 28 Apr 2014 13:36:29 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 3346227BC069 for ; Mon, 28 Apr 2014 13:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=G9DdcCIm3mBuOuqfB1PP6DuXYjU=; b=K12yXf5q2+L PXRw8UweSI/pGDjjEU/f5I1GDeP1lOFa9TtoL2dDen8X0SGMRcWIl9vMQi1RqLCQ 6hXnry1RA3A0gx2n3ny2mSpBRRtXjlsrWJ1w3ajg6EkBwbyOMMl/ZFiTYEFt/YLJ RwGw4fxITY1A67DyqoeMSRquDqVGfkjU= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id D98E127BC061 for ; Mon, 28 Apr 2014 13:36:27 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id x48so6751073wes.7 for ; Mon, 28 Apr 2014 13:36:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr17043797wic.5.1398717386766; Mon, 28 Apr 2014 13:36:26 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 13:36:26 -0700 (PDT) In-Reply-To: References: <535EB119.4000908@cisco.com> Date: Mon, 28 Apr 2014 15:36:26 -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/9dY1J0mCd54_53cYXkjrw6wABVE Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 20:36:30 -0000 On Mon, Apr 28, 2014 at 3:20 PM, Tim Bray wrote: > Protocols with messages which are objects are better than other protocols= , > because they are architecturally friendly to MustIgnore policies. > > Allowing top-level JSON to be a primitive - true, null, 42 - is batshit > crazy for anything the IETF might contemplate, and one of I-JSON=E2=80=99= s main > virtues is ruling that out. What if the service outputs JSON texts output by a jq program supplied by the client and applied to server-side data? > I don=E2=80=99t think top-level arrays are actively harmful at the same l= evel, but > the MustIgnore is a pretty big value-add, forcing people to sort-of > future-proof themselves even when they haven=E2=80=99t realized why that= =E2=80=99s a good > idea. Why can't schema changes be communicated out-of-band? Apps request JSON in a particular schema; servers report the schema when the schema was not requested... I can see the value in recommending the use of top-level objects in general, just not in requiring it. Still, I think if you want to say "so don't use I-JSON", I think that's mostly fine. The only problem that comes up is the possibility that I-JSON would crowd out JSON to the point where non-I-JSON might not be usable. I think what I'd want to see there is that JSON parsers should really just have an option as to this, rather than have I-JSON parsers that are not also JSON parsers. Nico -- From nobody Mon Apr 28 13:38:29 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A291A6FEE for ; Mon, 28 Apr 2014 13:38:22 -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_51=0.6] 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 Xwz-QST-vd9A for ; Mon, 28 Apr 2014 13:38:22 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 188E91A6FFC for ; Mon, 28 Apr 2014 13:38:22 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 7339D200B9990 for ; Mon, 28 Apr 2014 13:38:21 -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=DmFdFO0uJT6y8Z1seyGB yVrOV2o=; b=H+F7XJufkOG9LGLmtlemTw/L/yQrT/P1e3Vc4/XLEtYcL4O8JDiC LCCJMvOA/2kBb72+TjqMLyQm6N2BXH73VMnnWAaMC3GQenaIdKfqvbBfEs3VkMDq afLd03NFxVjUwdMkdE2BQNsoWGxIM//n6vDGE+Z0auIISZHTvUHTzhw= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 20EFF200B998F for ; Mon, 28 Apr 2014 13:38:20 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id b13so885559wgh.7 for ; Mon, 28 Apr 2014 13:38:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.82.35 with SMTP id f3mr21196894wjy.36.1398717500118; Mon, 28 Apr 2014 13:38:20 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 13:38:20 -0700 (PDT) In-Reply-To: <535EB33F.7090006@cisco.com> References: <535EB33F.7090006@cisco.com> Date: Mon, 28 Apr 2014 15:38:20 -0500 Message-ID: From: Nico Williams To: Matt Miller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/ll-pEOD48B9wF4D8xWwRdws5PkY Cc: IETF JSON WG Subject: Re: [Json] Topic #4: Software Behavior X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:38:23 -0000 On Mon, Apr 28, 2014 at 2:59 PM, Matt Miller wrote: > "Section 3 of draft-json-01 implies draconian error handling - when a > message is specified to be i-json but the receiver finds, for example, > a dupe key, it is required to halt and catch fire. There?s a chance > that this will be interpreted as 'tbray poisons JSON with XML > draconianism'. People with alternate language should suggest it." > > If you have suggestions for better text -- or other comments/concerns > on this language -- please respond to this thread with your > suggestions or reasoning. As in my latest reply as to top-level value types, I think this is best expressed as requiring an option in parser implementations. IMO it'd be very bad if I-JSON parsers were to exist that are not also JSON parsers (at least as an option) and which might then crowd out JSON. Nico -- From nobody Mon Apr 28 13:43:57 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58401A802C for ; Mon, 28 Apr 2014 13:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, 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 w9jYykxFCVow for ; Mon, 28 Apr 2014 13:43:50 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 80F531A7032 for ; Mon, 28 Apr 2014 13:43:50 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id lf12so6760148vcb.13 for ; Mon, 28 Apr 2014 13:43: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=fFLAvJrj0RKgjgI9TSc8fBDO0pbAnMo38pcGCOSqV1I=; b=I9Sg7jb17N+7r+NxUQNgbhWuc7geGcZqOJTu2SyxGa9CAc6aR7+h5C1Ot1uWgQt5nD tS2iZuxQrOxmn4wtUragIhgp75awupswS9ufo+IJQfTfKMDX+tLeE1PGIjMbr3qtvDUj XIbYZjucnMQcCRU8zjB+QMSayecwe3WcxKEf0azhq5yAALEMluOohAg16IJ90OiaBJ7f KVnuILocvX248/V4zP4HmK5Cd1MPZR8V5ElsFnhrbyFP3qGMbqGFVQhcrepBCIZN3FOf KrlqlR/xh1Y3U2relugZgM1goyJq4e7bAuiCSF8/y64Wacw+z34a7B6nSuwCKkZxIUWT nVeA== X-Gm-Message-State: ALoCoQlgBLAkXd9zNSAf6vvKyLh7xdF0eWv9tJC7FBVA6tdV1lMZru1l0WDJn191NjE+F81/ROVk X-Received: by 10.58.207.74 with SMTP id lu10mr25191167vec.15.1398717829568; Mon, 28 Apr 2014 13:43:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Mon, 28 Apr 2014 13:43:28 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <535EB33F.7090006@cisco.com> From: Tim Bray Date: Mon, 28 Apr 2014 13:43:28 -0700 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b6783ce5f6a7c04f8205fa8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/OMu-XGTr-ipKk6mshAHuZcbhkGQ Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] Topic #4: Software Behavior X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:43:51 -0000 --047d7b6783ce5f6a7c04f8205fa8 Content-Type: text/plain; charset=UTF-8 Draft language would be helpful. On Mon, Apr 28, 2014 at 1:38 PM, Nico Williams wrote: > On Mon, Apr 28, 2014 at 2:59 PM, Matt Miller wrote: > > "Section 3 of draft-json-01 implies draconian error handling - when a > > message is specified to be i-json but the receiver finds, for example, > > a dupe key, it is required to halt and catch fire. There?s a chance > > that this will be interpreted as 'tbray poisons JSON with XML > > draconianism'. People with alternate language should suggest it." > > > > If you have suggestions for better text -- or other comments/concerns > > on this language -- please respond to this thread with your > > suggestions or reasoning. > > As in my latest reply as to top-level value types, I think this is > best expressed as requiring an option in parser implementations. IMO > it'd be very bad if I-JSON parsers were to exist that are not also > JSON parsers (at least as an option) and which might then crowd out > JSON. > > Nico > -- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b6783ce5f6a7c04f8205fa8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dra= ft language would be helpful.

On Mon, Apr 28, 2014 at 1:38 PM, Nico Williams = <nico@cryptonector.com> wrote:
On Mon, Apr 28, 2014 at 2:59= PM, Matt Miller <mamille2@cisco.c= om> wrote:
> "Section 3 of draft-json-01 implies draconian error handling - wh= en a
> message is specified to be i-json but the receiver finds, for example,=
> a dupe key, it is required to halt and catch fire. There?s a chance > that this will be interpreted as 'tbray poisons JSON with XML
> draconianism'. People with alternate language should suggest it.&q= uot;
>
> If you have suggestions for better text -- or other comments/concerns<= br> > on this language -- please respond to this thread with your
> suggestions or reasoning.

As in my latest reply as to top-level value types, I think this is best expressed as requiring an option in parser implementations. =C2=A0IMO<= br> it'd be very bad if I-JSON parsers were to exist that are not also
JSON parsers (at least as an option) and which might then crowd out
JSON.

Nico
--

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

--047d7b6783ce5f6a7c04f8205fa8-- From nobody Mon Apr 28 13:52: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 31E531A6F9B for ; Mon, 28 Apr 2014 13:52:32 -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 cREEE2SK8uOD for ; Mon, 28 Apr 2014 13:52:31 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 62B221A6F5D for ; Mon, 28 Apr 2014 13:52:31 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id g10so1178557pdj.30 for ; Mon, 28 Apr 2014 13:52:30 -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:content-type; bh=GKifgRzZ6xCKyv3E6tUnZ1mggoI5CylInSgivUCovlU=; b=P1DmrAt4hV93Xy69ahDEtzbbrhSG1xMWi276pCNrC+Mw6GmbI6y4f0SOFZPRksH9eE izA80gybVX7f329FR4Bd01a//8RjbzlM/6ah/nv60T+7jv45oDyFkuA1VqcDD2rHWdEm eoTWtbmrM4zuM+EZouNwA408TrrS0jIBm5bmgqJWbdBOcFs39yNoYL/SqlJbqq4lB5bl 7SZvOofTn9WK7TuGF4onDnKjR06gvV7Sx4LA+q0KYbA7v37Zp0PrWxUeFhFsn3fWBvu3 JcfwbkaylmYBMqJkLwhEZ90Sma32vtmVQ3hu+SoPBMIh2shEhzx8k8NBHMXkqAnDopM/ w2yQ== X-Received: by 10.68.125.164 with SMTP id mr4mr27646545pbb.27.1398718350645; Mon, 28 Apr 2014 13:52:30 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.70.11.133 with HTTP; Mon, 28 Apr 2014 13:52:10 -0700 (PDT) In-Reply-To: References: <535EB33F.7090006@cisco.com> From: Jacob Davies Date: Mon, 28 Apr 2014 13:52:10 -0700 X-Google-Sender-Auth: LZDJyDQJhtfES4mfjK0xelQMfKw Message-ID: To: IETF JSON WG Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/ssFOwFfsK33_pc26Ta2zdSI8Kns Subject: Re: [Json] Topic #4: Software Behavior X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:52:32 -0000 It seems to me that all the requirements of the I-JSON profile (which I think is a good idea) are to be satisfied at the emitting end. The reading end can be I-JSON compliant, but the whole point is that any old JSON parser is very likely to be able to read I-JSON, isn't it? With no separate media type and no in-band marker, how can an parser possibly know it is looking at an I-JSON document? Therefore how can the compulsory error-handling behavior be specified? Or is the idea that an I-JSON parser is this strict about *all* JSON documents? In which case, this is essentially an effort to get the common understanding of "normal JSON" to be identical with I-JSON since I-JSON parsers will reject some legal JSON documents (which is true of any parser of course). Again I think that's probably a good idea as far as numbers & duplicate keys & illegal escapes are concerned. From nobody Mon Apr 28 13:52: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 4C0331A7D82 for ; Mon, 28 Apr 2014 13:52:44 -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_12=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 VK0vmiqtY2UT for ; Mon, 28 Apr 2014 13:52:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 345E21A70FD for ; Mon, 28 Apr 2014 13:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1360; q=dns/txt; s=iport; t=1398718357; x=1399927957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2gn7I/T9smmrTbt8jm/1mjPqLUK5FNomznNaMTsUzoA=; b=B2AUBzJwecfWMsGzetoDXEXuIdCDHtSo00zSYbQKQAFjmNvJRkaWrAfe OgmEb7yyGkAnDu03nniRjLiLwR9a9rQ3PZLKMO1qX8LTtLbC2l5dWZUzT QA8BtfPbTiljsBdd41LXfHqCs35/V54/PyDZ1RKQ5i7QLIHroL/93jX7j c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAAe/XlOtJV2c/2dsb2JhbABZgwaBJoJlwgUZgQIWdIIlAQEBBCMRRRACAQgOCgICJgICAjAVEAIEAQ0FiEGlEKM+F4EpjH0zB4JvgUoBA5kMkl6DMYIr X-IronPort-AV: E=Sophos;i="4.97,946,1389744000"; d="scan'208";a="320979971" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 28 Apr 2014 20:52:37 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3SKqcBn005746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Apr 2014 20:52:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 15:52:37 -0500 From: "Joe Hildebrand (jhildebr)" To: Tim Bray , "Matt Miller (mamille2)" Thread-Topic: [Json] I-JSON Topic #5: Numbers Thread-Index: AQHPYxzPc1qOL3zAFk6QxZ1T0YrJO5snzN0A//+jtwA= Date: Mon, 28 Apr 2014 20:52:36 +0000 Message-ID: References: <535EB3BF.8080606@cisco.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.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <59DF344F89D00E439C83222CE5986383@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/0OvLuVZZew4jT0ZqaLB4gNhHFFk Cc: IETF JSON WG Subject: Re: [Json] I-JSON Topic #5: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:52:44 -0000 V2lsbCB3ZSBuZWVkIHRvIHRhbGsgYWJvdXQgc3Vibm9ybWFscywgLTAsIE5hTiwgSW5maW5pdHks IGFuZCB0aGUgbGlrZT8NCg0KDQpPbiA0LzI4LzE0LCAyOjIyIFBNLCAiVGltIEJyYXkiIDx0YnJh eUB0ZXh0dWFsaXR5LmNvbT4gd3JvdGU6DQoNCj5JdCBvY2N1cnMgdG8gbWUgdGhhdCBpdCB3b3Vs ZCBiZSBzdXBlci11c2VmdWwgZm9yIHRoZSBkcmFmdCB0byBpbmNsdWRlDQo+ZXhwbGFuYXRpb24g b2YgaG93IHRvIGZvbGxvdyB0aGlzIHJ1bGUsIGluY2x1ZGluZyBleGFtcGxlcyBvZiBwcmludGYg YW5kDQo+SmF2YSBmb3JtYXQgc3RyaW5ncy4NCj4NCj4NCj4NCj5PbiBNb24sIEFwciAyOCwgMjAx NCBhdCAxOjAyIFBNLCBNYXR0IE1pbGxlcg0KPjxtYW1pbGxlMkBjaXNjby5jb20+IHdyb3RlOg0K Pg0KPi0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0NCj5IYXNoOiBTSEE1MTINCj4N Cj4iZHJhZnQtaS1qc29uLTAxIHNheXMgdGhhdCB5b3UgTVVTVCBub3QgcHV0IGluIGEgc3RyaW5n IHJlcHJlc2VudGluZyBhDQo+bnVtYmVyIHdpdGggZ3JlYXRlciBwcmVjaXNpb24vbWFnbml0dWRl IHRoYW4gSUVFRTc1NCBkb3VibGVzIGNhbg0KPnN1cHBvcnQuICAgSSB0aGluayB0aGlzIGlzIGEg Z29vZCBpZGVhIGJ1dCBJJ20gYSBsaXR0bGUgbmVydm91cw0KPmJlY2F1c2UgST92ZSBuZXZlciB3 cml0dGVuIHRoZSBjb2RlOyBpZiB0aGlzIGlzIHVucmVhc29uYWJseSBoYXJkIGF0DQo+ZWl0aGVy IHRoZSBzZW5kaW5nIG9yIHJlY2VpdmluZyBlbmQgc29tZW9uZSBzaG91bGQgc2F5IHNvLiINCj4N Cj5JZiB5b3UgaGF2ZSBzdWdnZXN0aW9ucyBmb3IgYmV0dGVyIHRleHQgLS0gb3Igb3RoZXIgY29t bWVudHMvY29uY2VybnMNCj5vbiB0aGlzIGxhbmd1YWdlIC0tIHBsZWFzZSByZXNwb25kIHRvIHRo aXMgdGhyZWFkIHdpdGggeW91cg0KPnN1Z2dlc3Rpb25zIG9yIHJlYXNvbmluZy4NCg0KDQotLSAN CkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Mon Apr 28 14:04:25 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5921A7035 for ; Mon, 28 Apr 2014 14:04:23 -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 E73w7xm3MtEi for ; Mon, 28 Apr 2014 14:04:22 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id ABAC71A86DE for ; Mon, 28 Apr 2014 14:04:18 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id jt11so4521380pbb.26 for ; Mon, 28 Apr 2014 14:04:18 -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=pAh3fTc/Ll5xQCxezE197UheyOKXL8LN851KtNOLzKc=; b=abcGyQpckyifXln3XjR2SEC4DUTS1BKPFqoeB4Ia9LsOnCIZspbPnIi5251WeJtbRO BPy6BCNi9eGh27CHVibicp/msbyt8vrVcKldIXdtY5eu83W1QbRvMizchNn2K+lc2puS k6o0lTz9BuFyd/AnlUaXe4wQbHI20XzRt2XNEZstJ99R9AuMfm5AD/eoh52mDkfBjdSD DPcgdOuOz+VUf+xR7la9aVbeCgpIBrVVX66+WpdFneYdf0FgRXnVOQ/3gKbxix+sTs8h Llz3Uh+2LGj9tRhvySknOlJumYULUnBkIyvgR43arBZOsSZL93h/CYBgZQhH8I6aXIfr p6wg== X-Received: by 10.66.248.228 with SMTP id yp4mr27794800pac.94.1398719057934; Mon, 28 Apr 2014 14:04:17 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.70.11.133 with HTTP; Mon, 28 Apr 2014 14:03:57 -0700 (PDT) In-Reply-To: References: <535EB119.4000908@cisco.com> From: Jacob Davies Date: Mon, 28 Apr 2014 14:03:57 -0700 X-Google-Sender-Auth: V3XH0rylxmUWGmXVIssiMZvGwFM 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/s5YK2QopF4AJMQg_hIEiwlGee6c Cc: Matt Miller , Tim Bray , IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 21:04:24 -0000 Requiring an object at the top level breaks the symmetry of JSON, rules out many useful applications (or requires a clumsy envelope for them), and needlessly conflicts with actual practice. It is solving a problem I am not convinced anyone really runs into - using (say) a JSON string instead of a JSON object and then oops not being able to pass along some extra metadata later (and for some reason HTTP headers or some similar mechanism won't work). In fact one of the nice things about JSON is that if you change your mind and decide to send objects instead of strings in some application you can know that the transport will support them; you can even allow older senders to keep sending strings, and new ones to send objects, and have the receiver accept both. Requiring further future-proofing with top-level objects seems very invasive. On Mon, Apr 28, 2014 at 1:36 PM, Nico Williams wrot= e: > On Mon, Apr 28, 2014 at 3:20 PM, Tim Bray wrote: >> Protocols with messages which are objects are better than other protocol= s, >> because they are architecturally friendly to MustIgnore policies. >> >> Allowing top-level JSON to be a primitive - true, null, 42 - is batshit >> crazy for anything the IETF might contemplate, and one of I-JSON=E2=80= =99s main >> virtues is ruling that out. > > What if the service outputs JSON texts output by a jq program supplied > by the client and applied to server-side data? > >> I don=E2=80=99t think top-level arrays are actively harmful at the same = level, but >> the MustIgnore is a pretty big value-add, forcing people to sort-of >> future-proof themselves even when they haven=E2=80=99t realized why that= =E2=80=99s a good >> idea. > > Why can't schema changes be communicated out-of-band? Apps request > JSON in a particular schema; servers report the schema when the schema > was not requested... > > I can see the value in recommending the use of top-level objects in > general, just not in requiring it. > > Still, I think if you want to say "so don't use I-JSON", I think > that's mostly fine. The only problem that comes up is the possibility > that I-JSON would crowd out JSON to the point where non-I-JSON might > not be usable. I think what I'd want to see there is that JSON > parsers should really just have an option as to this, rather than have > I-JSON parsers that are not also JSON parsers. > > Nico > -- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Mon Apr 28 14:12: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 559EE1A7030 for ; Mon, 28 Apr 2014 14:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, 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 UAovVsaeVEDK for ; Mon, 28 Apr 2014 14:12:06 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 68B551A6FBB for ; Mon, 28 Apr 2014 14:12:06 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id lf12so6539627vcb.41 for ; Mon, 28 Apr 2014 14:12:05 -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=K/7QY2aPZKloj5a0WSuZv8P2Baf03JxlS4MdB1NJfFs=; b=hcph11Pf0ElGwHbit6MMsF3pwdbiXTPPvv8vCf2q59Uiy55hCZgK74Ei3dIpfS7PtC 2SLUJ2+57GeR7yHlWET34Cp9g4ey8zldi53QcZ3jYEpL4OCateuuzD+6isCJQKe4Akzc 5dP3DT0LILzPN8amnRqmQxs3POq41m+YpXygRyRGeDpaTI7cor2FEcvUrjgWE1D9AhX3 vYoUDraPTkIEpSyLhNF5JC0p4QVeMFjrOM43mbhRgcNNx/++fQXOXpPoBvZ9jBc1K2/u OgjkGmq7vnTl9SAlO7/ErbxYhvxLb2Rv3zIUi49/NZPn61fsHVOVt66nKUNGO0xSvESl fnDA== X-Gm-Message-State: ALoCoQlU94Yl8iNf/MYNHNarVfgcof4ll9XSR8fq2zS5NecHaHN2Em2abGlfhMu2RLIqvQJygL7N X-Received: by 10.58.31.136 with SMTP id a8mr26480125vei.20.1398719525450; Mon, 28 Apr 2014 14:12:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Mon, 28 Apr 2014 14:11:45 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <535EB3BF.8080606@cisco.com> From: Tim Bray Date: Mon, 28 Apr 2014 14:11:45 -0700 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b2e49d07487ec04f820c4a3 Archived-At: http://mailarchive.ietf.org/arch/msg/json/pxdtHcq2UQvdkNilNtYYrhjgM9A Cc: IETF JSON WG , "Matt Miller \(mamille2\)" Subject: Re: [Json] I-JSON Topic #5: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:12:07 -0000 --047d7b2e49d07487ec04f820c4a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, they=E2=80=99re disallowed in JSON let alone i-json so I=E2=80=99d ha= ve hoped we can ignore them. On Mon, Apr 28, 2014 at 1:52 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > Will we need to talk about subnormals, -0, NaN, Infinity, and the like? > > > On 4/28/14, 2:22 PM, "Tim Bray" wrote: > > >It occurs to me that it would be super-useful for the draft to include > >explanation of how to follow this rule, including examples of printf and > >Java format strings. > > > > > > > >On Mon, Apr 28, 2014 at 1:02 PM, Matt Miller > > wrote: > > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA512 > > > >"draft-i-json-01 says that you MUST not put in a string representing a > >number with greater precision/magnitude than IEEE754 doubles can > >support. I think this is a good idea but I'm a little nervous > >because I?ve never written the code; if this is unreasonably hard at > >either the sending or receiving end someone should say so." > > > >If you have suggestions for better text -- or other comments/concerns > >on this language -- please respond to this thread with your > >suggestions or reasoning. > > > -- > Joe Hildebrand > > > > --047d7b2e49d07487ec04f820c4a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wel= l, they=E2=80=99re disallowed in JSON let alone i-json so I=E2=80=99d have = hoped we can ignore them.


On Mon, Apr 28, 2014 at 1:52 PM, Joe Hildebrand (jhildebr) <jhildebr@cisc= o.com> wrote:
Will we need to talk about subnormals, -0, NaN, Infinity, and the like?


On 4/28/14, 2:22 PM, "Tim Bray" <tbray@textuality.com> wrote:

>It occurs to me that it would be super-useful for the draft to include<= br> >explanation of how to follow this rule, including examples of printf an= d
>Java format strings.
>
>
>
>On Mon, Apr 28, 2014 at 1:02 PM, Matt Miller
><mamille2@cisco.com> wr= ote:
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>"draft-i-json-01 says that you MUST not put in a string representi= ng a
>number with greater precision/magnitude than IEEE754 doubles can
>support. =C2=A0 I think this is a good idea but I'm a little nervou= s
>because I?ve never written the code; if this is unreasonably hard at >either the sending or receiving end someone should say so."
>
>If you have suggestions for better text -- or other comments/concerns >on this language -- please respond to this thread with your
>suggestions or reasoning.


--
Joe Hildebrand



--047d7b2e49d07487ec04f820c4a3-- From nobody Mon Apr 28 14:13: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 3FC921A7030 for ; Mon, 28 Apr 2014 14:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-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 U-dCuPTpfAxv for ; Mon, 28 Apr 2014 14:13:53 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id D6AC11A6FBB for ; Mon, 28 Apr 2014 14:13:52 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id sa20so211556veb.15 for ; Mon, 28 Apr 2014 14:13:51 -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=k7egYT+OVad/TK592V3bd3RkWvhZ4VjU/wWWOuvvRqs=; b=J1qHreQHDdbHFjs2eKbgqwfpiGD4B63JD7ylEfPEE2mFXhp+iG/EQ8kkPR6DG5fJ0L 53sGjIb8V4B6n17WyPqhb3Y32Z8CCCOpPLYOPIH7j0USNS1bFluFumTqoYoZEAiKbFHd tDoeLaWwLkBLb1IWLTPFxQzCDrWw5pbiqgkIwR++rCNrODpGLosNcZmDcnBSrFjshs5K YuqBMWkWJZWlGXhtT3/b4dBQsNKA2A8Ac1k/KQeEEuIjpaGEkgonlGCUa/N/8gGd4wkf ioCmcZx3IBNTvcAoEX81POt4aILCp3mhzS1CMz+r4xub5oJBxTtiswZVQ7pMJJfeKaZz i9sw== X-Gm-Message-State: ALoCoQn2cctdbAEbzGcD3Uif/YUzCzFq/l8sFAXl90/XVhcCwoi8oDkmLTDsKxJ4/w6mmyjNhwMu X-Received: by 10.52.237.228 with SMTP id vf4mr1804916vdc.47.1398719631861; Mon, 28 Apr 2014 14:13:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Mon, 28 Apr 2014 14:13:31 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <535EB33F.7090006@cisco.com> From: Tim Bray Date: Mon, 28 Apr 2014 14:13:31 -0700 Message-ID: To: Jacob Davies Content-Type: multipart/alternative; boundary=089e0122f6aacc3dbb04f820ca56 Archived-At: http://mailarchive.ietf.org/arch/msg/json/blK_tLZIaGoqzZbYedGdmjmAViw Cc: IETF JSON WG Subject: Re: [Json] Topic #4: Software Behavior X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:13:57 -0000 --089e0122f6aacc3dbb04f820ca56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My mental model is that some working group, for example over in JOSE, says =E2=80=9Cmessages MUST be I-JSON=E2=80=9D and then people who are implement= ing the code that receives such messages tells the JSON library to go into i-json mode. On Mon, Apr 28, 2014 at 1:52 PM, Jacob Davies wrote: > It seems to me that all the requirements of the I-JSON profile (which > I think is a good idea) are to be satisfied at the emitting end. The > reading end can be I-JSON compliant, but the whole point is that any > old JSON parser is very likely to be able to read I-JSON, isn't it? > > With no separate media type and no in-band marker, how can an parser > possibly know it is looking at an I-JSON document? Therefore how can > the compulsory error-handling behavior be specified? Or is the idea > that an I-JSON parser is this strict about *all* JSON documents? In > which case, this is essentially an effort to get the common > understanding of "normal JSON" to be identical with I-JSON since > I-JSON parsers will reject some legal JSON documents (which is true of > any parser of course). Again I think that's probably a good idea as > far as numbers & duplicate keys & illegal escapes are concerned. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e0122f6aacc3dbb04f820ca56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My = mental model is that some working group, for example over in JOSE, says =E2= =80=9Cmessages MUST be I-JSON=E2=80=9D and then people who are implementing= the code that receives such messages tells the JSON library to go into i-j= son mode. =C2=A0=C2=A0


On Mon,= Apr 28, 2014 at 1:52 PM, Jacob Davies <jacob@well.com> wrote:<= br>
It seems to me that all the requirements of the I-JSON profile (which
I think is a good idea) are to be satisfied at the emitting end. The
reading end can be I-JSON compliant, but the whole point is that any
old JSON parser is very likely to be able to read I-JSON, isn't it?

With no separate media type and no in-band marker, how can an parser
possibly know it is looking at an I-JSON document? Therefore how can
the compulsory error-handling behavior be specified? Or is the idea
that an I-JSON parser is this strict about *all* JSON documents? In
which case, this is essentially an effort to get the common
understanding of "normal JSON" to be identical with I-JSON since<= br> I-JSON parsers will reject some legal JSON documents (which is true of
any parser of course). Again I think that's probably a good idea as
far as numbers & duplicate keys & illegal escapes are concerned.

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

--089e0122f6aacc3dbb04f820ca56-- From nobody Mon Apr 28 14:17: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 C9E3B1A07A2 for ; Mon, 28 Apr 2014 14:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 SAMBvdMGvRYF for ; Mon, 28 Apr 2014 14:16:57 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id AEDDE1A6FFC for ; Mon, 28 Apr 2014 14:16:57 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id im17so9109195vcb.0 for ; Mon, 28 Apr 2014 14:16:56 -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=D4blf9XqnFR5IjxLTTS3hfTjI4hLeH7D4SE7/srdfd4=; b=LWfM2WZVMLRz761+x1+RvITEi1259tFLK846VORZYKkpSeKH5R+LShAza1kNn8doSK WW0RC9+bIvNK/+5Bm9f3ssEIXify9aX2IkBZRbTDi9rra117UVtLFmIwIxnCi6NlgU9I LA2NtdJnX5P/s/m3+8yA3mHOGiUmzTDddz3beBRMR72WnktmB8kWn0omsqXPb5R8nGEY n8ouqbP+kJUaKI9YlFV9SLQu2SDLWuuCuKTFYMvGZMH0bdigaGBhX6Y/8JeuvtMTymyR ggwYgd6BFZ4wZEzRjhPOspJYFhrwsaXnTpKPPdfygeC/ZksiU1K7wDecsnCWTcil5qYv wj4w== X-Gm-Message-State: ALoCoQl28NacW1SJ1P+ssV+0jy+ZqSCotwgIuNXsrsRIdc4PXQvc5fNms22GznY0E6vRK5XXucHl X-Received: by 10.58.34.67 with SMTP id x3mr2182116vei.37.1398719816670; Mon, 28 Apr 2014 14:16:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Mon, 28 Apr 2014 14:16:36 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <535EB119.4000908@cisco.com> From: Tim Bray Date: Mon, 28 Apr 2014 14:16:36 -0700 Message-ID: To: Jacob Davies Content-Type: multipart/alternative; boundary=089e013a0d72d030bf04f820d57e Archived-At: http://mailarchive.ietf.org/arch/msg/json/c2l4W8_zIZWl_bgimKjqkHEh2DY Cc: Nico Williams , Matt Miller , IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 21:17:00 -0000 --089e013a0d72d030bf04f820d57e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable RFC 7159 already says that for interoperability, top level objects should be objects or arrays. At the simplest level, if all I-JSON does is forbid all the things that 7159 calls out as interoperability problems, that would be good enough for me. The notion that i-json would *weaken* 7159=E2=80=99= s requirements by allowing a top level object to consist of just true or "true" seems outlandish to me. ...It=E2=80=99s dawning on me that a piece on MustIgnore and why it=E2=80= =99s a big deal might be useful... On Mon, Apr 28, 2014 at 2:03 PM, Jacob Davies wrote: > Requiring an object at the top level breaks the symmetry of JSON, > rules out many useful applications (or requires a clumsy envelope for > them), and needlessly conflicts with actual practice. It is solving a > problem I am not convinced anyone really runs into - using (say) a > JSON string instead of a JSON object and then oops not being able to > pass along some extra metadata later (and for some reason HTTP headers > or some similar mechanism won't work). In fact one of the nice things > about JSON is that if you change your mind and decide to send objects > instead of strings in some application you can know that the transport > will support them; you can even allow older senders to keep sending > strings, and new ones to send objects, and have the receiver accept > both. Requiring further future-proofing with top-level objects seems > very invasive. > > On Mon, Apr 28, 2014 at 1:36 PM, Nico Williams > wrote: > > On Mon, Apr 28, 2014 at 3:20 PM, Tim Bray wrote: > >> Protocols with messages which are objects are better than other > protocols, > >> because they are architecturally friendly to MustIgnore policies. > >> > >> Allowing top-level JSON to be a primitive - true, null, 42 - is batshi= t > >> crazy for anything the IETF might contemplate, and one of I-JSON=E2=80= =99s main > >> virtues is ruling that out. > > > > What if the service outputs JSON texts output by a jq program supplied > > by the client and applied to server-side data? > > > >> I don=E2=80=99t think top-level arrays are actively harmful at the sam= e level, > but > >> the MustIgnore is a pretty big value-add, forcing people to sort-of > >> future-proof themselves even when they haven=E2=80=99t realized why th= at=E2=80=99s a > good > >> idea. > > > > Why can't schema changes be communicated out-of-band? Apps request > > JSON in a particular schema; servers report the schema when the schema > > was not requested... > > > > I can see the value in recommending the use of top-level objects in > > general, just not in requiring it. > > > > Still, I think if you want to say "so don't use I-JSON", I think > > that's mostly fine. The only problem that comes up is the possibility > > that I-JSON would crowd out JSON to the point where non-I-JSON might > > not be usable. I think what I'd want to see there is that JSON > > parsers should really just have an option as to this, rather than have > > I-JSON parsers that are not also JSON parsers. > > > > Nico > > -- > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > --089e013a0d72d030bf04f820d57e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC= 7159 already says that for interoperability, top level objects should be o= bjects or arrays. =C2=A0At the simplest level, if all I-JSON does is forbid= all the things that 7159 calls out as interoperability problems, that woul= d be good enough for me. =C2=A0The notion that i-json would *weaken* 7159= =E2=80=99s requirements by allowing a top level object to consist of just t= rue or "true" seems outlandish to me.

...It=E2=80=99s dawning on me = that a piece on MustIgnore and why it=E2=80=99s a big deal might be useful.= ..


On Mon, Apr 28, 2014 at 2:03 PM, Jacob D= avies <jacob@well.com> wrote:
Requiring an object at the top level breaks the symmetry of JSON,
rules out many useful applications (or requires a clumsy envelope for
them), and needlessly conflicts with actual practice. It is solving a
problem I am not convinced anyone really runs into - using (say) a
JSON string instead of a JSON object and then oops not being able to
pass along some extra metadata later (and for some reason HTTP headers
or some similar mechanism won't work). In fact one of the nice things about JSON is that if you change your mind and decide to send objects
instead of strings in some application you can know that the transport
will support them; you can even allow older senders to keep sending
strings, and new ones to send objects, and have the receiver accept
both. Requiring further future-proofing with top-level objects seems
very invasive.

On Mon, Apr 28, 2014 at 1:36 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Mon, Apr 28, 2014 at 3:20 PM, Tim Bray <tbray@textuality.com> wrote:
>> Protocols with messages which are objects are better than other pr= otocols,
>> because they are architecturally friendly to MustIgnore policies.<= br> >>
>> Allowing top-level JSON to be a primitive - true, null, 42 - is ba= tshit
>> crazy for anything the IETF might contemplate, and one of I-JSON= =E2=80=99s main
>> virtues is ruling that out.
>
> What if the service outputs JSON texts output by a jq program supplied=
> by the client and applied to server-side data?
>
>> I don=E2=80=99t think top-level arrays are actively harmful at the= same level, but
>> the MustIgnore is a pretty big value-add, forcing people to sort-o= f
>> future-proof themselves even when they haven=E2=80=99t realized wh= y that=E2=80=99s a good
>> idea.
>
> Why can't schema changes be communicated out-of-band? =C2=A0Apps r= equest
> JSON in a particular schema; servers report the schema when the schema=
> was not requested...
>
> I can see the value in recommending the use of top-level objects in > general, just not in requiring it.
>
> Still, I think if you want to say "so don't use I-JSON",= I think
> that's mostly fine. =C2=A0The only problem that comes up is the po= ssibility
> that I-JSON would crowd out JSON to the point where non-I-JSON might > not be usable. =C2=A0I think what I'd want to see there is that JS= ON
> parsers should really just have an option as to this, rather than have=
> I-JSON parsers that are not also JSON parsers.
>
> Nico
> --
>
> __________________= _____________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

--089e013a0d72d030bf04f820d57e-- From nobody Mon Apr 28 14:18: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 262111A7030 for ; Mon, 28 Apr 2014 14:18:50 -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 E5drlz1fBARL for ; Mon, 28 Apr 2014 14:18:49 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 021B91A07A2 for ; Mon, 28 Apr 2014 14:18:48 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id jt11so4571305pbb.40 for ; Mon, 28 Apr 2014 14:18:48 -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; bh=tmfFkzCgNnqx8x8Lf7HT6XA28IV/PSTvY2E62qgdC8g=; b=WEEK17zuQOTm/34VP0u0et9El9ywdLLwjdJSYds0VH+bQOr6HbpQJvzaUri8J1K+wZ VKAW1AAxb7oZfeme8JryY5xIyNv9r77HqEwTXhu/GL46GG9Mx/A2dbcV76NRDcSRIb/r WpLQeyX//ybaOUxxXtKDHe2Vx4NBsaeKxDDIyN3YFK0bFnMAat3Dwb7ug/htOickUEHd xLQXLrXl7wKlgFECXNArz+KksNDUnRFs+uknyNCgeL0tTMHdpp9dpOsUWe1By7heD/Ga ZLd1TxJJ26KVAujuTMm29T3ATI7Gt0MHFDPCySKoyeoxVYVeMsnMsYIJSL9B2j0m/sOJ Blqg== X-Received: by 10.68.133.229 with SMTP id pf5mr27843724pbb.115.1398719928334; Mon, 28 Apr 2014 14:18:48 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.70.11.133 with HTTP; Mon, 28 Apr 2014 14:18:28 -0700 (PDT) In-Reply-To: References: <535EB3BF.8080606@cisco.com> From: Jacob Davies Date: Mon, 28 Apr 2014 14:18:28 -0700 X-Google-Sender-Auth: tBKgo6R_n6tgknEJuxXigHlFPSI Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/json/Z7OGYpb9OhJUCXBv3MzpVHa0jSA Cc: IETF JSON WG , Tim Bray , "Matt Miller \(mamille2\)" Subject: Re: [Json] I-JSON Topic #5: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:18:50 -0000 On Mon, Apr 28, 2014 at 1:52 PM, Joe Hildebrand (jhildebr) wrote: > Will we need to talk about subnormals, -0, NaN, Infinity, and the like? NaN & infinity yes. Dunno about -0. I think the burden on the emitter of requiring compliance is low. In Java AFAIK it's just a case of checking that the value is a legal double value, is not NaN and not infinite, and converting it with default toString() (you can trim ".0" from the end if present for neatness). On the receiver I think it would be rather more difficult. From nobody Mon Apr 28 14:28: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 9B8E51A6F03 for ; Mon, 28 Apr 2014 14:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 TxcDmbzZ5OAa for ; Mon, 28 Apr 2014 14:28:31 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5801A07A2 for ; Mon, 28 Apr 2014 14:28:30 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gl10so1879420lab.24 for ; Mon, 28 Apr 2014 14:28:29 -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:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iUnQQ894cSR2saVo+eWtigeuyBM8622DnJuUPLYZRfw=; b=hyAEzq38Bja29XpfA/PMEVKPNF1DRZ24voECD2MKFDje/uA/qAX/g6RJKlEPXkg83y yckwAXL2TlqzX2tcJNH2mOZvPnP8zEJXZFkTCajL9UzHZ4mHnxHbGWVHHnI1phTG6u79 3E0n4AhPwa1ZpsKIQtFHta9oYP780CHbewXGVD4dKGQfh+UOyabXC4AQP0HzvjKu+PXa IUprm+olNWbewGyfUo0T2ryZRrpcuBcx538vXH//1FbPyDK9j+a/6ZybFhdD6T3P9aHB JxUAgN4bLnKYlqYf+h7lkyF+F7c1Pboh6zum99I3AjvlTcMX7Op0BpUVogOwSucOjlHW GL/w== X-Gm-Message-State: ALoCoQnzIQ1ZNVS45HtvuGzEiauDHlUZlF/WbH9khbk8PhT3eED8fsmdFLKWEBWqBfi1bgNQZjQJ MIME-Version: 1.0 X-Received: by 10.153.7.69 with SMTP id da5mr3206983lad.38.1398720509434; Mon, 28 Apr 2014 14:28:29 -0700 (PDT) Sender: mmorley@mpcm.com Received: by 10.114.0.172 with HTTP; Mon, 28 Apr 2014 14:28:29 -0700 (PDT) In-Reply-To: <535EB119.4000908@cisco.com> References: <535EB119.4000908@cisco.com> Date: Mon, 28 Apr 2014 17:28:29 -0400 X-Google-Sender-Auth: MsniB8gJRRGbvvMQAPtZbrNjEcg Message-ID: From: Matthew Morley To: Matt Miller Content-Type: multipart/alternative; boundary=001a113456301af19104f820ffd5 Archived-At: http://mailarchive.ietf.org/arch/msg/json/ORbXpmIs0ekIreaaAAOKPkdK6wE Cc: IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 21:28:33 -0000 --001a113456301af19104f820ffd5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 28, 2014 at 3:50 PM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > "draft-i-json-01 says the top level is an object (but doesn=E2=80=99t say > MUST, eek). I have heard arguments for allowing arrays too." > > If you are in favor -- or not -- of restricting the top-level I-JSON > text to only be object (or array / object), please respond to this > thread with your reasoning. > I am not in favor of restricting the top-level I-JSON text only to be an object. This would make it stricter than RFC4627/ecma-262 and then stand to muddy the waters of what the application/json media type currently states. I don't believe it is a good idea to make this stricter, without a matching media type, which I think makes this also a non-starter. I am content to see it as array or object at the top level. Since this seems to be the current level of accepted use by most people within the JSON community due to RFC4627. But, I would greatly prefer that any JSON value be allowed as the top level item. The requirement that any JSON value be represented within a structure creates an amount of unneeded indirection and overhead. If my program intends to set a local value to be the response from another source. It should not have to know that it must descend into the actual result to obtain the sources intended value. If both sides agree to send array/object structures, akin to golang's multiple return values, I consider this a better practice. But it should not be a requirement, or an imposed overhead. Add to this, http://www.ecma-international.org/ecma-262/5.1/#sec-15.12.1.2s= eems to define JSON text as any JSON value in contrast with RFC4627. My reading/understanding of RFC4267/ecma-262 may be incorrect, but my feeling that restrictions on the top level value should be lifted, not tightened. > > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > * "How to Argue about I-JSON" < > http://www.ietf.org/mail-archive/web/json/current/msg02775.html > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTXrEZAAoJEDWi+S0W7cO1bjAH/RxLeWEABXMoJEJrw92lYfkP > bLgoS7TRoSxVdUY9K8SVMEJKHMrY2QrK/aNqhwlpWvIirM70xFUT7Sb40M+Msmm/ > qFZTFfVRdRsnqsd21dciZ6hA4eSDfkP81cIoMn4MiCx8EExZCj7yroWaTor8jNct > 7BgVCWkom2ENVNOb6JEPFa7LD6hpm/9vx1FHctbDgreJuhsYxY9Uy17h/BjxxwPc > NkNFbo+OX4Zw6f053cKWbITps/R+IAM57atzJ9PgGpMpN+POQJF/BihnB1qRdUsv > y8QqQ1s8r47DauWQ0eX4BxgPXeGV+jBqXrtVAzyNq2B7KFkDukf9UVahUaJjwJU=3D > =3DnAfX > -----END PGP SIGNATURE----- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 Matthew P. C. Morley --001a113456301af19104f820ffd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Apr 28, 2014 at 3:50 PM, Matt Miller <mamille2@cisco.com>= wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

"draft-i-json-01 says the top level is an object (but doesn=E2=80=99t = say
MUST, eek). =C2=A0I have heard arguments for allowing arrays too."

If you are in favor -- or not -- of restricting the top-level I-JSON
text to only be object (or array / object), please respond to this
thread with your reasoning.

I am not in= favor of restricting the top-level I-JSON text only to be an object.=C2=A0= This would make it stricter than RFC4627/ecma-262 and then stand to muddy t= he waters of what the application/json media type currently states. I don&#= 39;t believe it is a good idea to make this stricter, without a matching me= dia type, which I think makes this also a non-starter.

I am content to see it as array or object at the top level. Since this = seems to be the current level of accepted use by most people within the JSO= N community due to RFC4627.=C2=A0

But, I would greatly prefer that a= ny JSON value be allowed as the top level item. The requirement that any JS= ON value be represented within a structure creates an amount of unneeded in= direction and overhead.

If my program intends to set a local value to be the response from anot= her source. It should not have to know that it must descend into the actual= result to obtain the sources intended value. If both sides agree to send a= rray/object structures, akin to golang's multiple return values, I cons= ider this a better practice. But it should not be a requirement, or an impo= sed overhead.

Add to this,=C2=A0http://www.ecma-international.org/ecma-262/5.1/#sec-15= .12.1.2 seems to define JSON text as any JSON value in contrast with RF= C4627.=C2=A0My reading/understanding of RFC4267/ecma-262 may be incorrect, = but my feeling that restrictions on the top level value should be lifted, n= ot tightened.

=C2=A0


- --
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

* "How to Argue about I-JSON" <
http://www.ietf.org/mail-archive/web/json/current/msg027= 75.html >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTXrEZAAoJEDWi+S0W7cO1bjAH/RxLeWEABXMoJEJrw92lYfkP
bLgoS7TRoSxVdUY9K8SVMEJKHMrY2QrK/aNqhwlpWvIirM70xFUT7Sb40M+Msmm/
qFZTFfVRdRsnqsd21dciZ6hA4eSDfkP81cIoMn4MiCx8EExZCj7yroWaTor8jNct
7BgVCWkom2ENVNOb6JEPFa7LD6hpm/9vx1FHctbDgreJuhsYxY9Uy17h/BjxxwPc
NkNFbo+OX4Zw6f053cKWbITps/R+IAM57atzJ9PgGpMpN+POQJF/BihnB1qRdUsv
y8QqQ1s8r47DauWQ0eX4BxgPXeGV+jBqXrtVAzyNq2B7KFkDukf9UVahUaJjwJU=3D
=3DnAfX
-----END PGP SIGNATURE-----

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



--
Matthew P. C= . Morley
--001a113456301af19104f820ffd5-- From nobody Mon Apr 28 14:28:47 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60A51A802C for ; Mon, 28 Apr 2014 14:28:44 -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] 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 JOyzlxaro4c8 for ; Mon, 28 Apr 2014 14:28:44 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 262B01A797C for ; Mon, 28 Apr 2014 14:28:44 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 769482007DA12 for ; Mon, 28 Apr 2014 14:28:43 -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=eSWe7QJKn6Xw+9IDDVdgdfV8FoY=; b=ryGl/KWGfnd Oy7S7uyAsTrL4illX9j+58HB8zqKUFyK46dQjSY2VspvTlYRpchiVXPe4zvzGtih z1kSycDVBZMmn5Dzerg3o4//KNgUbVHbAtsbtRaYPhoJp1NvWuWu4f9R+KMF75R0 wEM4rwf8dTjX/w/C3cDts0o2UyXoBCKE= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 2C2E82005D824 for ; Mon, 28 Apr 2014 14:28:42 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id t60so5109081wes.22 for ; Mon, 28 Apr 2014 14:28:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.105.132 with SMTP id gm4mr17183333wib.39.1398720521856; Mon, 28 Apr 2014 14:28:41 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 14:28:41 -0700 (PDT) In-Reply-To: References: <535EB119.4000908@cisco.com> Date: Mon, 28 Apr 2014 16:28:41 -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/kBLxr4R_6bAVuskFveRrCrYoRZU Cc: Matt Miller , Jacob Davies , IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 21:28:44 -0000 On Mon, Apr 28, 2014 at 4:16 PM, Tim Bray wrote: > RFC 7159 already says that for interoperability, top level objects should= be > objects or arrays. At the simplest level, if all I-JSON does is forbid a= ll > the things that 7159 calls out as interoperability problems, that would b= e > good enough for me. The notion that i-json would *weaken* 7159=E2=80=99s > requirements by allowing a top level object to consist of just true or > "true" seems outlandish to me. That was a hard-won but-grudging concession to reality. All encoders and parser I checked have long had an option to permit scalars at the top-level; RFC7159 should have required that by default scalars be accepted at the top-level given that such things are found in the wild. I don't really care to re-argue that -- grudging or not, the concession was all that mattered. But if we're going to argue about what I-JSON should do about the top-level based on the fact that the concession in RFC7159 was grudging, then I guess we'll have to re-argue this! But I'd rather focus on why one might want to mandate objects at the top-level, what to do when one has an array (use text sequences?!), and what to do when this isn't appropriate ("don't use I-JSON" being fine, provided we don't end up squeezing out non-I JSON). Nico -- From nobody Mon Apr 28 15:10:37 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9A11A6FCE for ; Mon, 28 Apr 2014 15:10:25 -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 ulM7uPArhKbd for ; Mon, 28 Apr 2014 15:10:17 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D90BA1A7035 for ; Mon, 28 Apr 2014 15:10:10 -0700 (PDT) Received: from [192.168.1.67] (unknown [118.209.107.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F352450A86; Mon, 28 Apr 2014 18:10:06 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: Date: Tue, 29 Apr 2014 08:10:01 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <535EB119.4000908@cisco.com> To: Tim Bray X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/eHXk_2dxK-qjjT3fs7p6P895PYc Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 22:10:26 -0000 On 29 Apr 2014, at 6:20 am, Tim Bray wrote: > Allowing top-level JSON to be a primitive - true, null, 42=E2=80=8B - = is batshit crazy for anything the IETF might contemplate, and one of = I-JSON=E2=80=99s main virtues is ruling that out.=20 Is the target audience for I-JSON just the IETF, or anyone who wants a = more interoperable profile of JSON? Regards, -- Mark Nottingham http://www.mnot.net/ From nobody Mon Apr 28 15: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 E09751A86F5 for ; Mon, 28 Apr 2014 15:13:46 -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 avZkiqQoSQja for ; Mon, 28 Apr 2014 15:13:43 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBB11A6FCE for ; Mon, 28 Apr 2014 15:13:43 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id oy12so8644956veb.26 for ; Mon, 28 Apr 2014 15:13:42 -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=eMX5pJUoSmdq2c1WezR8UvojXP9pCOyKhuATVEt1l1o=; b=CVQlSJ/tCIETvk17pHF1SXZElN4SjY5eEGCWlyEaOfVs/FBGi7+Pv/8WVSsGs8Admo nerYQeH3rOEYccg1Vk3Bbd5Z5M3pR0keK5Mc5nu4I+oHcs0pOy7+XmKwPg1BGT8CTrw5 oUkMsiCHDK6ezOCKank84/PPxz+nWG95o9ojsYX4TjADoh5dquAkxLrs3IGV7SCXJN1j kKFWftAM+ORbN3StafL1cJ2qrQDOGq8MYVEqV5IPCgcNk8i6tX46syqf6VIyHlBJ+D2t SOn0C8hSh3wa+ui/RD+L/lmhArvpQrVbm5hQQEkAfouzYAAkItjp7NTy/I3TriVGV0Lk zJ3g== X-Gm-Message-State: ALoCoQm1HkEXEDDCGIc6cCE6aMS8MKnpd61RfrHopGCdbmWMJdGbMe85hxoXZvARoB7rMpekXeJC X-Received: by 10.220.250.203 with SMTP id mp11mr25661491vcb.2.1398723222449; Mon, 28 Apr 2014 15:13:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Mon, 28 Apr 2014 15:13:21 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: References: <535EB119.4000908@cisco.com> From: Tim Bray Date: Mon, 28 Apr 2014 15:13:21 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=089e013d0502d0427f04f821a0d7 Archived-At: http://mailarchive.ietf.org/arch/msg/json/I-7CRLSURGHGaoQmEToERkNTD6I Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 28 Apr 2014 22:13:47 -0000 --089e013d0502d0427f04f821a0d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My main i-json motivation is application-level protocols, specifically JOSE-style stuff. So the IETF would be sort of the canonical user. -T On Mon, Apr 28, 2014 at 3:10 PM, Mark Nottingham wrote: > > On 29 Apr 2014, at 6:20 am, Tim Bray wrote: > > > Allowing top-level JSON to be a primitive - true, null, 42=E2=80=8B - i= s batshit > crazy for anything the IETF might contemplate, and one of I-JSON=E2=80=99= s main > virtues is ruling that out. > > Is the target audience for I-JSON just the IETF, or anyone who wants a > more interoperable profile of JSON? > > Regards, > > -- > Mark Nottingham http://www.mnot.net/ > > > > --089e013d0502d0427f04f821a0d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My = main i-json motivation is application-level protocols, specifically JOSE-st= yle stuff. =C2=A0So the IETF would be sort of the canonical user. -T
<= /div>


On Mon, Apr 28, 2014 at 3:10 PM, Mark No= ttingham <mnot@mnot.net> wrote:

On 29 Apr 2014, at 6:20 am, Tim Bray <tbray@textuality.com> wrote:

> Allowing top-level JSON to be a primitive - true, null, 42=E2=80=8B - = is batshit crazy for anything the IETF might contemplate, and one of I-JSON= =E2=80=99s main virtues is ruling that out.

Is the target audience for I-JSON just the IETF, or anyone who wants = a more interoperable profile of JSON?

Regards,

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




--089e013d0502d0427f04f821a0d7-- From nobody Mon Apr 28 17:41: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 A309B1A8852 for ; Mon, 28 Apr 2014 17:41:29 -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 zDrFIbOfQQoo for ; Mon, 28 Apr 2014 17:41:28 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id AA2811A8844 for ; Mon, 28 Apr 2014 17:41:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,948,1389704400"; d="scan'208";a="199910276" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 29 Apr 2014 10:41:25 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7422"; a="218115262" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbni.tcif.telstra.com.au with ESMTP; 29 Apr 2014 10:41:25 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 29 Apr 2014 10:41:24 +1000 From: "Manger, James" To: Nico Williams , "json@ietf.org" Date: Tue, 29 Apr 2014 10:41:23 +1000 Thread-Topic: [Json] New JSON Text Sequence I-D submitted Thread-Index: Ac9jF8HYObffFIbBS+aI0nC/1vm5bwAJbbJA Message-ID: <255B9BB34FB7D647A506DC292726F6E115456D2132@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/W875G4VmWzQj0D8IbPL5k2t7IZQ Subject: Re: [Json] New JSON Text Sequence I-D submitted X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Apr 2014 00:41:29 -0000 PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWpzb24tdGV4dC1z ZXF1ZW5jZS8NCg0KU2hvcnQgJiBzaW1wbGUg4oCUIGxvb2tzIGdvb2QuDQoNCjEuDQpPbmUgbWlz c2luZyBmZWF0dXJlIGlzIHRoYXQgYSBmaWxlIGNvbnRhaW5pbmcgb25seSB3aGl0ZXNwYWNlIHNo b3VsZCBiZSBhIHZhbGlkIEpTT04gdGV4dCBzZXF1ZW5jZS4gU3VnZ2VzdGVkIGNoYW5nZXM6DQoN CkZST006ICBKU09OLXNlcXVlbmNlID0gKihKU09OLXRleHQgMSood3MpKQ0KVE8gIDogIEpTT04t c2VxdWVuY2UgPSAqKHdzKSAqKEpTT04tdGV4dCAxKih3cykpDQoNClAuUy4gRG8geW91IG5lZWQg dGhlIGJyYWNrZXRzIGluICood3MpPw0KDQpGUk9NOiAgQSBKU09OIHRleHQgc2VxdWVuY2UgaXMg YSBzZXF1ZW5jZSBvZiBKU09OIHRleHRzDQpUTyAgOiAgQSBKU09OIHRleHQgc2VxdWVuY2UgaXMg YSBzZXF1ZW5jZSBvZiB6ZXJvLCBvbmUsIG9yIG1vcmUgSlNPTiB0ZXh0cw0KDQoNCjIuDQpXZSBj YW4ndCBoYXZlIGEgPHdzPiBBQk5GIHByb2R1Y3Rpb24gdGhhdCBpcyBkaWZmZXJlbnQgZnJvbSBS RkM3MTU5IEpTT04uIHdzIGluIEpTT04gaXMgdW5mb3J0dW5hdGUsIGJ1dCB3ZSBoYXZlIHRvIGxp dmUgd2l0aCBpdC4NCmpzb24tc2VxOiAgd3MgPSAgICAleDIwIC8gJXgwOSAvICV4MEEgLyAleDBE DQpqc29uICAgIDogIHdzID0gKiggJXgyMCAvICV4MDkgLyAleDBBIC8gJXgwRCApDQoNCkkgd291 bGQgYmUgdGVtcHRlZCB0byB3cml0ZSB0aGUgQUJORiB1c2luZyA8dmFsdWU+LCBpbnN0ZWFkIG9m IDxKU09OLXRleHQ+Lg0KDQogIEpTT04tc2VxdWVuY2UgPSAqd2hpdGVzcGFjZSAqKHZhbHVlIDEq d2hpdGVzcGFjZSkNCiAgd2hpdGVzcGFjZSA9ICV4MjAgLyAleDA5IC8gJXgwQSAvICV4MEQNCiAg dmFsdWUgPSA8Z2l2ZW4gYnkgUkZDNzE1OT4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From nobody Mon Apr 28 18:10: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 7A5971A8864 for ; Mon, 28 Apr 2014 18:10:31 -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 pouAaK9CNBLm for ; Mon, 28 Apr 2014 18:10:30 -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 163631A885B for ; Mon, 28 Apr 2014 18:10:29 -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 779D432E4F4; Tue, 29 Apr 2014 10:10:26 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 41f9_2507_19db4b9f_7247_4840_92d3_c4cf34315dc2; Tue, 29 Apr 2014 10:10:25 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 09A08BF4C5; Tue, 29 Apr 2014 10:10:26 +0900 (JST) Message-ID: <535EFBF5.6030208@it.aoyama.ac.jp> Date: Tue, 29 Apr 2014 10:10:13 +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.4.0 MIME-Version: 1.0 To: "Manger, James" , Nico Williams , "json@ietf.org" References: <255B9BB34FB7D647A506DC292726F6E115456D2132@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115456D2132@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/d1FK6wgWnFyMVvoEt-NzJjAreM4 Subject: Re: [Json] New JSON Text Sequence I-D submitted X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Apr 2014 01:10:31 -0000 On 2014/04/29 09:41, Manger, James wrote: > 1. > One missing feature is that a file containing only whitespace should be a valid JSON text sequence. Suggested changes: > FROM: A JSON text sequence is a sequence of JSON texts > TO : A JSON text sequence is a sequence of zero, one, or more JSON texts Can we make that: TO : A JSON text sequence is a sequence of zero or more JSON texts Regards, Martin. From nobody Mon Apr 28 21:29: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 C67271A08AE for ; Mon, 28 Apr 2014 21:29:22 -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] 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 DV0uM9SoZlWF for ; Mon, 28 Apr 2014 21:29:22 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 072371A08AD for ; Mon, 28 Apr 2014 21:29:22 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 346F3594059 for ; Mon, 28 Apr 2014 21:29:21 -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=2FlNARO1KZHQiUeyF19y0qA9/ow=; b=u1ZVYRvYo4T ryka5wcNDd8t5RD/tkjsWagiMaA+/hOJluFXq6S76UqTmv2kCdfG4lExKURrrjGe STdco3vhzXTvq2vVq3PvCLDIek5jGvbtR5NjwmrCU1iK6q9g7VDObz4/czjI9DBb Yt107lE8uFwin/DxVhsqUGZYpph42Cyk= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id DD4DA594058 for ; Mon, 28 Apr 2014 21:29:20 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so6704907wib.16 for ; Mon, 28 Apr 2014 21:29:19 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.188.41 with SMTP id fx9mr253485wjc.56.1398745759885; Mon, 28 Apr 2014 21:29:19 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 21:29:19 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115456D2132@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E115456D2132@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 28 Apr 2014 23:29:19 -0500 Message-ID: From: Nico Williams To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/eJUgGwxzl_dzoh2mIogH27l7paU Cc: "json@ietf.org" Subject: Re: [Json] New JSON Text Sequence I-D submitted X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Apr 2014 04:29:23 -0000 On Mon, Apr 28, 2014 at 7:41 PM, Manger, James wrote: >> https://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/ > > Short & simple =E2=80=94 looks good. Thanks. > 1. > One missing feature is that a file containing only whitespace should be a= valid JSON text sequence. Suggested changes: I think that's implied, but I'll make that explicit. > FROM: JSON-sequence =3D *(JSON-text 1*(ws)) > TO : JSON-sequence =3D *(ws) *(JSON-text 1*(ws)) OK. > P.S. Do you need the brackets in *(ws)? No, I didn't. > FROM: A JSON text sequence is a sequence of JSON texts > TO : A JSON text sequence is a sequence of zero, one, or more JSON text= s Sure. > 2. > We can't have a ABNF production that is different from RFC7159 JSON.= ws in JSON is unfortunate, but we have to live with it. > json-seq: ws =3D %x20 / %x09 / %x0A / %x0D > json : ws =3D *( %x20 / %x09 / %x0A / %x0D ) > > I would be tempted to write the ABNF using , instead of . > > JSON-sequence =3D *whitespace *(value 1*whitespace) > whitespace =3D %x20 / %x09 / %x0A / %x0D > value =3D Good point. Though to be fair I don't think the RFC7159 ABNF should be commingled with this one... Nico -- From nobody Mon Apr 28 21:52:03 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572381A08AD for ; Mon, 28 Apr 2014 21:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPdaX8d0mQ8z for ; Mon, 28 Apr 2014 21:51:59 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 52F5E1A02E3 for ; Mon, 28 Apr 2014 21:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s3T4pjbO007817; Tue, 29 Apr 2014 06:51:45 +0200 (CEST) Received: from [192.168.217.140] (p5489262C.dip0.t-ipconnect.de [84.137.38.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8E47C1F92; Tue, 29 Apr 2014 06:51:45 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (11D201) In-Reply-To: Date: Tue, 29 Apr 2014 06:51:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56A5D291-62BC-4E3C-A734-F8BC2358E831@tzi.org> References: <535EB3BF.8080606@cisco.com> To: Jacob Davies Archived-At: http://mailarchive.ietf.org/arch/msg/json/guf0z5YsDOkfekYe43RxgFHN0A0 Cc: "Matt Miller \(mamille2\)" , Tim Bray , "Joe Hildebrand \(jhildebr\)" , IETF JSON WG Subject: Re: [Json] I-JSON Topic #5: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 04:52:01 -0000 I still have no idea what that MUST is supposed to mean. Is 1.0 in, 1.000 o= ut? 1.0000000000000000000000000? Does it mean I can't write 10000000000000= 00000 but need to write 1e21 instead? Actually, both numbers cannot be repr= esented in binary64.=20 Repeat with 1.1, 1.1000000, 1.100000000000000000000 etc. Maybe what is meant here is excluding a number that doesn't round trip as a b= inary64? But whether that is true depends on rounding rules etc. that aren't defined f= or JSON. (There are several ways to write a binary64, e.g. 1.1 vs. the exact form of t= he number you get from rounding that into binary64.) If that is supposed to be a MUST, there needs to be a testable definition. Really, what needs to be excluded is the *intention* to obtain more precisio= n! and there is no way to see whether there was such an intention from the a= ctual JSON text.=20 Oh, and 1e400 is a way to interchange Infinity in some JSON implementations,= so this is not just about precision, but also about range. Sent from my iPad > On 28.04.2014, at 23:18, Jacob Davies wrote: >=20 > On Mon, Apr 28, 2014 at 1:52 PM, Joe Hildebrand (jhildebr) > wrote: >> Will we need to talk about subnormals, -0, NaN, Infinity, and the like? >=20 > NaN & infinity yes. Dunno about -0. >=20 > I think the burden on the emitter of requiring compliance is low. In > Java AFAIK it's just a case of checking that the value is a legal > double value, is not NaN and not infinite, and converting it with > default toString() (you can trim ".0" from the end if present for > neatness). On the receiver I think it would be rather more difficult. >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 From nobody Tue Apr 29 10:07: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 01D321A0952 for ; Tue, 29 Apr 2014 10:07:36 -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 Kr7VvTt2mUFW for ; Tue, 29 Apr 2014 10:07:32 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id CAB2A1A0941 for ; Tue, 29 Apr 2014 10:07:30 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WfBV9-00012h-OO; Tue, 29 Apr 2014 13:07:27 -0400 Date: Tue, 29 Apr 2014 13:07:27 -0400 From: John Cowan To: Tim Bray Message-ID: <20140429170727.GU11962@mercury.ccil.org> References: <535EB3BF.8080606@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/Dbk_TcIZJnQQjZyYsGprMT8pOY8 Cc: IETF JSON WG , Matt Miller Subject: Re: [Json] I-JSON Topic #5: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:07:36 -0000 Tim Bray scripsit: > It occurs to me that it would be super-useful for the draft to include > explanation of how to follow this rule, including examples of printf and > Java format strings. I don't think that can be done for C: the behavior of sprintf on floats is woefully underspecified. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org The present impossibility of giving a scientific explanation is no proof that there is no scientific explanation. The unexplained is not to be identified with the unexplainable, and the strange and extraordinary nature of a fact is not a justification for attributing it to powers above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913) From nobody Tue Apr 29 10:08: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 11D7D1A0923 for ; Tue, 29 Apr 2014 10:08:50 -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 A-jAFNolzFnd for ; Tue, 29 Apr 2014 10:08:48 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 16E311A0935 for ; Tue, 29 Apr 2014 10:08:44 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WfBWM-00017V-7v; Tue, 29 Apr 2014 13:08:42 -0400 Date: Tue, 29 Apr 2014 13:08:42 -0400 From: John Cowan To: "Joe Hildebrand (jhildebr)" Message-ID: <20140429170842.GV11962@mercury.ccil.org> References: <535EB3BF.8080606@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/nyMEljSD8CHwJSWWoBKm6z61ZnQ Cc: IETF JSON WG , Tim Bray , "Matt Miller \(mamille2\)" Subject: Re: [Json] I-JSON Topic #5: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:08:50 -0000 Joe Hildebrand (jhildebr) scripsit: > Will we need to talk about subnormals, -0, NaN, Infinity, and the like? I think -0 is the only issue here. The combination of a MUST and a SHOULD pretty much covers everything else. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org But the next day there came no dawn, and the Grey Company passed on into the darkness of the Storm of Mordor and were lost to mortal sight; but the Dead followed them. --"The Passing of the Grey Company" From nobody Tue Apr 29 10:12: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 DC93A1A08C5 for ; Tue, 29 Apr 2014 10:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 WHCN3yJQeDkQ for ; Tue, 29 Apr 2014 10:12:30 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id CBCBB1A0776 for ; Tue, 29 Apr 2014 10:12:30 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WfBa1-0001bZ-LA for json@ietf.org; Tue, 29 Apr 2014 13:12:29 -0400 Date: Tue, 29 Apr 2014 13:12:29 -0400 From: John Cowan To: json@ietf.org Message-ID: <20140429171229.GW11962@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/e7yitSiQ7V9Tt6F2TfvzdQGCBPw Subject: Re: [Json] I-JSON Topic #1: Media Types? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Apr 2014 17:12:33 -0000 If you expect JSON and get I-JSON, all is well, so I see no point in adding a media type or suffix to actual documents. It would be marginally useful to indicate that you expect I-JSON, but surely nobody would be so foolish at this stage as to insist on I-JSON. So let's not bother with these formalities until there is a proven need for them (which may be never). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org All "isms" should be "wasms". --Abbie From nobody Tue Apr 29 10:13:23 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A0D1A092A for ; Tue, 29 Apr 2014 10:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 0tBAf3od0Odr for ; Tue, 29 Apr 2014 10:13:17 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id A11D01A0776 for ; Tue, 29 Apr 2014 10:13:17 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WfBal-0001fx-TB for json@ietf.org; Tue, 29 Apr 2014 13:13:16 -0400 Date: Tue, 29 Apr 2014 13:13:15 -0400 From: John Cowan To: json@ietf.org Message-ID: <20140429171315.GX11962@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/p6KWTW8w-X9vYXjP4g0ZLh_Ke2c Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Apr 2014 17:13:19 -0000 > draft-i-json-01 says the top level is an object (but doesn’t say MUST, > eek). I have heard arguments for allowing arrays too​; anyone who thinks > that is a good idea should speak up. (I won’t.) As I understand it, the reason for this restriction was to support the in-band I-JSON signature. Since this is now dropped, there is no further reason not to allow the sending of arbitrary JSON values. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org "But I am the real Strider, fortunately," he said, looking down at them with his face softened by a sudden smile. "I am Aragorn son of Arathorn, and if by life or death I can save you, I will." From nobody Tue Apr 29 10:15: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 23F471A0912 for ; Tue, 29 Apr 2014 10:15:10 -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 3x1uTxUVkl3A for ; Tue, 29 Apr 2014 10:15:08 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id A9F9F1A0776 for ; Tue, 29 Apr 2014 10:15:08 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WfBcU-0001ns-Ez; Tue, 29 Apr 2014 13:15:02 -0400 Date: Tue, 29 Apr 2014 13:15:02 -0400 From: John Cowan To: Carsten Bormann Message-ID: <20140429171502.GY11962@mercury.ccil.org> References: <535EB3BF.8080606@cisco.com> <56A5D291-62BC-4E3C-A734-F8BC2358E831@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56A5D291-62BC-4E3C-A734-F8BC2358E831@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/D_ISWzhLIDGYK59eHSxOiZf8FjY Cc: Tim Bray , IETF JSON WG , Jacob Davies , "Joe Hildebrand \(jhildebr\)" , "Matt Miller \(mamille2\)" Subject: Re: [Json] I-JSON Topic #5: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:15:10 -0000 Carsten Bormann scripsit: > Maybe what is meant here is excluding a number that doesn't round trip as a binary64? That's what the MUST means. The SHOULD means something different. > Really, what needs to be excluded is the *intention* to obtain more > precision! and there is no way to see whether there was such an > intention from the actual JSON text. No, there isn't, that's why the MUST is a constraint on emitters, and it is precisely a constraint on what they expect rather than on what they do. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org LEAR: Dost thou call me fool, boy? FOOL: All thy other titles thou hast given away: That thou wast born with. From nobody Tue Apr 29 10:16: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 06D791A04AF for ; Tue, 29 Apr 2014 10:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 tsRUHOo2WFBz for ; Tue, 29 Apr 2014 10:16:15 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id CD44C1A08DB for ; Tue, 29 Apr 2014 10:16:14 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1WfBdd-0001sz-LZ for json@ietf.org; Tue, 29 Apr 2014 13:16:13 -0400 Date: Tue, 29 Apr 2014 13:16:13 -0400 From: John Cowan To: json@ietf.org Message-ID: <20140429171613.GZ11962@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: http://mailarchive.ietf.org/arch/msg/json/qAXBAIba5CbgXFaPbxyOyyVv_bI Subject: Re: [Json] I-JSON Topic #3: Unicode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Apr 2014 17:16:17 -0000 > draft-i-json-01 excludes the use of, and I quote, “Surrogates or > Noncharacters”. Is that the right use of Unicode nomenclature? This > really matters and I think it’s OK now, but first-class Unicode lawyering > is required here. It should say "code points which represent unpaired surrogates or noncharacters." The statement "\uDEAD is always illegal" is incorrect; it is entirely legal in the sequence "\uD800\uDEAD", which represents U+102AD CARIAN LETTER T. Rather it should say that "\uDEAD" is illegal unless preceded by an escape between "\uD800" and "\uDBFF" inclusive. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org I come from under the hill, and under the hills and over the hills my paths led. And through the air. I am he that walks unseen. I am the clue-finder, the web-cutter, the stinging fly. I was chosen for the lucky number. --Bilbo From nobody Tue Apr 29 10:22: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 CF0161A0935 for ; Tue, 29 Apr 2014 10:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 Til2RLAeWVem for ; Tue, 29 Apr 2014 10:22:06 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1C32D1A0920 for ; Tue, 29 Apr 2014 10:22:06 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id sa20so667594veb.8 for ; Tue, 29 Apr 2014 10:22:04 -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=QP6UtjrpcFqnh+F4TaXOTC/5UUnCVR+Ef8hM9gQmEMs=; b=aW6b2ALhPMxE8hJViDbk6RF2Jv+t47AiJwRPptAg5/+aCylPwT+K+/HvsIXeh/8EJA f1doJy90d5V5cY2mzcemaWVhKXp116pUcf4qHRMvRC+HIuuXmB4EWRbjZbPcbbVXTA8F WkDdkzTuZvJPNLVzSJlKc204bYA578PDcQM1JrL6Q5i5oeIzJTg85LhO2N5u4X79HzDW Nxe0V+yJZhhZr5L0gZYnDpfra/EFMWHL7bjzfwEF50+RZSg2KBZLaZRIXl6lAwDgaEhn 960D7j/FIlMdYj8psBJMuGR1mXRCRGhCuGGiFJxk8BHbvEX69KYCeZK9CdrrV4V2kekK f2rQ== X-Gm-Message-State: ALoCoQkwdN7vpqFbDgFSi6/uGVoevXanOxZ1TUXB/ojepADRnEC8m5mSeG/DSqAlT1zsy4r9a54L X-Received: by 10.58.198.75 with SMTP id ja11mr235824vec.59.1398792124724; Tue, 29 Apr 2014 10:22:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Tue, 29 Apr 2014 10:21:43 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <20140429171613.GZ11962@mercury.ccil.org> References: <20140429171613.GZ11962@mercury.ccil.org> From: Tim Bray Date: Tue, 29 Apr 2014 10:21:43 -0700 Message-ID: To: John Cowan Content-Type: multipart/alternative; boundary=047d7b6d9944b593e904f831abaa Archived-At: http://mailarchive.ietf.org/arch/msg/json/D6APxZevEdBo83UGhY4X_W-WJc0 Cc: "json@ietf.org" Subject: Re: [Json] I-JSON Topic #3: Unicode X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Apr 2014 17:22:07 -0000 --047d7b6d9944b593e904f831abaa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Actually, the statement currently is <<<< thus, "\uDEAD" is always illegal. >>>> And that is in fact correct if you look close at the quotation marks; 23 pedantry points to ME! Having said that, it would be improved by saying "\uDEAD" is always illegal because it is an unpaired surrogate, while "\uD800\uDEAD" is legal. On Tue, Apr 29, 2014 at 10:16 AM, John Cowan wrote= : > > draft-i-json-01 excludes the use of, and I quote, =E2=80=9CSurrogates o= r > > Noncharacters=E2=80=9D. Is that the right use of Unicode nomenclature= ? This > > really matters and I think it=E2=80=99s OK now, but first-class Unicode= lawyering > > is required here. > > It should say "code points which represent unpaired surrogates or > noncharacters." The statement "\uDEAD is always illegal" is incorrect; > it is entirely legal in the sequence "\uD800\uDEAD", which represents > U+102AD CARIAN LETTER T. Rather it should say that "\uDEAD" is illegal > unless preceded by an escape between "\uD800" and "\uDBFF" inclusive. > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > I come from under the hill, and under the hills and over the hills my pat= hs > led. And through the air. I am he that walks unseen. I am the clue-finde= r, > the web-cutter, the stinging fly. I was chosen for the lucky number. > --Bilbo > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --047d7b6d9944b593e904f831abaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Act= ually, the statement currently is=C2=A0

<<<<
thus, "\uDEAD" is always illeg= al.
>>>>

= And that is in fact correct if you look close at the quotation marks; 23 pe= dantry points to ME! =C2=A0Having said that, it would be improved by saying= "\uDEAD" is always illegal because it is an unpaired surrogate, = while "\uD800\uDEAD" is legal.


O= n Tue, Apr 29, 2014 at 10:16 AM, John Cowan <cowan@mercury.ccil.org= > wrote:
> draft-i-json-01 exclude= s the use of, and I quote, =E2=80=9CSurrogates or
> Noncharacters=E2=80=9D. =C2=A0 Is that the right use of Unicode nomenc= lature? =C2=A0This
> really matters and I think it=E2=80=99s OK now, but first-class = Unicode lawyering
> is required here.

It should say "code points which represent unpaired surrogates or
noncharacters." =C2=A0The statement "\uDEAD is always illegal&quo= t; is incorrect;
it is entirely legal in the sequence "\uD800\uDEAD", which repres= ents
U+102AD CARIAN LETTER T. =C2=A0Rather it should say that "\uDEAD"= is illegal
unless preceded by an escape between "\uD800" and "\uDBFF&qu= ot; inclusive.

--
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
I come from under the hill, and under the hills and over the hills my paths=
led. And through the air. I am he that walks unseen. =C2=A0I am the clue-fi= nder,
the web-cutter, the stinging fly. I was chosen for the lucky number. =C2=A0= --Bilbo

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

--047d7b6d9944b593e904f831abaa-- From nobody Tue Apr 29 10:26: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 7400D1A08DB for ; Tue, 29 Apr 2014 10:26: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 AIO2S0XbZZZD for ; Tue, 29 Apr 2014 10:26:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CE3E71A085A for ; Tue, 29 Apr 2014 10:26:17 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3THQFMq062402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 29 Apr 2014 10:26:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <535EAFDF.2020403@cisco.com> Date: Tue, 29 Apr 2014 10:26:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6456FCD4-E410-4FAB-96D0-E46260AABD9D@vpnc.org> References: <535EAFDF.2020403@cisco.com> To: IETF JSON WG X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/6bbhOonefG_53G6kiM2Nt2w1Jpo Subject: Re: [Json] I-JSON Topic #1: Media Types? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Apr 2014 17:26:18 -0000 > "Should there be an I-JSON media type, or a application/*+i-json > suffix? Draft i-json-01 calls for it, but this is at best = controversial." No. A receiver can check whatever data it gets against whatever rules it = wants. I-JSON is a standardized set of rules that an emitter probably = wants to follow. And emitter saying "Look! I followed those rules!" = cannot be trusted anyway. --Paul Hoffman= From nobody Tue Apr 29 10:27: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 EED041A08DB for ; Tue, 29 Apr 2014 10:27:31 -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 AOWTwFUKDHgb for ; Tue, 29 Apr 2014 10:27:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 762811A085A for ; Tue, 29 Apr 2014 10:27:31 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3THRSAE062457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 29 Apr 2014 10:27:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <535EB119.4000908@cisco.com> Date: Tue, 29 Apr 2014 10:27:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <535EB119.4000908@cisco.com> To: IETF JSON WG X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/INt1h0I5xzViQrWIcmVUykWvsk0 Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 29 Apr 2014 17:27:32 -0000 > "draft-i-json-01 says the top level is an object (but doesn=92t say > MUST, eek). I have heard arguments for allowing arrays too." There is no need for any top-level restriction. The restriction doesn't = help any capable receiver. --Paul Hoffman= From nobody Tue Apr 29 10:29:47 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D6C1A08FB for ; Tue, 29 Apr 2014 10:29:44 -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 2incQiq76rCK for ; Tue, 29 Apr 2014 10:29:44 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EC1B81A085A for ; Tue, 29 Apr 2014 10:29:43 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3THTfZQ062508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 29 Apr 2014 10:29:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <535EB33F.7090006@cisco.com> Date: Tue, 29 Apr 2014 10:29:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D092838-6949-44C2-9573-3C7B49A5E337@vpnc.org> References: <535EB33F.7090006@cisco.com> To: IETF JSON WG X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/ZOr-D45NeueZiHHUoWKRKe2Rs4A Subject: Re: [Json] Topic #4: Software Behavior X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:29:44 -0000 > "Section 3 of draft-json-01 implies draconian error handling - when a > message is specified to be i-json but the receiver finds, for example, > a dupe key, it is required to halt and catch fire. There's a chance > that this will be interpreted as 'tbray poisons JSON with XML > draconianism'. People with alternate language should suggest it." The current text is fine. It correctly sets the expectations for = emitters about receivers that require I-JSON. Weakening the text will = simply make draconian parsers seem like the bad actors. --Paul Hoffman= From nobody Tue Apr 29 10:34: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 2A3DE1A093C for ; Tue, 29 Apr 2014 10:33: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 6sfP7Q-_6cDA for ; Tue, 29 Apr 2014 10:33:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D8DA41A092A for ; Tue, 29 Apr 2014 10:33:53 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3THXpqE062705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 29 Apr 2014 10:33:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <535EB3BF.8080606@cisco.com> Date: Tue, 29 Apr 2014 10:33:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <295B22FF-2677-4FC8-B9B8-B59D9F4B78D2@vpnc.org> References: <535EB3BF.8080606@cisco.com> To: IETF JSON WG X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/DPhO20i0A30r8hmFcUc-aoMZu7U Subject: Re: [Json] I-JSON Topic #5: Numbers X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:33:58 -0000 > "draft-i-json-01 says that you MUST not put in a string representing a > number with greater precision/magnitude than IEEE754 doubles can > support. I think this is a good idea but I'm a little nervous > because I've never written the code; if this is unreasonably hard at > either the sending or receiving end someone should say so." =46rom the comments so far, it seems like it is not clear how to make = such restrictions in some languages. If we can't be definitive about = what we mean, we should remove it. RFC 7159 has pretty strong wording = already. --Paul Hoffman= From nobody Tue Apr 29 20:01:57 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16B61A090D for ; Tue, 29 Apr 2014 20:01:49 -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 maOkyZzPt7Ef for ; Tue, 29 Apr 2014 20:01:48 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 810041A090B for ; Tue, 29 Apr 2014 20:01:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,955,1389704400"; d="scan'208";a="6318982" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 30 Apr 2014 12:54:02 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7423"; a="218512958" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbni.tcif.telstra.com.au with ESMTP; 30 Apr 2014 13:01:44 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Wed, 30 Apr 2014 13:01:44 +1000 From: "Manger, James" To: IETF JSON WG Date: Wed, 30 Apr 2014 13:01:43 +1000 Thread-Topic: [Json] I-JSON Tpic #2: Top-Level Thread-Index: Ac9j0E+mJXEyey+7Q6641OWV6IMh9AATS8Sg Message-ID: <255B9BB34FB7D647A506DC292726F6E1154581E7C5@WSMSG3153V.srv.dir.telstra.com> References: <535EB119.4000908@cisco.com> 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/dbfr7BVOtdVnbG173l5-5BoIVXE Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Apr 2014 03:01:50 -0000 Pj4gImRyYWZ0LWktanNvbi0wMSBzYXlzIHRoZSB0b3AgbGV2ZWwgaXMgYW4gb2JqZWN0IChidXQg ZG9lc27igJl0IHNheQ0KPj4gTVVTVCwgZWVrKS4gIEkgaGF2ZSBoZWFyZCBhcmd1bWVudHMgZm9y IGFsbG93aW5nIGFycmF5cyB0b28uIg0KDQo+IFRoZXJlIGlzIG5vIG5lZWQgZm9yIGFueSB0b3At bGV2ZWwgcmVzdHJpY3Rpb24uIFRoZSByZXN0cmljdGlvbiBkb2Vzbid0IGhlbHAgYW55IGNhcGFi bGUgcmVjZWl2ZXIuDQoNCkkgYWdyZWUuDQoNCiJBbG1vc3QgYWx3YXlzIHVzZSBvYmplY3RzIGZv ciB0b3AtbGV2ZWwgbWVzc2FnZXMiIGlzIGdvb2QgYWR2aWNlIGZvciBkZXNpZ25lcnMgb2YgbmV3 IHByb3RvY29scyBhbmQgbWVzc2FnZXMuDQoiT25seSBhY2NlcHQgb2JqZWN0cyIgaXMgaG9ycmli bGUgYWR2aWNlIGZvciBkZXZlbG9wZXJzIG9mIEpTT04gcGFyc2VycyBhbmQgbGlicmFyeSBmdW5j dGlvbnMuDQoNCkpTT04gaGFzIHByaW1pdGl2ZXMgc28gYW4gIm9iamVjdC1vbmx5IiBydWxlIGNh biBvbmx5IHdvcmsgaWYgdGhlcmUgaXMgYSBjcnlzdGFsIGNsZWFyIGRpdmlkZSBiZXR3ZWVuIHRo b3NlIHN1YnNldHMgb2YgYSBKU09OIGRhdGEgc3RydWN0dXJlIHRoYXQgbWlnaHQgYmUgImV4Y2hh bmdlZCIgYW5kIHRob3NlIHN1YnNldHMgdGhhdCBhcmUgdG9vIGxvdy1sZXZlbCB0byBldmVyIG5l ZWQgdG8gYmUgImV4Y2hhbmdlZCIuIFRoZXJlIGlzIG5vIHN1Y2ggZGl2aWRlLg0KDQotLQ0KSmFt ZXMgTWFuZ2VyDQo= From nobody Tue Apr 29 20:19: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 274991A09A2 for ; Tue, 29 Apr 2014 20:19:28 -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 7HCiEpB98Bao for ; Tue, 29 Apr 2014 20:19:27 -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 1868C1A0985 for ; Tue, 29 Apr 2014 20:19:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,955,1389704400"; d="scan'208";a="210140292" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 30 Apr 2014 13:19:23 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7423"; a="219192943" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdvi.tcif.telstra.com.au with ESMTP; 30 Apr 2014 13:19:23 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Wed, 30 Apr 2014 13:19:23 +1000 From: "Manger, James" To: Tim Bray , IETF JSON WG Date: Wed, 30 Apr 2014 13:19:22 +1000 Thread-Topic: [Json] I-JSON Tpic #2: Top-Level Thread-Index: Ac9jH3EQUdYZDwGjRYioHTj6xLrKFABAmJ6Q Message-ID: <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com> References: <535EB119.4000908@cisco.com> 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/3aCm1MdWwdAAaTS9wDniXZbYcME Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Apr 2014 03:19:28 -0000 PiBQcm90b2NvbHMgd2l0aCBtZXNzYWdlcyB3aGljaCBhcmUgb2JqZWN0cyBhcmUgYmV0dGVyIHRo YW4gb3RoZXIgcHJvdG9jb2xzLCBiZWNhdXNlIHRoZXkgYXJlIGFyY2hpdGVjdHVyYWxseSBmcmll bmRseSB0byBNdXN0SWdub3JlIHBvbGljaWVzLiDCoA0KDQpQZXJoYXBzIHdlIHNob3VsZCBzYXkg YSBNdXN0SWdub3JlIHBvbGljeSBhcHBsaWVzIHRvIGFsbCBvYmplY3RzIGluIEktSlNPTjsgaW5z dGVhZCBvZiBtZXJlbHkgbWFraW5nIGEgTXVzdElnbm9yZSBwb2xpY3kgcG9zc2libGUgdmlhIGEg c29tZXdoYXQgdGFuZ2VudGlhbCBydWxlIHRoYXQgdGhlIHRvcC1sZXZlbCBtdXN0IGJlIGFuIG9i amVjdC4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From nobody Tue Apr 29 20:41:07 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0026E1A09B3 for ; Tue, 29 Apr 2014 20:41: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 QaNDGSLKxQTr for ; Tue, 29 Apr 2014 20:41:00 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id F2CC01A0849 for ; Tue, 29 Apr 2014 20:40:59 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id oz11so1433354veb.6 for ; Tue, 29 Apr 2014 20:40: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:from:date :message-id:subject:to:cc:content-type; bh=q8HzHp9AU9ssNGjIMjEfGVGOgyQc9q4pIgKKqbgfXvU=; b=ehC1ii5tYjtLXJax4wvPWozYCqxSmQMt1M45aVbWxGv72qfecSNy/7v00ENDcWmzR3 deYv4vjtxPAA4wWwJr6p0+PB/GVsjKTfavtALx59+0/c8UXqKW2bXWh1a8RF8ILerio+ y7GedwUXZDdXm4i+Hy+QWFy2zhfpnFA6alo7slDM3unYrme2amOAGc/AFslY40WnGKp9 aDujHmRIUurv1bfdnVT8ecVwa9km0TB53G30e036cpzP2vO6Tsv77zbzhub3j6g4zMzp YBWjZvMC2oKFulin31ffi5GDTfe1jIIASQQj0CJPtouRrToOsx7H9ZVm2LFCurwptlrX mY/Q== X-Gm-Message-State: ALoCoQm5n7ebftdAdNn480ii6ZzqfsIiGnvGwRNjVZYkLR971U6UmQ4wetyFy/WCpBxsKHv0Nlu0 X-Received: by 10.58.96.36 with SMTP id dp4mr1686915veb.21.1398829258412; Tue, 29 Apr 2014 20:40:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Tue, 29 Apr 2014 20:40:38 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com> References: <535EB119.4000908@cisco.com> <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com> From: Tim Bray Date: Tue, 29 Apr 2014 20:40:38 -0700 Message-ID: To: "Manger, James" Content-Type: multipart/alternative; boundary=089e013a26e60caaac04f83a5150 Archived-At: http://mailarchive.ietf.org/arch/msg/json/WSJtsgDzRV_3ax3TPB9yiz7ZFTg Cc: IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Apr 2014 03:41:02 -0000 --089e013a26e60caaac04f83a5150 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m sorry, but the central idea of I-JSON is to explicitly rule out= all the interoperability problems identified in RFC7159: How to produce maximally-interoperable JSON. 7159 specifically says that for interoperability a JSON Text should be an object or array, and the idea of making I-JSON less constraining totally defeats its purpose. This is just not a reasonable direction to be going. Yes, it=E2=80=99s perfectly clear to any language lawyer that in ECMAScript= , 42 is a first-class JSON text, nobody is disputing this. On Tue, Apr 29, 2014 at 8:19 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > > Protocols with messages which are objects are better than other > protocols, because they are architecturally friendly to MustIgnore > policies. > > Perhaps we should say a MustIgnore policy applies to all objects in > I-JSON; instead of merely making a MustIgnore policy possible via a > somewhat tangential rule that the top-level must be an object. > > -- > James Manger > --089e013a26e60caaac04f83a5150 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= =E2=80=99m sorry, but the central idea of I-JSON is to explicitly rule out = all the interoperability problems identified in RFC7159: How to produce max= imally-interoperable JSON. =C2=A07159 specifically says that for interopera= bility a JSON Text should be an object or array, and the idea of making I-J= SON less constraining totally defeats its purpose. =C2=A0This is just not a= reasonable direction to be going. =C2=A0

Yes, it=E2=80=99s perfectly cl= ear to any language lawyer that in ECMAScript, 42 is a first-class JSON tex= t, nobody is disputing this.


On Tue,= Apr 29, 2014 at 8:19 PM, Manger, James <James.H.Manger@team= .telstra.com> wrote:
> Protocols with messages= which are objects are better than other protocols, because they are archit= ecturally friendly to MustIgnore policies. =C2=A0

Perhaps we should say a MustIgnore policy applies to all objects in I= -JSON; instead of merely making a MustIgnore policy possible via a somewhat= tangential rule that the top-level must be an object.

--
James Manger

--089e013a26e60caaac04f83a5150-- From nobody Tue Apr 29 21:40:31 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552481A08A8 for ; Tue, 29 Apr 2014 21:40:29 -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 3D42kGx5mFDD for ; Tue, 29 Apr 2014 21:40:27 -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 6B8FA1A0A37 for ; Tue, 29 Apr 2014 21:40:27 -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 2D84E32E557; Wed, 30 Apr 2014 13:40:23 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3dce_d0dc_c7162d94_a25a_4857_bf05_5de094f96c7c; Wed, 30 Apr 2014 13:40:22 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 8FC03C0358; Wed, 30 Apr 2014 13:40:22 +0900 (JST) Message-ID: <53607EA9.50204@it.aoyama.ac.jp> Date: Wed, 30 Apr 2014 13:40:09 +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.4.0 MIME-Version: 1.0 To: Paul Hoffman , IETF JSON WG References: <535EAFDF.2020403@cisco.com> <6456FCD4-E410-4FAB-96D0-E46260AABD9D@vpnc.org> In-Reply-To: <6456FCD4-E410-4FAB-96D0-E46260AABD9D@vpnc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/EPxSC1V1LhO9GeoVvPWqJ41RfzM Subject: Re: [Json] I-JSON Topic #1: Media Types? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Apr 2014 04:40:29 -0000 +1. I have given my arguments already months ago, and they are much the same as given here recently by many. Regards, Martin. On 2014/04/30 02:26, Paul Hoffman wrote: > > >> "Should there be an I-JSON media type, or a application/*+i-json >> suffix? Draft i-json-01 calls for it, but this is at best controversial." > > No. A receiver can check whatever data it gets against whatever rules it wants. I-JSON is a standardized set of rules that an emitter probably wants to follow. And emitter saying "Look! I followed those rules!" cannot be trusted anyway. > > --Paul Hoffman > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Tue Apr 29 22:17:32 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9D31A2130 for ; Tue, 29 Apr 2014 22:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, 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 o7lRz_aLuGfV for ; Tue, 29 Apr 2014 22:17:19 -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 C22561A212D for ; Tue, 29 Apr 2014 22:17:18 -0700 (PDT) X-IronPort-AV: E=Sophos; i="4.97,956,1389704400"; d="scan'208,217"; a="10093090" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 30 Apr 2014 15:07:27 +1000 X-IronPort-AV: E=McAfee;i="5600,1067,7423"; a="273267620" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcavi.tcif.telstra.com.au with ESMTP; 30 Apr 2014 15:17:15 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Wed, 30 Apr 2014 15:17:10 +1000 From: "Manger, James" To: Tim Bray Date: Wed, 30 Apr 2014 15:17:09 +1000 Thread-Topic: [Json] I-JSON Tpic #2: Top-Level Thread-Index: Ac9kJgHQA2PKPTJXQxSbN+Cu6gpIKwABQBJg Message-ID: <255B9BB34FB7D647A506DC292726F6E1154581EB38@WSMSG3153V.srv.dir.telstra.com> References: <535EB119.4000908@cisco.com> <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com> 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: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1154581EB38WSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/json/4exC9txdtzt9NEs_6dBGdmxFuqw Cc: IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Apr 2014 05:17:23 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1154581EB38WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25seSBhbGxvd2luZyBvYmplY3RzIGFuZCBhcnJheXMgYXQgdGhlIHRvcCBsZXZlbCB3YXMgYSBj YXVzZSBvZiBpbnRlcm9wIHByb2JsZW1zLg0KSXQgd2FzIGEgYmFkIGZlYXR1cmUsIGFuIHVubmVj ZXNzYXJ5IHJlc3RyaWN0aW9uLCB0aGF0IHdlIHNob3VsZCBub3QgcGVycGV0dWF0ZS4gUkZDNzE1 OSBhbmQgRUNNQS00MDQgaGF2ZSB0YWtlbiBhIGdyZWF0IGxlYXAgdG8gcmVtb3ZlIGl0IHNvIEkg ZG9u4oCZdCB3YW50IEktSlNPTiB0byB0cnkgdG8gcmVzdXJyZWN0IGl0Lg0KDQpJIHdvdWxkIGJl IGhhcHB5IHRvIHVzZSBhIEpTT04gZnVuY3Rpb24gdGhhdDogcmVxdWlyZWQgVVRGLTg7IGZhaWxl ZCBvbiBzdXJyb2dhdGVzOyBmYWlsZWQgb24gZHVwbGljYXRlczsgaWdub3JlZCBlbGVtZW50IG9y ZGVyOyBmYWlsZWQgb24gaW50ZWdlcnMgYmV5b25kIDJeNTM7IGZhaWxlZCBvbiBmbG9hdHMgd2l0 aCBtb3JlIHRoYW4gMjIgZGlnaXRzOyBmYWlsZWQgb24gaW52YWxpZCBKU09OIChlZyB0cmFpbGlu ZyBjb21tYXMsIGNvbW1lbnRzIGV0YykuDQpJIHdvdWxkIE5PVCBiZSBoYXBweSB0byB1c2UgYSBK U09OIGZ1bmN0aW9uIHRoYXQ6IGZhaWxlZCB3aGVuIHRoZSB0b3AtbGV2ZWwgaXNu4oCZdCBhbiBv YmplY3QuDQpJIHdhbnQgdG8gYmUgaGFwcHkgdG8gdXNlIGEgSlNPTiBmdW5jdGlvbiBpZiBpdCBz YXlzIGl0IHN1cHBvcnRzIEktSlNPTi4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBUaW0g QnJheSBbbWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCAzMCBB cHJpbCAyMDE0IDE6NDEgUE0NClRvOiBNYW5nZXIsIEphbWVzDQpDYzogSUVURiBKU09OIFdHDQpT dWJqZWN0OiBSZTogW0pzb25dIEktSlNPTiBUcGljICMyOiBUb3AtTGV2ZWwNCg0KSeKAmW0gc29y cnksIGJ1dCB0aGUgY2VudHJhbCBpZGVhIG9mIEktSlNPTiBpcyB0byBleHBsaWNpdGx5IHJ1bGUg b3V0IGFsbCB0aGUgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBpZGVudGlmaWVkIGluIFJGQzcx NTk6IEhvdyB0byBwcm9kdWNlIG1heGltYWxseS1pbnRlcm9wZXJhYmxlIEpTT04uICA3MTU5IHNw ZWNpZmljYWxseSBzYXlzIHRoYXQgZm9yIGludGVyb3BlcmFiaWxpdHkgYSBKU09OIFRleHQgc2hv dWxkIGJlIGFuIG9iamVjdCBvciBhcnJheSwgYW5kIHRoZSBpZGVhIG9mIG1ha2luZyBJLUpTT04g bGVzcyBjb25zdHJhaW5pbmcgdG90YWxseSBkZWZlYXRzIGl0cyBwdXJwb3NlLiAgVGhpcyBpcyBq dXN0IG5vdCBhIHJlYXNvbmFibGUgZGlyZWN0aW9uIHRvIGJlIGdvaW5nLg0KDQpZZXMsIGl04oCZ cyBwZXJmZWN0bHkgY2xlYXIgdG8gYW55IGxhbmd1YWdlIGxhd3llciB0aGF0IGluIEVDTUFTY3Jp cHQsIDQyIGlzIGEgZmlyc3QtY2xhc3MgSlNPTiB0ZXh0LCBub2JvZHkgaXMgZGlzcHV0aW5nIHRo aXMuDQoNCk9uIFR1ZSwgQXByIDI5LCAyMDE0IGF0IDg6MTkgUE0sIE1hbmdlciwgSmFtZXMgPEph bWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208bWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0u dGVsc3RyYS5jb20+PiB3cm90ZToNCj4gUHJvdG9jb2xzIHdpdGggbWVzc2FnZXMgd2hpY2ggYXJl IG9iamVjdHMgYXJlIGJldHRlciB0aGFuIG90aGVyIHByb3RvY29scywgYmVjYXVzZSB0aGV5IGFy ZSBhcmNoaXRlY3R1cmFsbHkgZnJpZW5kbHkgdG8gTXVzdElnbm9yZSBwb2xpY2llcy4NClBlcmhh cHMgd2Ugc2hvdWxkIHNheSBhIE11c3RJZ25vcmUgcG9saWN5IGFwcGxpZXMgdG8gYWxsIG9iamVj dHMgaW4gSS1KU09OOyBpbnN0ZWFkIG9mIG1lcmVseSBtYWtpbmcgYSBNdXN0SWdub3JlIHBvbGlj eSBwb3NzaWJsZSB2aWEgYSBzb21ld2hhdCB0YW5nZW50aWFsIHJ1bGUgdGhhdCB0aGUgdG9wLWxl dmVsIG11c3QgYmUgYW4gb2JqZWN0Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E1154581EB38WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk9ubHkgYWxsb3dpbmcgb2JqZWN0 cyBhbmQgYXJyYXlzIGF0IHRoZSB0b3AgbGV2ZWwgd2FzIGEgY2F1c2Ugb2YgaW50ZXJvcCBwcm9i bGVtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SXQgd2FzIGEgYmFkIGZlYXR1cmUsIGFuIHVubmVjZXNzYXJ5IHJlc3RyaWN0 aW9uLCB0aGF0IHdlIHNob3VsZCBub3QgcGVycGV0dWF0ZS4gUkZDNzE1OSBhbmQgRUNNQS00MDQg aGF2ZSB0YWtlbiBhIGdyZWF0IGxlYXAgdG8gcmVtb3ZlIGl0IHNvIEkgZG9u4oCZdCB3YW50IEkt SlNPTiB0byB0cnkgdG8gcmVzdXJyZWN0IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSB3b3VsZCBi ZSBoYXBweSB0byB1c2UgYSBKU09OIGZ1bmN0aW9uIHRoYXQ6IHJlcXVpcmVkIFVURi04OyBmYWls ZWQgb24gc3Vycm9nYXRlczsgZmFpbGVkIG9uIGR1cGxpY2F0ZXM7IGlnbm9yZWQgZWxlbWVudCBv cmRlcjsgZmFpbGVkIG9uIGludGVnZXJzIGJleW9uZCAyXjUzOyBmYWlsZWQgb24gZmxvYXRzIHdp dGggbW9yZSB0aGFuIDIyIGRpZ2l0czsgZmFpbGVkIG9uIGludmFsaWQgSlNPTiAoZWcgdHJhaWxp bmcgY29tbWFzLCBjb21tZW50cyBldGMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIHdvdWxkIE5PVCBiZSBoYXBweSB0byB1 c2UgYSBKU09OIGZ1bmN0aW9uIHRoYXQ6IGZhaWxlZCB3aGVuIHRoZSB0b3AtbGV2ZWwgaXNu4oCZ dCBhbiBvYmplY3QuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkkgd2FudCB0byBiZSBoYXBweSB0byB1c2UgYSBKU09OIGZ1bmN0 aW9uIGlmIGl0IHNheXMgaXQgc3VwcG9ydHMgSS1KU09OLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDozNi4wcHQnPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPiBUaW0gQnJheSBbbWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tXSA8YnI+PGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgMzAgQXByaWwgMjAxNCAxOjQxIFBNPGJyPjxiPlRvOjwvYj4g TWFuZ2VyLCBKYW1lczxicj48Yj5DYzo8L2I+IElFVEYgSlNPTiBXRzxicj48Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtKc29uXSBJLUpTT04gVHBpYyAjMjogVG9wLUxldmVsPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48 bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tbGVmdDozNi4wcHQnPknigJltIHNvcnJ5LCBidXQgdGhlIGNlbnRyYWwgaWRlYSBvZiBJ LUpTT04gaXMgdG8gZXhwbGljaXRseSBydWxlIG91dCBhbGwgdGhlIGludGVyb3BlcmFiaWxpdHkg cHJvYmxlbXMgaWRlbnRpZmllZCBpbiBSRkM3MTU5OiBIb3cgdG8gcHJvZHVjZSBtYXhpbWFsbHkt aW50ZXJvcGVyYWJsZSBKU09OLiAmbmJzcDs3MTU5IHNwZWNpZmljYWxseSBzYXlzIHRoYXQgZm9y IGludGVyb3BlcmFiaWxpdHkgYSBKU09OIFRleHQgc2hvdWxkIGJlIGFuIG9iamVjdCBvciBhcnJh eSwgYW5kIHRoZSBpZGVhIG9mIG1ha2luZyBJLUpTT04gbGVzcyBjb25zdHJhaW5pbmcgdG90YWxs eSBkZWZlYXRzIGl0cyBwdXJwb3NlLiAmbmJzcDtUaGlzIGlzIGp1c3Qgbm90IGEgcmVhc29uYWJs ZSBkaXJlY3Rpb24gdG8gYmUgZ29pbmcuICZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDozNi4wcHQnPlllcywgaXTigJlzIHBlcmZlY3RseSBjbGVhciB0byBhbnkgbGFuZ3VhZ2UgbGF3 eWVyIHRoYXQgaW4gRUNNQVNjcmlwdCwgNDIgaXMgYSBmaXJzdC1jbGFzcyBKU09OIHRleHQsIG5v Ym9keSBpcyBkaXNwdXRpbmcgdGhpcy48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2LjBwdCc+PG86cD4mbmJz cDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2 LjBwdCc+T24gVHVlLCBBcHIgMjksIDIwMTQgYXQgODoxOSBQTSwgTWFuZ2VyLCBKYW1lcyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iIHRhcmdldD0i X2JsYW5rIj5KYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVm dDozNi4wcHQnPiZndDsgUHJvdG9jb2xzIHdpdGggbWVzc2FnZXMgd2hpY2ggYXJlIG9iamVjdHMg YXJlIGJldHRlciB0aGFuIG90aGVyIHByb3RvY29scywgYmVjYXVzZSB0aGV5IGFyZSBhcmNoaXRl Y3R1cmFsbHkgZnJpZW5kbHkgdG8gTXVzdElnbm9yZSBwb2xpY2llcy4gJm5ic3A7PG86cD48L286 cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQn PlBlcmhhcHMgd2Ugc2hvdWxkIHNheSBhIE11c3RJZ25vcmUgcG9saWN5IGFwcGxpZXMgdG8gYWxs IG9iamVjdHMgaW4gSS1KU09OOyBpbnN0ZWFkIG9mIG1lcmVseSBtYWtpbmcgYSBNdXN0SWdub3Jl IHBvbGljeSBwb3NzaWJsZSB2aWEgYSBzb21ld2hhdCB0YW5nZW50aWFsIHJ1bGUgdGhhdCB0aGUg dG9wLWxldmVsIG11c3QgYmUgYW4gb2JqZWN0Ljxicj48YnI+LS08YnI+SmFtZXMgTWFuZ2VyPG86 cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDoz Ni4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E1154581EB38WSMSG3153Vsrv_-- From nobody Tue Apr 29 22:50: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 D112C1A6EE2 for ; Tue, 29 Apr 2014 22:50:17 -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 vpGVj6eSOB0q for ; Tue, 29 Apr 2014 22:50:13 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) by ietfa.amsl.com (Postfix) with ESMTP id 841D21A09DF for ; Tue, 29 Apr 2014 22:50:12 -0700 (PDT) Received: from newyork.local.box ([80.187.97.156]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0M2571-1Wzv8D2Qxf-00u0zx for ; Wed, 30 Apr 2014 07:50:10 +0200 Message-ID: <53608F11.7080709@drees.name> Date: Wed, 30 Apr 2014 07:50:09 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: json@ietf.org References: <535EAFDF.2020403@cisco.com> <6456FCD4-E410-4FAB-96D0-E46260AABD9D@vpnc.org> <53607EA9.50204@it.aoyama.ac.jp> In-Reply-To: <53607EA9.50204@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:dEoipHzJ0bqA8a2+PBM2wjpe7srmuDOu7zSdz7HDjl9LhidYIcD et/Pc60xWOIKVcciWyKYEFEaN3/XWDmRuX7WvwWnmfpeuyT6ii9NYL3FqSk1iV/ZWnlYIMo YJwVWGaA9TaLg3RTSwA/+yEOMsCvIkrJfQEZGd/Vwn7uPCi+xqFXSdjQyto04knpblKepq8 0kP2Z6+ZeSnnh+lAj2+nQ== Archived-At: http://mailarchive.ietf.org/arch/msg/json/mUGiw6pHxSO0yjlAj9LGnpjUCOg Subject: Re: [Json] I-JSON Topic #1: Media Types? 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: Wed, 30 Apr 2014 05:50:18 -0000 +1 from my side also Am 30.04.14 06:40, schrieb "Martin J. Drst": > +1. I have given my arguments already months ago, and they are much the > same as given here recently by many. > > Regards, Martin. > > On 2014/04/30 02:26, Paul Hoffman wrote: >> >> >>> "Should there be an I-JSON media type, or a application/*+i-json >>> suffix? Draft i-json-01 calls for it, but this is at best >>> controversial." >> >> No. A receiver can check whatever data it gets against whatever rules >> it wants. I-JSON is a standardized set of rules that an emitter >> probably wants to follow. And emitter saying "Look! I followed those >> rules!" cannot be trusted anyway. >> >> --Paul Hoffman >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Tue Apr 29 22:53: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 B27321A6EE0 for ; Tue, 29 Apr 2014 22:53:46 -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 f2aDr6KYgary for ; Tue, 29 Apr 2014 22:53:45 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8F81A09DF for ; Tue, 29 Apr 2014 22:53:45 -0700 (PDT) Received: from newyork.local.box ([80.187.97.156]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0Ldn2d-1X6UfU0SXr-00ixoS for ; Wed, 30 Apr 2014 07:53:43 +0200 Message-ID: <53608FE6.3020101@drees.name> Date: Wed, 30 Apr 2014 07:53:42 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: json@ietf.org References: <535EB119.4000908@cisco.com> <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:v6qp46f3kBdvY8B9hwgwbgTpEDSqBUyCSaqz2qf9AqI82XSjjR3 Y54PEW+jX6tM/9wTC/oHD0YWJABHXBGhyk4TCsUKeruZpXqqlRojtqTD8AtOauCHn+KD0i7 /AulNAcu6FDjVqAScSuyfjbNwGpL5TnOIdrawiOpoPeC5Qb8lFYgxdAFN6wXOP8DfIdlV3t TRFynVBiO9vHean8iDhcA== Archived-At: http://mailarchive.ietf.org/arch/msg/json/ndKhwgFTLpRrquOvp7aWthyk5j0 Subject: Re: [Json] I-JSON Tpic #2: Top-Level 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: Wed, 30 Apr 2014 05:53:46 -0000 Yes, please. In OData we investigate suggesting adhering to such a constrained JSON (OData JSON Texts are in format JSON always wrapped as values of a {"d": VALUE} element. It is nice to be able, to just reference I-JSON draft. If we remove that essential constraint, to me it would look quite useless or should I say nostalgic :-? "Stefan" Am 30.04.14 05:40, schrieb Tim Bray: > Im sorry, but the central idea of I-JSON is to explicitly rule out all > the interoperability problems identified in RFC7159: How to produce > maximally-interoperable JSON. 7159 specifically says that for > interoperability a JSON Text should be an object or array, and the idea > of making I-JSON less constraining totally defeats its purpose. This is > just not a reasonable direction to be going. > > Yes, its perfectly clear to any language lawyer that in ECMAScript, 42 > is a first-class JSON text, nobody is disputing this. > > > On Tue, Apr 29, 2014 at 8:19 PM, Manger, James > > wrote: > > > Protocols with messages which are objects are better than other > protocols, because they are architecturally friendly to MustIgnore > policies. > > Perhaps we should say a MustIgnore policy applies to all objects in > I-JSON; instead of merely making a MustIgnore policy possible via a > somewhat tangential rule that the top-level must be an object. > > -- > James Manger > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Tue Apr 29 23:04: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 909FB1A09C5 for ; Tue, 29 Apr 2014 23:04:07 -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 VPv8BfQ78qZ9 for ; Tue, 29 Apr 2014 23:04:06 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.3]) by ietfa.amsl.com (Postfix) with ESMTP id 7E79A1A09DF for ; Tue, 29 Apr 2014 23:04:04 -0700 (PDT) Received: from newyork.local.box ([80.187.97.156]) by smtp.web.de (mrweb102) with ESMTPSA (Nemesis) id 0Le4Po-1XDN4H2Ltc-00prQU for ; Wed, 30 Apr 2014 08:04:01 +0200 Message-ID: <53609250.1040705@drees.name> Date: Wed, 30 Apr 2014 08:04:00 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: json@ietf.org References: <535EB3BF.8080606@cisco.com> <295B22FF-2677-4FC8-B9B8-B59D9F4B78D2@vpnc.org> In-Reply-To: <295B22FF-2677-4FC8-B9B8-B59D9F4B78D2@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KXfu1UyVAMTT7/XAn3WpOdtfUvNtjRb1Sc4nG5iDp4u++9f96xb 0XFjgMITSASmASFRa4x+wW6XFoQ6WMRC9S0e4pP+4uACQV3fMbVvB0NqnuDsW+87OM2zpP9 t9mZrnx4SG81cUTbBjRtrxg6XvgobhveJIo/xvr6ivcgBN34YdIqGHxARfox+UE8waDD6n0 ZZVwqasMP6fXc86qTdnXg== Archived-At: http://mailarchive.ietf.org/arch/msg/json/la7wTMssVKDccb4IhLJnh3i_WAI Subject: Re: [Json] I-JSON Topic #5: Numbers 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: Wed, 30 Apr 2014 06:04:08 -0000 Am 29.04.14 19:33, schrieb Paul Hoffman: > > >> "draft-i-json-01 says that you MUST not put in a string representing a >> number with greater precision/magnitude than IEEE754 doubles can >> support. I think this is a good idea but I'm a little nervous >> because I've never written the code; if this is unreasonably hard at >> either the sending or receiving end someone should say so." > > From the comments so far, it seems like it is not clear how to make > such restrictions in some languages. If we can't be definitive about > what we mean, we should remove it. RFC 7159 has pretty strong wording > already. from another context I remember, that being definitive here is complicated (at least when a generic consumer of the message is assumed) 1. There are clients that simply cannot digest a number being larger than IEEE754 doubles. In a robust scenario, I would expect, that in that case, they reparse that token as a decorated (client side) string and try to apply local rules in handling what has been received in that "slot". 2. Clients that can digest numbers of arbitrary length on the other hand would be "slowed down" when all numbers not fitting in IEEE754 doubles would be string-wrapped. 3. JSON strengths are not with types or schemas, but it also helps the client, when every value of identically named keys or constituents of arrays are of the same "kind" at least in moretrusted setups. So for me it would be ok to remove it, as no matter how we resolve it, from the above mentioned 3 "viewpoints" there are always some "local rules" or extra effort involved to handle the general case, which we must describe or leave out. {"stefan": "All the best."} From nobody Tue Apr 29 23:05: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 BE2731A6EE5 for ; Tue, 29 Apr 2014 23:05:05 -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 j7ECJYopzd4j for ; Tue, 29 Apr 2014 23:05:04 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4843C1A6EE0 for ; Tue, 29 Apr 2014 23:05:04 -0700 (PDT) Received: from newyork.local.box ([80.187.97.156]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0LeLSr-1XDe8O3TMD-00qBRf for ; Wed, 30 Apr 2014 08:05:02 +0200 Message-ID: <5360928D.4000601@drees.name> Date: Wed, 30 Apr 2014 08:05:01 +0200 From: Stefan Drees User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: json@ietf.org References: <535EB33F.7090006@cisco.com> <3D092838-6949-44C2-9573-3C7B49A5E337@vpnc.org> In-Reply-To: <3D092838-6949-44C2-9573-3C7B49A5E337@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:TdINIpB0o1OX/z//GIYYH/D1NUJeTp+q2wXjky8VWdBRq9+Mu1r U7nMiONfIUsa03uQz6eBzcfiBGGKePLYfiWd7zxauPz2k7pCTHA9EyXe6qwHTugoZg4/ySI JWn1OoPK7/0a9i6JLbY0WOiYA1yknow8VZEliuimxpISPCphQvMtpNh6klg+iEi4k54fdW2 YEyqGLldxt5hJfKpN8ldg== Archived-At: http://mailarchive.ietf.org/arch/msg/json/fTU4_8RnmyIgnD7ceapcL9GwxT0 Subject: Re: [Json] Topic #4: Software Behavior 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: Wed, 30 Apr 2014 06:05:06 -0000 Am 29.04.14 19:29, schrieb Paul Hoffman: >> "Section 3 of draft-json-01 implies draconian error handling - when a >> message is specified to be i-json but the receiver finds, for example, >> a dupe key, it is required to halt and catch fire. There's a chance >> that this will be interpreted as 'tbray poisons JSON with XML >> draconianism'. People with alternate language should suggest it." > > The current text is fine. It correctly sets the expectations for > emitters about receivers that require I-JSON. Weakening the text will > simply make draconian parsers seem like the bad actors. +1 from my side From w.bogaerts@kratz.nl Wed Apr 30 03:18:54 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944751A6F37 for ; Wed, 30 Apr 2014 03:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.442 X-Spam-Level: * X-Spam-Status: No, score=1.442 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_O6qv9_1t71 for ; Wed, 30 Apr 2014 03:18:53 -0700 (PDT) Received: from lebbis.kratz.nl (lebbis.kratz.nl [87.233.4.162]) by ietfa.amsl.com (Postfix) with ESMTP id 876B11A6F3D for ; Wed, 30 Apr 2014 03:18:52 -0700 (PDT) Received: from [10.77.77.108] (unknown [37.0.87.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lebbis.kratz.nl (Postfix) with ESMTP id 01F055DC003 for ; Wed, 30 Apr 2014 12:18:49 +0200 (CEST) Message-ID: <5360CDFA.9040803@kratz.nl> Date: Wed, 30 Apr 2014 12:18:34 +0200 From: Willem Bogaerts Organization: Kratz Business Solutions User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: json@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/json/lI-Uclyv82Po6806DLl6YPVXwZ0 X-Mailman-Approved-At: Wed, 30 Apr 2014 05:07:14 -0700 Subject: [Json] JSON encodings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Apr 2014 10:22:41 -0000 Dear Group, I am new here, so this issue may have been handled in the past. I'd like to solve an issue with JSON standard. The issue is that according to RFC 7159, JSON is both text-based and binary. And those two are not exactly compatible. With a mime-type of "application/json", one would expect a binary format, which it really is not. So one would expect a mime type like "text/json;charset=utf8", for example. This would allow the parser to "get ready" for the data before choking on it. In fact, most implementations check for an encoding, call some library to convert it to an internally used encoding, and only then call the JSON parser, which does not need to be aware of all the possible encodings. To do that, off course, the encoding should be separate from the data itself. Not separating the two is like sending a locked safe with its key inside: you will have to break open the safe to find the key that opens it. In fact, some references to the JSON standard provide an example on how to "crack the safe" by looking at the first 4 bytes. This can never be the intention. I know that the HTML standard has a history of "cracking" the pages for the http-header as a meta tag, but this only serves as an example on how it should NOT be done. To overcome the issue, I encountered content-types like "application/json;charset=utf8". Although this seems (and is) a little odd, I think this is the best way of preparing the client to the data it is getting. Although JSON has an "application" base type, it really is text and therefore needs an encoding. So my comment to RFC 7159 is that it should be possible to send the character encoding as meta-data when sending a JSON request. The absence of this encoding then causes the request to be treated as utf-8. In the section "IANA considerations", the standard now says "n/a" for optional parameters to the mime type. I'd like to propose that the "charset" parameter is an option. This can also be a security consideration. There are illegal sequences that can be misinterpreted and cause havoc. This is less likely with a "pure data" format like JSON, but you never know where the ill-formed data is going next. Somebody could try to inject characters that are not recognised as quotes by a web page script, but are regarded as such by the database that parses it as part of a query. You hardly need more for a successful SQL injection attack. If I recall correctly, attacks like this happened with UTF-7 encodings in the past. Also, imagine that somebody follows the advice on looking at the first 4 bytes for the encoding and uses a forgiving encoding translator for the rest. I am sure that it would be possible to start with, say, an UTF-16LE encoded white space and add some nasty surprises in an other encoding for the rest of the request. The encoding that is "cracked" out of the first 4 bytes is not likely to be checked, as it was cracked out of the request in the first place: there is nothing to validate it with. Treating a piece of text as a binary makes this kind of attacks possible. Stating the character encoding beforehand can prevent any surprises in how the request is parsed, can serve as a meaningful validation, and allows the programmer to send meaningful error messages for any ill-encoded request. Best regards, -- Willem Bogaerts Application Smith Kratz Business Solutions http://www.kratz.nl/ From nobody Wed Apr 30 05:44: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 EC1BE1A6F57 for ; Wed, 30 Apr 2014 05:44:07 -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, 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 mE-5PM0nnXHQ for ; Wed, 30 Apr 2014 05:44:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD4A1A081B for ; Wed, 30 Apr 2014 05:44:06 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MSduu-1WG5GY43tc-00RXKg; Wed, 30 Apr 2014 14:44:03 +0200 Message-ID: <5360F011.8080106@gmx.de> Date: Wed, 30 Apr 2014 14:44:01 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Willem Bogaerts , json@ietf.org References: <5360CDFA.9040803@kratz.nl> In-Reply-To: <5360CDFA.9040803@kratz.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:YJedzOiSdOOmLQUM87o06sglz9AttSVYKdkzfpozHMGJKvJyPm4 eLaVuKaJJMy2MlRjOkCSGJJn0O1Ua6nAPzMQ3llA+h6HeSJiiiJc9ShkLLlPFczKaOPBv6j E0mCE8p04Bvdu/Pv9E6rvlH2/dv8EbCdNgDG9HJzKqmja4TRFnvS8bRT3UgwPo5zmR77hSm MsF3vEy/4+ZUarvyBpmOw== Archived-At: http://mailarchive.ietf.org/arch/msg/json/40tcWoG6WADq9132IGi5-d7k4kk Subject: Re: [Json] JSON encodings X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Apr 2014 12:44:08 -0000 On 2014-04-30 12:18, Willem Bogaerts wrote: > ... Willem, application/json doesn't have a charset parameter, and never had one. We had long discussions about what encodings should be allowed, and how to detect them. I recommend that you have a look at the mailing list archives of the last ~6 months. Best regards, Julian From nobody Wed Apr 30 10:20:46 2014 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81BF1A092E; Wed, 30 Apr 2014 10:20:37 -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 i-dIBOB1KWXO; Wed, 30 Apr 2014 10:20:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D04A1A0919; Wed, 30 Apr 2014 10:20:32 -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.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140430172032.2452.93701.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 10:20:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/json/8X5uhz9ObnPaUYhz0krJLwZkMN0 Cc: json@ietf.org Subject: [Json] I-D Action: draft-ietf-json-i-json-00.txt X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 17:20: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-00.txt Pages : 5 Date : 2014-04-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-00 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 Wed Apr 30 10:29: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 B1D511A092E for ; Wed, 30 Apr 2014 10:29: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 utYZFJwlTnt4 for ; Wed, 30 Apr 2014 10:29:01 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id E81CC1A0798 for ; Wed, 30 Apr 2014 10:29:00 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id pa12so1572127veb.40 for ; Wed, 30 Apr 2014 10:28: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:from:date :message-id:subject:to:content-type; bh=XW+jipFMhaIjDa2Kk5TNVgSuGry68hQBtLq5aRS3IXs=; b=UpJmCb7Jg50VuTVmXOkfzm6PDZwhy5yWhvodUxft17zNlgZGOPbT2dZyuOps1Dj9W6 nlClN5r5T/4lvporR+hm3LQ99H9ExLzSkr+j5iSKRIpYBMqIVXjkCHay2R6f9eVoAyez QJ++YkFu+V7S0Ir2PhXvXvUqmELzooCbG4jEFgNmNpcrBOY80RLWd9ZDyc5ryRSwhjeC VIFKqCSwEgFWpjFwr6TSeXvYDDn3AETH05DiQ+rdLqQQKfK0Jm8jKaqmpQJyKCuXzRtz blTKhcJfLFFf4IMXuUUJWh56UhlgftJJy1Sp/BpTRBmRGoXHm7tVpBj+5DCkarfOqpkG ReSw== X-Gm-Message-State: ALoCoQmlq6D+jmFz6qXnDzhu0n7v8hO5dP9Ml4/FDnbdxnR4wXB2NvFD9EZFz47luzIELWHA9SKK X-Received: by 10.58.122.164 with SMTP id lt4mr4718128veb.2.1398878938099; Wed, 30 Apr 2014 10:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.73 with HTTP; Wed, 30 Apr 2014 10:28:38 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <20140430172032.2452.93701.idtracker@ietfa.amsl.com> References: <20140430172032.2452.93701.idtracker@ietfa.amsl.com> From: Tim Bray Date: Wed, 30 Apr 2014 10:28:38 -0700 Message-ID: To: "json@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2ed2553089c904f845e259 Archived-At: http://mailarchive.ietf.org/arch/msg/json/zhwrfVfZO8AO_Ipf7JWYJEa-Q4k Subject: Re: [Json] I-D Action: draft-ietf-json-i-json-00.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, 30 Apr 2014 17:29:02 -0000 --047d7b2ed2553089c904f845e259 Content-Type: text/plain; charset=UTF-8 A nice HTML version may be found at https://www.tbray.org/tmp/draft-ietf-json-i-json-00.html On Wed, Apr 30, 2014 at 10:20 AM, 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-00.txt > Pages : 5 > Date : 2014-04-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-00 > > > 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 > --047d7b2ed2553089c904f845e259 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A n= ice HTML version may be found at=C2=A0https://www.tbray.org/tmp/draft-ietf-json-i= -json-00.html


On Wed,= Apr 30, 2014 at 10:20 AM, <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-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-04-30

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


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

--047d7b2ed2553089c904f845e259-- From nobody Wed Apr 30 11:45: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 07DC81A885F for ; Wed, 30 Apr 2014 11:45:22 -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 rDlWjbq6WQHw for ; Wed, 30 Apr 2014 11:45:21 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BE1B41A094A for ; Wed, 30 Apr 2014 11:45:08 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id kp14so2389433pab.19 for ; Wed, 30 Apr 2014 11:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=F5QoCx4ijp4V5mDo3KEsE8SIskQ8a6Srh8QVpmmcs6E=; b=Iosp98SKZrUpspFi8sTo8nLF8oYVEqnkoovLBOPlSJOLP2l1KiIKlDAwI3YlzjYebG NzHvAAyAu72p6LYli8B9FF1tkKMC7KGwqRVkafiKnRcR0ha6bLJDqcp6+CMa0+xVEHY5 7k9TBiA3WrYDx3vq6mnNApiXau6hFF4AeWnV1WuDnwxE992iPo1pauE43Sq2CwZdWc/D quZUV1JQlFbxnAZQgLmAWSHbLrfF1lKJy78asINVhjGB+rnG91+fBPCMkObmL6yibGfL PqEiZkECyypo0Ux2fd1xyf2HUz5HJ/dM7HEMhTRl4LYsG5T8BKZT+KAkJ77EIDRCWL0k 8gdg== X-Received: by 10.66.248.228 with SMTP id yp4mr11637568pac.94.1398883506048; Wed, 30 Apr 2014 11:45:06 -0700 (PDT) MIME-Version: 1.0 Sender: cromis@gmail.com Received: by 10.70.11.133 with HTTP; Wed, 30 Apr 2014 11:44:45 -0700 (PDT) In-Reply-To: References: <535EB119.4000908@cisco.com> <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com> From: Jacob Davies Date: Wed, 30 Apr 2014 11:44:45 -0700 X-Google-Sender-Auth: UQ4QLb_H6SYZ61gJI7N4KUUZBBs 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/WEM68NGZBkpDSN06nJOSSKfhxDU Cc: "Manger, James" , IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Apr 2014 18:45:22 -0000 On Tue, Apr 29, 2014 at 8:40 PM, Tim Bray wrote: > I=E2=80=99m sorry, but the central idea of I-JSON is to explicitly rule o= ut all the > interoperability problems identified in RFC7159: How to produce > maximally-interoperable JSON. 7159 specifically says that for > interoperability a JSON Text should be an object or array, and the idea o= f > making I-JSON less constraining totally defeats its purpose. This is jus= t > not a reasonable direction to be going. Well, a lot of people disagree here. I also think the interop advice regarding top-level objects & arrays in 7159 was silly. It is not a significant interoperability problem, and in fact requiring that an "I-JSON profile" parser reject anything but objects and arrays would make I-JSON the one with the interoperability problem given that everyone else will happily be exchanging primitives at top-level. The real interoperability problem with this rule in the original spec was that everyone ignored it. From nobody Wed Apr 30 12:03: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 D6A361A887E for ; Wed, 30 Apr 2014 12:03:11 -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] 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 rVG64C26cblW for ; Wed, 30 Apr 2014 12:03:10 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 843C71A8867 for ; Wed, 30 Apr 2014 12:03:10 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 1FA8A778071 for ; Wed, 30 Apr 2014 12:03: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:content-transfer-encoding; s= cryptonector.com; bh=m73c4HazvHp90V117bH/7GvwJnw=; b=GJ4MCrH/pyr e+rkuSp96Nr32GTHvgiOJfGI7VciOTm7KiHxee3jB12N8HxrkvPwRammcFOPG5P+ usbKgTQGXLwwDtY7EHiTlH4I7cHne7tD+FdwLbY8gn6MkudYGnuOpqsSnf6B1cKR hmJoKhfgqPScBCJlIK9zGSETgB3Kksig= 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-a36.g.dreamhost.com (Postfix) with ESMTPSA id C7330778057 for ; Wed, 30 Apr 2014 12:03:08 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so2104965wes.4 for ; Wed, 30 Apr 2014 12:03:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.62.176 with SMTP id z16mr3385568wjr.67.1398884587320; Wed, 30 Apr 2014 12:03:07 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 30 Apr 2014 12:03:07 -0700 (PDT) In-Reply-To: References: <535EB119.4000908@cisco.com> <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 30 Apr 2014 14:03:07 -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/_EjEBoqGxq-khlHWCF6__TbP3QU Cc: "Manger, James" , IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Apr 2014 19:03:12 -0000 On Tue, Apr 29, 2014 at 10:40 PM, Tim Bray wrote: > I=E2=80=99m sorry, but the central idea of I-JSON is to explicitly rule o= ut all the > interoperability problems identified in RFC7159: How to produce > maximally-interoperable JSON. 7159 specifically says that for > interoperability a JSON Text should be an object or array, and the idea o= f > making I-JSON less constraining totally defeats its purpose. This is jus= t > not a reasonable direction to be going. Applications that use JSON -or any other encoding system for structured data- need to agree on schema to begin with. Yes, it's true that a human can eyeball a JSON text, or a dump of ASN.1 BER/DER/CER encoded data, or..., and get a pretty good idea of the meaning of various artifacts. But by and large it's applications that consume these things, not humans. And applications, not being humans, need to agree on schemata. Usually schema signalling is done out of band, and you have dropped your earlier proposal to do I-JSON signalling in-band. Why do we need to do anything else at all regarding this? (That's not rhetorical. I want to understand just why we should do what you propose.) Extensibility of schemata is a separable issue; we should separate it. I agree that uses of JSON should generally have a default implied extensibility rule, a-la modern ASN.1 -- i.e., ignore unknown names in objects -- all objects most likely. But that has nothing to do with the top-level being an object, which is why it's separable. Nico -- From nobody Wed Apr 30 16:43: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 642E71A6F22 for ; Wed, 30 Apr 2014 16:42:14 -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 SNENdrn6-gH2 for ; Wed, 30 Apr 2014 16:42:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BD2F41A09D3 for ; Wed, 30 Apr 2014 16:42:13 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3UNg9d0022767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 16:42:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Wed, 30 Apr 2014 16:42:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <535EB119.4000908@cisco.com> <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com> To: Tim Bray X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/json/jVzukwV1-gceOmiuCAmfpW2b_8U Cc: IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Apr 2014 23:42:15 -0000 On Apr 29, 2014, at 8:40 PM, Tim Bray wrote: > I=92m sorry, but the central idea of I-JSON is to explicitly rule out = all the interoperability problems identified in RFC7159: How to produce = maximally-interoperable JSON. =20 This is a good point, and one that I forgot when I said "this isn't = needed". There are probably some parsers out there that expect the = original JSON restriction; given that, repeating the restriction here = seems fine. --Paul Hoffman= From nobody Wed Apr 30 17:40: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 ECBAA1A0981 for ; Wed, 30 Apr 2014 17:40:11 -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] 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 OsXBlQUx-KiT for ; Wed, 30 Apr 2014 17:40:10 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CBC5A1A096A for ; Wed, 30 Apr 2014 17:40:10 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 4623F10060 for ; Wed, 30 Apr 2014 17:40: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:content-transfer-encoding; s= cryptonector.com; bh=eufqkg68olKJVt/HaxuQIyzvK7g=; b=P7Tw0kS0crn +b1gNmnN2O0pZ1etQecg75fSx9yLdDSNGt5/cJM/7b1dDPPBfxS8uNdSFsq0JYgh PK27z1cl9iu4U6AnaJasG21Zk2iWj73ZgyQl5XhL8HBaUntyUDIXovmkTKgXnKjD PQmsZXzlkN/dsBOsxjOUXfsmZLypBSPk= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id EC46110059 for ; Wed, 30 Apr 2014 17:40:08 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id f8so3808448wiw.9 for ; Wed, 30 Apr 2014 17:40:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr6059120wib.42.1398904807693; Wed, 30 Apr 2014 17:40:07 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 30 Apr 2014 17:40:07 -0700 (PDT) In-Reply-To: References: <535EB119.4000908@cisco.com> <255B9BB34FB7D647A506DC292726F6E1154581E82F@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 30 Apr 2014 19:40:07 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/json/XVVu0NmjuTV5kzTHsQqQ7LRN5ak Cc: Tim Bray , IETF JSON WG Subject: Re: [Json] I-JSON Tpic #2: Top-Level X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 01 May 2014 00:40:12 -0000 On Wed, Apr 30, 2014 at 6:42 PM, Paul Hoffman wrote= : > On Apr 29, 2014, at 8:40 PM, Tim Bray wrote: > >> I=E2=80=99m sorry, but the central idea of I-JSON is to explicitly rule = out all the interoperability problems identified in RFC7159: How to produce= maximally-interoperable JSON. > > This is a good point, and one that I forgot when I said "this isn't neede= d". There are probably some parsers out there that expect the original JSON= restriction; given that, repeating the restriction here seems fine. Conceding that for the time being, the restriction to repeat was that JSON texts must be objects or arrays at the top-level, NOT just objects. Now, as to whether we should repeat that restriction, given that every parser I know of at least has an option to permit non-object/array types at the top-level, I find the interop argument wanting. If I know some application uses I-JSON, and if I know I-JSON permits any type at the top-level (supposing it were to), why would I have any trouble implementing that with existing parsers? I haven't carried out an exhausting analysis of existing parsers, and since I can't -no one can-, I might concede that point even if no one confirms the existence of any JSON parsers that don't have an option to permit any type at the top-level. For now I'm just not buying the interop argument. Nico --